Building a DevOps Supply Chain on Zero Trust Principles
- [Chris] Alright. Good morning, everybody. How y'all doing today? - [Audience] Good. - [Chris] It's pretty good. For 8:30, I wasn't sure how many people were actually gonna get up rise and shine, so I think we have a pretty good crowd. I'm gonna introduce myself.
My name's Chris Federico, unlike the presentation, I'm not TJ Gonen. TJ had an emergency this morning, and I'm gonna take over on his behalf. So he apologizes for not being here. I am Check Point's leader for the Cloud Security Division for Sales and Engineering. And I'm gonna go over what it is to build a DevOps supply chain on zero trust principles. So, quick disclaimer.
I'll leave it up here for 30 seconds or so, but everyone's seen it in the past, so just adhere to the disclaimer. And what are we gonna talk about today? We're gonna recap some basic principles, first of Zero Trust. I'm gonna go over some breaches, attacks, and trends that have happened in the last couple of years.
And then we're gonna talk about how you infuse Zero Trust into a DevOps supply chain. And then we're gonna go over some solutions and value propositions around how we do that in Check Point. So, let's take a moment to recap what Zero Trusts is. Many of you have seen the term. If you're here in security or working in cybersecurity for a long time, you've probably followed on this journey.
So I'm gonna recap it into three key pieces. Number one is verify things explicitly. Number two is grant least privilege access. And number three is to assume breach. And where are the principles of Zero Trust coming from? They started back in late 2003, early 2004 in the Jericho Forum. It was a security consortium where people together came up with this idea of de-perimeterizing, no more perimeter.
Understanding that the perimeter was starting to die and you needed to take a different approach to how you explicitly verified people, assume that you had this breach. And that went on until around 2009 when Forrester actually coined the term, "Zero Trust". And this started a trend. So you'll see in the past companies like Google and Microsoft have published papers, if you're familiar with "BeyondCorp", and bringing this principle of Zero Trust forward. Fast forward to today, you see Zero Trust being used frequently in many different areas.
You see people promoting it. But we're gonna get into the details of what that means for the DevOps supply chain. So the question is, are we actually eliminating all the levels of trust today? And we believe the answer is no. And I'm gonna go into why.
First, you have places such as verifying network users. You implement frameworks around application access, micro segmentation, you have identity and access controls. But still what happens is you have these headlines on a regular basis. So number one would be API leaks. Constantly seeing that APIs are implemented, they're implemented quickly. They have the wrong kind of access controls, the wrong kind of identity management, and then data is leaked and taken out.
The second is around the supply chain. So you'll have very good examples of repos that are compromised. Packages which have vulnerabilities that end up being pushed out through open source channels.
A developer might explicitly take that package, install it, start using it. You've used it for two or three years, you have no idea that there's a vulnerability in there. And this goes into repo-jacking, which is something that's easily overlooked. And if someone takes over your repo, inserts a couple pieces of code, next thing you know you have a piece of crypto mining JavaScript on the front end of your website. And to give you an idea of what that looks like, these packages here that you have, the top 10 packages from Docker containers are downloaded over 18 billion times a year. And when you look and you scan those what you'll see is that they still fail critical tests because they all have vulnerabilities in them, things that haven't been explicitly fixed and you're putting into production.
And that's very, very scary. And we have these trends. So you'll see that in 2022 the API Trends Report shows an explicitly large amount of vulnerabilities, that 63% of people have had a breach. And now you're consistently seeing a trend where more and more spend is going into building things and deploying them quickly in the cloud. So most organizations moving 2/3 of all of their spend into cloud services, which means you're moving faster and you're moving faster and developers are gonna continue to move forward, and you have to be able to explicitly verify what they're doing. So, some trends in the last 12 months, and just for the guys in the back, could you put the presentation up here on the computer? And we see that there's lots and lots of specific attacks, and I'm just gonna walk down here for a minute.
Explicitly though, misconfigured services. How many people have a service in the cloud what they found it was misconfigured and had to roll something back? Can I see a show of hands? Yeah. And exploits that take advantage of known vulnerabilities and open source code. So these are common trends that we're seeing.
And one really big one that I wanna talk about is secrets that get stolen from a source code repository. So another show of hands, anyone ever had someone say, "We accidentally pushed our AWS Key or Microsoft Key or service account into a GitHub, and we need to go revert that." So, already a few hands here. This is a really common thing that happens. Super important that you understand how to prevent it, and has a giant impact, right? It seems really small or like it doesn't have, can't have such a big impact until you realize that a developer could do it by accident.
Check in the code, go remove it, not realize it's in the git history, for example. And then it can live there forever. Or they take it, they paste it in Microsoft Teams, they paste it in Slack, "Hey, take this."
Don't realize that someone else is in that channel, they have access to that secret key which gives you access to all of the production workloads. Somebody can go change it. Another really big area here that we want to talk about is vulnerabilities of internally deployed code.
And we're gonna see some statistics in a minute around pushing code that you know is vulnerable. So some of these trends here, 87% of responders believe the difference between Cloud-Native applications and the rest of their apps require a different set of technologies and policies. So you need to take a different approach here.
The traditional cybersecurity approach won't work when you're moving to the cloud. When you're moving quickly, things are moving closer to the developer and they're moving all the way left. So one of the biggest ones here is maintaining a constant policy that matches what you did in the data center, and then moving it to the cloud.
The second big thing here is having multiple different types of controls from different products, and not being able to act, actually manage them in an easy and simple way that makes it effective. The third is having the lack of actual visibility into your public cloud infrastructure, understanding the types of assets you have and knowing what's going on. And last, I wanna talk about the lack of clarity on the shared responsibility model.
Many times if anyone here has had to go in their board of directors and asked them, "Well, don't you get security from AWS? Don't you get it from Microsoft? Don't you get it from your cloud provider?" You probably have to go back and explain how that's a shared security model. That they provide security for the infrastructure, they'll provide you some tools, but it's up to you whether you are a CISO, you're an operator, you're an analyst, to make sure that those are implemented properly, that you have the right additional controls on top all the way up from the bottom of the infrastructure. And last was 22% of respondents looked and said, "Our existing security tools don't support Cloud-Native environments." So that's almost one fourth of people not realizing that they have to take a different approach. and this stuff changes as developers move faster and faster. How many people here have seen a trend where you used to be in charge of a certain level of security, and now it moved to a developer? So, few hands here.
That's gonna consistently grow and grow as you see things moving towards application and Cloud-Native development. So software gets released without going through the right security checks. Almost half of respondents said yes. Security lacks visibility controls into the development process.
Again, 40% said yes. So you can see that there's a consistent trend here. And as you continue to go through the digital transformation journey, that's going to evolve and become more relevant. And this is where I find I get a little bit scared. Security can't keep up.
And question is, do you push out code knowing that it has vulnerabilities in it? Half of respondents said, "Yes, we do that regularly." Extremely scary. 31% of respondents said, "We do it occasionally."
So right there, we're at almost 80% of people saying, "Hey, at some point we know some code is really vulnerable. We push it out anyways." And, you know, a very small amount of people saying that they're not doing it. Maybe they don't know that it's actually happening inside of their organization. And when you ask why it's, "Hey, we had to meet a critical deadline.
We'll remediate it later in a different release, or, "I put a WAF in front of it, I think it will be fine." Or, "We felt the vulnerability was low risk, it was only in one specific package." And one that I always find really interesting here, "Vulnerability was discovered too late in the development cycle, so we had to go forward with the release. We didn't wanna stop anything."
So these are common problems that you have, and these are reasons why we want to focus on making it easy and shifting security left for the developer. Because in all of this, who's the most privileged user that we have? And that's gonna be your developer, your operations, and your DevOps people. So look at developers for a second and understand what do they have access to, and then start to think about implementing that Zero Trust set of principles. They have access to your existing code base, they have access to everything you have in development.
They can compile code, they can take it, build a binary insert, something into the binary, as you know, in the source code after they've checked it out, send it into production. So all of these things here need to be thought about when you're looking at what a developer does, right? How are you actually helping them improve quality assurance? What kind of security awareness training are you doing with developers in making sure that they understand how critical it is. Then you have on the operation side people who deploy and install code.
They're always working to improve the delivery time. And they maintain infrastructure, they monitor, and so on. And as you bring these things together, this is where we go and you actually get a person who's supposed to be doing DevOps. And DevOps can be defined differently in every organization.
But this is where you want to build a pipeline on trust, where threats are actually being exploited. And that's a different way of looking at how you do cybersecurity today. Making sure that you're pushing things closer to DevOps, closer to developers, and actually building trust. So what's the solution? You want to infuse everything you do around DevOps and supply chain with a Zero Trust principle. That means going from code, build and test, release and deploy and operate. And then also in looking at the other tools, how are they communicating? What are you planning with, right? What are you monitoring with, et cetera.
And this is really critical. How many people here actually work and implement shift left technologies for security today? So, couple of hands, maybe like 10% of the audience. So there's no one valve that stops everything, right? You don't want to put something in place that stops a developer from doing what they need to do. You want it to be something that they can use and you want to have the ability to enable them, not to be a blocker and an enforcer. And the way that we approach that is we look at having automated gradual responses across multiple control points.
That means having the right controls at the code level, giving them the tools to scan the code. And we're gonna talk about that in a second. Second is having the right tools at the application layer, putting the right controls in place, looking at workloads and then at infrastructure. And by having these different places in these different points, it lets you tweak everything to your organization's needs without being a blocker. And this is how we look at this. And we want to think about security being born left.
So start with your code and understand what are you putting in place to actually help that developer. Tools that are easy to use. They do Static Code Analysis, they give them feedback quickly, they make sure that they have actionable things that they can do to go remediate the code. The second is to look at infrastructure as Code scanning.
So infrastructure is code, for those who don't know, a way of writing infrastructure as code using services like Terraform, Ansible, and so on, and making sure that you're using best practices there. So scanning those templates, making sure you didn't make simple mistakes. So everyone knows basic example, "I accidentally made my S3 bucket public and it has all my customers information in it, healthcare data, et cetera." So you want to implement those principles and controls as early on as possible to prevent it from going into production, then having to remediate it later.
The next one is secret scanning. So, as I mentioned before, this is something that's really easy to do. Very hard to go and figure out where the secret went after it happened. That means you want to implement the right tools inside of the pipeline.
For example, if you're using Azure DevOps, when you go and you actually deploy all of your code you should have a tool that's scanning to make sure you didn't accidentally leave the secret in there, and you can prevent it from actually going into the repository or going into production. The next area is here, how are you managing your API tokens and your access? So if you're not using the right tools and the right vaults to actually control this access, you're not implementing checks on APIs. So if you're not doing the basics, again, just authentication and authorization, then you're gonna have a big problem because it's an open vector that's easily overlooked for data to go out.
And then really just going back to the basics on misconfiguration. So starting all the way back with the developer, you can prevent many, many mistakes from happening and ease up the workload that you have as things go into production. And when you get to the build phase, this is where you can enforce security and compliance standards. That means implementing those Zero Trust permissions, ensuring that your developers have only the access that they need, and they can request or elevate permissions when they need it. Then focus on areas like Kubernetes and workload configuration. So, making sure you have the right guardrails.
Are you implementing the right types of admission controls so that somebody doesn't go and launch something, for example, in the most basic way as a root user. And as you go through here you should look and figure out how do you code and move to build in an automated way. The right type of packaging, making it easy to scan image repositories, take those results, automate them, and give them to a developer to remediate in a way that's meaningful. And last is to look at what do you have for containers in serverless protection? Understanding the workload. So, as those workloads get deployed, you want to have visibility into them. You want to understand how the container is built.
What are the packages that are being used? Do you have an old version of Python or Node that has something that's explicitly known to be exploitable? And make sure that you remediate that. Typically people did this with a vulnerability management program, but that's changed today. You don't just scan from the outside with a tool, you scan from the inside. You want to have access to every workload that's running, be able to look inside, understand how it's built, and make sure you take the right type of remediation. And that goes into implementing continuous image scanning.
And last is what do you do with all of the information that you get back? You want to make sure you have a way that gives you an effective way to manage that risk. So tools that distill it down to the most actionable things. How many people here have received like 10,000 alerts in a day and didn't know what to do with them? Almost everyone, I hope, right? Because it's happened at some point. And the idea here is that a developer can't get 10,000 alerts and go take action. You want to have the right tools that give you the visibility, but then prioritize based on the attack surface, the type of workload, the impact that it has on your organization.
And you want to focus on having what we call effective risk management in Check Point. And so we implement that by understanding all of the context and places. And that's a critical aspect when you're thinking about how to take action with a developer. So look at it from an infrastructure level first. Understand what you have. Second is to apply capabilities at the workload level, from virtual machines to containers to serverless.
Give developers tools to have insight and to take action. And then look at how those things are built and deployed in the CI/CD pipeline, and work towards a developer-first security model. And we do that today with Check Point by implementing all of those guardrails, and we call that from code to cloud.
So shifting all the way left from the first day someone writes a line of code, to the day that that workload goes into production. It's been built all the way through its lifecycle till you deprecate it and you shut it down. So, just to recap, what are the paths here? Have deep visibility into all layers, alright? From infrastructure to workload to what's being coded.
Second is work towards implementing that developer-first security model by integrating the right code quality gates, and put them at the right junction points. You want to have enough visibility in checks without building friction for your developers. Look at security, posture management, and compliance.
Understand how things are configured in your cloud environments. Make sure that you have the right type of reporting and the right people to take action. Take a layered approach. There's no one tool that fits and does everything, right? Putting that one gate and then trying to funnel everybody through it. You want to have the right tools at the right place for all of your developers.
From code protection to application security for APIs, for workload and on the network. And then infuse that with the right type of threat intelligence so you can find the unknown. So, how do you apply what you learned today? One, hug a developer. If there's a developer here, I will hug you at the end of the show. Look at conducting the right type of proof of concept around Cloud-Native application protections. Access yourself.
Do you have frictionless tools? Do you know how to identify those blind spots in your environment? Do you have customized way to prioritize all of your risk? And understand what the impact is so that you can make a developer's job easier. And in the next six months, this should make it easier for you to do things right. So with that, thank you very much.
Appreciate everyone's time this morning. (audience clapping) If anyone has any questions, please feel free to ask. - [Attendee] What are some of the examples of scanning tools that you can use for finding leaked secrets? - [Chris] So the question was, what's an example of a tool that you can use to scan code to find leaked secrets? So, last year we acquired a company called Spectral in Check Point where one of its primary use cases is to scan for secrets. So there are some other open source tools available, and other vendors do implement some of that. One of the main reasons that we acquired the company was for the secret scanning capability. So when we did customer interviews, they said, "We never realized the amount of impact that it would have on us."
And I'll give you an example. This company had a very mature security program, and they said every time somebody leaks a secret in the company, we have to get five different people to stop what they do, right? Because it takes two people to go and do the key rotation. We have to have somebody go scrub it. I have to open a change control, stop deploying things to production, roll it back. So it was a really big impact for them, and this is one of the reasons we acquired the company is the tool brought them that level of help. (Attendee 2 speaking indistinctly) - [Chris] So the question was around the four phases of the life cycle and how to take a different view of them? - [Attendee 2] Yeah.
- [Chris] I would say that you want to have a holistic view across everything, and then in each one of those areas there's key things that you want to focus on. But your holistic view should be to apply and infuse those principles across everything. - [Attendee 2] Is this for one of them, or all four? - [Chris] It's all four. - [Attendee 3] And how do you measure yourself successfully while applying Zero Trust? - [Chris] Yeah, very good question. So the question is how do you successfully measure yourself in implementing Zero Trust? I think the best way to do that is to make sure that you develop a program around what you want to do. So the companies that I work with who are the most mature have implemented a clear set of objectives that they want to go to.
And if you want, at the end I can show you some places to find reference around building a mature cloud security program. And then they measure themselves and they score themselves against how many of those things that they wanted to achieve. So, we can go through some of those key things that you should implement, and I can give you some guidelines. (Attendee 4 speaking indistinctly) - [Chris] Yeah, so the question was, what are some key performance indicators you can look at to gauge your level of Zero Trust in DevOps? I think the first one would be understanding how many incidents you've had that came from a developer related deployment, for example.
The second one would be measuring how many bug fixes and things you had for critical vulnerabilities. 'Cause it's gonna give you insight into, you know, "Hey, I actually have this problem or not." And I would go from there and understand these two things, and then I would look, as I mentioned, around building an actual program.
If you have no program, that's a pretty good indicator that you need to start somewhere. If you already have a program, I try to understand how is that program being measured, and what was success defined as before. So if you don't have some guidelines around what you think success is, I'd actually start there and and say, "Where do I want my end state to be?" And I'd work backwards from there. Alright everyone, thank you very much. (audience clapping)
2023-06-09 14:17
