Mapping application security to compliance

Mapping Application Security
to Compliance

Ed Adams Jason Taylor
CEO CTO
Security Innovation 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

1

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 NIST
require 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

2

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




• Conclusion

3

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 Framework
aligning development with management policies

4

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

Mid-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

5

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



Aligning software development activities



• Conclusion

6

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

7

Secure Coding Practices

• 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

Selected coding practices that contribute to compliance
High-Level Standards
Selected Coding Practices
Requirement (Partial List)
Confidentiality SOX, PCI DSS, HIPAA, Appropriate use of strong encryption for data in databases.
ISO 27002, HIPAA, GLBA, Encrypting confidential data in memory. No custom or untrusted encryption routines.
FFIEC, Basel l I, CA SB Encrypting data in motion, especially for wireless transmissions.
1386, FIPS 199, NIST SP
Masking confidential data that needs to be viewed in part
800-30/ 800-53/800-64
Data integrity SOX, PCI DSS, ISO Robust integrity checks to prevent tampering with data.
27002, HIPAA, GLBA, Input validation and comprehensive error handling to prevent injection attacks, privilege
FIPS 199, NIST SP escalation, and other hacking techniques.
800-30/ 800-53/800-64 Output encoding. Use of least privileges.
Hashing for confidential data that needs to be validated (e.g. passwords).
Authentication SOX, PCI DSS, ISO Support for strong passwords & two-factor authentication where appropriate.
and access 27002, HIPAA, II, Role-based access control and revocation of rights, with clear roles mapped to permissions.
control NIST SP 800-30/ 800- Locked down file access and database roles. No guest accounts.
53/800-64
Passwords and encryption keys encrypted before storage and transmission.
Logging and SOX, PCI DSS, ISO Detailed audit trails of users accessing data and resources.
auditing 27002, HIPAA, SB 1386, Detailed logging of systems that process sensitive data, including shutdowns, restarts and
NIST SP 800-30/ 800- unusual events. No confidential data exposed in logs.
53/800-64 Event logs and audit trails available only to system admins and protected from unauthorized
modifications.
Availability SOX, ISO 27002, HIPAA, Code reliability. Failover and redundancy built into applications.
II FIPS 199, NIST SP Applications resistant to denial of service attacks.
800-30/ 800-53/800-64 Clean up of confidential data in memory and in file systems during failures and shutdowns.
Change SOX, BASEL II, NIST SP Source control. Logging of application changes.
management 800-53/ 800-64 Application change logs accessible only to privileged users and resistant to tampering.

8

OWASP and Other Coding Standards

• 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

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

9

Addressing compliance requirements related to SDLC
Examples of Requirements and
Activity Selected Best Practices
Recommendations
Security “Security planning should begin...by: identifying Examine regulations and standards, potential exploits and attacks, and the
objectives key security roles for the system development; business risks of those exploits and attacks.
and identifying sources of security requirements, Evaluate business requirements in terms of information CIA
requirements such as relevant laws, regulations, and Write “abuse cases” detailing how malicious users might interact with system
analysis standards; and ensuring all stakeholders have a
Define measurable goals for compliance & reducing vulnerabilities
common understanding.” NIST SP 800-64
Threat “conduct an accurate and thorough assessment Describe how adversaries might choose targets, locate entry points, and
modeling of the potential risks and vulnerabilities to the conduct attacks.
CIA of electronic protected health information Identify what specific application defenses the attacker must defeat to be
held by the covered entity.” HIPAA successful.
Architecture “employ architectural designs, software Identify design decisions that can mitigate risk; e.g., use languages such as
and design development techniques, and systems Java and C# to reduce the risk from buffer overflow vulnerabilities, and
review for engineering principles that promote effective validate all user input on servers to prevent attacks that manipulate variables
security information security….” FIPS PUB 200 on clients.
Code review “must conduct a review of custom code prior to Use automated code scanning tools and manual reviews to identify patterns
for security release in order to identify any potential coding such as non-constrained methods, unchecked return values, methods without
vulnerability...by knowledgeable internal exception handling, embedded passwords, and sensitive information
personnel or third parties.” PCI DSS 2.0 disclosed in logs.
Security “must review]public-facing web applications via Rigorously test application components, validate inputs, parse file formats,
testing manual or automated application vulnerability and authenticate users. Conduct extensive penetration testing.
security assessment tools or methods, at least Check for sensitive information exposed in memory and temporary files.
annually and after any changes “ PCI DSS Maintain a unit test library. Have developers crosscheck each other’s code.
Deployment “must develop configuration standards for all Develop checklists to ensure web servers, databases, storage and networking
review for system components...Verify that system systems are properly configured and patched.
security configuration standards are applied when new Remove custom application accounts, user IDs, and embedded passwords
systems are configured....” PCI DSS before applications are put into production.

Compliance and the SDLC

• 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

10

Agenda




Creating an action plan to identify and remediate gaps between
 Conducting an SDLC Gap Analysis


• Conclusion

SDLC Process Assessment – Graphical View
1.) Review Org Structure and Team Roles

2.) Analyze
Policies &
Standards
Requirements

Best Practices

5.) Create Gap Analysis Report
with recommendations

3.) Analyze & 4.) Refine via focused
Aggregate Data Interviews (usually team leads)

11

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 Process
Activity 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

12

Security 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)?

Requirements & 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?

13

Implementation 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?

Verification 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

14

Release & 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

15

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




Creating an action plan to identify and remediate gaps between
• Conducting an SDLC Gap Analysis

 Application Security/Compliance case studies

• Conclusion

16

SDLC Compliance Assessment for Client
High-Level findings
• 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

Case Study: SDLC Assessment for Client
security activity recommendations
How security engineering activities can be layered into a
traditional software development process

17

how recommended activities could have prevented issues

• 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  )

training recommendations

Requirements & Architecture & Code Testing
Analysis Design Implementation
• How to Define Security • Fundamentals of Secure • Classes of Security • Fundamentals of
Objectives (ENG 111) Architecture (DES 101) Defects (TST 201) Security Testing (TST 101)

• Architecture Risk • Fundamentals of Secure • How to Test for OWASP
Analysis & Remediation Development (COD 101) Top Ten (TST 211)
(DES 212) • Understanding Secure
• Creating Secure Code- .NET 4.0 (COD 214)
Application • Creating Secure Code -
Architecture (DES 311) ASP.NET (COD 311)
• Intro to Threat • How to Perform a Code
Modeling (ENG 301) Review (ENG 401)

Everyone: Fundamentals of Application Security (AWA 101)

18

recommendations for requirements gathering
• 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

Design Recommendations

• 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

19

Implementation Recommendations

• Use TeamMentor security guidelines to
apply 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

Verification 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

20

Release Recommendations

• 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

Tools 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

21

Recommended rollout sequencing

• 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

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

22

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.

Sony Case Study: SDLC long-term vision

Define Design Code Test Deploy
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

Threat - Online
Modeling Application
Security Security Code Penetration
Requirements Analysis Testing Security
Security Monitoring
Design Review portal
- Recurring
Architecture Assessments
Use Case and Risk Analysis Metrics (Penetration
Metrics Testing)
Abuse Case – Gathering
Gathering and
Definition and - Reporting
Security Test Reporting
and Review Reporting
Planning

23

Sony Case Study
Training 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

24

Agenda





– AppSec/Compliance case studies

Conclusion

Repeatable, Secure Development Works
A look at the Microsoft SDL

Total Vulnerabilities Disclosed 12 Months After Release Total Vulnerabilities Disclosed 36 Months After Release
187
400

242
157
119
66 34
3
Windows® Windows OS I OS II OS III
XP Vista® SQL Server® 2000 SQL Server 2005 Competing
commercial DB
Before SDL After SDL Before SDL After SDL

45% reduction in Vulnerabilities 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

25

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
Match metrics to
• More efficient use of internal resources
• Less support burden and risk to end users objectives for higher
• Less out-of-pocket expense with outsourced vendors 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

26

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

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

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

27

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

Contact
jtaylor@securityinnovation.com
eadams@securityinnovation.com

28

Mapping application security to compliance

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Mapping application security to compliance