Category:OWASP AppSensor Project
From OWASP
Click here to return to OWASP Projects page.
Click here to see (& edit, if wanted) the template.
| PROJECT IDENTIFICATION | ||||||
|---|---|---|---|---|---|---|
| Project Name | OWASP AppSensor Project - Detect and Respond to Attacks from Within the Application | |||||
| Short Project Description | 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. | |||||
| 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/No (To update) --------- See&Edit: 50% Review/1st Reviewer (C) | Objectives & Deliveries reached? Yes/No (To update) --------- See&Edit: 50%Review/2nd Reviewer (E) | X |
| Final Review | Objectives & Deliveries reached? Yes/No (To update) --------- Which status has been reached? Season of Code - (To update) --------- See&Edit: Final Review/SelfEvaluation (B) | Objectives & Deliveries reached? Yes/No (To update) --------- Which status has been reached? Season of Code - (To update) --------- See&Edit: Final Review/1st Reviewer (D) | Objectives & Deliveries reached? Yes/No (To update) --------- Which status has been reached? Season of Code - (To update) --------- See&Edit: Final Review/2nd Reviewer (F) | X |
Summer of Code 2008 Project!
Overview
As critical applications continue to become more accessible and inter-connected, it is paramount that the information be protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application. In addition to implementing layers of defense within an application, it is critical that we identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. The application itself is the best place to identify and respond to malicious activity. This project will create the framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application
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 (e.g. user-name, ip, timestamp ). Further, the AppSensor guidance will detail how all the events should be handled. Events will be sent to a centralized logging system within the application. This system collect the security events from throughout the application (e.g. authorization attacks, business logic attacks, force browsing attempts) 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, and more. Essentially, the AppSensor 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.
Project Lead
Michael Coates (mwcoates [at] gmail [dot] com)
Project Roadmap
April 16, 2008 - Project Begins
High level planning & design
Identify and define attack patterns against applications
Document points of detection within the application for the attack patterns & identify key information to log
Pier Review & Revisions
June 29, 2008 - Status Report
Create thresholds for generating security alerts
Define recommended response actions for the security alerts
Pier Review & Revisions
Aug 31, 2008 - Project Complete
This category currently contains no articles or media.
