CyberWire Daily - Cloud configuration security: Breaking the endless cycle. [CyberWire-X]

Episode Date: October 3, 2021

Moving to the cloud creates a tremendous opportunity to get security right and reduce the risk of data breach. But most cloud security initiatives get underway after services are deployed in the cloud. It’s frustrating when major breaches resulting from basic mistakes, like S3 buckets left unsecured or secrets exposed. Continually checking for risky configurations and unusual behavior in cloud logs is a requirement, but there is an opportunity to be proactive. What if you could configure your security and access controls as you set up cloud infrastructure? The CyberWire's Rick Howard speaks with Hash Table members Kevin Ford of North Dakota State government and Steve Winterfeld of Akamai, as well as sponsor Sysdig's Omer Azaria to discuss how security teams are adopting Infrastructure as Code (IaC) security as part of their overall cloud security strategy to reduce risk. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. Hello, everyone, and welcome to Cyber Wire X, a series of specials where we highlight important security topics affecting security professionals worldwide. I'm Rick Howard, the Chief Security Officer, Chief Analyst, and Senior Fellow at the CyberWire. And today's episode is titled, Cloud Configuration Security, Breaking the Endless Cycle. Moving to the cloud creates a tremendous opportunity to get security right and reduce the risk of a data breach. But most cloud security initiatives get underway after services are deployed in the cloud. It's frustrating when major breaches resulting from basic mistakes, like S3 buckets left unsecured or secrets exposed.

Continually checking for risky configurations and unusual behavior in cloud logs is a requirement, but there is an opportunity to be proactive. What if you could configure your security and access controls as you set up your cloud infrastructure? In this show, we're going to discuss how security teams are adopting infrastructure as code, or IAC security, as the cool kids call it, as part of their overall cloud security strategy to reduce risk. A program note, each CyberWireX special features two segments. In the first part of the show, we will hear from industry experts on the topic at hand. And the second part, we will hear from our show's sponsor for their point of view.

And since I brought it up, here is a word from today's sponsor, Sysdig. Sysdig is driving the secure DevOps movement, providing visibility and security to confidently run containers, Kubernetes, and the cloud. Modern cloud apps are built using continuous integration slash continuous deployment, or CICD for short, and run as containerized microservices. This generational shift creates opportunity to get security right by embedding policy into DevOps workflows. Legacy tools can't see inside containers and slow application delivery. tools can't see inside containers and slow application delivery. What's needed is a container and a cloud security stack built on open source innovation with deep and unified visibility across workloads and multi-cloud infrastructure. Run confidently with secure DevOps by visiting www.sysdig.com. And we thank Sysdig for sponsoring our show.

To start things off, I've invited Kevin Ford, the CISO for the state of North Dakota, to the Cyber Wire hash table to talk about his mature DevSecOps program. For those of you that don't know, North Dakota has one of the larger state networks, managing and securing some 250,000 devices at any given time. As the CISO, he has the responsibility for the state network that includes government entities at the state, county, and city levels, plus all of the schools K through 12. And I've talked to a lot of CISOs in my career. Kevin has deployed one of the most mature DevSecOps And I've talked to a lot of CISOs in my career. Kevin has deployed one of the most mature DevSecOps environments that I have ever seen. I started out by asking him to describe the current state of the program. We have multiple actually DevSecOps initiatives.

One is our kind of main DevSecOps initiative, which is the DevSecOps initiative of the state IT organization. And so as the security organization within the state IT department, we are kind of that big capital S SEC within DevSecOps. help deploy and help write standards around CICD pipeline, as well as implement cloud technology and cloud security technologies. We also do have internal to the security team, a mini DevSecOps team that is an agile team that is comprised of members of our infrastructure team, our security automation engineers, as well as GRC and a number of other talent sets mixed in there, all working in an agile way in order to deploy kind of a DevSecOps approach to creating automations within the security team. There's two pieces to this DevOps thing. There's the traditional DevOps approach

where you're automating the infrastructure. You're inserted into the continuous integration, continuous deployment pipeline, the CICD pipeline. And then there's this other part where you're in charge of the security stack for the state. And you're experimenting with using the DevOps philosophy to automate the maintenance of the security stack. So are you using traditional DevOps tools to do that, like Ansible? Or are you trying to do it with traditionally security specific tools, like your SOAR tool? So for the larger portion of that, the enterprise-wide

DevSecOps approach, yes, we're doing it with more traditional tools. But the security side, actually, our tools are surfaced to us as software as a service, right? So there's not a whole lot of the underlying configuration, the Kubernetes, the containerization, and those sorts of things that we really worry a whole ton about. That's generally done on the vendor side. So you use a next-generation firewall. I think you guys are Palo Alto Networks customers, right? Yes.

So are you using the SOAR tool from that vendor, from Palo Alto Networks, my old stomping grounds, to update the next-gen firewall wherever it's deployed? Yes. So we use the sewer tools that Palo Alto provides as kind of the philosophy we're approaching is that we have the Palo Alto sewer tools, which are really the brain. And so that's going to be kind of the central brain for a lot of the security automations that we'll be firing off based on different conditions. The Palo Alto SOAR tool is also, we're hoping,

going to be enriched by a security development effort, which again is kind of our internal security DevSecOps process around connecting it to different APIs, around firing off different scripts based on different conditions. So we're leaning very heavily into that SOAR tool as a centralized brain. But one of the other things that I think I should observe here is we're also ingesting all the SASE tools from Palo Alto, right? And so what that means is a lot of the integrations with the SOAR tool are actually pretty easy because a lot of our stuff is the same vendor. So that makes it very easy. When we're talking about integrating with systems outside

of that, we're really right now only looking at our vulnerability management suite as well as our cloud suite, our Microsoft Azure. So can you give us some advice to any organization that's thinking about this? They haven't really started yet, do you bring in a consultant first so they can help you think your way through it? Or do you just start breaking things and then once you learn a little bit, you can bring in some consultants to help you undo it all?

So we call that fast fail, not breaking things. No. I think my biggest advice would be to first look at the organization. DevSecOps is an organizational approach, first and foremost. So, you know, look at your organization, see how it's structured, do some research around how successful DevSecOps organizations are structured and try to come up with a hypothesis around which one would be the best review. And once you have that hypothesis, don't absolutely do not say, okay, this is the way we're changing the entire organization. You want to take a evolution, not revolution approach here so that you're not breaking things.

What I would suggest is maybe put together a little tiger team and start looking at the applications or the products that you can facilitate that from the cloud perspective, meaning, you know, are we solid with Kubernetes and containerization or ephemeral environments, so on and so forth? From the security perspective, do we have sufficient application analysis in our CICD pipeline? And is that all automated so that we can make these continuous builds throughout the day without introducing new and exotic security loopholes? And then also at the application developers, do they have, you know, do they have the skills or the right tools in order to kind of create these kind of non-monolithic systems, right? It requires a whole different perspective, I think, than a lot of developers currently have these days.

And so it's a team sport. Everyone in the organization needs to participate, and everyone in the organization needs to understand where you're going. But start small and don't try to just reinvent your entire organization around these principles. Start small and disrupt yourself. Are your security people learning how to code? Because, you know, when I first started thinking about this, you know, back in 2015 or so, I thought that security people will become developers. That's clearly not happened.

But is that happening at North Dakota? Are your SOC people coding in this way? Are you leaning on the IT developers to do security things? So I will say coding has become more important to us as we've gone down this journey. In fact, a lot of the new employees that we're hiring here. We're looking for coding skill sets, you know, familiarity with Python, being able to script, so on and so forth. And that's been very important to us with our ability to set up the SOAR tool, being able to integrate with the different APIs of systems or write those scripts.

So that's been really important. But another interesting thing is, you know, the SOAR tools are becoming more and more approachable, right? And so maybe, you know, if they can, if the SOAR tools become more approachable and the SASE solutions become bigger, and as we migrate more and more off of our data center on the grounds here and into the cloud, potentially, you know, we may not need that capability.

But I think ultimately what I would like to see is my position as CISO become less of kind of a security, you know, a vertical where I have a whole ton of security people reporting up to me. you know, a vertical where I have a whole ton of security people reporting up to me. And one, which is where I'm more kind of a leader of a community of practice within the state, right? And so the security people, once we achieve, you know, full cloud and full SASE and all that stuff, then get mixed into the agile teams, creating all the different products. teams creating all the different products um and and i you know i become more of the the leader of that community but but they report up to the product people rather than to rather than to a ciso and and so you know when you're on those teams one of the principles of devsecops is trying

to create poly skilled teams and so you, it would be great if when we make that move eventually, years from now, they would all be able to code, you know, the developers would all be able to understand security, and both would be able to understand operations and what they need to do to, you know, roll out a server in the cloud or something like that. That was Kevin Ford, the CISO of the state of North Dakota and a regular contributor to the CyberWire hash table. One short diversion. I've been having this running argument with a good friend of mine, Steve Winterfeld,

the advisory CISO for Akamai, and another regular contributor to the CyberWire hash table, about my obsession with pursuing DevSecOps with all vigor. He has a different take. Instead of focusing on a grand strategy of infrastructure as code, something that would take years to deploy, he thinks we all would get more bang for the buck if we just focused tactically on securing APIs. Here's my short conversation with him. So over the past few months, you and I have been talking past each other, I think, regarding concepts of security orchestration and DevSecOps.

You make the distinction that we shouldn't be focusing on DevOps to do orchestration of our security stack. Instead, we should be focusing on APIs, providing them to our internal and external customers and monitoring them as an often forgotten attack service. And I say that you can't do security orchestration and DevSecOps without APIs, that you can't implement the infrastructure as code philosophy without them. So is that not an either or proposition? Is that a distinction without merit? So tell me why I got this wrong, because you and I have been arguing about this forever. I think where I'm frustrated is you've made it an absolute. And I keep coming back and saying, that's the norm. That's the majority.

It's not an absolute. You can do DevSecOps without APIs. You can do APIs without DevSecOps. And consequently, from a security point of view, I want to talk about how the APIs are working, not where we're hooked into the pipeline. How are we protecting APIs? How are they thinking about API discovery? Because just like with web pages, we have people deploying APIs without bringing in the security team. Some of those traditional guardrails we have on things

getting published, a server internet facing may not have those same guardrails around an API internet facing. And so I tend to want to talk about the API rather than the larger cultural process of DevOps. I mean, but why? What's the reason for it? I mean, how does that help you narrow the problem down? How does that help a CISO? I think the CISO is addressing the infrastructure. The API is what we need to protect. And the DevSecOps is behind it. So I can protect APIs holistically, or I can talk about, did you hook in these things? And ultimately, you need to do both.

But it's just about where you want to focus your discussion for me. you need to do both, but it's just about where you want to focus your discussion for me. So Steve, I know you're a huge fan of, you know, watching historical trends in cybersecurity, right? So have you seen any here? Can we, anything to learn from here? Because, you know, give us your wisdom. So, and I know you love the history, but I come from a heavily audited background, PCI, finance. If you're going to be regulated, if you're going to be audited, you want to build a program that has best practices, industry standards, leveraging the regulations. And this is an interesting area because you talk about history. We're so young here that when you look at NIST, which is one of my foundational standards I like to look at, they have a glossary definition for DevOps, but DevSecOps is a sub one and there is no definition.

It's just a one line within DevOps. You know, even Wikipedia, which we often go to since there is no glossary for our terms, there is no DevSecOps for Wikipedia. It's a sub line within it. And this kind of goes to me that we have this thought process that we need DevSecOps. But ultimately, do we need a DevQualityOps? Do we need a DevTestingOps? It's a component of it.

So I like to think that DevOps includes security, it includes testing, it includes quality assurance, and a mature program does all that. But it's really interesting to see that a lot of the regulations and the industry best practices haven't caught up with that. Well, clearly, if you read some history, you would know the answer to this perplexing problem that you have. So when we say DevSecOps, we don't say it's just, we're just doing the security piece. No, that's not what it is at all. What we're trying to do is say, we want to include security in all that infrastructure as code stuff that you guys have been doing for a decade that we haven't taken advantage of yet. That's what I think it means, even though if it's one line in this definition. Yeah, that's what I said a mature program includes all of those.

That was Steve Winterfeld, the advisory CISO for Akamai. Next up is my conversation with Omer Azaria from Sysdig, our show sponsor. He is the VP of Research and Development at Sysdig, a graduate of Ben Gurion University with a computer science degree, and has been a software engineer for well over a decade. I started out by asking him to describe the DevOps philosophy, or as some people call it, the infrastructure as code philosophy. Maybe taking a step back before, you know, jumping into infrastructure as code,

what we see in the industry and amongst companies is that as people are transitioning to the cloud and starting to deploy more things into the cloud, usually the first set of steps that they're taking is just playing either with the console, the UI, or just using a bunch of scripts to spin up services, the applications. And then they realize that that method, that methodology cannot really be replicated to other environments in case they want to go into other regions, maybe other cloud vendors, or even just for the ability to replicate what they have right now in case

the environment goes down. And then they start realizing that they need something different and they come across infrastructure as code. So infrastructure as code is the, again, the ability to go and express your infrastructure as something that is more resembles code or programming languages that are out there. The most common one I would say is Terraform, but we do see other type of infrastructure as code out there. But again, the goal is to go and express how you deploy things all the way from network accessibility to your compute and storage and so on, compute and storage and so on just using a set of instructions that you can go apply and will generate the same type of environment that you have right now. So this is infrastructure as code.

When we're looking at security baked into infrastructure as code, that obviously creates a huge opportunity to go and shift security even farther left than just doing it as part of the CICD. And again, maybe I'm getting ahead of myself, but the ability to go and look at the infrastructure and code and identify security issues right there when you're writing it or when you're pushing it into some Git repo is a huge advantage in the, again, in this kind of emerging cloud domain. Well, I totally agree with you, right? So, and ever since I read Gene Kim's book, The Phoenix Project,

I've been a fan of this philosophy. You know, he published it in 2013. I think I first read it back in 2016. And I know that the Cybersecurity Canon Hall of Fame Committee inducted it in 2017. the Cybersecurity Canon Hall of Fame Committee inducted it in 2017. And I thought back then that this concept was perhaps the most important innovation that has happened to the IT sector and the security sector, you know, since the invention of the personal computer. That's how important this thing was going to be because it forced us to think of the security apparatus as a whole, as a system of systems, and not individual turns of the crank for each, you know,

specific tool in the security stack. And I just knew that it was going to be just a matter of a few short years until all of us had switched over to this new way of doing things. But nothing happened. I mean, it's eight years since the book was published. And my experience is that security organizations of the world are still maintaining their security stack manually. They're not even close to infrastructure as code. So I'm wondering if that's your experience too.

And what are the barriers preventing security organizations from being further along this path than we are right now? So absolutely. I'm seeing a very small fraction of organizations that are actually embedded or embraced by AC or infrastructure as code. But again, I think it's just how slowly we're transitioning to the cloud and doing it the right way, which both of us agree that is using infrastructure as code. I think for me, one of the main barriers is, again, the complexity that is involved in the migration, the transition. And, you know, people are taking baby steps and slow steps, and it's really slow, you know. So we're getting to a point in which just the heavy lifting, the famous shift and leave from on-prem applications to the cloud takes so much time that the current processes that

are being used for security and for operations are still in place and not changing as well or moving to something that is better. So that is what we're currently seeing. And even when we get to a point in which people are operating in the cloud on a day-to-day basis, just realizing that there is a better way to do that

and just the thinking that they need to go through another migration of how they do things in terms of deploying their software and expressing their infrastructure, I think it's such a huge pain that there is a bit of a really slow adoption of best practices like infrastructure and code. What I hope is going to happen, by the way, is in the next year or two years, we're going to see a more exponential adoption of that.

And then more companies are going to shift to using that. And as a result, both processes and security is going to improve dramatically. What you said before is absolutely right. One of the reasons we wanted to go to the cloud is that we were going to be able to automate a bunch of stuff and take some of the complexity out of configuring, you know, bare metal boxes to do things for us. And, you know, and once you got it in code, it would be consistent and it wouldn't be as many mistakes and, you know, blah, blah, blah. But what you said is true.

Most people are just kind of going very slow. There's a number of ways any organization could try to do this. So let me ask you this. For your customers that are trying to adopt this model for DevSecOps kinds of things, or call it infrastructure as code for security type things, do they wrap themselves into the larger organization's DevOps movement? Or are they trying to do it themselves within the security organization? What's going on out there in the community?

So we see two types of things that are happening. Some companies do stay with the traditional, we have a security team versus the development team, and then the security team's trying to shift left. So within the security team, you see more people trying to identify those configuration issues or work more like DevOps people that are looking at the runtime environment and trying to fix things at the code,

not by actually fixing them, but approaching developers with the suggested fix. Another type of organization are really shifting security left. And then this is where you see DevSecOps team and DevOps team working side by side as part of engineering or kind of broader engineering groups. For both of them, those types of solutions are really necessary, A, from a visibility standpoint, B, from an ease of use. They do have their own day job, so they need to kind of try and do less on that front, or at least

have tools that will help them fix those issues. But again, to your question, we do see those two models, but they're using the same tooling or at least from a use case perspective, there is a convergence of the use cases there. If they're trying to wrap themselves up into the DevOps model, they're part of the team that designs the infrastructure. So for DevSecOps fans, you get to talk to a bunch of them, clearly, right? Are they using traditional DevOps tools to automate everything, like Puppet and Ansible or Nagios or Jenkins?

Or are they trying to use traditional SOC tools like SOAR tools and SIEM tools? How are most people doing that? I don't think there is most at this point. You know, we see... That's true. Everyone is using their own tool and, you know, it's all over the place,

which makes it slightly more difficult, right? You step into an environment and then you see the different type of seams and different type of, you know, source that are being deployed and so on. And this is one of the challenges for us as a company because the expectations is that we will be able to integrate and work with all of them or very smoothly transition from what they're using right now into SysD.

So it's definitely a challenge. But at the same time, the fact that they have those tools in place means that they're aware of the problem and they are trying to do better at fixing it. And this is usually the reason that we're there. So if I was going to start this journey today, Omer, can you give a single piece of advice? What's the first thing that we should be thinking about? How do I organize my thoughts? How do I make sure that I can demonstrate success so I can continue to pursue this interesting model? So that's an interesting question.

I would say the first thing that I would do is to really get great visibility into my runtime environment. Most likely, I have something running. And most likely, I don't have a good enough visibility into what is out there. What is from a security perspective? What is my security posture?

Where am I exposed? So, you know, giving you, you know, getting what is the current status from a security perspective of my environment, that's the number one thing that I would do. Then mapping the risks. The second thing you want to do is to prioritize. Right. Out of all those findings that I got, what is the most important one? Maybe what are the five most important ones? I can do two things. A, go and present that to my executive team or

to my manager, and B, start addressing them so I can see a real progress in this journey for a better security hygiene, which this is what I believe everyone is after, just a better hygiene overall. This is for me security. And this is the way that I would go about it. I think if I was doing it, I don't know if I would go after the most important one

because if it failed, we had some trouble with it. Maybe not failure is the wrong word, but if we had trouble with it, that would reduce the confidence in the leadership team on this new idea. I would pick something important. But if some aspect of infrastructure is code that wouldn't bring the business down if we screwed something up, I would find a nice middle ground.

What do you think about that idea? You're right. I mean, the reality is that people are doing that. When they're looking at some sensitive application, let's say you're working in some financial institution and the top item in your security list is changing, modifying the configuration of that application, you'll usually try and stay away from doing that. I agree with you because you don't want to have the business impact.

So you'll choose a good balance between impact or potential impact on the environment and security value that you're getting out of it. So, yeah, you're right. It's my impression, though, that organizations that decide to flip the model, this is basically everybody going 180 from manually doing everything themselves hardware-wise to going to a software model. I believe that you're not going to get this done in an organization from the bottom up. This has got to come from senior leadership at the top of the company and say, you know

what? We think the company will do much better if it adopts a DevOps model and then pushing it from the top down and making everybody comply with that. Any thoughts on that one way or the other? I agree with you. I just think that the conversation starts in a different place. So I think the adoption of DevOps methodology is the CICD is the first and foremost for speed. Everyone is participating in conventions and seeing the numbers out

there and the realization that if you shift to that model, you can be better as a business. And if you want to stay competitive, you have to adopt that model. So that is, I would say, how executive teams and how companies usually start this journey to move to the cloud, to move to a more DevOps-type approach. And then when you have the DevOps-type approach embedded, or at least there is a transition into that within the organization, then the question about, okay, so how do I make security into that comes into play? And this is where we see the question coming up, okay, so what's I make security into that comes into play. And this is where we see the question coming up. Okay, so what's the right way to do that?

What's the right way to really have a secure DevOps approach in my organization that addresses both those issues, which is speed and security at the same time? And I think this is very much achievable as we're seeing in the more mature organizations. I love the way you said that. And I just had an epiphany listening to your explanation. If you're in an organization and the leadership has decided to move to DevOps and you're in charge of the security part of it, don't wait. Jump on that and help them get there. Be part of that solution.

Don't let it get separated that you have to do security later after the DevOps guys figure out how to do it. You know, as soon as someone decides we're going to go this way, get security in there early. So it's not a weird thing two years down the road that we're going to try to throw security stuff in there, right? That's what I got out of that. Absolutely. You know, the earlier you are, the better. You know, if there is this gap that is open, it's very hard to go in and catch up because processes have been established. And then going and baking the security tools into the pipeline,

into the infrastructure and code and so on, it becomes very, very difficult rather than doing it from day one. Completely agree. So, Omer, what's the bottom line here? If you could tell our audience anything, what's the one message you want to give everybody? Just one? Come on. Yeah, you have to prioritize. You only get one.

You got it. So, baking security into the lifecycle, the new lifecycle of the application actually creates better security, which means that if you push security left as much as you can into infrastructure and code, as code, scanning your application, your containers and so on, eventually will get you a better security overall. So it's never too late to go and try and do that.

And if there is one takeaway is look into infrastructure as code, look at how you can improve security based on shifting to that, that would be it. That's all good stuff, Omer. That's Omer Azaria, the VP of Research and Development at Sysdig. Omer, thanks for coming on the show. Thank you, Rick. on the show. Thank you, Rick. We'd like to thank Kevin Ford, the CISO from the state of North Dakota,

and Steve Winterfeld, the Akamai Advisory CISO, both our own CyberWire Hatchtable subject matter experts, and SysDig's Omer Azaria for joining us. CyberWire X is a production of the CyberWire and is proudly produced in Maryland at the startup studios of Datatron, where they are co-building the next generation of cybersecurity startups and technologies. Our senior producer is Jennifer Iben.

Our executive editor is Peter Kilby. And I am Rick Howard. Thanks for listening.