[2018.05 Meetup #1] [TALK #1] Pedro Farinha - DevSecOps, Rugged DevOps, Shift left Security…Good sense really!

Transcript

1. Some key practices to Shiftleft software security Maio 2018 DevSecOps software engineering consulting
2. Pic from : https://www.slideshare.net/magnologan/devsecops-integrating-security-in-the-development-process-with-memes-magno-logan
3. Agile, CI/CD and DevOps… (and the human need to label stuff…) Graphics from: synopsis.com, xebialabs and Segue Technologies CI/CD…CD Software Life-cycle Tools Automation DevOps Culture People Colaboration Process Change Acceleration AGILE
4. DevOps : Software Delivery is a Well-oiled machine
5. DevOps : Smooth Handover
6. But….Cybersecurity…
7. Just DevOps…Security is lagging!
8. Door #1 - Compromise on security?
9. But If you do… Few hundred more… https://www.hackmageddon.com/2018/04/19/ march-2018-cyber-attacks-statistics/
10. But If you do… (the PT_PT version, because it does not happen only to others!) https://observador.pt/2018/03/31/funcionaria -condenada-por-alterar-dados-do-fisco-juiza- critica-sistema-de-seguranca/ http://leitor.exameinformatica.pt/#library/exameinformatica/09-09-2017/edicao- 31/noticias/epal-falha-deixa-um-milhao-de-portugueses-vulneraveis-a-hackers https://pplware.sapo.pt/informacao/hospital-garcia-da-orta-atacado-piratas-informaticos/
11. Door #2 …
12. DevSecOps brings organization together to “attack” security from (before) Requirements Elicitation Source code CI Server Test & Scan Components Run and Monitor Deploy DevOps -> Creates value With efficiency DevSecOps – Builds In Security and trust
14. The Sec bit in the DevOps Cycle & toolchain
15. SSL:Secure Sockets Layer:Shift Security Left Typical Model : • Pen Testing in production • Fuzz Testing … sometimes React to patch up Security! Security Defects Source: Bitwise Global Secure Software Development Life Cycle (S-SDLC) Requirements Design Code Test Deployment Maintain Vulnerabilities What security is needed Design security in Security built in Assert Security in Mitigate the remaining Start again  requirements… Defects
16. Let´s get down to business!
17. Start Raising the Questions: AM I SECURED? Where is the code? Is the code secure? What is the risk of the code? Is risk acceptable? Is there a plan to mitigate the risk to acceptable levels? THE CODE Are OSS versions secure? (old, deprecated, blacklisted, etc.) COMPONENTS LIBRARIES & OSS What OSS is being used? What is the risk associated with this OSS use? Am I allowed to use it? (Licencing) What are the defects? Are there critical defects? How is risk evolving? Who defines the rules? Who approves exceptions? GOVERNANCE CONTRACTS Are my contractors aware of my policies /constraints Are they prepared/trained/capable to address the risk level I am exposed to Are SLA’s in place? Are they cooperant? Am I able to transfer risk? My team knows how to develop Secure Code? My team is developing Secure Code? PEOPLE My team knows what is Secure Code? Do I have a Security “coach” enabled for the project
18. Act by maintaining reusable artefacts Accelerate Security Requirements Elicitation by maintain a list of applicable requireements for type of application OWASP Application Security Verification Standard Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.
19. Act by maintaining reusable artefacts Accelerate Planning by pre-defined type of testing With reusable scripts ISECOM Open Source Security Testing Methodology Manual (OSSTMM) What you get from utilizing OSSTMM is a deep understanding of the interconnectedness of things. The people, processes, systems, and software all have some type of relationship. OWASP Testing Project : includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
20. Act by maintaining reusable artefacts Microsoft Attack Surface Analyzer : - Developers view changes in the attack surface from changes - IT Professionals assess the aggregate Attack Surface change - IT Security Auditors evaluate the risk of a particular piece of software installed - IT Security Incident Responders gain a better understanding of the state of a systems security during investigations Keep architecture attack surface and threat Model up-to-date : Analise only changes OWASP Attack Surface Analysis Cheat Sheet simple and pragmatic way of doing Attack Surface Analysis and managing an application's Attack Surface. It is targeted to be used by developers to understand and manage application security risks as they design and change an application.
21. Act by maintaining reusable artefacts Mitre CVE – Common Vulnerabilities and Exposures CVE® is a list of entries—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities Accelerate design by Keeping/build a list of “trusted” componentes to be reused NIST National Vulnerability Database The NVD includes databases of security checklist references, security-related software flaws, misconfigurations, product names, and impact metrics
22. ACT by Automate security Test, Security Analysis and Verification throughout the complete SDLC Determines Violations of Componentes used automated security Tests (owasp zap, owtf,…) Assert acceptable security On Pull Request Do security Analysis on IDE prior to commit Update the attack Surface
23. Key take aways  Detect and resolve security issues quickly • Self-service testing • Automated Analysis • Break-the-build-if-unsafe • Know what you’re using • Develop with Forensics in mind  Enlisting and enabling the organization • Detect, contain and prevent • Maintain up-to-date Incident response • Deploy RedTeam/BlueTeam/Coaches • Metrics and communication • Educating inline with bit-sized chunks
24. software engineering consulting Consultoria em Engenharia de Software A SHIFTLEFT presta serviços especializados em engenharia de software suportados em ferramentas e técnicas que melhoram o sucesso de projetos, controlam a qualidade estrutural dos produtos, monitorizam a produtividade e reduzem os custos de desenvolvimento e manutenção Pedro Farinha pedro.farinha@shiftleft.pt (+351) 910581770 Lucas Gros lucas.gros@shiftleft.pt (+351) 938808225 Shiftleft - Av. da República, nº6, 1ºEsq. 1050-191 Lisboa, Portugal Powered by