SDLC & DevSecOps
- 1. Magnus Klaaborg Stubman, Improsec A/S Irina Kostina, Microsoft Security Development Lifecycle methodology & DevSecOps
- 2. Equifax breach 2017 Equifax's CEO and other executives resigned following a backlash over the hack at the company that compromised the data of 143 million people The thieves spent 76 days within Equifax's network before they were detected. $700 million to settle federal and state investigations $425 million to directly help consumers affected by the breach $1.4 billion: Amount Equifax has spent on upgrading its security in the wake of the incident
- 3. In contrast with: SQL Injection : Extracts Starbucks Enterprise Accounting, Financial, Payroll Database Bounty : 4000$ https://hackerone.com/reports/531051
- 4. Development Methodologies SDLC Dev Test Deploy to ProductionDev
- 5. Development Methodologies SDLC Dev Test Deploy to ProductionDev Dev Deploy to ProductionTest Dev Test Dev Test Dev
- 6. Development Methodologies SDLC Dev Test Deploy to ProductionDev Dev Deploy to ProductionTest Dev Test Dev Test Dev ?
- 7. Development Methodologies SDLC Dev Test Deploy to ProductionDev Dev Deploy to ProductionTest Dev Test Dev Test Dev ? ?
- 8. Development Methodologies SDLC Dev Test Deploy to ProductionDev Dev Deploy to ProductionTest Dev Test Dev Test Dev
- 9. Development Methodologies SDLC Dev Test Deploy to ProductionDev Dev Deploy to Production Test Test Test
- 10. Development Methodologies SDLC Dev Test Deploy to ProductionDev Dev Deploy to Production Test Test Test Training Training
- 11. Development Methodologies SDLC Dev Test Deploy to ProductionDevTraining
- 20. Development Methodologies SDLC How easy/hard is it to get rid of the solution?
- 21. Development Methodologies SDLC How easy/hard is it to get rid of the solution? How easy/hard is it to move the solution?
- 22. Development Methodologies - summarized SDLC • Your mileage may very – one size does not fit all
- 23. Development Methodologies - summarized SDLC • Your mileage may very – one size does not fit all • Waterfall approach may increase reliability, but reduce predictability
- 24. Development Methodologies - summarized SDLC • Your mileage may very – one size does not fit all • Waterfall approach may increase reliability, but reduce predictability • Agile approach may increase predictability, but reduce reliability
- 25. Development Methodologies - summarized SDLC • Your mileage may very – one size does not fit all • Waterfall approach may increase reliability, but reduce predictability • Agile approach may increase predictability, but reduce reliability • Training is a one time cost, and gives value over time
- 26. Development Methodologies - summarized SDLC • Your mileage may very – one size does not fit all • Waterfall approach may increase reliability, but reduce predictability • Agile approach may increase predictability, but reduce reliability • Training is a one time cost, and gives value over time • Ask yourself: • What do you need? • What works in your organization?
- 27. Internal Quality Assurance (QA) SDLC • Definition of Done: • Implemented according to Standards • Unit test cases has been written for all functionality • Documented • Code reviewed by colleague • Documentation review by colleague • dependency-check reports 0 vulnerabilities
- 33. Security – all or nothing?
- 34. Security – all or nothing? • Cost • Productivity hit • Security hit • Horror stories?
- 35. Security – all or nothing? • Cost • Productivity hit • Security hit • Horror stories? • Start over?
- 36. Security – all or nothing? • Cost • Productivity hit • Security hit • Horror stories? • Start over? • The most important step is the first! • Get started • Incremental improvements • Try, try and try again
- 37. Segmentation
- 39. Segmentation / Isolation / Separation
- 41. Simplicity
- 44. Simplicity Silver Bullets • Complex code • Hard to read
- 45. Simplicity Silver Bullets • Complex code • Hard to read • Hard to review
- 46. Simplicity Silver Bullets • Complex code • Hard to read • Hard to review • Hard to maintain
- 47. Simplicity Silver Bullets • Complex code • Hard to read • Hard to review • Hard to maintain • Hard to add new features
- 48. Simplicity Silver Bullets • Complex code • Hard to read • Hard to review • Hard to maintain • Hard to add new features • Hard to replace/deprecate
- 49. Simplicity Silver Bullets • Complex code • Hard to read • Hard to review • Hard to maintain • Hard to add new features • Hard to replace/deprecate • Lower developer satisfaction
- 50. Simplicity Silver Bullets • Complex code • Hard to read • Hard to review • Hard to maintain • Hard to add new features • Hard to replace/deprecate • Lower developer satisfaction • Harder to pentest
- 51. Simplicity Silver Bullets • Complex code • Hard to read • Hard to review • Hard to maintain • Hard to add new features • Hard to replace/deprecate • Lower developer satisfaction • Harder to pentest Expensive!
- 53. Security as a Cultural Phenomenon • Policies, guidelines from management → top-down approach
- 54. Security as a Cultural Phenomenon • Policies, guidelines from management → top-down approach • Security awareness, security trainings → bottom-up approach
- 55. Security as a Cultural Phenomenon • Policies, guidelines from management → top-down approach • Security awareness, security trainings → bottom-up approach • Code review after pentest → teammeeting, walk through vulnerabilities, talk about mitigations pros/cons. No finger pointing, only learning.
- 56. Security as a Cultural Phenomenon • Policies, guidelines from management → top-down approach • Security awareness, security trainings → bottom-up approach • Code review after pentest → teammeeting, walk through vulnerabilities, talk about mitigations pros/cons. No finger pointing, only learning. • "What are we doing to prevent this from being abused/exploited?"
- 57. Security as a Cultural Phenomenon • OWASP • "Top 10": https://owasp.org/www-project-top-ten/ • Present one topic each once a week, during a lunchmeeting
- 58. Security as a Cultural Phenomenon • OWASP • "Top 10": https://owasp.org/www-project-top-ten/ • Present one topic each once a week, during a lunchmeeting
- 59. Security as a Cultural Phenomenon • OWASP • "Top 10": https://owasp.org/www-project-top-ten/ • Present one topic each once a week, during a lunchmeeting • Copenhagen: https://owasp.org/www-chapter-copenhagen/ • Aarhus: https://owasp.org/www-chapter-aarhus/
- 60. Silver Bullets - summarized SDLC • Segmentation • Simplicity • Culture
- 61. Provide Training Ensure everyone understands security best practices. Define Security Requirements Continually update security requirements to reflect changes in functionality and to the regulatory and threat landscape. Define Metrics and Compliance Reporting Identify the minimum acceptable levels of security quality and how engineering teams will be held accountable. Perform Threat Modeling Use threat modeling to identify security vulnerabilities, determine risk, and identify mitigations. Establish Design Requirements Define standard security features that all engineers should use. Define and Use Cryptography Standards Ensure the right cryptographic solutions are used to protect data. Manage the Security Risk of Using Third- Party Components Keep an inventory of third- party components and create a plan to evaluate reported vulnerabilities. Use Approved Tools Define and publish a list of approved tools and their associated security checks. Perform Static Analysis Security Testing Analyze source code before compiling to validate the use of secure coding policies. Perform Dynamic Analysis Security Testing Perform run-time verification of fully compiled software to test security of fully integrated and running code. Perform Penetration Testing Uncover potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses. Establish a Standard Incident Response Process Prepare an Incident Response Plan to address new threats that can emerge over time. Microsoft SDL
- 62. Provide Training Ensure everyone understands security best practices. Define Security Requirements Continually update security requirements to reflect changes in functionality and to the regulatory and threat landscape. Define Metrics and Compliance Reporting Identify the minimum acceptable levels of security quality and how engineering teams will be held accountable. Perform Threat Modeling Use threat modeling to identify security vulnerabilities, determine risk, and identify mitigations. Establish Design Requirements Define standard security features that all engineers should use. Define and Use Cryptography Standards Ensure the right cryptographic solutions are used to protect data. Manage the Security Risk of Using Third- Party Components Keep an inventory of third- party components and create a plan to evaluate reported vulnerabilities. Use Approved Tools Define and publish a list of approved tools and their associated security checks. Perform Static Analysis Security Testing Analyze source code before compiling to validate the use of secure coding policies. Perform Dynamic Analysis Security Testing Perform run-time verification of fully compiled software to test security of fully integrated and running code. Perform Penetration Testing Uncover potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses. Establish a Standard Incident Response Process Prepare an Incident Response Plan to address new threats that can emerge over time. Microsoft SDL
- 63. #5 : Threat Modeling
- 65. Identify defects as early as possible Development Business requirements Operations Users Feedback loop Monitor
- 66. Development Business requirements Operations UsersDevelopment Business requirements Incremental Threat Modeling DAST Operations Users Dedicated Pentesting Vulnerability Scanning Monitoring Periodic pentesting Validation SAST Fast feedback loop DevSecOps Secure Deployment https://azsk.azurewebsites.net/
- 67. Static Application Security Testing https://owasp.org/www-community/Source_Code_Analysis_Tools https://github.com/features/security + • Scales well (only needs the code) • Finds vulnerabilities earlier in the process •Highlights the precise source files, line numbers, subsections of lines - • Many types of security vulnerabilities are difficult to find automatically • High numbers of false positives • Frequently can’t find configuration issues, since they are not represented in the code •Difficult to ‘prove’ that an identified security issue is an actual vulnerability https://sonarcloud.io/
- 68. #10: Dynamic Application Security Testing - • Not highly scalable • No code visibility • Slow scans + • Technology independent • Low false positives • Identifies configuration issues https://docs.microsoft.com/en-us/previous-versions/software-testing/cc162782(v=msdn.10) https://www.g2.com/categories/dynamic-application-security-testing-dast https://marketplace.visualstudio.com/search?term=security&target=AzureDevOps&category=All%20categories&sortBy=Relevance
- 69. SAST DAST White box security testing The tester has access to the underlying framework, design, and implementation. The application is tested from the inside out. This type of testing represents the developer approach. Black box security testing The tester has no knowledge of the technologies or frameworks that the application is built on. The application is tested from the outside in. This type of testing represents the hacker approach. Requires source code. SAST doesn’t require a deployed application. It analyzes the sources code or binary without executing the application. Requires a running application DAST doesn’t require source code or binaries. It analyzes by executing the application. Finds vulnerabilities earlier in the SDLC. The scan can be executed as soon as code is deemed feature-complete. Finds vulnerabilities toward the end of the SDLC Vulnerabilities can be discovered after the development cycle is complete. Less expensive to fix vulnerabilities. Since vulnerabilities are found earlier in the SDLC, it’s easier and faster to remediate them. Findings can often be fixed before the code enters the QA cycle. More expensive to fix vulnerabilities Since vulnerabilities are found toward the end of the SDLC, remediation often gets pushed into the next cycle. Critical vulnerabilities may be fixed as an emergency release. Can’t discover run-time and environment-related issues. Since the tool scans static code, it can’t discover run-time vulnerabilities. Can discover run-time and environment-related issues Since the tool uses dynamic analysis on an application, it is able to find run-time vulnerabilities. Supports all kinds of software. Examples include web applications, web services, and thick clients. Typically scans only apps like web applications and web services. DAST is not useful for other types of software.
- 71. Where do I start? aka.ms/sdlc Implement Use the implementers’ resources guides to create an implementation plan that advances your SDL maturity. Self-assess Review the self- assessment guide to assess your organization’s current SDL maturity level. Identify Identify where your organization falls on the SDL Optimization Maturity Model.