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 "Project Information:template AppSensor Project"

From OWASP
Jump to: navigation, search
Line 6: Line 6:
 
  |-
 
  |-
 
  | style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''  
 
  | style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''  
  | colspan="6" style="width:85%; background:#cccccc" align="left"|The goal of this project is to create the standard and guidance for how an application should detect, log and respond to malicious events. The deliverable for this project will be a framework of information which would be used by an application architect during the design of the system itself. This project would not create a tool or any code. Instead, it will build upon many of the IDS concepts developed in ESAPI and move towards a fully developed Application IDS Framework Standard. For example, when an architect considers the design of their authentication system (or any other critical system) they would reference the AppSensor guidelines on authentication. The AppSensor guidance will indicate what sort of authentication actions need to be logged (failed login attempt, use of multiple user-names from a single IP, high rate of login attempts etc) and what information must be captured (user-name, ip, timestamp etc). Further, the AppSensor guidance will detail how all the events should be handled. Events will have different severities and will be sent to a centralized logging system within the application. This system collect the security events from throughout the application (authorization attacks, business logic attacks, force browsing attempts etc) and will then be able to take appropriate action against the user. This could include locking out an account, generating alerts to sys-admins, shutting down portions of the application, etc. Essentially, my project is defining how an Intrusion Detection System should be designed, configured and built into the code of any custom application. By building the Application Level IDS within the application itself, we are in the best place to capture and respond to all malicious actions performed against the application.  
+
  | colspan="6" style="width:85%; background:#cccccc" align="left"|
 +
'''Overview'''
 +
 
 +
The AppSesnsor document is a conceptual framework that offers prescriptive guidance to implement intrusion detection capabilities into existing application utilizing standard security controls and recommendations for automated response policies based upon detected behaviour. When using AppSensor, an application will be able to identify malicious users whithin the application and eliminate the threat by taking response action such as logging out the user, locking the account or notifying an admnistrator. 
 +
 
 +
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.
 +
 
 +
'''A bit more detail'''
 +
 
 +
The goal of this project is to create the standard and guidance for how an application should detect, log and respond to malicious events. The deliverable for this project will be a framework of information which would be used by an application architect during the design of the system itself. This project would not create a tool or any code. Instead, it will build upon many of the IDS concepts developed in ESAPI and move towards a fully developed Application IDS Framework Standard. For example, when an architect considers the design of their authentication system (or any other critical system) they would reference the AppSensor guidelines on authentication. The AppSensor guidance will indicate what sort of authentication actions need to be logged (failed login attempt, use of multiple user-names from a single IP, high rate of login attempts etc) and  
 +
 
 +
what information must be captured (user-name, ip, timestamp etc). Further, the AppSensor guidance will detail how all the events should be handled. Events will have different severities and will be sent to a centralized logging system within the application. This system collect the security events from throughout the application (authorization attacks, business logic attacks, force browsing attempts etc) and will then be able to take appropriate action against the user. This could include locking out an account, generating alerts to sys-admins, shutting down portions of the application, etc. Essentially, my project is defining how an Intrusion Detection System should be designed, configured and built into the code of any custom application. By building the Application Level IDS within the application itself, we are in the best place to capture and respond to all malicious actions performed against the application.  
 
  |-
 
  |-
 
  | style="width:15%; background:#7B8ABD" align="center"|'''Email Contacts'''
 
  | style="width:15%; background:#7B8ABD" align="center"|'''Email Contacts'''
Line 22: Line 33:
 
The first draft of the AppSensor Project has been distributed to reviewers. Feedback has been received and updated.
 
The first draft of the AppSensor Project has been distributed to reviewers. Feedback has been received and updated.
  
The beta draft has been distributed to reviewers. Feedback has been received and updated.
+
The second draft has been distributed to reviewers. Feedback has been received and updated.
  
 
'''AppSensor Beta Release Now Available!'''
 
'''AppSensor Beta Release Now Available!'''

Revision as of 10:29, 6 November 2008

PROJECT IDENTIFICATION
Project Name OWASP AppSensor Project - Detect and Respond to Attacks from Within the Application
Short Project Description

Overview

The AppSesnsor document is a conceptual framework that offers prescriptive guidance to implement intrusion detection capabilities into existing application utilizing standard security controls and recommendations for automated response policies based upon detected behaviour. When using AppSensor, an application will be able to identify malicious users whithin the application and eliminate the threat by taking response action such as logging out the user, locking the account or notifying an admnistrator.

An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

A bit more detail

The goal of this project is to create the standard and guidance for how an application should detect, log and respond to malicious events. The deliverable for this project will be a framework of information which would be used by an application architect during the design of the system itself. This project would not create a tool or any code. Instead, it will build upon many of the IDS concepts developed in ESAPI and move towards a fully developed Application IDS Framework Standard. For example, when an architect considers the design of their authentication system (or any other critical system) they would reference the AppSensor guidelines on authentication. The AppSensor guidance will indicate what sort of authentication actions need to be logged (failed login attempt, use of multiple user-names from a single IP, high rate of login attempts etc) and

what information must be captured (user-name, ip, timestamp etc). Further, the AppSensor guidance will detail how all the events should be handled. Events will have different severities and will be sent to a centralized logging system within the application. This system collect the security events from throughout the application (authorization attacks, business logic attacks, force browsing attempts etc) and will then be able to take appropriate action against the user. This could include locking out an account, generating alerts to sys-admins, shutting down portions of the application, etc. Essentially, my project is defining how an Intrusion Detection System should be designed, configured and built into the code of any custom application. By building the Application Level IDS within the application itself, we are in the best place to capture and respond to all malicious actions performed against the application.

Email Contacts Project Leader
Michael Coates
Project Contributors
(if applicable)
Name&Email
Mailing List/Subscribe
Mailing List/Use
First Reviewer
Eric Sheridan
Second Reviewer
Randy Janinda
OWASP Board Member
(if applicable)
Name&Email
PROJECT MAIN LINKS

The first draft of the AppSensor Project has been distributed to reviewers. Feedback has been received and updated.

The second draft has been distributed to reviewers. Feedback has been received and updated.

AppSensor Beta Release Now Available!

AppSensor Beta Release 1.0

SPONSORS & GUIDELINES
Sponsor - OWASP Summer of Code 2008 Sponsored Project/Guidelines/Roadmap
ASSESSMENT AND REVIEW PROCESS
Review/Reviewer Author's Self Evaluation
(applicable for Alpha Quality & further)
First Reviewer
(applicable for Alpha Quality & further)
Second Reviewer
(applicable for Beta Quality & further)
OWASP Board Member
(applicable just for Release Quality)
50% Review Objectives & Deliveries reached?
YES
---------
See&Edit:50% Review/Self-Evaluation (A)
Objectives & Deliveries reached?
YES
---------
See&Edit: 50% Review/1st Reviewer (C)
Objectives & Deliveries reached?
YES
---------
See&Edit: 50%Review/2nd Reviewer (E)
X
Final Review Objectives & Deliveries reached?
YES


---------
Which status has been reached?
Beta
Season of Code - 2008
---------
See&Edit: Final Review/SelfEvaluation (B)

Objectives & Deliveries reached?
YES


---------
Which status has been reached?
Beta
Season of Code - 2008
---------
See&Edit: Final Review/1st Reviewer (D)

Objectives & Deliveries reached?
YES


---------
Which status has been reached?
Beta
Season of Code - 2008
---------
See&Edit: Final Review/2nd Reviewer (F)

X