Difference between revisions of "User:Afontes"

Latest revision as of 10:38, 18 April 2016

Hi, My name is Antonio Fontes, I am based in Geneva (Switzerland). I've been an active member of OWASP since 2008. My main objective at OWASP is supporting our Swiss national and local chapters and making sure our members get all the support they need to better interact with OWASP.

I also spend some time doing research work on some topics in direct relation with application security. These projects include:

Core programming skills: involves an empirical approach at identifying the core knowledge/skills that developers should learn during their initial training to immediately produce more resilient code. The project started in 2012, field testing with developers started in 2014 and we are collecting feedback to improve the list. The list now contains 9 items. The main project deliverable is a training slides deck that will be made available to teachers and trainers involved in software programming without strong emphasis on security.
Software intrusion patterns: involves identifying the root categories of attack patterns implemented by hackers and fraudsters in order to get leverage within software. The objective is to reach an exhaustive system that allows for more sophisticated threat identification (during the threat modelling process) than the reference STRIDE model. This research involves several appsec professionals and our latest model contains 6 items. The project deliverable is the list.
Threat Modelling - catalogue-centric approach: the main objective of this project is to accelerate one particular phase of the threat modelling process: the threat identification. The project involves creating a reference catalogue of threats, which may independently apply to certain types of software and defining a process for the selection of applicable and relevant threats within this catalogue. The process is currently under use and testing within some organizations. After a few iterations, the method will be published under OWASP (probably around mid-2017). The project deliverables includes the threat catalogue and a document explaining the process for deriving security targets from protection profiles (similar to the Common Criteria process).

You can reach me by e-mail at [email protected] or on twitter at @starbuck3000 for more information.

@@ Line 1: / Line 1: @@
-= Info =
+Hi,
-LARGO.2 project support page.<br/>
+My name is Antonio Fontes, I am based in Geneva (Switzerland). I've been an active member of OWASP since 2008. My main objective at OWASP is supporting our Swiss national and local chapters and making sure our members get all the support they need to better interact with OWASP.<br/>
-Note to viewers:
-* Please do not edit this page. Use the discussion tab if necessary (I'm watching this)
-* You can contact me through twitter (@starbuck3000) or email ([email protected]) for private inquiries
-= Objective =
+I also spend some time doing research work on some topics in direct relation with application security. These projects include:
-Accelerate and improve the efficiency of the threat modeling activity by submitting an initial list of common (generic) threats to the application. (see LARGO.2 Threat Modeling process)
+* ''Core programming skills'': involves an empirical approach at identifying the core knowledge/skills that developers should learn during their initial training to immediately produce more resilient code. The project started in 2012, field testing with developers started in 2014 and we are collecting feedback to improve the list. The list now contains 9 items. The main project deliverable is a training slides deck that will be made available to teachers and trainers involved in software programming without strong emphasis on security.
+* ''Software intrusion patterns'': involves identifying the root categories of attack patterns implemented by hackers and fraudsters in order to get leverage within software. The objective is to reach an exhaustive system that allows for more sophisticated threat identification (during the threat modelling process) than the reference STRIDE model. This research involves several appsec professionals and our latest model contains 6 items. The project deliverable is the list.
+* ''Threat Modelling - catalogue-centric approach'': the main objective of this project is to accelerate one particular phase of the threat modelling process: the threat identification. The project involves creating a reference catalogue of threats, which may independently apply to certain types of software and defining a process for the selection of applicable and relevant threats within this catalogue. The process is currently under use and testing within some organizations. After a few iterations, the method will be published under OWASP (probably around mid-2017). The project deliverables includes the threat catalogue and a document explaining the process for deriving security targets from protection profiles (similar to the Common Criteria process).
-= Next steps =
+You can reach me by e-mail at antonio.fontes@owasp.org or on twitter at @starbuck3000 for more information.
-* round 3 review.
-* QA -> compliance match with OWASP Top 10 2010
-* QA -> compliance match with OWASP Top 10 2013
-* QA -> compliance match with OWASP ASVS
-* QA -> compliance match with WASC threat enumeration
-* QA -> compliance match with CWE Top 25
-* round 4 review.
-* for each threat, describe
-* for each threat, identify symptomatic behavior and/or common culprits
-* for each threat, document recommendations to achieve L1-compliance
-* for each threat, document recommendations to achieve L2-mitigation
-* for each threat, document recommendations to achieve L3-detection
-* for each threat, document recommendations to achieve L4-countermeasures
-* round 5 review.
-* release
-= Methodology =
-The identification of generic (non-business related) threats to HTTP-applications can be performed through several methodologies:
-* Attacker-centric (ARC) threat identification: devising threats based on a list of threat agents and their resources/capabilities.
-* Attack-centric (AKC) threat identification: devising threats based on a list of attack techniques known by the industry (i.e.: the Top 10 Web applications security risks, by the Open Web Application Security Project).
-* Attack-pattern-centric (APC) threat identification: devising generic threats to a particular subset of applications, based on the list of fundamental systems intrusion threat patterns (i.e.: injection pattern).
-* Weakness-centric (WEC) threat identification (devising threats based on a list of known software weaknesses (i.e.: Software attacks and weaknesses, by the Web Application Security Consortium)
-* Asset-centric (ASC) threat identification: devising threats based on the actual and perceived value of the components/assets involved in or around the application.
-* Standard or policy-based (STC) threat identification: devising threats based on a pre-defined set of threats.
-* etc.
-In the context of L.2 project, the APC process was chosen to identify the list of threats to be considered in all HTTP-based applications.
-= Software attack patterns =
-Software is exposed to five adverse behaviors, either by systems or by direct human interaction, which can be summarized as follows:
-* Pattern 1: observation
-* Pattern 2: tampering
-* Pattern 3: bruteforcing
-* Pattern 4: denial of service
-* Pattern 5: reverse engineering
-The attentive reader may argue that the reverse engineering attack pattern is a subset of the observation pattern. While this would be fully accepted under an academical environment, economics of software security required us to differentiate behaviors that rely solely on the simple observation of "things" from cases where the attacker would invest resources (time, money, acquisition of knowledge, licenses or hardware acquisition) in order to understand what she observes.
-== Observation pattern ==
-The observation pattern includes all threats involving an interception or collection of data whether while in-transit (i.e.: interception of network communications) or at-rest (i.e.: direct access to datastores, configuration settings, etc.).
-== Tampering pattern ==
-The tampering pattern includes all threats resulting from the client-server query-response architecture pattern, under which an attacker has both the ability to submit forged or tampered queries to the system and to observe its subsequent response (feedback).
-== Bruteforcing pattern ==
-The bruteforcing pattern includes all threats resulting from an attacker investing resources in submitting a large set of queries that contain discrete variations to one or more components of the system (i.e.: password bruteforcing).
-== Denial of service pattern ==
-The denial of service pattern includes all threats resulting from the identification of, and interaction with, architecture components, whose invocation or inner-attributes do not solely/exclusively depend on the size of the client population.
-== Reverse engineering pattern ==
-The reverse engineering pattern includes all threats resulting from careful scrutiny and/or examination of one or more components or assets, that are part of the system and made available to a potential attacker (i.e.: hardware, source code, algorithms, etc.).
-== Threats to HTTP-applications ==
-The tentative list below aims at enumerating 2nd level generic threats to which '''all''' HTTP-applications may be/are exposed:
--- observation and interception threats<br/>
-Interception, of sensitive data while in transit<br/>
-Interception, of credentials while in transit<br/>
-Observation, of error messages<br/>
-Observation, of HTTP response status codes<br/>
-Observation, of HTTP headers in responses<br/>
-Observation, of session identifiers<br/>
-Observation, of usernames<br/>
-Observation, of authentication error messages<br/>
-Observation, of the account recovery tokens<br/>
-Direct access, to credentials, server-side<br/>
-Direct access, to configuration settings, server-side<br/>
-Direct access, to access control lists, server-side<br/>
-Direct access, to cached objects, client-side<br/>
-Direct access, to cached objects, on a proxy<br/>
-Direct access, to source code<br/>
-<br/>
--- injection and tampering threats<br/>
-Injection, of invalid data into requests<br/>
-Injection, of filter-evading data into requests<br/>
-Injection, of active client-side data into requests<br/>
-Injection, of invalid or hostile files<br/>
-Injection, of user-generated session identifiers<br/>
-Tampering, of server-side configuration<br/>
-Tampering, of server-side access control lists<br/>
-Tampering, of cookies (non-session)<br/>
-Tampering, of session identifier cookies<br/>
-Tampering, of parameter validation code in responses<br/>
-Tampering, of hidden fields submitted as form-data<br/>
-<br/>
--- reverse engineering<br/>
-Reverse engineering, of tokens user for session identification<br/>
-Reverse engineering, of tokens used for account recovery<br/>
-Reverse engineering, of cryptographic authentication code<br/>
-Reverse engineering, of symetric encryption code<br/>
-Reverse engineering, of asymetric encryption code<br/>
-Reverse engineering, of parameter sanitization code<br/>
-Reverse engineering, of parameter validation code<br/>
-<br/>
--- bruteforcing<br/>
-Sequencing, of resource identifiers submitted in requests<br/>
-Bruteforcing, of resource identifiers submitted in requests<br/>
-Bruteforcing, of passwords through the authentication console<br/>
-Bruteforcing, of passwords through the passwords database<br/>
-<br/>
--- denial of service<br/>
-Lockout, of user accounts<br/>
-Submission, of large inputs (parameters, files, etc.)<br/>
-Submission, of large number of queries without session identifier<br/>
-Susmission, of large number of authenticated sessions<br/>
-Submission, of large values on parameters that induce memory allocation

Difference between revisions of "User:Afontes"

Latest revision as of 10:38, 18 April 2016

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Tools