Compliance as Code: Expert Discussion

Compliance as code enables a company to efficiently monitor its compliance and risk situation. Custom configurations are often deployed across a company’s complete infrastructure, providing automated monitoring and reporting with a remarkable degree of detail. In fact, in many cases, compliance as code can tell an organization more about its infrastructure than any of its human staff.

In this webinar, we discussed:

• What is compliance as code, and how can it help businesses? 

• Traditionally security has been a very conservative field, what changes do you see in response to increased growth of cloud and security’s role in cloud computing?

• With DevOps enabled by automation, what security and compliance concerns do you hear from customers?

• There have been a number of recent breaches with ransomware, Twitter’s hack, etc. What are the pieces that CISOs are missing to prevent and mitigate these attacks?

• What challenges do you see with ensuring security and compliance with the multi-cloud strategy that most enterprises are looking to pursue?

To provide insight into the future of this key technology, I spoke with three leading experts:

Corey Scobie, CTO, Chef Software

Curtis Barker, VP, Solution and Product Architecture, Rezilion

Oded Hareven, Co-Founder, CEO, AKEYLESS

Moderator: James Maguire, Managing Editor, Datamation

Download the podcast:

Transcript – see edited highlights below:

What is Compliance as Code

Maguire: I looked it up and this is my short definition would be, compliance as code means defining your compliance requirements in a human and machine readable language, which is kind of contradictory in the first place, because of course, machines and humans don’t read the same language. So Corey, help me out. What is compliance as code?

Scobie: Machines and humans generally don’t read the same language. I think one of the challenges that we have with compliance in the enterprise is that often, it takes the form of a whole bunch of unstructured data. So for instance, traditional compliance in the enterprise looks like a PDF document that neither a human can interpret equally well and you certainly can’t automate it.

So the whole concept of compliance as code is expressed to state and the security posture of the technology footprint that you have, whether that’s your compute or your application footprint, in some kind of format that can be automated, and that can help drive sort of that automation through the DevOps pipeline, through your cloud environments, etc.

The way that we solve that at Chef is we use a markup language, a DSL that helps bridge the gap between what is interpreted by the automation machines and ultimately makes it very readable from a human perspective, so it is in fact code, but it’s code that is so simple that everybody can interpret it. Now, that may or may not be true in various different parts of the entire scope of compliance for us, that’s really around the state of systems and the configuration of systems, so there’s sort of an element to that, but I know that the folks at Rezilion and AKEYLESS also have similar sort of artifacts that can be human interpreted as well as drive the automation systems.

Maguire: what is the relationship between compliance in code and DevOps or is there one?

Hareven:  from our perspective at AKEYLESS, so for us as providing secrets management mainly as a service and also on-prem, we’re providing the ability to basically totally eliminate, in a lot of ways, the human interaction for whenever secrets are being needed. So everything is… Everything is fully automated in terms of whenever a container goes on and requests for access, then it gets a dynamic access, and what’s great about it is that it’s got a combination between the human access that says… Or the Administrator, or the DevOps guy that says, “Okay. Whenever a certain machine would ask for a certain axis or certain credentials, then this is how it will look like, and this is the policy.” And this is how they set it up in the system, and this is, this in the way is the compliance’s code for us. So the DevOps guy would say, “Whenever someone asks for access, this is how it will look like, this is the certificate template that it will get. And that’s in a way, for us, the way to set the amount of access that every component can get inside the system.

Maguire: If you take Devops and you enable with automation, what sort of security and compliance challenges might you run into, if any? Curtis, what have you seen in that regard?

Barker: So having ops folks and security folks work together, I think is for the betterment of society, and we’re all striving for that, of course, but DevOps has been evolving for a long time, and for those of us that have been in security for a long time, we’ve seen a huge evolution that’s kind of part of a broader revolution.

If you just think about the way code has been developed, you’ve had waterfall that led on to Agile, that’s really led on to DevOps and security organizations have been starting to capitalize on the innovation in that space. This is being driven by a massive growth in the delivery of digital services that we all use on a daily basis, so DevOps it can be seen as the internal paradigm shift in building services and the emergence of cloud marries with that external paradigm as an external paradigm shift to deliver those services and host those services, and that started with infrastructure and has expanded to incorporate DevOps tooling and code repos and pipeline management, some of the things Corey spoke about a moment ago.

 Scobie: First of all, I think that the general posture of security in the enterprise has gone from being something that was just one of many bullet points that they were trying to accomplish to being absolutely paramount all the time, constantly. And the rate at which we’re moving in a modern DevOps environment in terms of deploying, managing, and then destroy and compute, and the immutability of that compute, and all of that stuff has led to the necessity to have security encoded in the actual application pipelines themselves.

“I think it was okay in the past to have a software development team create a bunch of stuff, and then at some point in the distant future when your infrastructure was ready and you’re ready to deploy it, to test it and see if it met your security and compliance posture. No longer the case in a world where every single day, there’s thousands and thousands of changes being pushed to enterprise compute environments. And so you really have to shift all of that definition of what is compliance, what is security, what is key management. All of that has to shift to the left side of the equation. It has to shift to being built into the SDLC, built into the software development life cycle, and then built into the operations management life cycle as well.

Cloud Computing and Security

Maguire: There’s two things that have sometimes had an uneasy relationship. There’s cloud computing on the one hand and there’s security in the other. And security tends to be pretty conservative and cloud has a certain disruptive quality in it, it continues to change rapidly. So what about cloud computing meets security? What kind of challenge is inherent there?

Hareven: Well, this is exactly when we think about what happened with security until today, when we were using the on-prem or the perimeter approach, and when we shift to the cloud and the last of that perimeter. And the code name, which started a few years ago, recently, and it keeps staying, which is zero-trust.

“A lot of people thought that zero-trust is here not to stay and they thought it’s just a gimmick. But with time, it is becoming something that everyone understands and everyone continues to talk about and to interpret. With zero-trust, it’s basically the understanding where you don’t have a perimeter, you cannot longer trust either the network environment or the component themselves or the user behind it. So everything needs to be either multi-factor authenticated, and then later you need to make sure that everything is based on just in-time access so no one has permanent access to anything, with least privileges approaches and zero standing permissions. So when you look at all of those things, security has definitely changed when we talk about cloud and hybrid approaches, and that’s very, very good things to see. Of course, on us, with AKEYLESS, those are exactly the things that we are focusing at to facilitate that zero-trust method.

Barker: Some of the terms that you’re hearing, immutability, zero-trust and the new wave of SaaSE, it all comes back down to trust and it all comes down to the same thing. And that example is an early iteration on that. You trust the one guy and guess what? He’s the person that’s gonna get you and hold everyone hostage.

“So we’re trying to avoid that, which is why so much more automation that you’re seeing come into this and actually Chef has been a leader in this space for a long time in terms of IT tooling has gone. But if you look at the traditional ways why DevOps and cloud may have wed, many businesses are polygamous and not wed to a single platform, which offsets dependencies on their side on a single provider, among other things. But with these shifts come like the shift away from bolt-on security, which by the way, is how data center security particularly used to be delivered and it’s not viable because bolting on security to a service with inherent flaws and tools are then reduced to invoking basically servicing impacting measures to stop an attack, is simply not desirable, especially when the impact is maybe a false positive on a critical service that results in downtime.”

“So that the focus and certainly the focus at Rezilion is plugging into the development pipeline. So as Corey mentioned shifting left into those toolsets, including Shift. To reduce the attack surface measured by vulnerabilities that are exploitable. And where flaws do make their way through, to act as a compensating control to vulnerabilities and zero days are exploited. And in doing that triggering service-healing procedures IT teams already use.

“Rather than the security tool being a thing that impacts a service, triggering IT tools that are already in place, that have the trust to make the changes necessary, which do not have as much of a detrimental impact on service availability, because that was one of the charges with security in this space and one of the reasons why you’ve had friction really between IT operations and security is that you’ve got security tooling that maybe made a detrimental impact taking a service down.

Scobie: So when we talk to the CISOs in big organizations. They’re starting to change the way that they’re thinking about partnering with the software development teams that they are trying to help secure, and the infrastructure that they’re trying… The infrastructure operations teams that they’re trying to help secure. So the big shift has traditionally been that the CISOs organization was focused on measurements, and producing data of things that they felt needed to be rectified in order to meet the security and compliance policies of an organization.

And what we’re seeing now is them actually taking ownership of helping to deploy some of the automation tooling that will help teams do a better job at security and compliance at the left-end of the software development life cycle, at the front-end of the thing. So that they’ll have compliance, so if they have compliance in their development environments they’ll have compliance in their operations environments. And so there’s less of… What we’re seeing is that CISOs are partnering more with the App Dev teams.

Barker: As Oded said, not everyone is in the cloud, a lot of them are on-prem and they’re expanding some services in the cloud, so you’re seeing a lot of organizations with a multi-environment strategy, and even a multi-cloud strategy, which is actually why tools like Chef work really well in that regard, because they work across those environments, regardless of you’re in the cloud or you’re on-prem, to basically automate the updates of those IT estates everywhere, and we at Rezilion, we integrate in with that cycle as well.

But if you think about some of the problems that CISOs are concerned about in that space is as they are expanding, as they’re pushing services out more and more frequently, the code environment that their development team and their developers are operating in is a lot more dynamic than it used to be. Updates are happening, sometimes hundreds of times a day across multiple applications. And according to some well-known analysts, 70% of the attacks against containers, which are used very prevalently nowadays across on-prem and cloud environments will be attributed to known vulnerabilities and misconfigurations that could have been remediated pre-production, and we’ve seen some of that with some of the big breaches.

Maguire: In the beginning of your answer, you threw a little shade at containers, like containers might be a weak point in the security infrastructure, am I reading you correctly or not necessarily? When a manager hears the term containers, should he or she say, “Oh, no that’s a security hole.”

Barker: I’ve literally met, and I’m not gonna call them out for sure, but some people that have said containers are the devil. I don’t think so, they provide massive benefits in terms of decoupling services to businesses, there’s no doubt about it, but they’re fairly new, there’s a lot of benefits to moving to containers, which is why so many businesses are doing that.

But it creates a more dynamic code environment. You’ve got these things that are fairly ephemeral, a container can come up and be disposed of very easily, and there may be… And there’s a lot of open source coming from images out there in the wild, so you need to stay on top of that very dynamic, frequently shifting code and compute environment. So that’s what it gives way to. It’s not that containers are bad, it’s just that the movement of more dynamically changing environments creates a broader attack surfaces that CISOs need to do a more decisive job of locking down, and it’s not an easy job, it’s an increasingly hard job, which is why automation in the process is so important. And building tools in across IT and security that work seamlessly together with your entire environment and makes the job, a hell of a lot easier.

The Security and Compliance Challenges of Multicloud

Maguire: It seems like multi-cloud creates its own security compliance challenges. What’s the answer there? If someone’s in a multi-cloud world, how can they secure their deployment?

Scobie: I think we all unanimously agree that most of the customers that we talk to are in a multi-cloud world.  They have one foot in a data center and one foot in the cloud and they continue to operate in that way for some extended period of time.

“And the big challenge is part of being a high-performing IT organization and getting high velocity out of your software development teams and everything is reducing the number of patterns that you have in how you operationalize software components, etcetera, in all of your environments and the way that you can do that is to find tools that work across all of your environments, and to land and to codify the patterns of those tools and technologies across all of your cloud environments. And so, that’s something that we have certainly experienced at Chef. I think probably Rezilion and AKEYLESS would concur on that, which is that ultimately most of our customers are looking for solutions that can meet them wherever they are, today and tomorrow. And they’re looking to sort of establish those patterns in the enterprise that allow them to reduce the complexity and the number of paths to production.

“If you think about the digital high performers in the tech industry, for example, the FANG companies, Google, Facebook, Apple, etcetera, many of those organizations have a really broad set of compute environments, but there’s only one or two paths for how you take a component and get it into production, and so that’s really part of the secret to velocity and so I think we all represent set of technologies that are very ubiquitous across all of the environments that most enterprises are operating in.

Maguire: Curtis, why isn’t AWS with all of its deep pockets already providing the services offered by the three of you?

Barker: It comes down to what I said earlier, which is businesses are polygamous, and putting all their eggs in one basket and one tool set, which is married to one cloud platform doesn’t make sense, and with some companies it does… And you’re right. They’ve got the deep pockets, they have partnerships with all of us. So they see our tech and they recreate some of it. And that’s not a bad thing. For some people that are getting started with maybe a smaller business and then put all their eggs in one basket to get scaled up, great. In my view, it’s whatever works best for the business, but the reality is that a lot of businesses don’t want a dependency on a single platform.

“Or, they’ve got a lot of services that have been developed over a long period of time, and they’re not necessarily gonna take them all to the cloud, so they need, as Corey said, to recreate as minimal patterns as possible that represent optimization in their workflows. But then allow them to scale and get the benefits of reaching their customers using infrastructure that’s hosted by cloud providers and some of the services that come along with that. And it’s then our job to work into those workflows as well, and as I said, we mesh really well with tools like Chef in that regard, because they work across the IT environment, whether you’re on-prem or cloud, and we work with those workflows as well to deliver a seamless experience.