MTC2018 - Shifting Security to the Left the Right Way

Speaker: Yannarak Wannasai

As software development evolves, it is vital to shifting security “to the left” earlier in the software development life cycle (SDLC) to make application security move faster with lower cost. This session will discuss on why application security needs to shift left and how to build a modern security engineering organization with a shift-left approach.

Transcript

1. Shifting Security to the Left the Right Way Yannarak Wannasai Engineering Manager (Security)
2. Engineering Manager Security Yannarak Wannasai
3. Shifting Security to the Left, The Right Way
4. What we are covering today: • Why is Security important to Business? • What is Shift-left Security? • How can we shift security to the left?
5. ここにテキストをかく。こ こにテキストをかく。ここ にテキストをかく。ここに テキストをかく。く。ここに Source: Verizon 2017 Data Breach Investigations Report Web App Attack is the Main Culprit of Data Breaches
6. ここにテキストをかく。こ こにテキストをかく。ここ にテキストをかく。ここに テキストをかく。く。ここに Cyber Attack is on the Rise “Since December 2017, a dataset containing more than 200 million lines of Japanese personally identifiable information (PII) were sold on the Chinese underground market” -- FireEye. Source: https://www.securityweek.com/200-million-sets-japanese-pii-emerge-underground-forums
7. Data Breach Cost is Extremely High Number of victims 5,198,142 people Number of incidents 386 incidents Estimated total indemnity 191,427,420,000 yen Number of victims affected per incident 14,894 people Estimated avg. indemnity per incident 548,500,000 yen Estimated avg. indemnity per victim 23,601 yen Data of personal information leakage incidents in 2017 Source: http://www.jnsa.org/result/incident/ (Information as of Aug 2018)
8. Why Application Security is Still Missing • Application Security is not taught in most universities or colleges. • Most people in security teams have a networking or system administrator background. • Strict constraints on time and resources. • Application Security is HARD!!!
9. Shift-Left Security in Layman’s Term “Start security at the very beginning and perform security in every step of the SDLC.” -- Tanya Janca, a senior cloud developer advocate for Microsoft, specializing in application security. Requirements Design Code Release Testing Security
10. Why we should shift left
11. It’s Cheaper to fix security issues early “Shifting security left significantly saves time, money and company resources.” Coding Build QA & UAT Production $80 / Defect $240 / Defect $960 / Defect $7600 / Defect Source: Ponemon Institute Research
12. Security is Outnumbered!!! DEV / OPS / SEC 100 / 10 / 1
13. Faster time to market! Security does not win if the business does not also win.
14. Shift-left Security = Modern AppSec Program
15. Modern Application Security Program • Define Standard Security Requirements • Threat Modeling • Automated Security Testing • Security as Code • Security Awareness & Education
16. Define Standard Security Requirements
17. Why are Security Requirements Important? • Security vulnerabilities allow software to be abused in ways that the developers never intended. • Having security requirements helps developers to clearly understand what security functionalities need to be implemented.
18. Application Security Verification Standard 3.0.1 • First application security standard • by developers, • for developers. • • Defines 3 risk levels with around 150 controls Source: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
19. Application Security Verification Standard 3.0.1 • Level 1 contains 82 controls • Minimum required for all applications. • Mostly fully testable. • Mostly automatable. Source: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
20. Strategy to Define Standard Security Requirements 1. Start with ASVS level 1 2. Get your developers in the room and fork ASVS 1 so THEY AGREE AND DECIDE on all requirements they will care for. 3. Now you have the beginning of a secure coding standard agreed upon (and that is key) by your developers 4. Then, working with developers, grow the list over time.
21. Conduct Threat Modeling
22. Designated Hackers Project A Project B Project C Security Team Security Security Security Security Security Security NW Monitoring Automated Test Endpoint Security Security Policy Security Security Security Security PM EM Backend Frontend iOS Android PM EM Backend Frontend iOS Android PM EM Backend Frontend iOS Android Security Security Security Supporting Projects (Both of Business and Development) Our Own Projects
23. Getting Security into Requirements • Security team should understand what developers are working on and what their priorities are. • Security team should participate in planning meetings to: ◦ Offering support on threat modeling ◦ Help review and fill in security-related and compliance-related stories, and other high-risk stories.
24. • A description / design / model of what you’re worried about • A list of potential threats to the system • A list of actions to be taken for each threat • A way of validating the model and threats, and verification of success of actions taken What is Threat Model? Source: https://www.owasp.org/index.php/Application_Threat_Modeling
25. How to Threat Model? • What are we building? ◦ Architecture diagrams, Data-flow transitions, Data classifications • What can go wrong? ◦ Brainstorming with Developers ◦ STRIDE, CAPEC, Cyber Kill Chain • What are we going to do about that? • Did we do a good enough job? Source: https://www.owasp.org/index.php/Application_Threat_Modeling
26. Sample Threat Model for Login Feature Bruteforce Attack Credential Stuffing Enter username & password User Authentication Lock out account after N failed login attempts Block IP address after N failed login attempts Includes Includes Includes Account Takeover Includes Includes User Hacker Application Server Threatens Mitigates Mitigates
27. Augmenting Requirements with User Stories and Misuse Cases Misuse Story #07— Account Takeover with Bruteforce Attack "As a malicious user of Mercari Japan, I want to take over the account of another user so that I can steal his/her personal data or commit fraudulent transactions."
28. Non-Functional Requirements #07 – Secure Login "Implement security controls to protect Mercari users from Account Takeover attacks." Functional Requirements #08 "A user account must be locked out for 30 minutes after 6 failed login attempts within 30 minutes." Functional Requirements #09 "If 300 or more failed login attempts originate from a single IP address within 60 minutes then that IP address will be blocked for 30 minutes." Functional Security Requirement is preferable.
29. Automate Security Testing
30. Writing Unit Test • To ensure that code is being developed in compliance with secure coding standard requirements. • Here are some common security test cases: ◦ Authentication & Authorization ◦ Input Validation & Encoding ◦ Error and Exception Handling
31. Writing Integration Test • Integration tests can be written using Postman, Selenium, Cucumber. • You may also use test frameworks such as Gauntlt, Mittn, BDD-Security.
32. Static Application Security Testing (SAST) 1. Identify specific classes of vulnerability you care about most, and start with them. 2. Eliminate false-positives. 3. Produce vulnerability reports that can directly be consumed by developers themselves. 4. Once stable, add 1 or 2 more vulnerability classes. 5. Repeat.
33. Pro Tips for implementing SAST • Start with the easiest to implement ◦ Command Execution. ◦ Use of vulnerable functions or 3rd-party components. ◦ Hard-coded AWS/GCP tokens. • Build an alert when sensitive and rarely changed portions of the codebase have been modified.
34. Dynamic Application Security Testing (DAST) • Most DAST tools act as an intercepting proxy between your browser and the target sites. • Only vulnerabilities with a fairly standard signature can be identified: ◦ SQL Injection, XSS, CSRF, Path Traversal, Misconfiguration. • There are paid and free options available.
35. Pro Tips for Implementing DAST • Ensure you have permission from your boss. • Inform all stakeholders when you start and finish. • Run a scan on a separate environment that is identical to the production environment. ◦ Be careful, scanners can be destructive. ◦ Be considerate, scanners can hog resources. • Do not carelessly run it. ◦ Check if a session is still valid. ◦ Update CSRF tokens and/or request signatures.
36. Security As Code
37. What is Security as Code • Building security into DevOps tools and practices. • Making security an essential part of the tool chains and workflows. • Using Continuous Delivery as the control backbone and the automation engine for security and compliance.
38. Understanding the current workflow • What happens when a change is checked in? • Where are the repositories? Who has access to them? • How do changes transition from check-in to production? • What tests are run? Where are the results logged? • What tools are used? How do they work? • What manual checks or reviews are performed and when? • How can you take advantage of all of this for security and compliance purposes?
39. Commit Change Build Test Deploy to Staging Acceptance Test Deploy to Production Continuous Integration Acceptance Stage
40. Commit Stage (Continuous Integration) • Identifying risk in third-party components ◦ OWASP Dependency Check • Incremental static analysis scanning • Alerting on sensitive code changes • Automated unit testing of security functions
41. Acceptance Stage • Secure, automated configuration management and provisioning of the runtime environment ◦ Using tool like Ansible, Chef, Puppet, and/or Docker ◦ https://dev-sec.io/ • Automated functional and integration testing of security features • Targeted dynamic scanning (DAST) (can be done out of band) • Deep static analysis scanning (can be done out of band) • Manual Security Testing (out of band)
42. Production Deployment and Post-Deployment • Automated deployment and release orchestration (authorized, repeatable, and auditable) • Post-deployment smoke tests • Production monitoring/feedback • Implementing Event Driven Security • Blameless postmortems (learning from failure)
43. Stackdriver Logging Cloud Pub/Sub Cloud Function Slack Cloud Armor Event Driven Security
44. Security Awareness & Education
45. OWASP Proactive Controls 2018 Source: https://www.owasp.org/index.php/OWASP_Proactive_Controls
46. OWASP Cheat Sheet Series Provides a concise collection of high value information on specific web application security topics Developer Cheat Sheets • Authentication • Session Management • Access Controls • Input Validation • Output Encoding • Logging • ... Mobile Cheat Sheets • Android Testing • iOS developer • Mobile Jailbreaking Defender Cheat Sheets • Virtual Patching • Vulnerability Disclosure Breaker Cheat Sheets • Attack Surface Analysis • Web App Security Testing • REST Assessment • ... Source: https://www.owasp.org/index.php /OWASP_Cheat_Sheet_Series
47. SAFECode Training • Software Assurance Forum for Excellence in Code (SAFECode) provides free training and secure coding guidelines, including: ◦ Security Development Lifecycle 101 ◦ System Hardening 101 ◦ Basic Practices for Secure Development of Cloud Applications ◦ Introduction to Cryptography ◦ Threat Modeling 101 ◦ And many more Source: https://safecode.org/training/
48. Security Champions Program Main advantages of having a team of Security Champions: • Scaling security through multiple teams • Engaging "non-security" folks • Establishing the security culture
49. Who is a Security Champion? • Someone who wants to upgrade security. • Someone who can make decisions about when to engage the Security Team. • Someone who can act as the "voice" of security for the given product or team. • Someone who is willing to assist in the triage of security bugs for their team or area.
50. Steps to Build a Security Champion Program 1. Identify teams 2. Define the role of Security Champion 3. Nominate Champions 4. Set up communication channels 5. Build solid knowledge base 6. Maintain interest Source: https://www.owasp.org/index.php/Security_Champions_Playbook
51. Key Takeaways for Today • Verify for security early and often. • Automate the security tasks as much as possible. • Security is everybody's job.