This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "AppSensor Cheat Sheet"

From OWASP
Jump to: navigation, search
(Concept)
(Completely rewritten to match the introduction for developers)
Line 1: Line 1:
= Concept =
+
= What Is AppSensor? =
 +
AppSensor provides real-time application-layer attack detection and response. AppSensor:
  
The idea is to detect suspicious and malicious behavior by a user within an application, by identifying typical things that attackers would do but normal users could not possibly do, even by accident, and then taking action by for example logging them out or locking their account. Unacceptable behavior could include unauthorized scraping of content, searching for vulnerabilities, and attempts undertake fraud.
+
* Detects attackers, not vulnerabilities
 +
* Is application-specific, not generic
 +
* Does not use signatures, or try to predict anything
 +
* Allows applications to adapt and respond in real-time to� an identified attacker
 +
* Stops and/or reduces the impact of an attack
 +
* Provides visibility and security intelligence into your� applications.
  
= Introduction =
+
A single instance of AppSensor can support multiple client applications at the same time, and could aggregate attacker knowledge by, for example, correlation using SSO.
  
All users make mistakes, but attackers also perform actions that the user interface doesn't offer or are impossible to do without using tools like intercepting proxies. The AppSensor concept describes how to make applications attack-aware.
+
=Why Should I Use It?=
  
AppSensor will:
+
There are many security protections available to applications today. Many are at the host or network layer, and are not directly accessible to, or even known by, the application itself. Application level protections are generally focused around secure software development processes.
  
* Identify whether your application is under attack in real time
+
The AppSensor approach is implemented in the place where the most information is available to make the best security decisions: within the application itself. It also is implemented by the people with the most application context: developers and architects.
* Optionally initiate an immediate response action to protect the application and its data
 
  
AppSensor does not:
+
This leads to far greater accuracy and flexibility than many other application defence approaches.
  
* Implement error handling for you (although detection points are often inherently linked with error handling code)
+
= How Do I Use It?=
* Perform application security logging (but logging mechanisms could be used to record detected events)
 
* Protect you if you have existing vulnerabilities (fix known vulnerabilities and implement secure-SDLC activities to avoid new ones)
 
  
Where possible implement the recommendations in the other cheat sheets as thoroughly as possible first, before considering the ideas within AppSensor. Robust error handling mechanisms and security event logging should already be part of  well designed quality software.
+
==Policy Configuration==
  
= Purpose =
+
There are few steps to get setup using AppSensor. The first step is to configure your detection and response policy. You will build a configuration that has a number of business-justified descriptions such as:
  
Attackers take a finite number of attempts to find vulnerabilities, and additional attempts to craft an exploit. This may be scores or hundreds of attempts; or tens or hundreds of thousands if using automated tools. If you can detect some of these steps, you identify an attack and take some immediate action.
+
3 Insufficient Authorization events in 5 minutes for an individual user represents an attack. I want to respond by blocking the user account.
  
Distribute detection points in the application to detect very suspicious and blatantly malicious use
+
Collectively, these descriptions will define your policy for automated attack analysis and real-time response.
  
Collect these event event data
+
==Application Instrumentation==
  
Define a very low tolerance threshold, and take a predefined automated action once a user exceeds the limits of reasonable use
+
Once the policy is created, you must place “detection points” that notify AppSensor of suspicious events. These might be done individually or using AOP, or even done with an external tool or process of some kind. Some example pseudo-code is below:
  
= Pre-requisities =
+
if ( isUserAuthorized( account ) ) {
 +
      // present/view account
 +
} else {
 +
    //new code for appsensor
 +
    appSensor.addEvent( logged_in_user, “INSUFFICIENT_AUTHORIZATION” )
 +
}
  
* application that is fully tested (e.g. functional, stress) since the AppSensor concet relies on detecting abnormal behavior, and errors in an application could be misinterpredted
+
Now, when a user attempts to access an account for which he is not authorized, the application notifies AppSensor and the event is tracked. If AppSensor determines the defined policy (e.g. 3 events in a span of 5 minutes) has been crossed, it is considered to be an attack. At that point, AppSensor executes the response, in this case an account lockout for the user.
* secure application (using a secure development life cycle) to minimize the existence of unknown weaknesses
 
  
 +
==Runtime Monitoring==
  
 +
Once the configuration is complete and the application is instrumented to signal events to AppSensor, the last step is to monitor the state of the running application. While AppSensor does provide an automated means of detection and response, monitoring the activity gives great visibility into the runtime state of the system. The intelligence you obtain from monitoring will lead to policy changes, new detection points, and new requirements for your system.
  
= What to detect =
+
=Code, documentation and tips=
 
 
It is very important not to make detection overly complex, and vital not to include events which could be triggered by normal, even accidental, behavior.
 
 
 
The most commonly implemented detection points are exceptions relating to:
 
 
 
*
 
* access control (e.g. a user attempting to access a resource they do not have permission to)
 
* whitelist input validation (e.g. non-numerical characters for a non-editable parameter value that is expected to be a positive non-zero integer)
 
 
 
 
 
= How to respond =
 
 
 
Legally. Policy.
 
 
 
Thresholds:
 
 
 
*
 
*
 
*
 
 
 
Typical responses, that the application may already support in some manner, are:
 
 
 
* Change monitoring of the user (e.g. increase logging level)
 
* Raise an alert
 
* Add time delays
 
* Log a user out (and possibly lock the account)
 
 
 
More advanced responses could include
 
 
 
*
 
* Changing a function (adding a CAPTCHA, ??? )
 
* Disabling a function (for the user, for a group of users, for all users)
 
* Affecting behaviour of another systems (e.g. goods despatch held, firewall blocks IP address)
 
* Altering user properties (changing their credit level)
 
 
 
 
 
 
 
= How to =
 
 
 
== Software acquisition ==
 
 
 
== In your own code ==
 
 
 
 
 
 
 
 
 
== No code available ==
 
 
 
Watch out for
 
 
 
 
 
 
 
= Related articles =
 
 
 
Other [http://www.jtmelton.com/2012/05/01/year-of-security-for-java-week-18-perform-application-layer-intrusion-detection/ Year of Security for Java Week 18 - Perform Application Layer Intrusion Detection ]
 
  
 +
http://www.appsensor.org
  
 
= Authors and primary contributors =
 
= Authors and primary contributors =
  
 
+
John Melton
 
+
Colin Watson
Colin Watson - colin.watson[at]owasp.org
 
 
 
 
 
  
  

Revision as of 13:03, 19 May 2015

What Is AppSensor?

AppSensor provides real-time application-layer attack detection and response. AppSensor:

  • Detects attackers, not vulnerabilities
  • Is application-specific, not generic
  • Does not use signatures, or try to predict anything
  • Allows applications to adapt and respond in real-time to� an identified attacker
  • Stops and/or reduces the impact of an attack
  • Provides visibility and security intelligence into your� applications.

A single instance of AppSensor can support multiple client applications at the same time, and could aggregate attacker knowledge by, for example, correlation using SSO.

Why Should I Use It?

There are many security protections available to applications today. Many are at the host or network layer, and are not directly accessible to, or even known by, the application itself. Application level protections are generally focused around secure software development processes.

The AppSensor approach is implemented in the place where the most information is available to make the best security decisions: within the application itself. It also is implemented by the people with the most application context: developers and architects.

This leads to far greater accuracy and flexibility than many other application defence approaches.

How Do I Use It?

Policy Configuration

There are few steps to get setup using AppSensor. The first step is to configure your detection and response policy. You will build a configuration that has a number of business-justified descriptions such as:

3 Insufficient Authorization events in 5 minutes for an individual user represents an attack. I want to respond by blocking the user account.

Collectively, these descriptions will define your policy for automated attack analysis and real-time response.

Application Instrumentation

Once the policy is created, you must place “detection points” that notify AppSensor of suspicious events. These might be done individually or using AOP, or even done with an external tool or process of some kind. Some example pseudo-code is below:

if ( isUserAuthorized( account ) ) {
     // present/view account
} else {
    //new code for appsensor
   appSensor.addEvent( logged_in_user, “INSUFFICIENT_AUTHORIZATION” )
}

Now, when a user attempts to access an account for which he is not authorized, the application notifies AppSensor and the event is tracked. If AppSensor determines the defined policy (e.g. 3 events in a span of 5 minutes) has been crossed, it is considered to be an attack. At that point, AppSensor executes the response, in this case an account lockout for the user.

Runtime Monitoring

Once the configuration is complete and the application is instrumented to signal events to AppSensor, the last step is to monitor the state of the running application. While AppSensor does provide an automated means of detection and response, monitoring the activity gives great visibility into the runtime state of the system. The intelligence you obtain from monitoring will lead to policy changes, new detection points, and new requirements for your system.

Code, documentation and tips

http://www.appsensor.org

Authors and primary contributors

John Melton Colin Watson


OWASP Cheat Sheets Project Homepage