Fork me on GitHub

Overview


While this site primarily discusses the reference implementation of AppSensor, this page describes any AppSensor-like system.

 

    Read the Documentation


The AppSensor Guide can be found here: [https://www.owasp.org/index.php/OWASP_AppSensor_Project]. The guide contains extensive discussions of the methodology behind AppSensor. There are various topics covered, including:

The guide is the best resource for comprehensive coverage of the AppSensor concept as well as coverage of design ideas that are not used by the reference implementation.

 

    Configure AppSensor


Any AppSensor system will need some measure of configuration and setup. One defining characteristic for any AppSensor system is the methods of analysis that are supported. While the guide describes several (behavioral, model-driven, expert-system, stochastic, etc.), the simplest and that chosen by the reference implementation is a policy-driven analysis solution. This section briefly describes the steps involved in configuring a policy upon which to base your analysis.

There are a few primary components of policy-based configuration:

We'll cover each of these briefly.

Detection Points

Detection Points (examples here) represent the specific concerns you are interested in detecting within your application. These are suspcicious activities that may trigger an attack if detected with a certain frequency (defined by the threshold). Part of policy configuration is defining the detection points that your application should be able to handle.

Thresholds

Thresholds are simple definitions used to determine the acceptable number of events over a given period of time, for a given user or group of users. An example might be:

3 IE2 events in 5 minutes for an individual user represents an attack.

There can be more complex definitions of thresholds, namely trends, but these may or may not be necessary in your system.

Responses

Responses (examples here) are actions taken as the result of detecting that a certain detection point has crossed its' configured threshold, and therefore now represents an attack. Responses allow you to handle an attack in any way you like, given policy and legal requirements. The reference implementation allows for a chained response order, in which several responses can be configured, and executed as subsequent attacks for the same detection point are registered in the system.

 

    Instrument Your System


Another key component of a functional AppSensor is the system instrumentation. In order to detect and respond to events, the application and its' surrounding components must be capable of performing the initial event detection. The AppSensor system is responsible for evaluating where an event or series of events constitutes an attack as well as finding the appropriate response for said attack. However, the initial event detection is handled outside AppSensor. There are various ways for this to occur:

Whatever mechanism or set of mechanisms you use, instrumentation is critical as detection must happen first before analysis and response can occur within the AppSensor architecture.

 

    Deploy and Monitor


The last step is deployment and monitoring. As with any production system, you must first test, then deploy your AppSensor system.

However, the AppSensor system is somewhat unique in that it is intended to be a monitored and tweaked system. The detection points, thresholds and responses should be evaluated on a regular basis for their efficacy within your environment. The AppSensor Guide provides great planning resources and details about how to perform this step effectively. The insights in the guide should allow you to grow AppSensor with your deployed system.

 

Summary


With proper planning, configuration, deployment and monitoring, AppSensor should be an extremely useful part of your infrastructure and lead to enhanced security awareness and an improved security posture.