DevSecOps: What, Why and How Anant Shrivastava, NotSoSecure (Claranet Cyber Security)

About: Anant Shrivastava

Agenda ● What is DevSecOps? ● Why do we need DevSecOps? ● How do we do DevSecOps? ● Integrate Security in Pipeline ● Tools of Trade ● Sample Implementation ● Case Studies

Disclaimer ● I will be listing a lot of tools, It’s not an exhaustive list ● I don’t endorse or recommend any specific tool / vendor ● Every environment is different: Test and validate before implementing any ideas

What is DevSecOps? Effort to strive for “Secure by Default” ● Integrate Security in tools ● Create Security as Code culture ● Promote cross skilling

Why do we need DevSecOps? ● DevOps moves at rapid pace, traditional security just can’t keep up ● Security as part of process is the only way to ensure safety

Shifting Left saves cost & time Developer /QA Penetration Testing

Shifting Left saves cost & time Developer /QA Automated Source Code Review 1 SQL Injection Fewer Man Day Effort No New Deployments Penetration Testing

How do we do DevSecOps? ● DevSecOps is Automation + Cultural Changes ● Integrate security into your DevOps Pipeline ● Enable cultural changes to embrace DevSecOps

Injecting Sec in DevOps

Sample Implementation

Tools of the trade

Tools of the trade

To be or not to be in Pipeline ● API / command line access ● Execution start to final output should be 15 minutes max ● Containerized / scriptable ● Minimal licensing limitations (parallel scans or threads) ● Output format parsable / machine readable (no stdout, yes to json /xml) ● Configurable to counter false negatives / false positives

What about Cloud • The Threat Landscape changes - Identity and Access Management - Billing Attacks • Infrastructure as Code allows quick audit / linting • Focus more on: - Security groups - Permissions to resources - Rouge /shadow admins - Forgotten resources (compromises / billing)

Cultural Aspect ● Automation alone will not solve the problems ● Focus on collaboration and inclusive culture ● Encourage security mindset specially if it’s outside sec team ● Build allies (security champions) in company ● Avoid Blame Game

Security Champion ● Bridge between Dev, Sec and Ops teams ● Build Security Champions ● Single Person per team ● Everyone provided with similar cross skilling opportunities ● Incentivize other teams to collaborate with Sec team ● Internal Bug bounties ● Sponsor Interactions (Parties / get-togethers) ● Sponsor cross skilling trainings for other teams

Security Enablers

Generic Case Study

Case Study

Case Study

More Case Studies

Case Study: Last one I promise Prevention: Patching and Continuous monitoring of Assets

Is it Enough? ● Rite of passage by periodic pen test and continuous bug bounty ● It’s not just important to get feedback but to also action on them ● Risk Acceptance Documentation should be the worst case scenario not your first bet

References • https://www.blackhat.com/docs/us-17/thursday/us-17-Lackey-Practical%20Tips-for-Defendin g-Web-Applications-in-the-Age-of-DevOps.pdf • https://www.sonatype.com/hubfs/2018%20State%20of%20the%20Software%20Supply%20 Chain%20Report.pdf • https://snyk.io/opensourcesecurity-2019/ • https://www.veracode.com/state-of-software-security-report

Key Takeaways ● Security is everyone responsibility ● Embrace security as an integral part of the process, use feedback to refine the process ● DevSecOps is not a one size fit all: your mileage will vary