2022 DOI SKILup Days_Your Developers Decide Your Security Posture_Not Your Security Teams.pptx
Download as PPTX, PDF0 likes43 views
The document discusses the importance of integrating security within the DevOps lifecycle, focusing on DevSecOps as a shared responsibility across teams. It outlines challenges faced in cloud-native security and proposes strategies for scaling DevSecOps adoption by empowering developers and fostering collaboration. The text emphasizes the need for cultural change, accountability, and trust to ensure developers are engaged in security processes, ultimately aiming for a more agile and secure development environment.
2022 DOI SKILup Days_Your Developers Decide Your Security Posture_Not Your Security Teams.pptx
- 1. © 2022 Devops Institute DevSecOps SKILup Day Your developers decide your security posture, not your security teams Turja Narayan Chaudhuri
- 2. Thank You all for being here. And , a Big Thank You to the DevOps Institute for hosting this event, and inviting me over . I hope you all have a wonderful session.
- 3. A brief about me - • Currently , I am working as an Assistant Director, Cloud Practice at EY (Ernst & Young). • Before that I led the CCOE ( Cloud Centre Of Excellence) Team at Accenture. • I have around 10+ years of IT experience, working on Public Cloud technologies since 2017.
- 4. Expectation management - • This is not an introductory session on how to get started with DevSecOps, or shift-left security. • It is expected that the audience for this session is already familiar with a high-level understanding of security challenges in modern software systems, and DevSecOps – principles and practices.
- 5. Overall Agenda - • Section I - Context : Challenges with cloud- native security • Section II - Solutions : DevSecOps • Section III – Scaling DevSecOps Adoption : Developer Relations • Section IV - Conclusion
- 7. •Section I - Context : Challenges with cloud-native security • Section II - Solutions : DevSecOps • Section III – Scaling DevSecOps Adoption : Developer Relations • Section IV - Conclusion
- 8. Cloud-native applications refer to applications which have architectures that are conceptually built and run to take advantageof the distributed computing that is normally offered by the cloud delivery model. What is cloud-native? History of Cloud Native
- 9. There has been tremendous growth in Cloud-native ecosystem, especially in use of Kubernetes, over the last couple of years. It has become the de-facto standard for application deployment everywhere. Growth of cloud-native ecosystems State of Cloud Native Development : This shows the rapid growth in containerization ecosystems (CNCF, 2020)
- 10. But, at the same time, security concerns are among the most crucial topics in the radar of enterprises today. Challenges with sustained inorganic growth
- 11. The current model of implementing security does not work well for cloud-native ecosystems. It has quite a few challenges : Lack of visibility Large number of entities that must be secured Misconfigurations Diverse architectural patterns need to be secured Inability to enforce consistent policies Environments are in a flux Security challenges for cloud-native
- 12. • Section I - Context : Challenges with cloud-native security •Section II - Solutions : DevSecOps • Section III – Scaling DevSecOps Adoption : Developer Relations • Section IV - Conclusion
- 13. Perimeter security, or just securing the boundary, or the traditional model of having a security team to do all the testing will not work any more. We need to do things differently !
- 14. Traditionally, how was security handled by enterprises? • The role of the security team was restrictedto a specific team, that too postponedtill the last stage of deployment. • This was okay when development cycles lasted months or years.
- 15. In today’s age of frequent deliveries, say weeks/even days, outdated/traditional security practices can hamper the most efficient DevOps practices.
- 16. What needs to change? • A more collaborative approach between the different teams needs to be enforced. • Security needs to be treated as a shared responsibility across the enterprise, not handled in silos. • Security tools needs to be injectedinto the software development lifecycle, integrated end-to-end, and enforced from the start of the project, not as an after-thought.
- 17. So, what exactly is DevSecOps? • DevSecOpsstands for development, security, and operations. • It's an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.
- 18. This is also tied with Shift-Left Security • The idea is to inject security controls early in the software development lifecycle, so that issues/vulnerabilities can be identified at the beginning rather than at the end. • This effectively streamlines the development lifecycle, drastically improves quality, and enables faster delivery of business value by quick progression to future stages in the product development lifecycle.
- 19. • Section I - Context : Challenges with cloud-native security • Section II - Solutions : DevSecOps •Section III – Scaling DevSecOps Adoption : Developer Relations • Section IV - Conclusion
- 20. There are a lot of aspects that are at play when an enterprise wants to successfully adopt DevSecOps. Some of them might be : Cultural change Executive buy-in Leaders and enthusiasts to act as evangelists Cross-functional teams Measurable indicators How do I scale DevSecOps adoption across my enterprise?
- 21. But, at the hear of it all is - Developer Relations
- 22. Developer Relations – What is it? DevRel, or developer relations, is a process for nurturing mutually beneficial relationships between organisations and software developers. In other words, it’s a collection of strategies and tactics that help companies to work better together with software engineers (developers). Exactly what developer relations teams do and why they do it depends on what their organisation needs.
- 23. Why do developers matter for enterprise security. • No adoption initiative can succeed without enthusiasm from developers. • Security is no exception, and the more we are trying to shift-left, the more we need to empower developers, involve them in the processes.
- 24. So, what are some of the things that as an enterprise, we can do , to solve this problem?
- 25. 1 . Empowerment • Developers should be a part of the planning/strategy phase of DevSecOps adoption in the journey. • They should have a say in what processes, principles and practices should be brought in. • They should be treated as change agents, and their inputs also considered for key decisions that are taken at the start of the adoption journey.
- 26. 2 . Cyclic Accountability • Security teams should be accountable to developers as well. • They should take time to educate developers and explain the rationale behind their choices and decisions. • Security constraints should not appear as a diktat, rather a consensus should be reached after collaborative discussion making.
- 27. 3 . Trust • If developers are involved in the process from Day1, they will be as accountable for the success of the initiative as the executive or security teams. • They will trust the findings of the security teams, and adhere to the guidelines if they had a part in drafting them.
- 28. 4 . Information Democratization • Information should not be maintained in silos. • All relevant documentation should be available to the developers. • They should even have privileges to suggest changes or raise issues in case something is not working in the ground.
- 29. 5 . Self-Service • Developers should be able to consume security tools via self-service. • The process to onboarda new product/project onto a security management platform/vulnerability scanner should be simple and seamless. • There should be no friction, and developers should not have to wait or talk to different people to get a simple job done.
- 30. 6 . Federated Governance • A governance structure should be established to maintain high-level control of the adoption process. • This could be a central excellence team with representatives from all teams, followed by local representation in Service Line teams. • Developers should be able to reach out to this team for generic guidance or in case of conflicts.
- 31. 7 . Right to dissent • Enterprise should meet developers where they are and not try to drag them on an executive sponsored journey which is not aligned with the developer community. • Developers should have the right to flag issues in current security processes if they hamper progress, with a strong focus on including their insights to incrementally transform the initiatives.
- 32. • Section I - Context : Challenges with cloud-native security • Section II - Solutions : DevSecOps • Section III – Scaling DevSecOps Adoption : Developer Relations •Section IV - Conclusion
- 33. If you do not involve developers in your journey, they will find a way to bypasseven the most stringent policies.
- 34. Like it or not, even with the most sophisticated security guardrails, end of day, if you want security with agility, you need to ensureyour developers are aligned with your vision and equally invested in the process.
- 35. TurjaChaudhuri- LinkedIn Thank you so much !!
- 36. © 2022 Devops Institute DevSecOps SKILup Day Your developers decide your security posture, not your security teams Thanks for Watching Why not continue the conversation in the Experts Corner?