Recommended
More Related Content
Similar to AddingtheSecToDevOpsBSides (1).pptx for Bsides Nairobi 22 with Joylynn Kirui
Similar to AddingtheSecToDevOpsBSides (1).pptx for Bsides Nairobi 22 with Joylynn Kirui (20)
Recently uploaded
Recently uploaded (20)
AddingtheSecToDevOpsBSides (1).pptx for Bsides Nairobi 22 with Joylynn Kirui
- 1. DevSecOps BSides Nairobi Talk: Adding the Sec in DevOps Speakers | Date; 17th September 2022 Joylynn Kirui Ellan Wambugu 1
- 2. Securing software development 2 What do we mean by Devops DevOps Definition (Development + Operations) DevOps is the union of people, processes, and technology to deliver continuous value to users.
- 3. Securing software development 3 Current DevOps Setup
- 4. Securing software development 4 Threat landscape is changing Breach Vulnerable developer secrets Vulnerable supply chain Electronic Arts Breach Vulnerable Applications Vulnerable ID Verification
- 5. Securing software development 5 What do we mean by DevSecOps? Application PLAN DEVELOP OPERATE DELIVER DevOps Definition (Development + Operations) DevOps is the union of people, processes, and technology to deliver continuous value to users. DevSecOps Definition (Development + Security + Operations) DevSecOps is an evolution in the way development organizations approach security by introducing a security-first mindset culture, and automating security into every phase of the software development lifecycle from design to delivery.
- 6. Securing software development 6 The benefits of DevSecOps MORE SECURE CODE, SHIPPED AT THE SAME SPEED Reduce remediation time by shifting security left Integrate with and secure your existing toolchains Quickly identify new threat vectors
- 7. Securing software development 7 Barriers to DevSecOps adoption WHY IS DEVSECOPS HARDER TO ADOPT THAN DEVOPS Organization and team gaps Skill and knowledge gaps Solutions aren't built for developers
- 8. Securing software development 8 Importance of shifting security left 80 % reduction in security incidents by extending security to development² 60x Security cost to fix a security defect in production versus in development1 62 % of enterprises do not integrate security in the development phase³ 1https://www.gartner.com/doc/reprints?id=1-265CMWW4&ct=210527&st=sb 2https://www.gartner.com/smarterwithgartner/is-the-cloud-secure/ ³Sources: McKinsey Developer Velocity, Microsoft Enterprise DevOps Report, GitHub Octoverse Report 2020
- 9. Securing software development 9 Three themes for successfully securing the developer workflow EMBEDDED SECURITY IN THE DEVELOPER WORKFLOW Developer – First Tooling Native and built-in security capabilities Automation
- 10. Securing software development 10 How security fits in the development lifecycle EMBEDDED SECURITY IN THE DEVELOPER WORKFLOW PRE-COMMIT • Threat modeling • IDE security plug-in • Pre-commit hooks • Secure coding standards • Peer review OPERATE & MONITOR • Continuous monitoring • Threat intelligence • Blameless post- mortems COMMIT (CI) • Static code analysis • Security unit tests • Dependency management • Credential scanning DEPLOY (CD) • Infra as code (IaC) • Dynamic security scanning • Cloud configuration checks • Security acceptance tests
- 11. Securing software development 11 Secure the DevOps Pipelines SECURE THE DEVELOPMENT ENVIRONMENT - INFRASTRUCTURE BE ABLE TO PRODUCE VERIFIABLE AND REPRODUCIBLE BUILDS Compilers Sign properly with validated signatures Builds Produce verifiable build manifests— describing sources, cryptographic hashes of binaries/artifacts and full build parameters Build Machines & Infrastructure Make highly restricted with least privileged access applied and with ephemeral build agents DevOps Services Build and release infra use isolated managed identities and sensitive tenant profiles for isolation Compilers & User Processes Execute in isolation or locked down environments Software on Build Machines Sign properly with validated signatures PREVENT THESE TYPES OF ATTACKS: • Compromised compilers and build machines • Compromised dependencies
- 12. Securing software development 12 Harden Pipeline Access SECURE THE DEVELOPMENT ENVIRONMENT – ACCESS MANAGEMENT ENSURE CODE-TO-CLOUD PIPELINE IS SECURE Create organization device policies – AAD + Device policies - to secure development machines Make sure all operations adhere to least privileged principles Regularly scan for identity access management to ensure least-privileged access management policies Use multi-factor authentication and dual key/JIT approval for privileged operations and human-induced pushes Enable endpoint protection for all workstations and allow only registered devices Inject identity early into the automation pipeline PREVENT THESE TYPES OF ATTACKS: • Compromised credentials • Malicious insiders
- 13. Thank You
Editor's Notes
- Today, we’re going to talk about devsecops and the difference between devops and devsecops in terms of adding security to software rollouts and infrastructure.As Tech permeates most if not all aspects of society it becomes important for the people building software as ourselves to take into account the security aspect of it all.The world now has a really large threat landscape offered to malicious actors.
- Ellan - Devops as a culture has quickly risen to be a go to methodology for companies who want to stay ahead where the connection between devs and IT ops is paramount for an organization from building a product to roll out and support. Problem with DevOps ---
- Ellan - Use this picture to show the complexity of devops leading to security issues Problem with DevOps Set flow to introduce DevSecOps
- Ellan - With this threat landscape changing, we’ve already seen two examples of modern attack vectors; CodeCov and Electronic Arts. In CodeCov’s case, an attacker targeted their developer workflow and software supply chain. The attacker was able to not only gain access to their Google Cloud Storage account but also to upload a new image into thousands of builds that scanned their software supply chain, extracting even more secrets and widening the breach. Another example is EA which recently had source code from one of their games stolen due to stolen cookies that contained Slack login information. They didn’t have the secret or identity protections needed and these vulnerabilities became an easy target. There’s also a recent supply chain security example known as the log4j vulnerability, which has impacted more than 35k+ different java artifacts. The vulnerability, which comes from a popular logging tool in the biggest Java library – the Maven Central Repository - allows an attacker to perform remote code execution by exploiting the insecure JNDI lookups feature exposed by the logging library log4j. This exploitable feature was enabled by default in many versions of the library, allowing this attack to spread to many affected parties all at once. But, this is not just an issue for enterprises… -///Running modern applications on the cloud—which are exposed as APIs, designed as microservices, packaged with containers, and deployed with Kubernetes—introduces new dimensions of risk. Microservices open many perimeters (for many services), have a flexible flow and are constantly/rapidly deployed, which make it even more challenging to address security issues associated with them.as tech pwe see that the threat landscape has increased tremendously ,a while ago only a few devices were at risk.Tech incorporation to our cars,houses even Industrial control centers ,malicious actors now are able to cause massive damage as witnessed in e.g //EA ,CodeCovs cars example **Choose 2 after session
- Joylynn - You may be familiar with how DevOps practices and collaboration between developer and operations teams led to faster software delivery. DevOps combines people, processes, and technology to deliver continuous value to users. DevSecOps is the evolution of DevOps where the company takes on a security-first mindset — putting security into every phase of the development lifecycle, from design to delivery. When implemented successfully, companies gain both the speed of DevOps development practices and the holistic security and peace of mind that comes with DevSecOps. even with DevOps, the aspect of security remained unresolved. While you could improve the speed of deployment without compromising the reliability of the software using DevOps, the software development ended up either being slowed down due to security practices (which are implemented toward the end of the delivery pipeline) or having vulnerabilities that often leak into the production environment. DevOps could help patch these vulnerabilities quickly, but the ideal solution would have been to make the code secure without compromising the speed of delivery.
- Joylynn - However, organizations that adopt DevSecOps unlock the ability to ship code at the same speed, securely. Specifically, DevSecOps helps organizations: Shift their security left to occur at more critical points throughout the development lifecycle, aiding to lower vulnerability remediation time. It also helps organizations to form a seamless workflow by integrating into existing toolchains. More so, this aids organizations to continually identify new threat vectors.
- Joylynn - DevSecOps presents barriers and inefficiencies for developers that we don't find with DevOps. These include: Organization and team gaps: Some organizations have security-specific teams who own all of security. This siloes DevOps and SecOps teams and leads to a fragmented security culture. Skill and knowledge gaps: When DevOps and Developer teams don’t see security as part of their responsibly, the skill base stays solely within the SecOps team. Third, solutions are not being built for developers, leading to issues like false positives . False positives are high because the tools live with security teams rather than developers. Since security teams are more likely to scan repositories than developers, they may only run them once a quarter, causing them to be higher than the rate would be if these tools lived with developers. Another issue is that we also see misaligned expectations. In DevOps, having a 30% failure rate on Unit Tests is considered very bad. However, in security, having a 30% failure rate is actually good. While you are always dealing with a trade-off between false positives and false negatives, security prefers no false negatives and more false positives. However, a developer doesn't want any false positives and doesn't care as much about false negatives.
- Joylynn - To safeguard the developer cloud against these new threat types, the answer is to shift security left and leverage cloud-native security. Shifting left helps enterprises find and remediate vulnerabilities earlier and across their development lifecycle. Enterprises that extend security to development reduce security incidents by 80%. And it’s not just a reduction in events, there is also a financial component. It costs 60 times more to fix a security defect in production than in development. Blending security and development together within the development workflow remains a challenge for many enterprises. While more enterprises are starting their transforms, there are 62% of enterprises that have yet to integrate security into the development phase. Now, how do we start shifting security left and moving to cloud-native environments?
- Joylynn - To successfully implement DevSecOps, there are three themes that need to be considered: The first is making sure to provide developer-first tooling that empowers developers to be more cognizant of the security impacts of the code they’ve created. The second is to remove any friction for developers, by providing data and built-in automated security capabilities natively-integrated into their workflow. The third is to apply automation to all of these different checks and within the developers’ workflows on their day-to-day. So instead of coming up with a huge list of vulnerabilities that need to be fixed, developers are constantly being guided in the right direction through continuous security feedback. Now, let's talk about how we can realize these themes within the developer workflow:
- Each stage of the development lifecycle has unique security components, that when used together help prevent threats at all critical junctions. For pre-commit: It’s important to start with a focus on threat modeling and understanding the threat landscape, to grasp the overall risk of what you are looking to bring to execution in code. Employ a range of IDEs, security, plugins, and pre-commit hooks to make sure that the code you’re generating adheres to the security standards. This step also helps ensure there are no vulnerabilities created unintentionally. Don’t forget to hold peer reviews to align different teams about the security risks and code that they recently introduced into the code-base. When it comes to the commit stage: It’s time to start taking on more extensive security methods to review the code, including static code analysis. Security unit tests may involve running scanners or performing manual tests on running code. In this stage, remember to review dependency management and the overall dependency tree for inherited vulnerabilities. After this is complete, you can check for credentials that may have been inadvertently introduced into the code-base. This is called credential scanning but may also be known as secret scanning or token scanning. In the deploy stage: We look at the overall health of the code-base and, in addition to the items checked in the commit stage (which can be repeated in the deploy stage), we also look at the infrastructure-as-code (IAC) segments, which are necessary for identifying abstracted layers of infrastructure. In Deploy, you also need to examine the high-level security risks, cloud configuration checks, and security acceptance tests to make sure everything is in line with the expectations and organizational security goals. Once code is being deployed: Now it’s a matter of operating and monitoring through continuous monitoring and additional threat intelligence, which not only helps visualize results; it also covers the overall dependency vulnerabilities that may be inherited over time. Make sure to hold additional post-mortems, so your teams take away lessons learned, and to continue iterating as you move through the development lifecycle. Run Static and Dynamic Tests: Another aspect of securing the developer workflow is through assessing our own created code. One of the ways to check our code is with Static and Dynamic analysis. It’s best to use a combination of these techniques to make sure that the findings are prioritized in the right way. Let’s look at the techniques: Static analysis: Examines the code-base and finds potential vulnerabilities that may be present in the code being created. Dynamic analysis: Reviews running code and runs simulated attacks on the code-base itself. Both techniques use automation, so inspect automated security reviews in different stages of the code as you move through the milestones of a project. Running one of these methods will provide a good view of the security levels of the project before deployment. But running multiple techniques throughout the life cycle yields the best results as it provides full visibility of the code and potential effects. If followed correctly, these practices will help your business defend and remediate common technical application security attacks. sast in 1.Code use codesonar 2.building use tainted data analysis in build to detect code injection Check for Hard-Coded Secrets: Secret scanning is another component that needs to be secured within the developer workflow. Specifically, secret scanning looks at secrets (also known as “credentials” or “tokens”) that can be hard-coded into the code. While this process can be lengthy if done manually, you can easily enable automation to help you: Prevent secrets leaving development machines with push protection While detecting previously leaked secrets by scanning full git history And you can even resolve issues faster with automated resolution (e.g., revoking found credentials) Secret scanning helps any organization fend off attacks like: Privilege escalation by internal actors due to leaked credentials in private repos And infrastructure compromise due to leaked credentials in public repos //tools such as Microsoft threat modelling tools,git-secrets,goSDL,pytm,Threagle
- Ellan - DevOps Pipelines are another important consideration when securing the development environment. To ensure your organization is producing verifiable and reproducible builds you’ll need to adjust security at every point from compilers to build machines. Let’s take a look at each step in more detail: Compilers Confirm that each compiler signs properly with validated signatures. Builds Produce verifiable build manifests—describing sources, cryptographic hashes of binaries/artifacts and full build parameters. Build Machines and Infrastructure Make these highly restricted with least privileged access applied and with ephemeral build agents. DevOps Services Build and release infrastructure uses isolated managed identities and sensitive tenant profiles for isolation. Compilers and User Processes Execute in isolation or locked down environments. Software on Build Machines Sign properly with validated signatures. Practices like these secure your organization from threats like: Compromised compilers and build machines (Electronic Extreme – video game company, is an example of this type of breach) Compromised dependencies (An example is the Copay application attack) -- Notes: Compromised compilers (more examples from the first attack type) Link 1 : https://faun.pub/zombie-infestation-software-developer-tools-the-ms-visual-studio-attack-7fc8cd257eb9 Link 2 : https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain/ Compromised build machines (more examples from the first attack type) Link 1 : https://www.wired.com/story/inside-the-unnerving-supply-chain-attack-that-corrupted-ccleaner/ Compromised dependencies (more examples from the second attack type) Malicious dependency – event-stream attack: https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident
- Joylynn - In order to ensure the code-to-cloud pipeline is secure, organizations need to do the following: Create AAD and device polices that will secure development machines. For example, if a device gets lost, wipe the device. Ensure all operations adhere to least-privileged principles. A privileged operation means granting more privileged access, adding a user, changing build / deployment steps, etc. Run regular Identity Access Management scans that enforce least privileged access policies Use multi-factor authentication and dual key/IT approval for privileged operations and human-induced pushes, like CI/CD. Dual key addresses credential loss and malicious insiders, which is critical to use. Enable endpoint protection: Imagine if a developer’s laptop was affected by ransomware… To protect these endpoints, deploy an endpoint protection platform, including next-generation antivirus (NGAV) to protect against unknown and zero-day malware, behavioral analysis to identify anomalous activity on an endpoint, and vulnerability scanning. And lastly, inject identity early in the automation pipeline: Injecting identity as early as possible into automation pipelines is a key step to minimizing the exposure of sensitive accounts and credentials. This way, your DevOps team can remove static credentials from code, replacing them with just-in-time credentials that help to reduce the threat surface and enterprise-wide risk. Fortifying identity controls like this helps protect against attacks like: Compromised credentials (2018 eslint incident is a good example of this type of attack) Malicious insiders -- Leaked credential example: Malicious maintainer - ESLint-Scope attack: https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes // https://francescodeliva.medium.com/devsecops-with-github-f8b9d07702c3
- Thank you for this opportunity to share with you how DevSecOps can accelerate and transform your business.