Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mapping application security to compliance


Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mapping application security to compliance

  1. 1. Mapping Application Security to Compliance Ed Adams Jason Taylor CEO CTO Security Innovation Security InnovationAgenda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
  2. 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 competencyApplication 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
  3. 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 planningAgenda• 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 3
  4. 4. Aligning Development Processes with CorporatePolicies• 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 jobsThe Corporate Application Compliance Frameworkaligning development with management policies 4
  5. 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 expensesThe 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 5
  6. 6. The Corporate Application Compliance FrameworkBase 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 complianceAgenda• 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 6
  7. 7. Aligning Development Activities with ComplianceSecurity 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 programAligning 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
  8. 8. Aligning Development Activities with Compliance: 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-64Data 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 800-53/ 800-64 Application change logs accessible only to privileged users and resistant to tampering. 8
  9. 9. Aligning Development Activities with Compliance: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 recommendationsCompliance 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
  10. 10. Addressing compliance requirements related to SDLC Examples of Requirements and Activity Selected Best Practices RecommendationsSecurity “Security planning should identifying Examine regulations and standards, potential exploits and attacks, and theobjectives 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 CIArequirements such as relevant laws, regulations, and Write “abuse cases” detailing how malicious users might interact with systemanalysis standards; and ensuring all stakeholders have a Define measurable goals for compliance & reducing vulnerabilities common understanding.” NIST SP 800-64Threat “conduct an accurate and thorough assessment Describe how adversaries might choose targets, locate entry points, andmodeling 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 asand design development techniques, and systems Java and C# to reduce the risk from buffer overflow vulnerabilities, andreview for engineering principles that promote effective validate all user input on servers to prevent attacks that manipulate variablessecurity 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 patternsfor security release in order to identify any potential coding such as non-constrained methods, unchecked return values, methods without 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 networkingreview for system components...Verify that system systems are properly configured and 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
  11. 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 SDLC Process Assessment – Graphical View 1.) Review Org Structure and Team Roles2.) 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
  12. 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, tooAssessing your Existing Development ProcessActivity Matrix Product A Product B Product CDefine Security Objectives X XApply Security Design Guidelines X XThreat Model X XSecurity Architecture and Design Review X XApply Security Implementation Guidelines XSecurity Code Review X X XSecurity Penetration Testing X X XApply Security Deployment Guidelines XSecurity Deployment Review X3rd party Security Penetration Test X X XSecurity Incident Response Plan X X X 12
  13. 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? 13
  14. 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 14
  15. 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 15
  16. 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 changeAgenda• 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 16
  17. 17. SDLC Compliance Assessment for ClientHigh-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 auditsCase Study: SDLC Assessment for Clientsecurity activity recommendationsHow security engineering activities can be layered into atraditional software development process 17
  18. 18. Case Study: SDLC Assessment for Clienthow 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  )Case Study: SDLC Assessment for Clienttraining 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
  19. 19. Case Study: SDLC Assessment for Client 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 Case Study: SDLC Assessment for Client 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
  20. 20. Case Study: SDLC Assessment for ClientImplementation 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-inCase Study: SDLC Assessment for ClientVerification 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
  21. 21. Case Study: SDLC Assessment for ClientRelease 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 planCase Study: SDLC Assessment for ClientTools 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
  22. 22. Case Study: SDLC Assessment for ClientRecommended 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 cracksSDLC 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
  23. 23. SDLC Case Study: SonySony 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
  24. 24. Sony Case StudyTraining recommendations Product A Product B Product CHow to Define Security Objectives PM, SC PM, SCApplication Security Fundamentals E EAttacker Techniques Exposed O O OArchitecting Secure Solutions O O OSecurity Architecture and Design Review A, SC A, SC A, SCThreat Modeling A, D, SC A, D, SCCreating Secure Code Java DCreating Secure Code – C# and ASP.NET D DConducting a Security Code Review D, SC D, SC D, SCClasses of Security Defects D, T D, T D, TWeb Vulnerabilities – Threats & Mitigations D D DSecurity Testing T T OSony 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
  25. 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 ConclusionRepeatable, Secure Development WorksA look at the Microsoft SDLTotal 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 SDL45% 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
  26. 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 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 successConclusion• 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
  27. 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 TestingeKnowledge 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 engineeringApplication 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
  28. 28. Try eLearning for free Free eLearning Course for Attending • Introduction to Threat Modeling • Fundamentals of Application Security • How to Conduct a Code Review WhitepaperMapping Application Security to Compliance Contact 28