software security the bigger picture

Copyright © 2007 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this license, visit http://creativecommons.org/licenses/by-sa/2.5/

The OWASP Foundation

6th OWASPAppSec

Conference

Milan - May 2007

http://www.owasp.org/

Software SecurityThe Bigger Picture

Rudolph AraujoSenior Principal, Foundstone Professional [email protected]

6th OWASP AppSec Conference – Milan – May 2007

Who am I?

Developer for over 10 yearsFoundstone / McAfeeMorgan StanleyBindView

Microsoft Visual Developer Security - MVP Masters from Carnegie Mellon University

Computer Science / Information Security

Areas of expertise: C / C++ / C#, Windows / Unix


Agenda

State of Software Security Defining a Security Frame Security Requirements Engineering Security Acceptance Testing Security Knowledge Management Parting Thoughts Q&A

3


STATE OF SOFTWARE SECURITY

4


The Stages of Software Security


Innocence

No formal security requirements

Security flaws are identified through:Penetration TestingSecurity Incidents


Application Security Awareness

Penetrate & PatchBug fixing late in the lifecycle is extremely

expensive and time consumingReactive approach

Application Security Identifies and corrects instances of security

issues in applicationsTactical, near-term approach to securing an

application


Application Security Enlightenment

Push security earlier in the lifecycle

Threat Model the ApplicationStructured approach for identifying, evaluating

and mitigating risks to system securityModels the system as an attacker would see it

…with the advantage of knowing the internals

Code Review the Application


Software Security Awareness

Application Security is expensive and time consumingVulnerabilities are still found year

after year

Application Security Enlightenment is false enlightenmentAddressing the symptoms and not the

disease


Software Security Awareness

Root cause analysis determines the sources of insecure software

People– Lack of security knowledge

and motivation Process

– Reactive approach to security issues

Technology– Lack of appropriate tools


Software Security Enlightenment

Create a holistic Software Security program Integrate security into all phases of the SDLC

High-ROI activities first

Not all software security programs are identical Build a program to meet your needs


State of Software Security

12


DEFINING A SECURITY FRAME

13


Defining a Security Frame

14


Foundstone Software Security Frame

Configuration Management Data Protection in Storage & Transit Authentication Authorization User & Session Management Data Validation Error Handling & Exception Management Logging & Auditing

15


SECURITY REQUIREMENTS ENGINEERING

16


Security Requirements Engineering

Lack of / bad software requirements leads to bad softwareLack of security requirements leads to insecure

softwareNo benchmarks for QA to perform testingNo traceability!

Problem: Requirements are often written by business analysts or product management that may not be technicalAES-256-CBC – WTF is that?

17


Organizational Drivers

Regulatory complianceSOX 404HIPAAPCIGLBACA SB1386 / State

Notification LawsBASEL IIFISMAEU Data Protection

Directive…

Industry regulations and standardsFFIECOWASP Top 10 /

GuidesSCADA SecurityOASIS ISO 17799…

18


Organizational Drivers

Company policies / documentsPrivacy policyCoding standardsPatching policyData classification policy Infosec policiesAcceptable use policiesExport controlResults from previous

security audits…

Security featuresAuthenticationAuthorizationAdministrative

interfacesUser management…

19


Requirements Pre Process

1. Work with legal / internal audit to identify drivers

Define an organizational superset

2. Convert each driver to a superset of technical requirements

Use your security frame as a guide

Eliminate duplicates

1. Build application vs. driver matrix

20


Requirements Process

1. Based on features / data elements determine which drivers apply

Leverage data classification / privacy policy

2. “Copy-paste” requirement(s) from superset defined earlier

Consider building a thin “requirements” application

Perhaps an Excel template?

21


SECURITY ACCEPTANCE TESTING

22


Security Acceptance Testing

QA folks test software!How many test for security?Plus unit tests, build verification tests, test

driven development …

Penetration testing can often be too late But …

23


Security Acceptance Testing

The Mindset Training and exposureConsider Foundstone Hacme* / WebGoat

Testers need to help define the threat modelUse threat model to prioritize and scope effort

Define attack libraries of test casesBased on vulnerabilities and the security frameBased on phase of testing

Choose which ones to apply to this rev

24


Unit Testing

Data validationFuzzingSQL injectionBuffer overflowsCross site scripting

AuthorizationMethod level permissions

25


Build Verification Testing

Integrate source code analysisSimple regular expression based scansCommercial tools

Build custom rule sets Define exit criteria for build acceptance

26


QA Testing

Integrate with existing bug tracking systemsNo high / medium / low!Go with Severity / Priority ratings

Follow the existing processTreat security bugs no different than other

bugs Well maybe a little different ;)

27


QA Testing

Tag security bugsMaybe used to ensure developer assigned to fix

is “security conscious”

Classify by security frameAllows root cause and other statistical analyses

Classify by natureBugsFlawsCommendations Informational

Mark for regression testing28


SECURITY KNOWLEDGE MANAGEMENT

29


Why Knowledge Management?

Well, learn from other’s mistakes!Within your team / organization / community

Guidance on an ongoing basis

30


Software Security Portal

Document repository Threat modeling artifact repository

Leverage commonality across similar applications

Metrics reporting

31


Software Security Wiki

Security architectures and infrastructure components

Reviewed and tested code snippets for commonly used tasks

Links to additional information about software security on the Internet

Lessons learned from previous security issues identified in applications

32


Security Knowledge Management

Benefits Wide distribution of

best practices Prevention of

repetition of similar issues

Improved productivity Overall better

software quality

Gotchas! Don’t disclose too soon –

even if it is internal only! Anonymize the examples

and code if necessary Share not only the issue

but how the issue was discovered and fixed Root cause analysis Tweaking the SSDLC

Make sure the fix is bug free!

33


Special Case: Third Party Components

Open Source / COTSOpenSSLzlib

Who is tracking updates / patches?The average developer???Which of our applications are affected?What’s the plan to rollout patches?

Back again to matrices!Role: Software Security Architect

Subscribe to mailing lists– Patch reliability

Notify application owners34


PARTING THOUGHTS

35


It takes a village to raise software security!

36

software security the bigger picture

Documents