d271633cd524aaf76535e675f4b14c9c.ppt
- Количество слайдов: 41
Attack Detection and Prevention with OWASP App. Sensor Colin Watson Hall Ltd colin @ watsonhall. com
OWASP App. Sensor
App. Sensor • Established Summer 2008 • Presented at multiple conferences in US & Europe • Recent video presentations by Michael Coates • Real Time Application Defenses - The Reality of App. Sensor & ESAPI http: //vimeo. com/15726323 • Automated Application Defenses to Thwart Advanced Attackers http: //michael-coates. blogspot. com/2010/06/online-presentation-thursdayautomated. html • Application Based Intrusion Detection highlighted in OWASP Top Ten 2010 “What’s Coming”
App. Sensor Team • Core team: • Michael Coates • John Melton • Colin Watson • Contributors: • Ryan Barnett • Simon Bennetts • August Detlefsen • Randy Janida • Jim Manico • Giri Nambari • Eric Sheridan • John Stevens • Kevin Wall
App. Sensor concepts
Add App. Sensor to your own applications • Build it into requirements • Develop your own • ESAPI • App. Sensor integration into Java ESAPI imminent • Security Information/Event Management • Add detection points into application • Integrate logging into real time monitor
App. Sensor detection points • A detection point is a highly-tuned “instrumentation” sensor (within the application’s code) and used to identify a particular type of suspicious or malicious activity • Over 50 detection points • 12 exception types • 9 signature based (request, authentication, session, etc) • 3 behavior based (user, system, reputation) • Latest list of detection points with descriptions, considerations and examples is maintained at: http: //www. owasp. org/index. php/App. Sensor_Detection. Points
Detection point exception types “limiting each session to the TRACE IP failed authentication “blocking requests using a after multipleaddress” • “locking a user account particular HTTP method” attempts”
App. Sensor response actions • Response actions describe a change to the application’s behavior • 14 response actions • Many ways to categorize them, including: • Effect on user / application • Target of response • Duration of response • Latest list of response actions with descriptions, considerations and examples is maintained at: http: //www. owasp. org/index. php/App. Sensor_Response. Actions
Response actions from the user’s viewpoint
Implementation planning methodology 1. Preliminary requirements 2. Detection point selection 3. Response action selection • Then • Procure/develop • Deploy • Verify • Monitor and tune
1. Preliminary requirements
1 a) Application risk assessment • Many alternative methods and processes: • http: //www. whitehouse. gov/sites/default/files/omb/memoranda/fy 04/m 04 -04. pdf • http: //csrc. nist. gov/publications/nistpubs/800 -30/sp 800 -30. pdf • http: //csrc. nist. gov/publications/fips 199/FIPS-PUB-199 -final. pdf • http: //www. sans. org/reading_room/whitepapers/auditing/introduction-information -system-risk-management_1204 • http: //www. owasp. org/index. php/OWASP_Risk_Rating_Methodology • http: //www. owasp. org/index. php/Threat_Risk_Modeling • http: //www. nr. no/~abie/Risk. Analysis. htm • Application risk ranking
1 b) Secure coding (and deployment) • Build the application securely • Governance • Construction • Verification • Deployment • Software Assurance Maturity Model http: //www. owasp. org/index. php/Category: Software_Assurance_Maturity_Model • Application Security Verification Standard http: //www. owasp. org/index. php/ASVS • OWASP Development, Code Review and Testing Guides • OWASP Secure Coding Practices Quick Reference Guide
1 c) Application logging • How to Do Application Logging Right Anton Chuvakin and Gunnar Peterson, IEEE Security & Privacy Journal http: //arctecgroup. net/pdf/howtoapplogging. pdf • Securosis Blog - Monitoring Up the Stack series http: //securosis. com/blog/monitoring-up-the-stack-app-monitoring-part-1 http: //securosis. com/blog/monitoring-up-the-stack-app-monitoring-part-2 • OWASP App. Sensor. Demo 2 Intrusion Store (HSQLDB) http: //code. google. com/p/appsensor/source/browse/#svn/trunk/App. Sensor. Demo 2 • OWASP ESAPI Java Edition documentation http: //code. google. com/p/owasp-esapi-java/ • Preventing Log Forging in Java http: //www. jtmelton. com/2010/09/21/preventing-log-forging-in-java/ • NIST SP 800 -92 Guide to Computer Security Log Management http: //csrc. nist. gov/publications/nistpubs/800 -92/SP 800 -92. pdf
2. Detection point selection
2 a) Categorization • • • Exception types Signature or behavior based Suspicious events or attacks Outcome/result of the request, or request properties Classes: • Discrete • Generic pre-processing • Business layer • Aggregating • Modifying
2 a) Categorization (continued)
2 b) Requirements • Approaches: • Classes • Discrete • Generic pre-processing • Business layer • Aggregating • Modifying • Application risk classification • Threat assessment
2 b) Requirements (continued)
2 b) Requirements (continued)
2 c) Model development • Specification for each detection point: • purpose • general statement of its functionality • details of any prerequisites • related detection points. • Duplicate codes • Aggregating detection points
2 c) Model development (continued)
2 c) Model development (continued)
2 d) Optimization • Three aims • Ensure we maintain a low false positive rate through adjusting the sensitivity • Consider relationships with other systems and the effects these may have on detection points • Identify if any detection points can be removed to eliminate overlaps and duplicates • Test cases
2 e) Code location • Instrumentation not new functionality • Process • Procurement • Development • Frameworks • Libraries • Common code / business layer
2 f) Attack analysis • Attack vectors • Threat modelling • WASC Threat Classification v 2. 0 http: //projects. webappsec. org/Threat-Classification • OWASP Top Ten 2010 http: //www. owasp. org/index. php/Category: OWASP_Top_Ten_Project • Common Attack Pattern Enumeration and Classification http: //capec. mitre. org/ • Check the model • Detection points are activation • Human error
3. Response action selection
3 a) Strategic requirements • Organizational risk tolerance • User experience • Application’s purpose “Application functionality will not be changed unless the user's “Authenticated users doing anything, but log, monitor and “Do not preventadministrators who have access to the mostalert source location is in greatest data access functionality fervently. ” and the a higher-risk country. ”permissions should have the strictest thresholds before a response action is undertaken. ”
3 b) Thresholds • Approaches • Role dependent • Per detection point / per application • Weightings of suspicious and attack events • User events and user trends • Individual detection points • Overall number of security events • System trend detection points • Modifying detection points
3 b) Thresholds (continued)
3 c) Model tuning • Attacks • Typical user activities • Speed of use • Static content • Missing content • Actions that disable features or the application • Other systems • Business metrics
3 c) Model tuning (continued) • Only log • Source location override • Export • Vulnerability management programmes • Security integration manager (SIM) systems • Secure development practices
Plan execution
Implementation • Secure development practices: • Risk analysis • Design and code review • Testing • Operational enablement • Change management • Monitoring and tuning • Ongoing testing
Quick start
Piloting App. Sensor / fast-track approach • Focus on input, signature based detection points that detect attacks rather than suspicious events in the discrete class: • Request exceptions (RE 1, 2, 3 and 4 ) • Access control exception (ACE 1 and 2) • Input exceptions (IE 1, 2 and 3) • Authentication exceptions (AE 1, 2 and 3) and Session Management exceptions (SE 5 and 6) when authentication & session management is use • And limit response actions to additional logging (ASR-A), administrator notification (ASR-B), account logout (ASR-J) & account lockout (ASR-K). • Do it with ESAPI
Concluding thoughts
Supporting materials • App. Sensor Project: • Home page http: //www. owasp. org/index. php/Category: OWASP_App. Sensor_Project • Detection points http: //www. owasp. org/index. php/App. Sensor_Detection. Points • Response actions http: //www. owasp. org/index. php/App. Sensor_Response. Actions • Mailing lists • https: //lists. owasp. org/mailman/listinfo/owasp-appsensor-project • https: //lists. owasp. org/mailman/listinfo/owasp-appsensor-dev • Planning guide and workbook http: //www. owasp. org/index. php/File: Appsensor-planning. zip
Related presentations at App. Sec DC 2010 • Application Portfolio Risk Ranking: Banishing FUD With Structure and Numbers Dan Cornell http: //www. owasp. org/index. php/Application_Portfolio_Risk_Ranking: _Banishing_FU D_With_Structure_and_Numbers • Solving Real World Problems with ESAPI Chris Schmidt http: //www. owasp. org/index. php/Solving_Real_World_Problems_with_ESAPI • Next: OWASP Mod. Security Core Rule Set Ryan Barnett http: //www. owasp. org/index. php/OWASP_Mod. Security_Core_Rule_Set
Questions and feedback • Now • During the last two breaks today • Subsequently • colin @ watsonhall. com • +44 20 7183 3710 Photographs: Machinery and instrumentation at the Discovery Museum, Tyne & Wear Archives and Museums, Newcastle-upon-Tyne, England