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
Why is it important that software developers and security experts understand the benefits of introducing security in the SDLC?
Did you know that:
1. Preventing defects in design phase requires one-tenth the effort of catching and fixing those at the system test phase?
2. Removing 50% of vulnerabilities prior to deployment or release can reduce configuration management and incident response costs by 75%?
3. Overall, setting security objectives, designing applications with a strategic defense and running attack simulation before release means having a much more stable control of your application, has cost reductions, better performance and reliability?
This webcast (now in PDF version) discusses how security can be implemented in all phases of the SDLC, while aligning your standards to the general compliance.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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,
• 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
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