1

Mapping Application Security

to Compliance

Ed Adams

CEO

Security Innovation

Jason Taylor

CTO

Security Innovation

Agenda

About Security Innovation

• Aligning software development processes with corporate policies

• Aligning software development activities with compliance requirements

• Creating an action plan to identify and remediate gaps between current and best practices

– Conducting an SDLC Gap Analysis

– Application Security/Compliance case studies

• Conclusion

2

About Security Innovation

• Application Security Experts

– 10+ years research on vulnerabilities and cryptography

– Hundreds of assessments on world’s most dominant software

• Products, Services & Training

– Application and SDLC Assessments• white and black box assessments

• Secure SDLC consulting

– eLearning• Industry’s largest library of application security courses

– Secure Development Methodologies

• Web based guidance for each phase of SDLC

• Helping organizations:

– Ensure applications are secure and in compliance

– Build internal software security competency

Application Security: the Next Frontier of Compliance

• Insecure applications are the biggest threat to data security

– 90% of attacks at application layer

– Regulations historically focused on network security

• New Application Security Requirements

– FISMA (Federal Information Security Act) and NISTrequire organizations to integrate security assessments into SDLC

– PCI DSS v2.0“secure coding standards”

– PCI DSS standard“..prevent vulnerabilities such as injection flaws,

buffer overflows, etc”

– MA 201, dozens of others

3

Why Application Security is so Challenging?

• Organizations often have dozens or hundreds of applications exposed

– need to understand how applications interact with their environment

• more importantly, exactly where these interactions introduce risk

• Regulations call out general requirements like “developing according to industry best practices”

– uh, where can I find those?

• Many regulatory requirements have non-obvious implications

– i.e. protected information “should not be improperly altered or destroyed”

• Implementing application security is multi-tiered

– involves policies, processes, tooling, and knowledge

– affects development, IT, security, risk, compliance, and many other teams

• But it can be done - with the right knowledge and planning

Agenda

• About Security Innovation

Aligning software development processes with corporate policies

• Aligning software development activities with compliance requirements

• Creating an action plan to identify and remediate gaps between current and best practices

– Conducting an SDLC Gap Analysis

– Application Security/Compliance case studies

• Conclusion

4

Aligning Development Processes with Corporate

Policies

• Software development groups need guidance from management on topics like

– the importance management places on data security and compliance

– the direct impact software applications have on data security risks

– the applicability and relative importance of the many federal, state, and international regulations and industry standards

– the business implications of not meeting compliance mandates

– the potential impact of different types of data breaches and attacks on business systems

• ENTERPRISES NEED AN EXPLICIT PROCESS for formulating corporate security and compliance standards and policies

– and for translating these into terms specific enough for people to apply on their jobs

The Corporate Application Compliance Frameworkaligning development with management policies

5

The Corporate Application Compliance Framework: Top Level: Executive Management

• Enterprise Risk Management, HR, and Legal define the global scope, objectives and requirements for corporate governance

– applicable legislation (Sarbanes-Oxley, HIPAA, California SB 1386)

– industry standards (ISO 2700x, FISMA/NIST standards)

– compliance mandates (PCI DSS)

– legal and human resources requirements (data privacy laws)

– the potential impacts of security breaches• on customers, corporate reputation, regulatory bodies, and domestic and

international governments

– the costs of security breaches and attacks• regulatory fines, customer notification, loss of revenue, interrupted

operations, loss of business continuity, and other expenses

The Corporate Application Compliance FrameworkMid-level: GRC & Security Groups

• ERM, GRC & Security teams add detail to create policies

– high-level guidelines for operational security and compliance activities

– can be contextualized for specific business units and functional roles

• Typical tasks include:

– studying the applicable regulations and standards

– conducting a threat assessment to determine the security breaches potentially most damaging to the enterprise

– classifying data assets to define levels of data sensitivity

– defining concrete application security objectives

• Ideally the policies developed will be specific enough to guide the operational teams

– in practice, reaching the right level of specificity can be challenging

6

The Corporate Application Compliance Framework

Base Level – functional practitioners

• Security & Compliance teams define specific development processes, coding practices, and procedures for documenting compliance documentation procedure

– ensures they’re relevant to local requirements and technology, and consistent with corporate security and compliance policies

– should address regional and business-unit specific regulations and the technologies used by each development team

• Contextualizing the policies for each team can be a labor-intensive and deeply technical process

– But the effort is justified and saves a TON of time long-term

– The more specific and practical the guidance, the more successful the team will be in with respect to compliance

Agenda

• About Security Innovation

• Aligning software development processes with corporate policies

Aligning software development activities with compliance requirements

• Creating an action plan to identify and remediate gaps between current and best practices

– Conducting an SDLC Gap Analysis

– Application Security/Compliance case studies

• Conclusion

7

Aligning Development Activities with Compliance

Security Training

• HIPAA– “implement a security awareness and training program for all members of

its workforce (including management)

• PCI-DSS– “implement a formal awareness program to make all personnel aware of the

importance of cardholder data security….verify that personnel attend

awareness training upon hire and at least annually.”

• The Federal Financial Institutions Examination Council (FFIEC) – “educate users regarding their security roles and responsibilities. Training

should support security awareness and strengthen compliance

• NIST SP 800-64 R2– “System development training and orientation should include basic and

specialized security awareness, training, and education.”

Security training is a critical prerequisite to a successful and COMPLIANT application security program

Aligning Development Activities with Compliance:

Security Training

• While the type and amount of security training varies across organizations, in most cases:

– All members of development should know basic software security principles

– Managers and architects need to understand topics like threat modeling, architecture risk analysis, and secure SDLC practices

– Software engineers should know how to code defensively for the specific languages and environments they are developing in

– Engineers should know how operate tools like code and web scanners

• Unless they understand how applications function and fail with respect to security, they will not get full utility out of tools

• Unless they understand the limits of the tools, there is false sense of security

– Software engineers, network/IT managers, and quality professionals should know how applications are attacked

– Compliance professionals can benefit from understanding where application security fits into standards like HIPAA or PCI DSS

8

• Standardized coding practices are essential

– embody best practices, improve consistency, reduce errors, facilitate

testing, and provide a benchmark for compliance measurement

• “Connecting the dots” between coding practices and compliance can be challenging:

– a broad range of domain expertise is required• Applicable regulations and standards

• Probable threats and application-related vulnerabilities

• Application security techniques and coding practices

– many requirements imply that certain functionality be provided or specific practices be followed, without stating details

– a number of implementation steps are required• Security coding practices and standards need to be documented

• Engineers, architects, DB analysts and QA staff need to be trained

Aligning Development Activities with Compliance:

Secure Coding Practices

Selected coding practices that contribute to compliance

High-Level

Requirement

Standards

(Partial List)Selected Coding Practices

Confidentiality SOX, PCI DSS, HIPAA,

ISO 27002, HIPAA, GLBA,

FFIEC, Basel l I, CA SB

1386, FIPS 199, NIST SP

800-30/ 800-53/800-64

Appropriate use of strong encryption for data in databases.

Encrypting confidential data in memory. No custom or untrusted encryption routines.

Encrypting data in motion, especially for wireless transmissions.

Masking confidential data that needs to be viewed in part

Data integrity SOX, PCI DSS, ISO

27002, HIPAA, GLBA,

FIPS 199, NIST SP

800-30/ 800-53/800-64

Robust integrity checks to prevent tampering with data.

Input validation and comprehensive error handling to prevent injection attacks, privilege

escalation, and other hacking techniques.

Output encoding. Use of least privileges.

Hashing for confidential data that needs to be validated (e.g. passwords).

Authentication

and access

control

SOX, PCI DSS, ISO

27002, HIPAA, II,

NIST SP 800-30/ 800-

53/800-64

Support for strong passwords & two-factor authentication where appropriate.

Role-based access control and revocation of rights, with clear roles mapped to permissions.

Locked down file access and database roles. No guest accounts.

Passwords and encryption keys encrypted before storage and transmission.

Logging and

auditing

SOX, PCI DSS, ISO

27002, HIPAA, SB 1386,

NIST SP 800-30/ 800-

53/800-64

Detailed audit trails of users accessing data and resources.

Detailed logging of systems that process sensitive data, including shutdowns, restarts and

unusual events. No confidential data exposed in logs.

Event logs and audit trails available only to system admins and protected from unauthorized

modifications.

Availability SOX, ISO 27002, HIPAA,

II FIPS 199, NIST SP

800-30/ 800-53/800-64

Code reliability. Failover and redundancy built into applications.

Applications resistant to denial of service attacks.

Clean up of confidential data in memory and in file systems during failures and shutdowns.

Change

management

SOX, BASEL II, NIST SP

800-53/ 800-64

Source control. Logging of application changes.

Application change logs accessible only to privileged users and resistant to tampering.

9

• Several organizations publish documents and tools that can help organizations develop and document their own secure coding practices:

– OWASP

• Top 10 listing of critical web application security threats and suggested preventative practices

– CWE: most dangerous software weaknesses

– The CERT secure coding standards

– The Microsoft SDL (Secure Development Lifecycle)

– Security Innovation’s TeamMentor™ • secure development standards, an extensive collection of

SSDLC practices and recommendations

Aligning Development Activities with Compliance:

OWASP and Other Coding Standards

Compliance and the software development lifecycle (SDLC)

• Most enterprises have defined processes for development

– Helps control functionality, quality and developer productivity

– rarely place much emphasis on security or compliance activities

• Integrating security is important for both compliance and productivity

– preventing defects in design phase requires one-tenth the effort of catching and fixing those at the system test phase

– removing 50% of vulnerabilities prior to deployment or release can reduce configuration management and incident response costs by 75% (Gartner)

– Similar to the introduction of performance, reliability activities years ago

• Industry regulations increasingly specifying requirements related to SDLC best practices

– PCI DSS: Incorporate information security throughout the SDLC

– DoD: recently published a 114-page Application Security and Development Security Technical Implementation Guide

10

Addressing compliance requirements related to SDLC

ActivityExamples of Requirements and

RecommendationsSelected Best Practices

Security

objectives

and

requirements

analysis

“Security planning should begin...by: identifying

key security roles for the system development;

identifying sources of security requirements,

such as relevant laws, regulations, and

standards; and ensuring all stakeholders have a

common understanding.” NIST SP 800-64

Examine regulations and standards, potential exploits and attacks, and the

business risks of those exploits and attacks.

Evaluate business requirements in terms of information CIA

Write “abuse cases” detailing how malicious users might interact with system

Define measurable goals for compliance & reducing vulnerabilities

Threat

modeling

“conduct an accurate and thorough assessment

of the potential risks and vulnerabilities to the

CIA of electronic protected health information

held by the covered entity.” HIPAA

Describe how adversaries might choose targets, locate entry points, and

conduct attacks.

Identify what specific application defenses the attacker must defeat to be

successful.

Architecture

and design

review for

security

“employ architectural designs, software

development techniques, and systems

engineering principles that promote effective

information security….” FIPS PUB 200

Identify design decisions that can mitigate risk; e.g., use languages such as

Java and C# to reduce the risk from buffer overflow vulnerabilities, and

validate all user input on servers to prevent attacks that manipulate variables

on clients.

Code review

for security

“must conduct a review of custom code prior to

release in order to identify any potential coding

vulnerability...by knowledgeable internal

personnel or third parties.” PCI DSS 2.0

Use automated code scanning tools and manual reviews to identify patterns

such as non-constrained methods, unchecked return values, methods without

exception handling, embedded passwords, and sensitive information

disclosed in logs.

Security

testing

“must review]public-facing web applications via

manual or automated application vulnerability

security assessment tools or methods, at least

annually and after any changes “ PCI DSS

Rigorously test application components, validate inputs, parse file formats,

and authenticate users. Conduct extensive penetration testing.

Check for sensitive information exposed in memory and temporary files.

Maintain a unit test library. Have developers crosscheck each other’s code.

Deployment

review for

security

“must develop configuration standards for all

system components...Verify that system

configuration standards are applied when new

systems are configured....” PCI DSS

Develop checklists to ensure web servers, databases, storage and networking

systems are properly configured and patched.

Remove custom application accounts, user IDs, and embedded passwords

before applications are put into production.

• In the real world not every best practice can be adopted at once

– organizations need to identify which are most important

• For some, a “find and fix” approach in short-term may suffice

– organizations with web-facing legacy applications may determine top

priority is plugging a few gaping vulnerabilities

– companies with hundreds of small, internally-facing applications might

determine that code reviews are the best use of their time

• An enterprise needs to understand the inherent risk level of the applications it is building and deploying, based on:

– applicable compliance requirements

– source (internal or outside third party)

– age, language, environment in which they will be deployed

– Type/amount of sensitive information processed, stored and transmitted

Compliance and the SDLC

11

Agenda

• About Security Innovation

• Aligning software development processes with corporate policies

• Aligning software development activities with compliance requirements

Creating an action plan to identify and remediate gaps between current and best practices

Conducting an SDLC Gap Analysis

– Application Security/Compliance case studies

• Conclusion

1.) Review Org Structure and Team Roles

2.) Analyze

Policies &

Standards

Requirements

3.) Analyze &

Aggregate Data

4.) Refine via focused

Interviews (usually team leads)

5.) Create Gap Analysis Report

with recommendations

SDLC Process Assessment – Graphical View

Best Practices

12

Identifying Objectives and Gaps

• Compare to industry best practices, standards, mandates, etc.– ISO 27002, NIST-800, ITIL frameworks, the Microsoft SDL, internally-defined

• Start with Policies and Standards, then procedures at each phase

• Investigate:– gaps between existing and industry security practices

– technical and business risks associated with each gap

– costs, benefits, and expected value of addressing each gap

– documentation of appsec processes and coding practices

• Create a spreadsheet with compliance requirements on one axis and controls and actions on the other

– Identify opportunities to use a single control for multiple requirements

– highlights which practices do not meet standards, or need to be added

• Assess your security training program, too

Assessing your Existing Development ProcessActivity Matrix

Product A Product B Product C

Define Security Objectives X X

Apply Security Design Guidelines X X

Threat Model X X

Security Architecture and Design Review X X

Apply Security Implementation Guidelines X

Security Code Review X X X

Security Penetration Testing X X X

Apply Security Deployment Guidelines X

Security Deployment Review X

3rd party Security Penetration Test X X X

Security Incident Response Plan X X X

13

Assessing your Existing Development ProcessSecurity Policies

• Security policies

– are the backbone of your development process

– without them, many efforts are wasted

• what good is a scanning tool if it’s use is not required

• Questions to ask yourself

– do you have a formal development process with well-defined phases and activities?

– do you have a dedicated security team?

– do you have corporate security and compliance policies?

– how is the development team made aware of security policies?

– how does the development team access security policies?

– how does your development team interact with company security policies (governance, compliance, etc)?

Assessing your Existing Development ProcessRequirements & Design Phase

• Requirements and design phase security activities– security requirements objectives

– threat modeling

– design best practices & design reviews

• Questions to ask yourself:– do you gather security objectives?

• How are they stored? How are they mapped to the rest of the design process?

– do you have a set of design best practices that you employ for security?• How are they stored? How do you ensure architects are using them?

• How do you revise and improve them over time?

– does your team conduct security architecture and design reviews?• How often? Is it done before implementation?

• Do you use checklists to drive the process?

• How are the results tracked and used to improve the design?

– does your team create threat models for your application’s architecture/design?• When? Where is it stored? Is it updated over time?

• How is it used to improve the design, implementation and testing?

14

Assessing your Existing Development ProcessImplementation Phase

• Implementation phase security activities

– development best practices

– security code reviews

• Questions to Ask– does your team use a formalized set of security coding best practices?

– what type of code scanning tools do you use?

– do you perform code reviews against security best practices?

• How often? What is the process?

• Do you have a set of checklists that can use drive the review process?

• How are the results tracked and used to improve the implementation?

Assessing your Existing Development ProcessVerification Phase

• Verification phase security activities

– abuse case definition

– penetration testing

• Questions to ask:

– does your team conduct 3rd party or internal penetration tests?

• How often do you perform internal and 3rd party penetration tests

• Do you prioritize attack paths based on a threat model?

• Do you have a set of vulnerabilities, unique to your system, that you test against?

• How are the results tracked and used to improve the implementation?

– are your testers and QA trained on the latest attack trends and test techniques?

– do you use security testing tools?

• Web scanners such as AppScan or WebInspect

• File and network fuzzers

• etc

15

Assessing your Existing Development ProcessRelease & Response Phase

• Release/response phase security activities and preparedness

– security deployment review

– security attack response

– patching processes

• Questions– does your team use a formalized set of security deployment best practices?

– do you have a security incident response plan?

– do you use network scanning tools such as Nessus?

– do you have a set of deployment best practices that you employ for security?

• How are they stored? Do you ensure your developers are using these?

• How do you revise and improve these best practices over time?

– do you review the deployment for security best practices before deployment?

• How often are inspections performed?

• What is the process? Do you have a set of checklists to drive the review process?

• How are the results tracked and used to improve the deployment?

Plan a Remediation Roadmap

• Use assessments from previous phases to prioritize identified threats and areas most in need of improvement

– based on practical and proven IT risk, cost/benefit considerations

• For each high-priority area:

– review the major risk management strategies

• avoid, transfer, accept, remediate

– identify appropriate control options

– describe necessary modifications to compliance activities

– consider a stakeholder strategy and planning workshop

• Will show which activities and/or controls will yield biggest “bang for the buck”

– by addressing most important requirements, or addressing several at once

• Use results to construct phased software risk remediation roadmap– will become the basis of specific subsequent security improvement initiatives

16

Implementing the Roadmap

• Should be designed around where you need the most help

• Select tools and partners that can help implement– training courses that cover security design,

development and testing best practices; or a specific tool

– threat Modeling conducted earlier in the SDLC

– more frequent, iterative code reviews

– the development of secure coding practices

• Sequencing is critical– introduce baseline guidance for all first

– work with security champions; develop them as mentors

– beware not to invest in new tools too soon

• Continue to measure progress relative to security and compliance objectives and requirements

– adjust the roadmap as corporate priorities, threat patterns, and compliance standards change

Agenda

• About Security Innovation

• Aligning software development processes with corporate policies

• Aligning software development activities with compliance requirements

Creating an action plan to identify and remediate gaps between current and best practices

• Conducting an SDLC Gap Analysis

Application Security/Compliance case studies

• Conclusion

17

• Good software engineering processes but lacks coordinated formalized security engineering processes

– teams not trained on security principles

– no standards for secure design or implementation

– no architecture, design or code reviews focused on security

– no threat modeling being done to assess risk

• team unable to prioritize efforts or mitigate threats repeatedly

• Team is making lots of mistakes, both in design & development

– resulted in many exploitable vulnerabilities in critical applications

– likely indicative of all the company’s applications

• Would fail PCI and ISO audits

SDLC Compliance Assessment for Client High-Level findings

Case Study: SDLC Assessment for Clientsecurity activity recommendations

How security engineering activities can be layered into a

traditional software development process

18

• A threat model would have exposed the key assets for protection and design-level mitigations could have then been created

– centralized input and data validation, consistent output encoding using an

established security library, selection of appropriate cryptographic algorithms

• A design review would have checked that each design mitigation was placed in the architecture properly

• The use of secure implementation best practices and security focused code reviews would ensure:

– the development of input and data validation routines

– the proper use of output encoding and cryptography

• A penetration test before deployment could discover issues that fell through the cracks in the early phases of development

• All of the above would have been steps toward compliance– (not to mention making their software systems more secure )

Case Study: SDLC Assessment for Clienthow recommended activities could have prevented issues

Case Study: SDLC Assessment for Clienttraining recommendations

Requirements & Analysis

•How to Define Security Objectives (ENG 111)

Architecture & Design

• Fundamentals of Secure Architecture (DES 101)

•Architecture Risk Analysis & Remediation (DES 212)

•Creating Secure Application Architecture (DES 311)

• Intro to Threat Modeling (ENG 301)

Code Implementation

•Classes of Security Defects (TST 201)

• Fundamentals of Secure Development (COD 101)

•Understanding Secure Code- .NET 4.0 (COD 214)

•Creating Secure Code -ASP.NET (COD 311)

•How to Perform a Code Review (ENG 401)

Testing

• Fundamentals of Security Testing (TST 101)

•How to Test for OWASP Top Ten (TST 211)

Everyone: Fundamentals of Application Security (AWA 101)

19

• When accepting a change request or a new requirement, examine each requirement for security and compliance impact

– if there will be a security impact, track it as a new security requirement

– evaluate if there needs to be additional security requirements in place to mitigate added risk

– requirements management tools can help here (esp. with traceability)

• Before moving on to application design, security objectives and requirements must be defined

– review security objectives to ensure they are appropriate for the functional requirements and application scenario

– determine security objectives based upon data asset classification

• All security requirements should be tracked in the requirements management tool

– they had one already; just weren’t using it for security

Case Study: SDLC Assessment for Clientrecommendations for requirements gathering

• Use the TeamMentor security guidelines to apply security design best practices

• Perform a security architecture and design review before coding starts

– Use the TeamMentor security checklists to drive the review, provide usable guidance, and document for compliance audits

• Create a threat model on your application’s design before coding begins

– Ensure asset classification and to help prioritize threats

Case Study: SDLC Assessment for ClientDesign Recommendations

20

• Use TeamMentor security guidelines toapply security implementation best practices

– “Secure Coding Standards” requirement in PCI

• Perform a security code review before each check-in

– can be implemented with buddy code reviews as well as with the occasional group code review for knowledge sharing

– use the TeamMentor security checklists to drive the review

• Require that Visual Studio Code Analysis is turned on and all errors and warnings are handled before each check-in

Case Study: SDLC Assessment for ClientImplementation Recommendations

• Use the security objectives and the threat model to build a security penetration test plan

– can write tests before code is written

• Complete internal penetration testing before deployment

– document for PCI and ISO requirements

• Complete a 3rd party penetration test on Internet facing applications before deployment

– document for PCI and ISO requirements

Case Study: SDLC Assessment for ClientVerification Recommendations

21

• Perform a security deployment review, including configuration settings, before deploying

– Use TeamMentor security checklists to drive review

• Ensure there is a security incident response plan in place

– should include severity levels for potential vulnerabilities,escalation plans and engineers on call

• Where there is an incident response plan in place, this can be used as the basis for the security incident response plan

Case Study: SDLC Assessment for ClientRelease Recommendations

• TeamMentor Security Knowledgebase– security best practice guidelines, checklists, code examples, etc

• Appscan – should be used to scan any Internet facing web applications

• Visual Studio Code Analysis – Free tool for performing static analysis on all .NET code

• Fortify 360 Source Code Analyzer– effective when scanning .NET, Java or C++ code

– finds more vulnerabilities than VS Code Analysis; requires training

• Upgrade to Visual Studio 2010– contains additional security safeguards to improve code security

• Adopt Team Foundation Server– integrated toolset for a variety of development activities

– use MSF-Agile plus Security Development Lifecycle Process Template• contains many features to help adopt and enforce a secure SDLC

Case Study: SDLC Assessment for ClientTools Recommendations

22

• Security Objectives– if you don’t know the security it’s difficult to be successful with any other activities

• Architecture and Design Review for Security– bugs introduced in the design phase are the most expensive to deal with later

• Threat Modeling– helps focus efforts and ensures that you address relevant threats

– drives the test plans

• Code Review for Security– implementation bugs are the most common

– can save you later rework or help avoid costly exploits

• Security Review for Deployment– even an effective process can be undone by a configuration error during deployment.

• Design Guidelines for Security– adopting proven design principles ensures your application is secure from the start

• Security Testing– used to validate designed mitigations and ensure nothing slipped through the cracks

Case Study: SDLC Assessment for ClientRecommended rollout sequencing

SDLC Case Study: Sony

• Had high-throughput, near shore development team of roughly 100

– limited expertise in secure development and security testing

• Organizational challenges

– lack of a “Security Champion” in each software development team

– limited time that developers and testers can be taken “off the bench”

• Critical marketing site that is regularly updated and needs frequent

security assessments with short turn-around/delivery timelines

• Needed to comply with privacy laws, ISO 2700x, and internal policies

– dev. team had little insight into how requirements impact them (and vice versa!)

• Danger of vulnerabilities in their applications exploited

– could mean loss of customer base, reputation, and share price

• Risk of operating in increasingly open environments (web, ESA, et al) with

no foreknowledge of operating environments or user intent

– translates to drastically accelerated risk

23

SDLC Case Study: Sony

Sony requested an SDLC business proposal, with several phases, that will help Sony:

• Comply with corporate requirements for security and privacy

• Build and maintain internal software security expertise

• Become more proficient developing secure, high-quality web applications

• Implement a recurring security assessment program

• Rollout a repeatable, easily-adoptable SDLC that includes security activities and check points at each phase

• Enable audit “check points” to document and measure SDLC activities

End goal was nothing short of making Sony significantly more self-reliant

for security expertise via tailored processes, practices, and technology.

Define

Security Requirements

Use Case and Abuse Case –

Definition and Review

Design

Threat Modeling

Security Design Review

Architecture Risk Analysis

Security Test Planning

Code

Security Code Analysis

Metrics Gathering and

Reporting

Test

Penetration Testing

Metrics Gathering

and Reporting

Deploy

- Online ApplicationSecurity Monitoringportal

- Recurring Assessments (Penetration Testing)

- Reporting

Software Security Risk Management Solution encompassing : Process Improvement (services), Education (training) and Tools to greatly improve both efficiency,

reliability, and accuracy during the phases of the SDLC

Sony Case Study: SDLC long-term vision

24

Sony Case StudyTraining recommendations

Product A Product B Product C

How to Define Security Objectives PM, SC PM, SC

Application Security Fundamentals E E

Attacker Techniques Exposed O O O

Architecting Secure Solutions O O O

Security Architecture and Design Review A, SC A, SC A, SC

Threat Modeling A, D, SC A, D, SC

Creating Secure Code Java D

Creating Secure Code – C# and ASP.NET D D

Conducting a Security Code Review D, SC D, SC D, SC

Classes of Security Defects D, T D, T D, T

Web Vulnerabilities – Threats & Mitigations D D D

Security Testing T T O

Sony SDL Case Study: Solution

• 3-phase, 18-month program

• Defined a recurring Web security assessment program – trend reports to measure effectiveness and document for compliance

• Customized training program for development team

• Adopt best-practices and standards and optimize their SDLC with: – appropriate team activities at each phase

– appropriate phase transition gates

• Appoint a security champion or “representative” that will:– drive security and ensure compliance with application security best practices

– be responsible for mapping development activities to security requirements

– hold regular meetings to discuss security issues encountered and business impact

• Each team will start to analyze security statistics such as:

– the number of security issues dealt with

– the number of times the Incident Response Plan has been used

– how issues have been resolved

25

Agenda

• About Security Innovation

• Aligning software development processes with corporate policies

• Aligning software development activities with compliance requirements

• Creating an action plan to identify and remediate gaps between current and best practices

– Conducting an SDLC Gap Analysis

– AppSec/Compliance case studies

Conclusion

Repeatable, Secure Development WorksA look at the Microsoft SDL

11966

400

242

157

Windows®

XP

Windows

Vista®

OS I OS II OS III

Total Vulnerabilities Disclosed 12 Months After Release

34

3

187

SQL Server® 2000 SQL Server 2005 Competing

commercial DB

Total Vulnerabilities Disclosed 36 Months After Release

Before SDL After SDL

45% reduction in Vulnerabilities

Before SDL After SDL

91% reduction in Vulnerabilities

Consistent application of sound security practices during all phases

of a development project will not only facilitate compliance, but

result in fewer vulnerabilities

26

Secure, Repeatable SDLC: Benefits

• Microsoft SDL Results

– Activity: adopt secure SDLC following best practices

– Result: 91% reduction in vulnerabilities

• Results drove cost and reputation savings

– Reduction of vulnerability count alone not great metric

– For a software vendor like Microsoft, this means

• Less time ($$) finding same mistakes

• Less time developing fixes for vulnerabilities

• Less time issuing and maintaining patches

• Less support burden to end users

– For Enterprise IT Security/Risk team, this may means

• Meeting key compliance objective

• More efficient use of internal resources

• Less support burden and risk to end users

• Less out-of-pocket expense with outsourced vendors

Match metrics to

objectives for higher

chance of success

Conclusion

• Most regulations, frameworks, and compliance mandates revolve around key, best practices for secure development

– Simple tools like spreadsheets can help you organize these with controls for rows

and activities for columns

• helps visualize impact of single activity on multiple compliance requirements

• Rolling out a repeatable SDLC that integrates key security and compliance activities helps ensure

– future requirements will have little impact on existing efforts

– you maintain a “big picture” view to software development and IT teams

• Mapping AppSec to compliance is easier than you may think

• Secure development has benefits beyond compliance

– Gartner estimates that removing 50% of software vulnerabilities prior to production

can reduce configuration management and incident response costs by 75 percent

– audit costs and “re-do” expenses dramatically reduced

– over 70% of all exploits take advantage of known and common vulnerabilities

27

How Security Innovation can Help

• TeamProfessor eLearning– all application types

• Web, database, mobile, embedded, client/server, and more

– popular technologies• ASP.Net, Java, C/C++,.Net, Windows, C#, JRE

– maps to industry standards and regulations• OWASP, PCI-DSS, Microsoft SDL, HIPAA, NIST, etc.

• TeamMentor: Security Implementation System

– aligns corporate standards and industry regulations with development activities

• Secure SDLC Consulting– SDLC Assessment & Optimization (and mapping to compliance reqts!)

– Design & Requirements Review

– Code Review

– Security Testing

eKnowledge Solutions

Application Security eLearning:

– Creating Secure Code

– How to Test for OWASP Top Ten

– Fundamentals of Application Security

– How to Conduct a Code Review

– PCI-DSS for Developers

TeamMentor:Secure Development Methodologies

– Out of the box secure development standards and best practices (maps to OWASP, PCI-DSS, etc.)

– How-to’s, how not-to’s, code snippets, attacks, checklists

– Targeted, on-demand, context specific application security training

– Dedicated section for software security engineering

28

Try eLearning for free

http://elearning.securityinnovation.com

Free eLearning Course for Attending

• Introduction to Threat Modeling

• Fundamentals of Application Security

• How to Conduct a Code Review

getsecure@securityinnovation.com

Whitepaper

Mapping Application Security to Compliance

Contactjtaylor@securityinnovation.com

eadams@securityinnovation.com