voiding the Security Potluck: Integrating Cloud Exposure Management Into DevOps Toolchains | DevOps Connect: DevSecOps 2023

Hello everyone. My name is Litter and I'm a product manager at Tenal. I primarily focus on cloud security, and today I want to talk to you about exposure management and how to avoid the security pot.

Have you ever been to a potluck or a hosted one? The idea is that each person brings something unique to the party instead of the host having the responsibility to provide all of the food. Now everybody wants to contribute something special to make the pot potluck memorable.

Although everyone brings something different, there is no coordination among the participants. Generally, each person acts independently without considering the overall menu or complimentary dishes. And this is what you get.

All the dishes are amazing on their own, but not necessarily work together. Just like the potluck, a similar situation offer occurs in the world of cybersecurity. Many organizations recognize the importance of securing their assets and deploying, um, and deploy a variety of security tools to protect their systems and data.

However, if these security tools are not properly coordinated and integrated, they can create a fragmented and inefficient security strategy. Each tool may serve a specific purpose and provide value on its own, but they may not work together seamlessly to provide comprehensive protection, or in other words, without coordination. These separate security tools can lead to blind spots and missed vulnerabilities.

Just as the potluck lack to unified vision, organizations may face challenges in identifying and prioritizing security risks, responding to incidents, and maintaining a strong security posture. Now this slide should look familiar to technical organizations who are building solutions on the cloud. You first plan your solution, you split it into smaller pieces, and for each piece or a story, you have a continuous integration pipeline where developers contribute code to a single repository and various checks are placed to ensure software committed passes.

The standard tests and guardrails. CI pipelines, generally speaking, end with some sort of testing. As you can see on the screen here, the CD pipeline that takes over, which is continuous deployment and is in charge of deploying the solution to the cloud.

So this includes a couple of different steps, including releasing the solution, managing security on a deployed solution on an ongoing basis, and also monitoring drifts and zero day vulnerabilities. Finally, you need to, you need governance to continuously assess your solution for, for threat detection, uh, and report on compliance and risk, uh, so you can security manage and reduce the attack surface. Now, the problem is that each part of this pipeline, excuse me, the problem is that each part of the pipeline is managed and owned by a different team, and therefore security is implemented in silos.

This leads to blind spots. The end result of that is too many silos that can lead to fragmented security measures, inconsistencies and gap in security coverage. Too many tools that can lead to inefficient workflows, data inconsistencies and difficulty in obtaining a unified view of your security posture.

Too many policies that can result in policy overload, making it difficult for teams to keep up with and implement the necessary controls. And finally, too many alerts that can overwhelm security teams leading to alert fatigue and a decreased ability to prioritize and respond to critical security incidents. The problem is that you might think since you work in silos, a problem in a given area is constrained to that area only.

However, attackers are not attackers do not honor security silos. This is an actual attack path, a real world incident. An attacker might come in from a cloud asset or an on-prem premise asset by compromising a misconfiguration and then quickly move laterally to exploit a known C V e in another system.

This might lead to the attacker getting privileged access and further compromising the system leading to revenue loss, data breaches, and overall damage to reputation and customer trust. So how can we make better security solutions to address these problems? First, we need to transition from a siloed security practices to unified approach where every asset and risk are viewed as part of a single attack surface while considering the connections between the different systems.

Such a unified approach leads to improved visibility, streamlined security operations, and a comprehensive understanding of the organization's overall security posture. Second, security findings by themselves are not enough. It is essential to understand how they translate into actual exposures and potential impacts in terms of lost revenue, privacy reaches, and lack of compliance coverage.

And finally, we need to shift from a reactive security practice to a preventative one with the right policy guardrails and security practices early on in the software development lifecycle to address and to identify and address vulnerabilities and exposures right from the outset. So this is where we want to hit in our exposure management journey. Having more context about security threats, vulnerabilities and exposure enables organizations to make more informed and effective decisions.

We need to shift from more of a reactive approach to a preventative approach and mindset in security and exposure management. Being reactive means responding to security instances, uh, incidents after they occur, whereas being preventative means proactively identifying and addressing vulnerabilities and exposures before they can be exploited. And finally, the better and improved communication leads to better outcomes by enabling prompt response, more efficient incident management and effective implementation of security controls and measures.

Let's go back to the picture we saw earlier, including security in the planning phase of the software development. Life cycle is crucial for building secure and resilient systems. So when you plan your software, you need to come up with the right security related KPIs and threat models, which will then, um, lead into the, uh, remaining guard guardrails and constraints in the rest of the phases in the continuous integration pipeline.

On the code side, a popular way to put in policies is using the pre-commit hooks that developers can use to check their work, including scanning IAC or infrastructure as code files before committing to an s e m. In the build phase, you can have the same policies checked for vulnerabilities in your images that are built from your code. Finally, in the test phase, you can use dynamic application security testing D or interactive application security testing, I A S T in order to put in some guardrails in place.

Moving on to the deployment cycle, there are a couple of different things to look for on the release side using a continuous deployment engine like GI Ops, which, uh, two examples are Flex CD in Argo cd, uh, again gives you a way to put in guardrails with web hooks to apply the same policies that you applied in the continuous integration cycle. Once your software is deployed, you need to then manage, uh, and have well-defined incident response plan to handle security incidents in a timely and effective manner. Furthermore, the work is not done yet.

You need to then be able to monitor your software, uh, as deployed on the cloud for drift deviations, uh, as well as zero date, uh, threat. Finally, all of this sits on top of your cloud runtime governance, uh, in which you need to take care of drift management, uh, continuance assessment, and, uh, um, look at policy automation in order to reduce your attack surface. Here's an example of an open source tool called tecan, uh, developed by Tenable that you can use to scan your ISE files.

In this particular example, the command that is run as TECAN scan and essentially it goes through your current directory and recursively all the other directories to look for ISC files and report on policy violations. In this case, it has found a couple of high end medium policy violations. One of the high violations is that your r d s database instance is not encrypted.

If you want to try a terra scan on your own, you can scan this QR code. It takes you to a sandbox where you can put in your own is D files and, uh, scan that using terra scan. Here's an example in your C I CI pipeline build phase.

Uh, in this case, you've scanned your built images, uh, again using policies defined on the Tenable platform, and it has, it is reporting vulnerabilities by severity and by uh, V P R. And finally, here's an example of how Tenable enables you to, uh, determine coverage, compliance coverage on different cloud accounts or multi-cloud environment, all within the same, uh, pan of class. So hopefully that gives you an idea of how taking an exposure management view of cloud security can better align DevOps and security teams.

It is really important to take a unified and preventative approach to security to avoid tool policy and alert overload, uh, and avoid the potluck situation. This enables each team to run the same security policies using their preferred workflow, and at the same time provides a comprehensive security and exposure management. Thank you.