So your organization failed a compliance audit and got slapped with fines and penalties. Bummer! You pay the fine, spend a few days fixing your configurations, run a scan, and get ready to do it again come the next audit. But that approach doesn’t work anymore: The risks are too high, and fixing months of configuration drift at the drop of a hat (let alone hunting down all the paperwork for auditors) certainly isn’t your team’s favorite thing to do.
The broad scope of today’s compliance management requires a coordinated effort from more than just the security team. In this episode of Pulling the Strings, two Puppet compliance experts make the case for cooperation among security, compliance, ops, and just about everyone else in your organization. They discuss the crumbling walls between security, compliance, and ops, as well as tools organizations use to ensure continuous compliance.
Highlights:
- Why organizations always wait until something goes wrong to pay attention to compliance + security
- The simple micro-adjustments that prevent massive corrections come audit time
- Working toward better alignment between teams so that they’re making compliance easier
- The point and benefits of continuous compliance – and why ‘cowboy compliance’ isn’t enough
- Why compliance frameworks matter across security, compliance, and ops
Links:
- Read Claire’s content on the Puppet blog
- Read Robin’s content on the Puppet blog
Ben Ford: [0:18] Hello everybody and welcome again to today's episode of Pulling the Strings podcast, as always powered by Puppet. My name is Ben Ford. I'm our developer relations director here at Puppet, and I'm pretty active in the community as BenFord2K. Today we're talking with a couple of my coworkers, Robin Tatam and Claire McDyre, and we're talking about how security and compliance are creeping in and taking over the operations world. We'll start with some introductions. Robin’s got quite the bio here. It's a lot of information about this long, long, distinguished career in security and compliance. He's one of the people who is recognized in IBM Power Systems Security, IBM champion, and certified in CISM and whatnot. He's been in a lot of different magazines and publications, Computer World, et cetera, and he joined us last year as our senior director of product marketing. Obviously there's an emphasis on infrastructure and compliance here. Robin, I will ask you to tell us a little bit interesting about yourself, maybe not related to work, I don't know if you've ever had to wrestle a bear off during a fishing trip in Alaska.
Robin Tatam: [1:29] Thanks, Ben. And fortunately the answer to that is no. However, thanks to work, I have been to Alaska many times and I do remember one of the first times I went up there and went hiking in the wilderness thinking, "How beautiful this is," and was a little startled at the trailhead when they give you instructions on how to fight off a bear and from a kid that grew up just outside London was alarming. But fortunately I've not yet run into one specifically in the wild. I've certainly not had to wrestle any of them.
Ben Ford: [1:59] Believe it or not, I did not prompt that question, that was just fortuitous there. Claire is a senior product manager. She's been working on our compliance and security solutions for a while and she's got a lot of experience helping customers simplify their work lives using this data and has spent time working in the public and private sectors guiding the delivery of varied software solutions and a lot of data analytics projects. How about you, Claire? Have you ever had to fight off a bear?
Claire McDyre: [2:31] No, not a bear, but actually Robin's story or this story reminds me of, I traveled through Australia and I spent a lot of time in Northern Australia, like the northern territories, and we would go swimming in these fresh water springs and there would be signs up to say, they pretty much said, I'm paraphrasing, but they would say, "We're fairly certain that there aren't any crocodiles in these springs." That would make me feel, "Oh my god," this level of, "Okay, you're somewhat certain, but they could never be sure that the saltwater crocs had not made their way into the freshwater pools." I survived.
Ben Ford: [3:12] That is a lead into the security world. We never do know when for certain, Claire, but we're fairly certain.
Claire McDyre: [3:23] I think I've just got crocodiles in my head.
Ben Ford: [3:27] That’s all right. Puppet Enterprise is certified crocodile free in case anybody was wondering, I'll share my little fun story too. My partner and I got married over the weekend and instead of cakes, instead of a big wedding cake that we cut together, we didn't do any of the spearing or any of that weird stuff that people do. We had an axe throwing truck, if we had such bears and crocodiles at our wedding, we could have thrown axes and scared them off.
Claire McDyre: [3:53] Very useful skill.
Robin Tatam: [3:55] Congratulations as well, Ben.
Ben Ford: [3:58] Thank you. All right, let's go ahead and get started with this, and I'm curious to know what themes that we're seeing in the security and compliance world that are having maybe the biggest impacts on operators, on operations and whether there's trends maybe is a good way of saying it.
Claire McDyre: [4:17] Sure, I can take this one. Definitely what we're seeing, Ben, is a lot of new and updated regulations and laws coming out. One that comes to mind is a recent, it would've started off in the 2021 executive order from the White House with regards to cybersecurity. The White House has also just issued their cybersecurity strategy there in March. We're seeing a lot more of that and we're seeing other things, very similar things happening within the EU, within the UK, within Australia and lots of different territories. We're seeing that increasing focus and move towards legislation in the area of security and compliance.
Ben Ford: [5:01] I’ve got a question for Robin actually. I just realized we had talked earlier about the difference between security and compliance and it might be really good for you to set that stage so that people know what we're talking about.
Robin Tatam: [5:12] Absolutely. I know for sure there are terms that tend to get used interchangeably, and while they're certainly related, they're not exactly the same. For me, when I define security, it's really a state of being, it's a lack of risk. You're typically never going to get down to zero risk. You probably don't even want to, it turns into more effort than the return that you're going to get, but you certainly want to eliminate as much risk as it's reasonably possible. When we talk about compliance, what we're talking about is adherence to, let's call it a baseline. We've basically said, "This is how we want X to look and we want to check and make sure that it is actually conforming to that." The intent of compliance is to establish that consistent state, that desired state in the intent of that compliance usually is to adhere to a standard that is going to be helpful when it comes to being secure. Again, very related, but there is definitely a distinct difference. You can be compliant without being secure. You typically can't be secure without being compliant.
Ben Ford: [6:11] That makes a lot of sense. And as somebody who's done a lot of home repairs, it's like building codes. It's like you can totally build something, you can build a set of stairs without ever looking at the codes, but in order to pass, get your permit, you need to follow the set of codes. And that would be more like compliance.
Robin Tatam: [6:29] Absolutely. And I'm a big analogy fan too, and I always say, "Hey, it's me tidying up my garage every year." I put my tools back and I put everything in its place, but if I don't check it until the following year, chances are when I come back it's going to be a big old mess. My kids have taken something or put it back in the wrong place and I've really just not established that good standard. Part of that compliance is it's not once and done, it's also then a recurring theme of checking and correction as we go so that if I find a tool out of place, it only takes me a split second to put it back versus the garage looks like a bomb went off in it and I've got to start from scratch.
Ben Ford: [7:06] It is amazing how quickly entropy can take over.
Robin Tatam: [7:09] Absolutely.
Ben Ford: [7:10] Let’s talk about how different teams, we've got, the dev teams, the ops teams, the DevOps, we've got now security and compliance, and how do you think that we ought to work together better? Are there friction points? Are there ways that we can work better?
Robin Tatam: [7:25] I think definitely there are responsibilities across all teams. When it comes to security, it's not really anything that falls purely into one specific area. Certainly some of the workload may fall on the shoulders of a security team or an audit team, but ultimately the responsibility for the safety of the data, the availability of the application and the protection of the organization is going to ultimately fall on everybody's shoulders. Part of what we're seeing is I think organizations struggling a bit with defining who is in essence responsible for each of the steps that go into that model. And while traditionally security teams handle assessing or auditing environments, oftentimes the deployment and the correction of configurations falls on the IT operations team. Part of what we're seeing is I would say some jockeying around as we get better alignment in those roles so that they are more synergistic rather than, as you say, creating friction points. And there's definitely things we talk to a lot of customers about in terms of IT operations where they can ease the transition, they can ease that burden of assessing audit so that we are doing those micro adjustments, like I said, about putting my tools back rather than waiting for that quarterly or annual audit to find that we're way off track and we've got to do these massive corrections.
Ben Ford: [8:55] Who’s the overarching owner of these movements? Clearly we all have something to do. When I've got my project, I have to follow certain standards, I have to check certain boxes and everything, but I'm not the one defining those. I'm not the one who's really going to be tracking or monitoring a lot of those. Somebody's got to be owning the top level security policies and compliances.
Robin Tatam: [9:17] Absolutely. And nowadays, that's typically going to fall into the office of the CISO, the chief information security officer. For people that don't have a CISO, then it typically falls on the chief information officer. But initially really the protection is going to come out of the CISO C-suite there. As it trickles down through the organization, certainly security and compliance is going to be the ones that are declaring in essence what that policy is going to be for the organization. But where there tends to be a disconnect is it's the deployment validation and correction of that because they don't have their hands on the infrastructure in the same way that the operations and the infrastructure teams do. And that's why they've got to work together. It's really going to come down from the top, but ultimately having that declared in some kind of security policy is the way that we're going to accomplish that.
Ben Ford: [10:07] I’ve got a question that is maybe nuanced and layered, and maybe both of you'll weigh in on this while I ask Claire first, is that a lot of organizations don't have formal mandates or policies and they internally develop their own ways of doing things. We won't even go as far as to call it a policy or maybe they do build a policy, but I've heard you talk about why it's important to adopt a more industry recognized compliance framework. My question here is what are the benefits of doing an industry recognized framework? And if you don't have one, if you're still cowboying it a little bit, how do you get there?
Claire McDyre: [10:49] That’s a really good question and certainly lots of customers we speak to, they balance on that path too. They've spent an awful lot of time developing what they want their security policies to be. It takes a huge amount of time to figure out what they should be to best protect your organization and then also what are the deviations, what are the exceptions that you need in order for this to actually work functionally in your environment? And that in itself takes a huge amount of time. But I think the thing to remember with managing security policies and compliance like this, it's not a one and done thing. It continuously changes. And it's not only that it continuously changes and the fact that you have to continuously be minding it and making sure that it's as you want it to be, but as you want it to be changes as well, because security threats change all the time. We are getting constant new information from different government agencies and different security researchers, et cetera, to tell us that we need to update how we're managing and how we're deploying our security policies, what we're looking for, that changes all the time. The burden of having to deal with that yourself, within your IT department, within your InfoSec team, it's a big burden trying to figure out, "Okay, what do I need to be secure today? What does that need to look like in three months? How do I keep up with that?" It's a lot to do. Whereas if you're taking on an industry accepted framework, they provide a huge amount of guidance on how to do this, and they also work with lots of industry experts in both security and infrastructure. They work with vendors, all of that good stuff to make it all available for you. And they also put it together in a way that it's a framework that you can adopt in levels. That's something I actually really like about them is that they start off with basic cyber hygiene levels, level one and then they proceed through the higher levels. They help you create action plans as to how you can implement it. You're taking a lot of that burden off your teams in how you're going to decide how secure you are and how that should look because you're getting all of this information from frameworks that are generally free. They're generally freely available online resources. One that's really good is the CIS controls from the Center of Internet Security, but you'll also see other ones from NIST, from the US government. There's a lot of different variations and they all come with implementation plans to help you start off at a basic level and move on through.
Robin Tatam: [13:26] I think it's worth saying too that one thing I think people are surprised about when they first get into regulatory compliance is that regulation doesn't spell out what they need to do. It just says, "Thou must be more secure, thou must have better security." And it doesn't really give that step-by-step direction. That's really where these frameworks and these security standards come in. It's a layered thing, Ben. It breaks down. It starts with that regulation and there's typically a framework built underneath that and those frameworks often cross multiple different regulations and then the security standards such as CIS give you more of a how to on how to accomplish that task. They're more prescriptive about what they're in instructing people to do and it's more actionable.
Ben Ford: [14:10] If a team wants to get started doing this, do they just like Google CIS or something or NIST and just start following the directions on the webpage? Or are there better ways to go about that? Can they just maybe hire somebody to do it for them?
Robin Tatam: [14:23] I wish it was as easy as just Google and go, they are complex. There's a lot of value in those benchmarks and with that value comes a fair level of complexity. There are definitely things that can be done to simplify that. It's not usually initiated by the IT side of the house, but oftentimes audit will have correlation back to those particular standards or benchmarks and that certainly is going to be helpful in defining that policy. For me, when I talk to organizations about getting started on the road to compliance, usually it begins with the definition of that policy in which case you're declaring, "How do I want my organization to be?" And it's usually a layered thing. "Here's my stuff at a corporate level, here's maybe at a geography level or a department level," and then we declare those policies and then we leverage those standards to do that.
[15:17] And you can absolutely find people that are hireable in order to come on and do that, but they're certainly not cheap and they're not a dime a dozen. One of the things we know is what a shortage there is of cybersecurity expertise in the world market. And leveraging technology certainly can help that as well. There are certainly things that can be implemented that are pre-developed or pre-programmed with these standards in that really make that process a whole lot more manageable, not only from the outset but on an ongoing basis as Claire said, because the risks and the standards continue to evolve almost nonstop.
Ben Ford: [15:56] What’s usually the impetus for a company or an organization to start taking security more seriously?
Robin Tatam: [16:02] Sadly, often comes at the cost of some kind of security incident. That's usually when the checkbook gets opened and money gets spent. It's usually a little bit late at that stage, but it can also be in terms of regulatory compliance as well. An organization might be in a particular industry or in a country that implements a certain standard. Claire mentioned a couple of them, but we've got Essential Aid in Australia, we've got various things here in the US and the UK has a number of security initiatives. When somebody falls under that, GDPR was a huge driver in Europe and really what made people sit up and take note with GDPR was the structure of what the penalties could be. They were so significant. It can go up to 4% of an organization's annual global revenue, not profit but revenue which could run into the billions of US dollars. It certainly makes people go, "This is impactful and therefore we need to take this seriously." And that tends to be an eye-opening moment I think for a lot of people.
Ben Ford: [17:10] Definitely. As a community person, GDPR was huge for us. Puppet has always been very good at managing our user security, but now we had to prove it and that was a little bit more involved.
Robin Tatam: [17:27] Absolutely. The compliance angle of this is not just about, "Hey, I'm doing the right thing." It's that, "If anybody asks, I can demonstrate it." Even if you do, like you said, roll your own and have that security policy that you built, you better also have the mechanisms that you can prove and also in a way that has enough independence that then the auditors aren't going, "Are you excluding the things I really want to see from the list of items that you're sharing with me?" It's like the old fox watching the chicken coop. There's certainly questions about an IT department running their own policy management component, but certainly it happens, it's a start, but it's maybe not the end game that people should be targeting.
Claire McDyre: [18:11] And also the fact that we were talking about trends there earlier, Ben, with GDPR, it was a starting point almost where regulations ended up on everyone's desk. There's certain industries, highly regulated industries, they're a little bit more used to this stuff. They just have to do so much of it. Doesn't mean it's easier to do, but they're a bit more familiar. But GDPR, brought it to everyone's desk, and I remember where I was working at the time was a very small business and we hadn't really done anything about it. And it was the 1st of May and I remember, I think it was the 18th of May and around then was the date that it was going to be in place.
Ben Ford: [18:53] No pressure or anything, that's fine.
Claire McDyre: [18:55] No pressure. We had to figure out how to do a data protection officer and then also that thought of, what is it 4% of your earnings? It's a lot for a small business as well and larger enterprises of course, but it definitely brought this notion of requirements around compliance and security to everyone. And that's what we're seeing continuously now is a trend that it's not just for the highly regulated folks, it's coming.
Ben Ford: [19:21] It’s coming for us all.
Claire McDyre: [19:24] Everyone’s scared. That makes it sound scary. It's hard to do, but it's 100% worthwhile.
Ben Ford: [19:31] Robin, you said something a minute ago about using tools to get started and help yourself with the compliance thing. Maybe we could ask Claire to talk a little bit about the product that you're working on.
Claire McDyre: [19:41] Sure. We can definitely do that. What we're working on is around infrastructure compliance. If your listeners are Puppet users or interested in Puppet, they're familiar probably with the Puppet agent and the capabilities around state enforcement and configuration management. And that whole model really lends itself really well to managing infrastructure compliance continuously because we have the agent there and we're making sure that everything is set as it should be. We also are measuring your infrastructure compliance against industry benchmarks, and we provide the policy as code there as well to enforce it and to set up your servers and your infrastructure based on those industry except the guidelines.
Ben Ford: [20:28] I like that. Not only do you get the reporting that you can share with your CISO, but you can also do that regular maintenance and upkeep that Robin was talking about, keep your garage clean.
Claire McDyre: [20:39] For sure. We do that and then we also make sure that we take care of any of the updates that are coming from those industry standards. They regularly get updated at least once a year or sometimes more frequently depending on where they're coming from.
Ben Ford: [20:50] Right on. We will be sure to put a link to that in our show notes. I'm thinking of a question here, and I'm not entirely certain how to word it, I'll just go for it. How big of a change is this newer focus on security and compliance? How big of a change is it to how we configure and manage our modern infrastructure? How big of an impact is this?
Robin Tatam: [21:15] I think it can be pretty significant to organizations that first of all are not maybe familiar with doing that on an ongoing basis. I think there's a general acceptance that, "Hey, we understand a server has to be configured. We understand it has to be deployed whether on premise or in cloud. Maybe it has different settings depending on where it lives. We're used to that. What we're not necessarily familiar with is that we're aligning that with a base standard and that we have to check it repeatedly." The big change there becomes that ongoing continuous assessment in remediation cycle that is very important so that we can keep that asset in line constantly. I think that tends to be a bit of a shock to the system. Using automation around that is a big step in eliminating that additional burden. But I think for many, it comes as a bit of a shock to the system that is not a once and done activity and that they do have to interact with the security team and they do have to be synergistic between departments and have that cooperation, which isn't always forthcoming. I think a lot of times people can own different aspects of it and they don't like to relinquish that power, but efficiently doing that with interaction and shared responsibility is a much more effective and efficient way to go, especially in this era where we don't have staff just sitting around twiddling their thumbs. They're all typically engaged in business centric activities and as they should be.
Ben Ford: [22:51] We’re not waiting for code to compile anymore.
Robin Tatam: [22:53] Exactly. And in compliance is something that I think from a DevOps perspective is perceived as slowing us down. We're looking to be as agile as possible, all about efficiency and speed to deploy. And compliance has this perspective of, "Oh my gosh, now I got to jump through these hoops and I got to check these boxes." And like you said, Ben, you're building something, you just want to slap that deck on the back of your house and now I got to wait three weeks for an inspector just to come and look at the footings to make sure they're good. What we're trying to do is compliance at the speed of development. Getting that compliance in a state where it can be done effectively and efficiently is realistically going to only be done via automation and that benefit, I think is that then we're not going to slow the cycle. We're going to keep that development going at the speed the organization needs it to.
Ben Ford: [23:45] Maybe this is too soon, but we've all noticed in the last week or so what happens when you build things without getting things certified and following standards and whatnot.
Robin Tatam: [23:55] The world is full of examples of many, many things where people have done that.
Ben Ford: [24:02] If this has such a big impact on how we do configuration management, that seems like there's a lot of opportunities to maybe get it wrong a little bit. And we talked about what the costs could end up being later on down the road. That makes me wonder about cyber insurance. We hear that every now and then, and I'm curious to know what that actually does for you and how much that'll help or not help.
Robin Tatam: [24:26] It certainly leaned on heavily or has traditionally been, especially in the ransomware realm, where we look to that insurance provider to bail us out of a looming disaster. The reality is that that was a fairly undefined insurance marketplace. And I think along the last couple of years, the insurance companies have learned a lot around how that works and not necessarily in their favor. There's definitely been a significant rethink in the policy requirements that associate with cyber insurance policies. The expectation that it's going to get you out of jail for free is very unrealistic at this stage. Typically, insurance policies, number one, will have mandated requirements around that you have to meet certain expectations of basic security hygiene. And then the other thing is insurance on anything else they're not going to pay if they think you've not done your due diligence. It's definitely something that you want to think about beforehand. Otherwise, you're going to be paying a premium without any potential protection when something happens. In the same way, if you leave your keys in the ignition of your car and it gets stolen soon as the insurance company finds out, then they're going to declare that as self-inflicted and therefore they're not going to pay.
Ben Ford: [25:52] And honestly, I've always wondered about it because it's pretty clear how they can cover penalties or whatnot if you get a fine, but if you have a business ending experience, there's no amount of money that is going to be able to bring that back. And that's something that especially smaller companies, I think that's something that is got to be looming over people's minds.
Robin Tatam: [26:16] For sure. In fact, Claire and I have a conversation with an analyst yet today, and one of the things we're going to talk about is the fact that when we talk about security incidences and the total cost associated with that, we all gravitate towards the idea of a fine or a penalty, but arguably it's like an iceberg. That's the part that sticks above the water. What sits below the water are many other things, and arguably that can be more impactful or more expensive. And things like business interruption or damage to reputation, all of those things can ultimately have a tangible value. But it is difficult to associate that from an insurance perspective. And typically insurance is not going to cover your name being trashed on Twitter/X because you got everybody's name released, but it can possibly help you with the smaller pieces of it. It's definitely not a get out of jail free car by any stretch of the imagination.
Ben Ford: [27:14] I’m glad to hear that there are people on top of this because I think it's going to change our industry in ways that we still don't even know yet, and I'm glad to know that you are on the forefront of that. I think as we close up here, the thread that I'm hearing is that this is something that we all need to take seriously. This is something that we all need to pay attention to, and if we don't have a formal process in place, we need to get one. And if possible, we need to use something that's industry recognized. But even more than that, the key is to go back and check it continuously and make sure and not just assume that you can just roll it out and be done with it. Would that be a good summary of the conversation, maybe?
Robin Tatam: [28:00] I think that's a great summary, it's not once and done. It is a continuous thing, and unless you are a glutton for punishment, automation is the way to make that absolutely manageable because humans can only do so much in a day, and technology has the ability to scale and handle these kinds of things. It's get the mindset around the idea, this is critical. It's not a matter of if you're going to encounter a security incident, we all know it's going to be when, how well are you prepared for that if or when that happens so that you can recover and keep moving?
Ben Ford: [28:35] Prepare for it. Have a good backup policy, have a good response policy.
Robin Tatam: [28:39] Do your backups.
Ben Ford: [28:42] And test them. Your backup does not exist until it's tested.
Robin Tatam: [28:46] One hundred percent.
Ben Ford: [28:48] Cool. Thank you so much for being on here. Thank you everybody for listening. I hope you learned a little bit from this and got some ideas, and we'll have a couple of interesting links in the show notes. If you want to follow it up, just go up to puppet.com and find the podcast and click through. That's a wrap for today, and thanks again everybody. Thanks for being here on Pulling the Strings Podcast, powered by Puppet.