Integrating security into Continuous Delivery

4,141 views
3,913 views

Published on

How to integrate application security into an Agile Continuous Delivery framework.

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,141
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • Threat modeling is about understanding who is going to attack your system, why they are going to attack it, what they are going to target and how they are going to attack it.SQL injection is a classic attack surface. Although we have known about it for 30+ years it is still a vulnerability that gets exploited on a regular basis.
  • Pen Testing is different from Security Testing in that Pen Testers will use all means to compromise the system including social engineering, zero day flaws, security analysis, code analysis, you name it. Security Testing is more about know vulnerability playback.Both are valuable and have their place. Neither is a substituent for the other.Pen testing is a specialized skill set, it is often necessary to get external pen test professionals
  • Example: User shall not be allowed unlimited login attempts. Potential attackers use unlimited login attempts to use dictionary password attack methodsExample: Use shall not be given details regarding authentication failure.Potential attackers can use authentication failure details to figure out if they have legitimate user names
  • Fail safe, it can mean different things based on your application and functionality. Don’t create your own encryption or random number generation, use open standards that have been vetted by industry recognized experts.Use tools to scan you source code for known dangerous code constructs, system and library functions. Replace dangerous code right away.
  • Fail safe, it can mean different things based on your application and functionality. Don’t create your own encryption or random number generation, use open standards that have been vetted by industry recognized experts.Use tools to scan you source code for known dangerous code constructs, system and library functions. Replace dangerous code right away.
  • Use automated secure code review tools to find specific well known problem patterns and to highlight areas where manual reviews should be conducted. Bugs tend to cluster so sections of the code where a number of secure issues are present is a good candidate for a manual code review.
  • All applications are now networked applications and all need application security requirements.
  • Integrating security into Continuous Delivery

    1. 1. Integrating Security into Continuous Delivery Thomas Stiehm, CTO tom.stiehm@coveros.com © Copyright 2012 Coveros, Inc.. All rights reserved. 1
    2. 2. About Coveros Coveros helps organizations accelerate the delivery of business value through secure, reliable software © Copyright 2012 Coveros, Inc.. All rights reserved. 2
    3. 3. SecureAgileTM Development Process adaptability transparency Agility is… simplicity STRATEGY roadmap funding unity goals vision RELEASE secure estimation release plan backlog risk ITERATION threat review analysis Iteration plan retrospectiveburndown model secure DAILY regression pen defensive code standup testing coding I review design CONTINUOUSvelocity TDD collaboration security refactoring integration stories testing secure testing burnup tests risk Working software Assures time-to-market while achieving security objectives © Copyright 2012 Coveros, Inc.. All rights reserved. 3
    4. 4. SecureAgileTM Security Practices Threat Modeling Risk Analysis Pen Testing Security Stories Secure Code Review Defensive Coding and Design Secure Testing – Static Code Analysis – Automated Security Testing © Copyright 2012 Coveros, Inc.. All rights reserved. 4
    5. 5. Threat Modeling Threat modeling is the process of defining a system’s attack surface to support application risk assessments and to determine appropriate security controls. This includes assets that may be compromised and vulnerabilities that can be used to attack the system. Enabler SQL Commands Process SQL Input Database Target Form in XML Enabler User Input ID=48983 SQL Injection Classic Attack Surface Example Figure Source: Carnegie Mellon University Figure Source: Carnegie Mellon University © Copyright 2012 Coveros, Inc.. All rights reserved. 5
    6. 6. Risk Analysis Identify areas of risk in the system, including: – Requirements – Design – Architecture Use abuse cases to drive risk based testing Build scenarios based on identified risks Use risk scenarios to drive security requirements Test risk conditions explicitly © Copyright 2012 Coveros, Inc.. All rights reserved. 6
    7. 7. Pen Testing Penetration Testing or Pen Testing, is the process of attacking a system like a malicious outsider in order to evaluate the security of the system Perform penetration testing for risks uncovered throughout the lifecycle Penetration testing is not a substitute for automated secure code review © Copyright 2012 Coveros, Inc.. All rights reserved. 7
    8. 8. Security Stories  Why write Security Stories? – To make sure all explicit security requirements, both functional and non-functional, are documented and can be used to guide secure development and testing activities  Develop misuse and abuse cases that capture non- normative behavior (attacks) according to your threat model  Think like a potential attacker and use your knowledge of the system architecture and risks  Drive test plans from the abuse cases  Also write functional security stories © Copyright 2012 Coveros, Inc.. All rights reserved. 8
    9. 9. Misuse / Abuse Case Development Purpose: Define the possible mechanisms an adversary might exploit to compromise your system Approach:  “User shall not …” pattern – Misuse cases are extensions to stories that highlight ways in which the system might be misused accidentally – Abuse cases are extensions to stories that highlight ways in which the system might be abused on purpose Results: – Insight into potential abuses that can be avoided and tested © Copyright 2012 Coveros, Inc.. All rights reserved. 9
    10. 10. Defensive Design Software is designed to be secure through: – Identification and integration of security controls based upon the threat model – Use of security protection mechanisms for software startup, reboot, and shutdown procedures – Appropriate and comprehensive error and exception handling of all critical functions – Use of code libraries that have been vetted for security – Use of off-the-shelf components for encryption, random number generation, and other complex mathematical calculations © Copyright 2012 Coveros, Inc.. All rights reserved. 10
    11. 11. Defensive Coding Secure coding is done through: – Avoiding known dangerous coding constructs, system calls and programming short cuts – Continued security scans of new code at each check-in – Proper integration and testing of secure design features © Copyright 2012 Coveros, Inc.. All rights reserved. 11
    12. 12. Secure Testing There are a variety of testing types that must be performed during agile development iterations to assure application security – Functional security testing – testing the capabilities and integration of security controls into the application – Non-functional security testing – testing against the misuse and abuse cases developed during story creation – Risk-based testing – testing the application against the identified threats within the threat model Automation is required for continuous security testing Leverage security testing tools, either Open Source or Commercial tools © Copyright 2012 Coveros, Inc.. All rights reserved. 12
    13. 13. Secure Code Review  Start with automated secure code review tools to find known issues and pinpoint areas in the code to review manually  Review sections of the code manually, focus on areas that the automated tools found to contain a lot of issues, bugs cluster  Real-time secure code review can be done as part of pair programming  Train developers how to do secure code reviews  Automated security analyzers should be run as part of a continuous integration process to identify known coding weaknesses during all builds © Copyright 2012 Coveros, Inc.. All rights reserved. 13
    14. 14. Why Integrate Application Security into CD? To make your application more secure To reduce the cost of Application Security To increase the overall quality of your code base To protect your application from attackers To demonstrate compliance with security requirements To make yourself a hero © Copyright 2012 Coveros, Inc.. All rights reserved. 14
    15. 15. Why Application Security is Difficult Security is an aspect of an application, it isn’t an application feature. No Product Owner will ever pick security over application features Most developers aren’t security experts, very few are even application security aware, most discount security threats or consequences Implementing Application Security processes can be expensive, both in terms of cost to acquire commercial applications and the cost of implementing and maintaining © Copyright 2012 Coveros, Inc.. All rights reserved. 15
    16. 16. Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated security testing using scanners and proxies Level 4: Automated Configuration Management Level 5: Continuous Delivery © Copyright 2012 Coveros, Inc.. All rights reserved. 16
    17. 17. What Static Analysis Does Finds potential defects or flaws in an application by analyzing the application source code All code can be analyzed include: – Java/C#/C/C++/PHP/Etc. – SQL – JavaScript – XML – Most languages used by Enterprise Developers – Remember: Context Matters © Copyright 2012 Coveros, Inc.. All rights reserved. 17
    18. 18. What Static Analysis Finds Static Analysis can find: – Common errors – Unused variables – SQL injection – Cross-Site Scripting (XSS) – Hard-coded passwords – I.E. Things we know about Static Analysis can’t find: – Zero Day Vulnerabilities – Architectural Flaws – Things we don’t know about © Copyright 2012 Coveros, Inc.. All rights reserved. 18
    19. 19. Static Analysis Tools Static Analysis: – Open Source  Sonar for many languages  PMD for Java  FindBugs for Java  PHPMD for PHP  FxCop for .Net  PyChecker for Python  pylint for Python – Commercial  Coverity  Fortify  Built into Visual Studio Ultimate Audit Static Analysis Findings © Copyright 2012 Coveros, Inc.. All rights reserved. 19
    20. 20. Scanner Web application scanners: – Open Source  w3af  wapiti  Skipfish – Commercial  AppScan  Cenzic Hailstorm  WebInspect Complete system scans  OpenVAS  Nmap  Nikto2  Nessus Audit scanner findings © Copyright 2012 Coveros, Inc.. All rights reserved. 20
    21. 21. Proxies Proxies: – Better coverage – XSS and Cross-Site Request Forgery (XSRF) – Data leakage – URLs for logs to augment spidering – Web application proxies:  OWASP Zed Attack Proxy (ZAP) Project  OWASP WebScarab  Ratproxy © Copyright 2012 Coveros, Inc.. All rights reserved. 21
    22. 22. Open Source vs. Commercial There are advantages and disadvantages of both Open Source Advantage: – Free to acquire – Often has a community around it Open Source Disadvantage: – Limit free support (requires more experienced users) Commercial Advantage: – Often better reporting tools (including more help and vulnerability explanations, better for less experienced users) – Paid Support (someone to blame for issues) Commercial Disadvantages: – Limited community – Cost $$ © Copyright 2012 Coveros, Inc.. All rights reserved. 22
    23. 23. Issues in CD Some security testing tools can take a long, long time to run – Ex. A 2 million line of code Java application can take 12-24 hours to complete a Fortify scan So plan for some security testing to happen outside of the 15 minute build CI schedule Expect push back when you implement this from: – Developers – Product Owners – Your Management – Your Security Group © Copyright 2012 Coveros, Inc.. All rights reserved. 23
    24. 24. Security Finding Remediation Create a Remediation Plan (POA&M) Include scope of remediation: – All issues vs. Critical and High – Time frame for remediation Expect Development push bask: – That is the way it works – We don’t have time for that – It is open source, we can’t fix it officially Security Office Negotiation Remediation can take a really long time © Copyright 2012 Coveros, Inc.. All rights reserved. 24
    25. 25. Implementing Agile Application Security  Adopt and use an application security process from the beginning of the project  Create application security requirements with the functional application requirements  Lead the security requirements process, sell the value of good security practices to the business  Development teams need software security training, early  Security practices needs to be burned-in and made part of how the team works  Security work should be done by experienced, technically strong developers  Create application security standards and practices, monitor compliance with the standards  Put security controls into your base software architecture © Copyright 2012 Coveros, Inc.. All rights reserved. 25
    26. 26. Implementing Agile Application Security  Use security tools such as static code analysis and web scanners to verify security controls  Conducting manual security verification like code reviews and penetration testing  Use outside security testers to break the system and look for holes  Problems found in security testing need to be added the team’s backlog  Security tests don’t always fit in time boxes so, if needed, run them as parallel engagements  Consider a “hardening sprint” to focus on fixing the security problems found through security testing © Copyright 2012 Coveros, Inc.. All rights reserved. 26
    27. 27. Thank You © Copyright 2012 Coveros, Inc.. All rights reserved. 27
    28. 28. Supplemental Material © Copyright 2012 Coveros, Inc.. All rights reserved. 28
    29. 29. Vulnerabilities  OWASP Top Ten: – https://www.owasp.org/index.php/Top_10_2010  2011 CWE/SANS Top 25 Most Dangerous Software Errors – http://cwe.mitre.org/top25/  There is a lot of overlap as there are major categories that generate a lot of vulnerabilities  For Example: – Injection Attacks and – Misconfigurations © Copyright 2012 Coveros, Inc.. All rights reserved. 29

    ×