Building An In-House Application Security Assessment Team OWASP

Building An In-House Application Security Assessment Team OWASP Keith Turpin The Boeing Company keith. n. turpin@boeing. com 206 -683 -9667 11/13/2009 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. Copyright © 2009 Boeing. All rights reserved. The OWASP Foundation http: //www. owasp. org

Contracted Services Considerations < Some Advantages: 4 Highly skilled 4 Established tools, processes and standards 4 Unbiased 4 Available as needed < Some Disadvantages: 4 Expensive, especially for an extended engagement 4 Less control and flexibility 4 Not familiar with company processes and culture 4 Rotating staff OWASP Copyright © 2009 Boeing. All rights reserved. 2

Planning < Considerations for establishing an internal team: 4 Time to staff and train the team 4 Overlap of external and internal teams 4 Development of processes and standards 4 Acquiring necessary tools OWASP Copyright © 2009 Boeing. All rights reserved. 3

Service Model < Define the services your team will provide. This will be greatly influenced by: 4 The team’s size and skills 4 The number of applications you have to support 4 The tools available 4 The level of executive support 4 The funding model § Who pays for your services 4 The team’s role § Development support, pre-deployment testing or post deployment auditing and pen testing OWASP Copyright © 2009 Boeing. All rights reserved. 4

Staffing the Team < Decide how to staff your team and what skills you need. Possible candidates include: 4 Experienced Application Testers § This is ideal from a skills standpoint, but people in this category may be harder to find, cost more, may not be familiar with your company and or fit its culture. 4 Experienced Developers § Developers will have a good understanding of the technologies, but may not understand security principles. Their focus is on what an application is intended to do, not what it can be made to do. OWASP Copyright © 2009 Boeing. All rights reserved. 5

Staffing the Team - continued 4 Other IT Security Professionals § They have a good understanding of security principles, but may lack specific technical skills. However, some skills may provide a useful overlap, like experienced OS or network testers. 4 Service and Project Managers § Building a new team, defining processes and standards, managing work flow and handling customer relations requires a set of skills as important, but distinct, from technical testing skills. OWASP Copyright © 2009 Boeing. All rights reserved. 6

Selecting Tools < There a lot of options when it comes to tools. What you choose depends on the services you want to provide, your team’s skills and your budget. 4 Commercial vs. Free or Low Cost Tools § Commercial tools scale to support enterprise use, utilize a higher degree of automation and come with product support. They also come with a big price tag. § Open source and low cost tools allow for more customization, are free or inexpensive, usually have a supportive user community, but often require a higher degree of user knowledge and skill. OWASP Copyright © 2009 Boeing. All rights reserved. 7

Selecting Tools - continued < Types of Tools 4 Vulnerability Scanners § Commercial examples include IBM App. Scan, HP Web. Inspect and Cenzic Hailstorm 4 Source Code Analysis Tools § There are commercial options like Fortify or open source tools like the OWASP Yasca Project 4 Client Side Web Proxies § Options include Web. Scarab, Burp Suite and Charles Proxy 4 Other Tools § These include password crackers, hex editors, text extractors, browser plug-ins, integrated development environments, network mapping, network traffic analysis and exploitation tools OWASP Copyright © 2009 Boeing. All rights reserved. 8

What to Assess < Measuring an application’s risk: 4 The Types of Users § Privileged Users, employees, suppliers, customers or the general public 4 The Sensitivity of the Data § Intellectual Property, PII or other regulatory requirements 4 Availability and Integrity Requirements § The impact to the business if compromised 4 Technology and Environmental Consideration § What technologies are used, where is it deployed, … OWASP Copyright © 2009 Boeing. All rights reserved. 9

Gather Necessary Information < Before starting an assessment you will need to gather important information: § § § Application contacts Server contacts The process for getting accounts A description of what the application does The description or diagram of the system architecture The types of interfaces (human and system to system) The development platform The URL(s) or application installation files Is the source code available? Is this an in house, open source or commercial application? Are there schedule constraints or test windows? OWASP Copyright © 2009 Boeing. All rights reserved. 10

Assessment Planning Meeting < Meet with the application development and support teams: 4 Get a demonstration of the application 4 Review the information gathered to support the assessment 4 Discuss the testing process and ground rules § No changes to the code during testing § Backups of the application servers and databases § How to address system crashes during testing § Database corruption issues § Emails generated by the application OWASP Copyright © 2009 Boeing. All rights reserved. 11

Testing Notifications < You should have a process to notify affected parties before the actual testing begins. 4 Key system contacts 4 Intrusion detection teams 4 Other assessors < Information to include in the notification: 4 Source IP addresses 4 Target IP addresses, URL, system name 4 Testing schedule 4 Assessment team contacts Copyright © 2009 Boeing. All rights reserved. OWASP 12

Conducting the Assessment < If you are using automated scanning tools, beware of false positives and negatives. 4 Pattern recognition has limitations 4 Combine various testing methods § Automated scanning § Code review § Manual testing 4 Learn what your tools do and do not do well 4 Validate every finding 4 Keep detailed notes OWASP Copyright © 2009 Boeing. All rights reserved. 13

Establish Standards < Assessments performed by two different people or the same person over time, may result in the same finding being presented very differently 4 This may result in inconsistent descriptions of the vulnerability or different recommendations for remediation 4 Without standard findings you may also finding it difficult to produce meaningful metrics about discovered vulnerabilities OWASP Copyright © 2009 Boeing. All rights reserved. 14

Standard Findings < Opinions about how to standardize software vulnerabilities are like noses, everyone has one. At Boeing we have categorized vulnerabilities into approximately 70 standard findings like: § SQL Injection § Path Traversal § Session Fixation § Excessive Authentication Attempts § Forced Browsing § System Information Leakage OWASP Copyright © 2009 Boeing. All rights reserved. 15

Data Elements for Standard Findings < Each finding is made up of the following data elements: 4 Name 4 Control Classification 4 Severity………. . …Likelihood + Impact 4 Company Policy References 4 Industry References 4 Summary Description 4 Impact Statement 4 Detailed Description 4 Recommendation OWASP Copyright © 2009 Boeing. All rights reserved. 16

Control Classifications < We group individual vulnerabilities into control classifications. This helps us determine how effective we are at implementing control types. < Our classifications: 4 Input and output controls 4 Authentication and password management 4 Authorization and access management 4 Sensitive information storage or transmission 4 System configuration and management 4 General coding errors OWASP Copyright © 2009 Boeing. All rights reserved. 17

Reporting Findings < Developing a standardized reporting template will allow you to deliver a consistent, branded message. Key elements of our reports include: 4 Cover Page 4 Executive Summary 4 Findings Summary 4 Detailed Findings 4 Conclusion 4 Appendixes 4 Attachments – (optional) OWASP Copyright © 2009 Boeing. All rights reserved. 18

Reporting Findings - Continued 4 Cover Page: § Provides information necessary to identify the assessment, what was assessed and who the key people involved were. 4 Executive Summary: § A quick summary of the assessment which may include: – – Description of the assessment Identification of application being assessed A list of findings by severity Testing techniques 4 Findings Summary: § A brief description of each finding mapped to control classifications. OWASP Copyright © 2009 Boeing. All rights reserved. 19

Reporting Findings - Continued 4 Detailed Findings: § Includes all the standard findings data elements 4 Conclusion: § Summary of assessment results, discussion of next steps and links to additional resources 4 Appendixes: § Information on how severity ratings are determined, description of control classifications 4 Attachments: § Typically these are raw scan files or other supplemental data files OWASP Copyright © 2009 Boeing. All rights reserved. 20

Managing Corrective Actions < Once a report is issued you need a closed loop process to ensure serious issues are addressed. Considerations include: 4 Tracking Findings: § Critical and high findings should be tracked to resolution § Medium findings are less straight forward § Low or informational findings may not be value added 4 Customer Responses to Findings: § Implement a technical fix to address the finding § Implement a process fix to address the finding § The business formally accepts the risk of not remediating OWASP Copyright © 2009 Boeing. All rights reserved. 21

When to Re-Evaluate An Application < Depending on the number of applications you support and the frequency with which they change you may need to establish re-evaluation guidelines. Some criteria to consider include: § Fixes to previously accepted risk § User population changes § Data sensitivity changes § Business’s dependency on the application has increased § Authentication mechanism has changed § Authorization management code has changed § New functionality or user interfaces are being added OWASP Copyright © 2009 Boeing. All rights reserved. 22

Application Assessment Process Flow Version START Option 1 Requested Assessment START Option 2 Targeted Assessment Request for Service Form Targeted Assessment Asset selected for assessment Requester completes online RFS Pre-Assessment Questionnaire Asset owner is notified of assessment initiation Assessment team conducts Intake Review Go To Technical Assessment? YES NO Customer completes the Pre. Assessment Questionnaire Assessment planning meeting takes place to better understand the target and scope the assessment. Assessor is assigned Assessment Complete or Closed Letter NO Continue Assessment? End of Process YES Findings worked to resolution NO Full Assessment Findings Report END Corrective Action Process YES Were there findings? Conduct Assessment OWASP Copyright © 2009 Boeing. All rights reserved. 23

Conclusion < Building an assessment team from the ground up takes: 4 Executive support 4 A lot of planning 4 Staffing 4 The right tools 4 Training 4 Standards 4 Supporting processes OWASP Copyright © 2009 Boeing. All rights reserved. 24