Hello, this is Nick Holland for Information Security Media Group, and today I am speaking about cloud security and overcoming roadblocks with Rick Bosworth, who is the Director of DSOM Solution Marketing Cloud Security and Operations at BMC. Rick, welcome. Thank you for having me, Nick. Pleasure to be here with you.
So the first question, then, it's actually a multi-part question in this new era of cloud-first. Let's have a chat about some of the cloud security concerns that enterprises might be overlooking. I want to talk about misconfigured resources, governance and policies, discovery of assets, and change management. But for the first one, let's talk about misconfigured resources and essentially what is being missed there.
Misconfigured resources remain the number one cause of cloud security failures for the enterprise. So these developers are out there moving at light speed. They are agilely innovating, continually integrating, and delivering new services, but perhaps not always with an eye to security. Now, every developer I speak with, they want to create phenomenal code, and secure code can be part of that as well.
Perhaps we haven't done a very good job as the infosec community in making the job of security or the weight of that lift on the developers, we haven't made it as light a lift as we could. So we're giving them too many tools, and perhaps they become overwhelmed and they don't know how to move forward in securely configuring those resources. And these resources I'm talking about, they're the IaaS and PaaS services that the likes of AWS, Azure, Google Cloud, that they put forth for these developers to use and develop their cloud-native microservices. These IaaS and PaaS services must be securely configured if they are to be secure.
And it is absolutely not the responsibility of the cloud service provider to make sure that those resources are securely configured. If you check the T's and C's of your contract with your cloud service provider under the shared responsibility model, it's incumbent upon the enterprise themselves, the users themselves, to make sure that those IaaS and PaaS services are securely configured. Moving on, Rick, let's talk about governance and policies. So a good question here is how can this be both centralized and automated?
Right. So you have all of these asynchronous scrum teams out there, as I mentioned, continuously delivering and updating their microservices, sometimes multiple times a day. So every time something is touched in the cloud, you run the risk of misconfiguring it. So then this opens up the discussion around governance and also policy-based governance.
Now, the inclination might be, and I've spoken with some organizations whose security, while well-intended, might be a little bit heavy-handed or draconian, and this tends to put obstacles in the way of these agile scrum teams. And the moment you make the job too difficult for them, you run the risk of circumventing process. So that is the first case, I would say, for automation and making it easy on the scrum teams. And so if we can codify all of our governance policies around who can use what services and how those services are going to be configured, and we can centralize those, and instead of putting a broom in the hand of the security team and letting them sweep up after the developers, help the developers own their own compliance to those centralized policies and let the infosec team then own those policies and maintain them continually, update them, as, you know, the Center for Internet Security refreshes their benchmarks for the secure configuration of these IaaS and PaaS services.
Let's talk about another aspect as well, which is discovery of assets. So, I mean, why is that so critical in today's cloud-based security era? Okay, so the cloud is changing fast. As we spoke previously, these asynchronous scrum teams are continuously innovating.
So the first thing, we have to know what we have deployed out in our enterprise cloud accounts, which IaaS services, how many instances of an EC2, S3 bucket, a blob. And not only what are we using, but how do they relate together to form these cloud-native microservices? So you might have a scrum team that's responsible, I don't know, for developing an inventory microservice. So the developer themselves, they want to know every single cloud resource, an instance of an IaaS or PaaS service that they've deployed to form their microservice.
They could even get wrapped around the axle sometimes, you know, so many people with their fingers in the pie and things are changing so quickly. So what we need to do is automate the discovery of the assets and keep that continually up to date, as well as visually illustrate how those resources interconnect. So then you can learn, the developers can decide how that would impact their security backlog, for example. So summarizing that answer, I'm sorry, it was a little bit long-winded there.
I would say twofold. One, know what you have so you can manage it. And then two, know how they connect together so that you can understand the business context. Final question out of this particular series related to security concerns around cloud.
Change management. I mean, clearly that is a big issue as well in that we're rapidly transitioning in a lot of cases from something that's more on-premise to something hybrid to maybe something that's completely cloud. In terms of change management, how is that done smoothly? So when I think of change management, the first thing that comes to mind, for right or wrong, better or worse, is I begin to divide up the cloud footprints into I have dev accounts, and then I have stage or QA accounts, and then I have prod.
The devs, this is their sandbox. We probably don't need change management there. But for prod, we certainly do. And QA, we certainly do because QA and prod is where we're supposed to have this immutable infrastructure and this well-oiled or well-governed machine.
Anytime we make a change, we need to automate our change management workflows so that any change is smoothly orchestrated, fully documented, because audits happen. So we want to make sure that any change in the production environment is fully documented, well aware, and then we can close the loop back to our infrastructure as code libraries and our CMDB so that we don't keep making the same mistake over and over and over. So the key there is automated change management orchestration and complete documentation and updating the CMDB. So Rick, on to the next question, which is how does DevSecOps benefit from enhanced cloud security?
And I think maybe for the first part of that as well, could you just very quickly define DevSecOps for our listeners? Sure. For me, DevSecOps, in plain English, just means embedding good security practice into the CI/CD pipeline so that we are shifting left. We are testing early and often to make sure that the IaaS and PaaS services that we're using are securely configured.
For example, every time a developer would commit a code change, you could automate a security compliance check of the configuration, perhaps of everything in the microservice, perhaps only what has changed since the last security compliance checks against that centralized policy-based compliance. So that's DevSecOps. And I'm fine with, you know, we just call it DevOps. I always like to say that Sec is silently pronounced in DevOps, so DevSecOps, there you go.
And the other thing is, I believe you had asked a question around how does cloud security become enhanced by DevSecOps practices? Yes, that is correct, Rick. So yes, how does DevSecOps benefit from enhanced cloud security? Sure.
So if the developers and the scrum teams are identifying their insecure or misconfigured resources in their dev accounts and rectifying those there, you're going to have less issues, presumably zero, promoted to QA or stage and then certainly to prod. So shifting left where it's less disruptive to production operations obviously saves the company money. Disruptions to productions are very costly. The other thing is you could then shift from reactive firefighting in production to more of a continuous monitoring for configuration drift.
And we talked earlier about production environments being immutable, but invariably, it's good practice to monitor that for drift because you will always have someone with read-write privilege on your production accounts. And unfortunately, it's probably all too easy for an administrator to go in there, flip a configuration setting on something at the request of a developer or line of business stakeholder, and then maybe something happened outside of governance there. The CMDB won't be updated, and everything just runs afoul in a month, and that's just not good practice. But certainly to summarize, the enterprise would benefit by monitoring for drift the production environments and simply having fewer security and compliance issues actually making it to prod by identifying them all the way back left in the development environments.
And finally, how is BMC helping to ensure that its customers have a better, more secure cloud experience? Well, BMC, we began our cloud journey perhaps five, six, maybe seven years ago. We've been automating and optimizing all manner of IT environments for the global enterprise going back all the way to the mainframe in the early 80s on in through now to the public cloud. So how are we helping enterprises have a more secure cloud experience?
I would say we help them with the discovery of their assets. We help them with the secure configuration and the continuous monitoring of their cloud accounts, regardless of scale or size. I think an enterprise could easily spin up hundreds of enterprise cloud accounts, and you need a solution that is stable at scale. And I would argue or put forth that the BMC Helix cloud security in combination with BMC Helix Discovery would be a potent combination to not only discover your assets and map the relationships between those assets, but then to also automate the security compliance checks and remediation without any coding required.
So the whole perspective we're bringing to the table is we really want to simplify the job for the scrum teams so that they