DevSecOps Roundtable: Why Automation Matters

DevSecOps practices accelerate the pace of digital transformation but introduce new challenges to maintaining security and compliance. Traditional approaches risk slowing software delivery, exacerbating audit pain, and leaving organizations with an incomplete view of security or compliance posture.

Fortunately, there is automation. Automation is a cornerstone component of DevSecOps because it allows Developers, Security, and Operations professionals to efficiently deliver value instead of focusing on error-prone, manual, repetitive work. Code serves as a common source of truth, shared as a common language among the teams and can be used to codify and automate infrastructure configuration, security and compliance.

In this roundtable webinar, Chris Hughes, CISO/Co-Founder at Aquia, Chris Medina - Solution Architect Sr. Manager at Chef and AJ Yawn – Co-Founder and CEO at ByteChek discuss DevSecOps practices from soup to nuts.

Watch this video to:

• Understand what DevSecOps really means
• Learn how DevSecOps and Automate can help deliver continuous compliance or security
• Explore how DevSecOps practices can impact organizations from different industries

DevSecOps is all about philosophy. It's all about the mindset, how you're thinking about-- thinking about security early on in the process. A lot of times organizations will run out and care about spending a ton of money before they think about what exactly is DevSecOps at their organization. What does it actually mean? And good security always requires context so you should be thinking about, how does this fit in my organization based off of my test, et cetera? But to me it's a philosophy. It's making decisions and educating your users and operators engineers, et cetera, to think about security earlier on in the process.

And when we're specifically talking about developing web applications or software tools like we do here at ByteChek, that's earlier on in the development process, it's incorporated security and thinking about it. And I like this graphic because you see security is just wrapped around the entire cycle, and that's to me is really what DevSecOps is. In every single phase as you go through developing something or just doing anything in your organization there's a security mindset being taken place. And from a compliance perspective, I think DevSecOps has been missed, compliance professionals just dodged it a little bit the matrix trick when they hear the DevSecOps terms they run the other way.

And I think we need to have more compliance professionals, more talks like this where DevSecOps is considered for compliance, because compliance is supposed to be for security. You're supposed to be able to improve your security but it's turned into this check the box. But that's because we're not doing these DevSecOps things, we're not thinking about it from how do we actually improve our environment. And then once we start doing that, promiscuity perspective, how do we prove it to an auditor or to whoever else is coming through, and more the way that we traditionally think about things are how do we prove it to the auditor?

Doesn't matter if it's secure and anything, doesn't matter if it's going to benefit the organization, it's just let me just get this evidence to this auditor internal or external so he can get-- he or she can get away from me and I can go back to doing what I'm doing. But what we would want to see in DevSecOps from a compliance perspective is, let's actually start doing some control checks earlier on, let's start monitoring some of this stuff early on. So again, it's just a mindset shift to where, I'm not going to wait until my application is deployed before I start thinking about compliance. I'm going to think about it at the beginning when we're writing requirements. And that's to me it's all about, it's all about up between the two eyes what you're thinking about more so than what you're using out there.

That's more than just going through the motions, is really active participation. I think is one aspect that I think DevOps has instituted in the organizations and now where we talk about, OK, why not include security in that conversation as well? Because the impact of not having a security or secure environment is impacting the organization, be it at any stage of a DevOps practice, so why not include it? It's not just another term that we're attaching to DevOps, but it is truly being that active participant in bringing value to the organization overall, full stop.

Hughes, what's your perspective as the security guy there dealing with compliance and, oh, my gosh, here we go, another audit. Oh, my God, another check box. Some time away from nonproductive time I want-- how do you see DevSecOps playing in your little world?

I think-- a lot of things AJ said are things that resonate with me, which is no surprise because me and AJ think a lot alike. I think that DevSecOps at a high level without getting too technical was about breaking down the silos between the security team and the operations team to basically expedite delivery of value to the organization. And our reason I think we've seen the evolution of the term is because initially security wasn't a focus of that paradigm shift. And we're not realizing that delivering something fast it's insecure, is not delivering value. Delivering something that securely-- secure fast is delivering value.

And I think that, as an industry there's a lot of room for innovation around this too. Like AJ said, we always think of adding compliance after the fact. There's a lot of technologies and innovations around cloud and infrastructure as code compliance as code, things of that nature they can back in, those compliance things from the beginning. And then if you look at the ability of DevOps to deliver fast, if you have a control deviation, for example, you can remediate that very quickly by using DevOps practices and technologies. So I think that we're starting to see this paradigm shift moving towards broader DevSecOps and bringing compliance along with that is just like anything it takes time, it's a maturation process.

Well, thank you. Medina how do you see-- what are some of the benefits that you see out there with some of our customers and clients that have started that direction, that journey of DevSecOps journey, what are some of the benefits you've seen some of the customers get there?

So that's a good question Alan. There's a ton of people out there who went straight to market with automation for the sole purpose of being able to implement security quickly. And soon they found that just being able to get in and make changes on the fly or at will got to be not only a slower process, because they were breaking dependencies and they were putting themselves at risk more but the use of automation really helped them speed up part of the process when shifting more to the left.

And so I like what AJ was saying about the philosophy of this. This is-- in a way I look at this as-- it's a dance. And we look at these, the way this flow rolls around, this is an age old dance that we've done forever. We've got security baseline, we've got controls, we need to implement, we've got to be able to modulate and/or manipulate the systems as new as our adversaries figure out new ways to penetrate and infiltrate. And so it's just a constant flow and never ending battle between, hey how can I improve the baseline or how can I think ahead of what the next thing is going to be?

And so the customer comes back to, hey, if I can implement this, the faster I can implement this, the quicker I can be to market, the quicker I can get production start up, the quicker I can recover if there's an incident, and all of those equate to time and money. You consolidate the tool sets, you consolidate the operations teams with the Dev teams and the security teams, they all come together as one to move this stuff through fast. Remember when we talk about automation to me it's synonymous with speed, and you can only go so fast in this world depending on how complex your system is. So to be able to get things into production quicker has really meant a lot of time and money to our customers in the field.

Good point. Any other thoughts guys on this or more importantly, how do you think DevSecOps relates to CI/CD. Because many of the stages they are all part of the CI/CD part of continuous integration, continuous delivery process. How do you see DevSecOps playing or relating to that? Hughes, why don't we start with you?

Yeah, I think CI/CD is definitely a critical aspect of-- many organizations successful implementation have DevOps, have DevSecOps leveraging these technologies CI/CD pipelines to deliver those-- to deliver updated code and updated capabilities and updated functionality and that automated fashion. A lot of organizations are leveraging CI/CD pipelines to facilitate that, and I think that's definitely critical to achieving the goal of DevSecOps basically.

Well, when you got there, AJ?

Yeah, I think it's-- that's where it all comes together I believe. That's where you have all of these opposing forces that are typically opposing, they're not supposed to be but they fill opposing the organization where you have developers, operations, and security. And this is where it all happens. This is where you bring them together and you can get all of-- everybody can obtain value from having DevSecOps in the CI/CD pipeline where in other areas a developer is not going to see a ton of value in a compliance report, there is not. At the end of the day an operator is not going to feel like they should sit in a board meeting explaining what they do.

But that's what these other areas have to do but I think the CI/CD model when we talk about DevSecOps. All of these opposing forces that we see come together and they can bring-- and everybody gets value out of this because it's seamless, it's streamlined and everybody gets to operate, we're going to talk about using the same language later but everybody gets to operate in the environments that they're typically used to operating, and no one really has to change a lot of things. So I see it as-- if you're thinking about DevSecOps you're like, all right, AJ, we have that philosophy down now what do we do? This is your north star. Get into where it's fully baked into your full CI/CD pipeline so that now when things are being released, when you're getting that application out the door it's meeting everybody's needs from the operations, developers, and security perspective.

Very good point. Medina, any thoughts there?

No, I think they-- I think they said it well. This--

I have one question for you then, why do you think is the state of affairs of InfoSec? What's on top of mind? What are some of the difficulties that the information security teams are facing in today's tumultuous, multimedia, multi-- front issues with all this going on there?

So again, going back to what I was saying before in this dance that we do, I think top of mind for most is the speed to which they can get things implemented or shore up any leaks that they have. And so it's really to me more, again, in art. Because a, you're going to take what you see at the gateway. And I've had a lot of interesting, very energetic conversations about the philosophy of it's an edge thing, no it's a client thing now we've got to figure this out somehow. No way the two meet, but if you can bring it through number 1, have a baseline of what you see, understand who's knocking at the door, and then constantly keep your security updated. What better way than to pull the mundane out of creating that baseline deployment as you move that stuff left?

We didn't have the opportunity to do things as code before, it was very manual. I'd get my list to CVE's, I'd have to manually go in and check everything, and that's not where I want to live. And that's really today from a customer's perspective, you see people voting with their feet. Like, I didn't sign up to check CVE's all day, I want to code something, I want to create and make feature functionality. So be able to pull the mundane out of this. If you have that list and you create this declarative language that you can not only put into your CI/CD but you can develop and test as you move along that pipeline and deploy it. Is really pretty exciting because then it just-- it's the ability to say what if-- how creative can you be? If I can do this why can't I do that? If I've got this environment, why couldn't I do it in another environment? It's limitless in the possibilities, and so it just lends itself to-- this is like a natural progression of where security would go.

Great point. In terms of security this is one-- understanding and belief that there's a delicate balance necessarily between speed and security. You agree that there's this consistent battle or need for balance being waited for one versus the other? And what does it mean for organizations? AJ, why don't we start there? Do you think there's this balance of the ability to-- one versus the other? How is that?

I think that's the old school, I was going to say monolithic but I don't think that applies here. I just think it's about [INAUDIBLE]. That's the old school of thought of security and development, is that it's going to slow you down. But I think with the acceleration of the technologies that we have and then the realization that deploying unsecured code into an application is going to slow you down dramatically more than meeting some gate earlier on in the process. So I think you're still going to run into it, I run into it, I'm sure both the Chris's run into it all the time where you meet somebody, like, hey well, I just got to focus on growing the business. I got to focus on this I can't invest in this right now. But I'm starting to see a shift where folks realize it's important to get this done now. Regardless of the size of the organization and the majority of them they realize that you save time, you save money, you save reputational damage if you do consider security early on.

Now that's where the philosophy comes in. This is where the DevSecOps philosophy comes in because if your engineers are actually thinking about security, because you are implementing this DevSecOps mentality it's not going to be seen as a blocker, it's just a part of the gates that they're going through when they're doing things. And it's not something that's, oh, this is slowing me down. So that's where-- I think this is something that we're starting to see a shift but you still hear the argument, well, security is going to slow down the business or whatever it may be. And I just-- I think it's the opposite. If you don't consider security early on you're going to slow down later. You're going to run into issues later that are going to cause way more delays time, et cetera and a lot of money as well.

So Hughes, the people run away when they see security guy coming in?

I think they definitely do in some cases, depending on the organization and the way security is approaching things. We have some innovative organizations who pro security totally different than the way their legacy organizations and legacy to me and you, and it's a lot more collaborative. Something that AJ mentioned is being an enabler, and I think this is where it's important to have security integrate with existing developer workflows. I have this ongoing debate right now on LinkedIn about-- there's always a focus on reducing friction from the security perspective to enable developers. But I think some friction, some resistance, some stress is healthy to ensure that what we're introducing, what we're implementing aligns with the organization's risk tolerance.

But once you integrate with existing workflows for developers and organizations it becomes a lot less of a tedious and a cumbersome process. It integrates with the way they currently do things and it makes it a lot more easier for them to continue to move at the speed they want to move while having those security assurances and checks in place and letting them do what they want to do. This is where you start to see the shift of conversation, start to call security implement guardrails, you don't have guardrails. So people can go fast but they can't go off the road and just run off the side of a cliff. They can go fast but there's some controls or some regard or some control in place to keep them on the path they need to go securely.

It's a great point, great point. Chris, I think you have a story where you see speed security, and what's the other one? Cost? I think if there's--

Oh, my gosh. I can't believe these guys in bringing up the both of them as many times as we talked about it. Is speed security and price pick too? You can't have your bread and butter at the same time it's wow. And this is-- from my perspective I say, this is a higher level. When you hit the sea level conversations and we're talking about this. Because everybody knows security and the philosophy of security is going to be based around how you value that particular data or what it is that you're doing in those transactions. So the lesser you value that particular part of whatever said data, those particular things against these other things you're going to build more security and security practice around the stuff that's more valued and that costs money.

And lot of times, more times than I'd like to reconcile with it's been about, hey, you know what? I've got this pot of money, I've only got so much to spend and I want to spend more on this side then I do on that side. But speed is always a top of mind. I don't think the three of us-- four of us would be here having a conversation without the topic of speed. Because automation is like I said, all about speed, and how you do that, how you employ it depends on how fast you can go. We call it velocity or the rate at which you can develop and then get into production. How fast you can get that is the velocity. And to be able to implement the three of them in a good timely way but it's never that way ever, ever. I want to spend more at the edge, no I'm going to spend more on the client, no I want to spend more on my security consulting guys like Chris and AJ to get in here and help me build out the framework. It's a huge factor in what it is that we do.

Yeah, that's true. So we did a survey back in early 2020 I think, where we talked about-- went to InfoSec professionals. And one of the-- there was a couple of findings that I want to share with most here and get your feedback and your thoughts here. We talked about that pace of delivery that Medina just mentioned. So we asked companies, how was the involvement from the security team impact the pace of the software that is delivered from your organization? And from the people that have adopted some level of DevSecOps practices, 47% say that they feel that they've been faster in delivery while non-adopters feel that they've been slower. So essentially what it means is that there's a perception, an incorrect perception that security slows you down. Those that have adopted have-- can clearly see that they believe that it's now helping them be a lot faster. Do you agree with that Hughes?

I do. And I think this comes back to where AJ, myself, and Chris were also talking about a moment ago, which is like the integration into existing developer workflows and leveraging automation. When you do that it allows speed to continue on and it helps facilitate that velocity. When you stick with legacy approaches to security for example, you may be going really fast and then you hit the security team and things come to a grinding halt. So integrating with the DevSecOps and using the modern practices and tooling to facilitate that velocity is probably why you're seeing those positive reactions from the team that have done DevSecOps and implemented automation-- implemented automation and things of that nature. So can help facilitate it when done correctly, I think that's what this is showing here.

AJ, you were smiling when you look at the slide. So any thoughts there?

Yeah, I think it's the age-old story about security. Once you start to think about it and incorporate it you realize, oh, this isn't that bad. But before you're like, oh, this is the worst thing ever. And I think Chris you said something interesting on the last slide about guardrails. And I think that's why when you implement-- when you get this DevSecOps mentality you're able to still move fast, if you feel like you're able to do things because we're not stopping you, we're just going to make sure nothing bad happens. We want to make sure if you go that way you bounce back a little bit this way--

And I think this is the message that I think I often see when companies start to realize, OK, I'm going to take this seriously for whatever reason, they are going to breach or whatever it may be. They realize, oh, wow, this is what I was avoiding, this is it. This is all I was avoiding, and they realize it's an improvement to them.

And I think something also that I believe Chris Hughes mentioned as well, what we're talking about here automation and using the tools to do that it's a concept that we talk about in the course I teach but it's like living off the land. In compliance we should try to live off the land, we should really try to use the tools that our people are using, our administrators are using and then let them administer them. That makes things a lot easier, allows them to move faster. You go to your engineers or your operators and say, hey, I got this DevSecOps thing but here's seven new tools you've got to learn. They're going to run away from you. They're not going to be interested in doing that. But you can find out, what are the tools you currently use? OK, there's this one tool that we get it incorporates with all these tools, I'll give you a script, and all you have to do is run it, and we're good to go and I'll get all my compliance reports. They're going to like that a lot more than having to install a bunch of tools. So I think that's why we see this slide is because when you do adopt it, it's about let's make your life easier but also keep the company secure which allows them to move fast. They don't even think about security anymore because we've done a lot of the work up front to protect them. So I love this slide as well there's a lot of great slides you all have that I just-- I think are great slides to help me just grow my business.

Great point. So Medina, I asked you about the benefits of DevSecOps and we ask the same question to the CSO's and CISO's out there. And so one of the benefits of implementing DevSecOps practices in their software development lifecycle here's the results, improving efficiency and audits, reducing the risk, and greater agility. So I think it counters all the perceived, predefined perceptions that security slows things down. It's very efficient, it secures obviously, and it provides some level of agility there. And then ultimately cost savings is like the last end of the scale there. But interestingly, increased innovation is also aspect because I guess, teams are working together and there's a synergistic effort when you work with different disciplines. You have a compliance officer, you have a security professional, and you have an operations team come in together and have those discussions. How do you see that distinction in playing different areas working together, Chris?

We increase-- that is an interesting looking statistic right there. So one of the things that we haven't said so far, which I think we probably should just put out on the table here is that security forever has always been thought of insurance. It's just like insurance, nobody wants to pay for it, but I know I need to have it because it's that one thing AJ said, it's like for whatever reason they've taken interest in it. Usually it's a breach or maybe some data leakage, and now they've equated it, somebody has come back and equated it to how much money they've lost and they're like, well, I shouldn't have invested in my insurance plan with ByteChek. They should have built me out of framework I shouldn't have invested in them to do these things. And you need right up front, you need to have a good consulting team come in here and build out a good workflow, a good practice around what you're doing from a security perspective.

So no one typically is going to think of security as being innovative, it's more of what do I know and how do I lock it down? But in terms of being innovative, if they are they're not telling you. Because if I've got some tricky way to put out some honeypot that draws in bad guys who are looking for my stufff or I can create a better mousetrap I'm not going to tell you about it. So it's there, I think this percentage number is probably hiding a lot more than what people would tell you because security people often won't tell you what it is that they're doing anyway.

Very good point. So I have one of the best anecdotal stories that I've heard recently. And Chris Hughes, you tell me, what is the analogy that you use when you talk to-- about your kids room, and how does it relate to audience?

I was hoping to see this slide because it's very much like the best analogy I've come across this year around compliance and security. I have four kids now. And we were talking about the slide once in the past, compliance is always a snapshot in time. Same thing with my kids, if I tell them, hey, go clean your room I'm going to come check in 30 minutes it better be clean. And when I come in is super clean. But as soon as I walk away this is what it looks like about five minutes later.

Same thing with compliance, the way we typically do compliance and security is like we have a snapshot in time, things look good, OK, everyone's been working really hard, get everything tidied up, cleaned up, secure, where it should be all the paperwork completed et cetera. But then as soon as the compliance assessment period is over it looks like this again. And this inefficient. Your adversaries, they don't operate in a snapshot of time, they operate at all times. So you need to have this continuous assessment model-- continuous security model in place to ensure that things are always tidy, things are always secure, things are always hard in the way they should be. And that's why I love that analogy, is because the traditional way we do compliance and security is just inefficient and it's not working and we need modernize.

It's a great point. I'll write a blog about it. You should write a blog about it. It's a really down to Earth, any of those that have kids can totally relate to that. Even teenagers like I can totally relate to that. You start looking under the covers then you'll see where all the hidden skeletons and all the busted stuff is located. So now to someone else's favorite slide. And AJ why do you like this slide so much?

I think it accurately depicts the problem with compliance. We get these reports and they show that for every second of the year for the past year everything was amazing, and the way that was identified was through screenshots. So we took manual evidence and we said it applies across this entire time frame when everyone that works in this field understands that the right graph is actually what happens. Especially in the cloud you can create an S3 bucket with about three words in the ACL And you can do really bad things with a few more words on the head of your ACL, doesn't take a ton of work to spin up a new resource and for things that fall out of compliance.

And if you're a startup or growing company, you're hiring people like crazy, some new people are coming in they may not enable MFA right away. And the reality is security compliance all of this, you're going to do this, you're going to go up and down. It's just the reality of how this stuff works. And the goal of compliance should not be to get the left side of the graph, it should not be to get a clean report. The goal of compliance should be able to tell management what's going on so they can go make a better business decision.

I think compliance has a bad connotation because everyone sees just that left side of the graph. But if we pull it back and think about what is actually compliance, what it controls, the control is just a risk mitigation activity. It's you are doing something that's going to mitigate the risk. So a compliance assessment is coming in to see, are you doing these things consistently to mitigate a risk? And yes you may have some really cool stuff in place but the reality is at times you're going to need those systems to either trigger in order to remediate or scream at someone and be on alert to tell them to go fix those things.

And I think internally I get the need for a formal report, externally for business, and to get that out there you don't want that necessarily to look all jacked up like your systems all jacked up, you've got to grow your business. However, internally you should be looking at your compliance assessments. And if you get one of those graphs that say, we've been good forever, you should-- your eyes should perk up because we all know that that's not the case. So I think this is a perfect depiction of actually going on.

So how do we make sure that when these dips happen someone knows or it's automatically fixed or whatever it is that you want to do and your treatment plan there? But let's think about reality. This is not real but compliance is going to look like this for 12 months, which most of these assessment frameworks got. I think it's a perfect slide. I think this is the reason why most engineers, operators, folks hate compliance. Is because the auditors actually believe that the left side is true and they know what's going on is actually on the right side of the slide.

Yeah, the interesting thing about audits too is that-- correct me if I'm wrong, is that you're only looking at a subset. Two, you're only looking at a little section of the population of what is reality and assuming that, OK, everything else-- because this little sliver is cool to go all the rest is well because it should follow some level of standardization across the board. And is that really true Hughes? Do you see that?

No I actually was shaking my head when you said that because it's like I just said screenshots. And typically they do statistical sampling of a subset of the systems. Now some of these are good then everything else is good. And often there's a little bit of negotiation like, OK, test these systems. And then those systems are definitely the ones that are going to be tested, get those hard, get those good, get those jar.

And that's just inefficient like I said, the adversary it's not just a snapshot in time, it's not just a sampling of your system, it's your entire environment. That's why you're leaning to automation and cognitive technologies to make sure that your entire environment, not just a sample of your environment, is compliant and secure at all times. Not just a snapshot in time, not just a subset of systems but at all times and all systems. Obviously like AJ says, it's never going to be perfect. That's just the nature of our career field in IT but you definitely want to try to even out that line more so than having those drastic peaks and valleys essentially.

We should talk about what makes those dips too Alan. Because the slide on the left shows you where they flow down, and that's large--

And that's the perception. That's the perception that, oh yes because I'm compliant at this stage my compliance state will remain the same, I think AJ mentioned that. But in reality what happens is when changes occur within your environment, within your systems, new things are added, things are modified that within a steep. What else helps impact that? Medina.

And how fast are we making changes in the environment? We're constantly updating our phones, production so development wants to make changes-- would make changes every hour if they could, but the reality is these points in time are audits and audits depending on how big your enterprises can take forever. So if you've got a CI/CD pipeline that's building stuff at the rate of-- at a blinding rate of the speed of market then you're constantly changing that environment just over and over. And it's-- the end it worse, because you've got different infrastructure, you get different applications, you get different code builds, you've got all the sprawl that happens with your configuration management and your configuration specifications as Gartner would like to call it.

So to be able to catch that point in time, and I know anyone at least my perception in my 2007 years, when their morning meeting happens with the CISO they're going to ask, what is my risk rate right now? What's my risk factor look like? And so the team has to be able to respond and tell them where he's vulnerable or she's not compliant. It's got to be there every morning and it's constantly happening thing.

Yeah, we talk about continuous compliance, which is the ability through automation to really reduce the cycle sides then takes-- on average our survey also showed that an audit takes two months to complete. So by automating that and making it more frequent throughout the process you're able to shorten those periods of compliance validation, verification to where it's almost a straight line because it is continuously validated. And can maintain continuous compliance there too. So we'll get in a little bit more detail about that in a few minutes.

But the next slide I like-- we mentioned it earlier, but different teams have different languages with different tools. And it speaks a little bit to that conflict that we typically see or historically have seen before this advent of DevSecOps practice where compliance ha stock of procedures and policies and things that you need to check off and follow. Security will have a set of validation tools to scan and make sure the systems are the way they are supposed to be and they'll hand it off to their DevOps teams and say, OK, here make sure the systems follow this. And so this-- having this mix of different tools, different responsibilities, and the translation time alone, that it takes from one tool to another to be mind boggling can be very time consuming, very manual, very painful in a way. So do you see this in reality out there? Why don't we start with you Hughes? Do you see this different languages, different tools, different conflicting interests there?

Yeah, I definitely do. And this is why I kept stressing integrating into existing workflows and breaking down silos just like now do you see different languages and terminology and way of operating? But you also see almost like an adversarial relationship between the teams. Like it's always the Devs or it's always security with x, y, and z. And then you need to bring these teams together working towards a unified goal, unified business outcome that we're trying to support and break down those barriers between those teams to help facilitate that collaboration, is where we need to head in my opinion.

AJ, your thoughts.

Yeah, I think this is the core of the problem, and I see it often. And the way that I can-- easy way I can tell that this is going on is when I send whoever it is at the organization is responsible from clients some information, and I can see the email chain and I get a response, they just forward it off to someone. They didn't even consider what I said, didn't even-- I had no clue I'm asking about change management or something it just hey, someone how can you answer that blow question? And that's because that compliance person truly doesn't even know what is going on in the CI/CD world. They don't even know-- they don't even know what CI/CD is because they're so far removed from the work and they speak a different language, like you're saying. They're thinking about controls, exceptions, auditors. The developers are thinking about development, security people are thinking about protecting the data. And I think when it comes to these different teams, different languages, and tools it's on the compliance side.

Most businesses are not in the business of security, there's very few businesses that are in the business of compliance. So if you're a compliance professional, you need to come to the developers, you need to come to the engineers, the operations folks, and speak their language. I think this is-- I mean have you ever been to a foreign country where you don't speak the language? You try to go order food, it's a challenging experience. It's a way you really learn about yourself, you're out there truly don't understand what's going on. And I think that's most compliance professionals when we talk about DevSecOps and some of this technology.

So I think that does cause a significant issue during this process because the compliance personnel are like, hey, I need information on your firewall. And then they're like, we're also AWS, we have security groups. What are you-- why are you asking me these questions? Get out of my office. And that happens. And then now there's this adversarial relationship. So the compliance person is too scared to even go there so the next time this engineer is asked a question it's from an auditor. And now they are going to do whatever they can do to get this out. And that's why I think we have to stop thinking about audits, and you mentioned something earlier, Alan, about scoping out audit.

Organizations always try to do that. They're always trying to figure out, let's scope this down. Phrase I used to hear way too much, let's scope this down. And it's like, hackers don't scope anything down, they're going to find a way in regardless of what your scope is for your audit. So when we get away let's forget audits, they have to happen, they're going to happen, we all know that, but focus on the security and that would bring compliance professionals to the table. Because we're just talking about security, we're just talking about operation, we're talking about the processes that's going on. We're not talking about meeting PCI or SOC 2 or ISO, it's just truly security because all of that other stuff will work out. So I think this is another one of those great slides but I'm going to put it on the compliance folks. The compliance folks have to come to the table and be willing to learn the languages and tools that security and the DevOps are using or at least be educated enough to have an intelligent conversation.

Oh, great. I have a couple of slides that I want to share with you guys now. And Medina, you help me out here because I think we have an interesting aspect of the basic, the core part of automation we believe that it is through code. And why do we believe the code is the toolset? Because it enables that continuous compliance. Because it's something that is collaborative, is an ambiguous common language, is human readable and inspect, on the right hand side, you see the sample there. Because it's code fireball it's scalable, and can be done across different environments. It can be on Prem, it can be in the Cloud it could be even in the Kubernetes [INAUDIBLE]. So it allows you to do a lot across the board. You're able to shift left through the software delivery process incorporating everybody in that process. And ultimately it provides you this continuous visibility because it is reportable, it's scalable, and it can cover your entire environment, especially. Why do you think, Chris, the code or compliances code is so important?

I had a customer meeting the other day and the engineering team was on and they were a little bit finicky. And one of the questions that came from that team was, well, I've been doing Nessus scans and I've got scap scanning, and I have a good understanding of how to install the latest from CISA and get a reading back on what it is that I see, why would I-- why would I want to do this? What's the point in shifting left when I have a good security practice going? And the answer was pretty straightforward and simple to me but it's difficult to couch in those meetings, which is, hey, let's talk about the maturity of where you are especially if you are doing DevOps. The maturity of that pipeline really can be based on how well you build a security practice and how well and how fast you can deliver code that's in line with the compliance team.

So when you look at this piece of code, here's a great example to the right. This is just straight code that you'd use to build out security policy as code. And it's very descriptive, it tells you what control. You've got a package here that we want to do and say, we do not install Telnet server. See this is very easy to read, it tells you the impact level, it tells you exactly what it's doing, where it came from, these are the guidance levels, here's where you would get this and how it would pass an audit. This is, I mean, this is straight up, I mean the actual piece that's working here is at the bottom. Just describe the package at telnetd, and say it should not be installed and come back and give me a reading on that. That's just number 1.

Having this in front of an auditor to AJ's point, they don't really-- they're not necessarily speaking the language of operations and/or real security maybe, but they don't necessarily understand the code, and this is super easy for them to understand. So you see things this implemented, it cuts audit times in half, which can go on for days or weeks, even months sometimes. So it begged me not to respond to the customer but put it in so many words that, hey, look, it's one thing to be able to scan your environment and get something back. There's a number of architectures that can prohibit that from happening, but rest assured if you can take the code that you have build it in anywhere and be able to use it anywhere. Look at the agility that you've created for the company, look at the probably time and money spent on saving, all the stuff that you've been doing in multiple different types of environments, which we all know we need. You can't-- there's never going to be one single environment AJ talked about monolithic. I think he was probably doing an outmigration somewhere but it's those types of things that keep us on Prem. So you have those hybrid environments where you're still or you're trying to get to Cloud and having this code is the quickest simplest, most risk-free way that you can get yourself there and your agency there.

With this code I think this is the power, you can see right there PCI, HIPAA, NIST. We're checking three different frameworks with one set of code here, one little class or whatever we're going to call this here. That's the power where if I'm an auditor and I see this, it might look foreign to me when I first look at it and I get scared and run away but when I come back and I see this I'm like, oh wow, I just tested PCI HIPAA and NIST, all that one time, and I'm doing it in an automated fashion? This is why we should do this. Because there's a lot of enterprises, especially the larger ones that-- both Chris's and I we all know this, they're doing multiple frameworks, they're not doing just one, they're not just doing PCI, they're doing-- they have all of these many requirements to meet.

And if you think about the way that audits have traditionally been done, you have your PCI auditor, your HIPAA auditor, your NIST, your federal guys, your SOC 2 folks, ISO, all of these different auditors. And the people that are getting the worst part of this aren't the compliance professionals, that's their job. The internal auditors are supposed to coordinate with the auditors. They're cool with that, that's fine, that's how they make their money. But the engineers are collecting information that they don't have a Telnet server installed 30 times for 30 different auditors. And that's not what anybody wants to do, they want to be out building. And this is where it gets into that speed versus security thing, especially when we talk about compliance because there's so much wasted effort. And using unambiguous language like this using language that all of us can understand and implement it reduces that time because most of these compliance by what you're saying the same thing.

I'll be the first to tell you they're all going to repeat themselves it's just a matter of who you're paying. We're going to tell you to do vulnerability scan, you're going to do a Pinterest. Make sure the right people have access, make sure you on-board and off-board people the right way. They all say the same stuff. So when we come to that agreement, now it's like how do we make sure we get the maximum value out of one piece of evidence? How do we make sure we can use that one piece of evidence across multiple

Frameworks? And this is-- I think this slide and with the code there you can just see three frameworks right there, and then you even have a CIS reference in there. That's powerful from an audit perspective and a compliance perspective. And this is the-- I think the future, this is what we have to get to because no organization is trying to comply with one framework. And like you said as well Chris Medina, multiple different types, there's different operating systems. I can't remember the last time I came across 100% Windows or 100% Linux. You're seeing Linux, Windows, you're seeing virtual machines, containers, little serverless here. There's just all kinds of stuff going on in these organizations that you have to have some central way of collecting this information because if not you're going to ask for five different types of things, you're going to want to know how are they doing security across those five different things, is going to be different pieces of evidence or you can just use this one set up language that allows you to do that continuous compliance, Medina.

And how easy would it be to take the output from this, it's a two liner really. You take the output from this and pipe it into what you already have. You don't have to rip and replace stuff. And you've built yourself a good practice, I'm going to take the output of this, I'm going to give it to whatever automated tool said I have to make the changes, I'm going to give it to my security team and let them do what it is that they do. And a way you go, you're bound to do some good stuff when you're building out a practice like that.

Yeah, Medina. You are alluding to this new-- what we call the human free zone. Chris Medina, why don't you walk us through this? And I'm going to ask Hughes on the latter part of this, what do you think about human free zone as a security model? But Chris, why don't you walk us through this?

So this is really good, I like this. I call this the secure supply chain of code. And everything is code as we see it today, I mean even when you're building it on infrastructure probably somewhere, it's just the cloud of someone-- someone else's computer. But as you're deploying it you can see we're employing practices where you don't-- where humans don't have to touch the stuff because we are the weakest link. In any type of black and white scenario for doing zeros and ones and we're allowing there to be no errors, then we put these things in source code management, a version control and we send it through the pipeline.

Now on this particular picture we've got the hooks in here to allow for certain rules that happened in security. You've got two person rules that say, hey, I need to be able to control, I need visibility. And they want to understand what's happening throughout this pipeline. Maybe it's broken maybe it's not, automation is very scary to me because you just-- you flip in and it's either done or it isn't, and I've been breaking production forever. But in this case we send it through each particular stage. There's a stop gap here where it's looking for input, and this could be piped out to whatever. It could be looking for a ServiceNow response or some type of email response, whatever it is, and it looks for input before it takes onto the next stage. So we get into testing and it goes through those.

But literally you could automate this entire process. No one touches it, and if it passes the criteria of what your security policy should be, when it gets into production it should be clean. You're building out products that are aligned and compliant with your security policies. So this is a fantastic way of building in that zero trust workflow that a lot of people are looking for today.

A great point. So Hughes, is this a secure model? Do you think security professionals believe in this-- OK, if automation is the way to go for security?

I think it depends on the security professional, obviously we have three of us on the line who seem to think that that's the case, this is the direction we need to go. But a lot of things we talked about all tie together, like one aspect AJ brought up is the lack of knowledge and even skills in some cases among the compliance workforce when it comes to modern technologies, Cloud native environments, automation, CI/CD pipelines, DevSecOps. Some need to bring that workforce along with us and help them understand the value of moving to this new paradigm. And that's where they'll get on board with this, is when they understand how things are working, how these things tie together, and why it can be trusted, and why it's even better than the traditional way we do things in many cases.

I've heard some proponents, I'm sorry, I should say people that anti to this approach. We can't automate all the controls or everything can't be put in code. That's right, maybe not everything can. But if you've ever done this kind of work, you can do in a large subset of that into code and automation is an incredible win. And it could save so much time and provide so much more continuous monitoring, continuous security. So I think it's a multiple factors at play from technology perspective as well as from the workforce perspective and bringing people along.

And that said maybe you won't have a total human-free zone. I've worked in some environments around national security in DoD for example, and you may need a human gate depending on if it's a weapon system or things of that nature. But that doesn't mean for everyone, some systems definitely can be fully automated. So it's just unique to each situation, each environment, and what risk tolerances.

We account for that in terms of human approvals in that model as well because we believe that they are stages or gates that need to be validated by a human being. It's just that the matter that we believe is that once you set those controls, and once it's human-free zone if there's a human interaction where it's not supposed to be, that's a red flag. That's a major issue you need to make sure you're secure. Because you're not supposed to be there, what the hell are you doing?

I was just gonna-- I'll say it quick, it goes back to what Chris Medina said, if the codification of everything, if it's in code there's no human subjectivism in play there. This is what it is, this is where it was assessed as. There's no subjectivity there, you know for sure that what is being assessed and evaluated aligns with exactly what's being seen.

That single source of truth, and that becomes ubiquitous. Everybody agrees that this is what we're saying, this is what we want. And it goes forward and there is no ifs, ands, or buts about it.

I think some of the pushback-- sorry, go ahead. I think some of the pushback when some people see human--free zone they're like, oh, you're going to take my job. It's like, no.

Skynet it's going to come in take over the world.

Exactly, they're like, oh, you're trying to buy a tool to replace me. And that's not the case, especially not on security. What I think most organizations are trying to get back to are the security professionals thinking. Doing what they hire them to do, which is critically think, assess threats, stay up to date with what's going on, and be able to-- be a little bit more proactive, most security programs are reactive because you have way too many humans involved doing manual tasks repeatedly. So now they're just-- instead of your SOC analysts actually doing some triage and some incident response and some forensics, they're sitting there making sure people have MFA enabled all day. That you're literally paying someone $100,000 a year to make sure people have MFA when you could probably do something programmatic to fix that.

And I think that's the piece that senior leaders need to push down because you're going to get that pushback from the teams. I don't want to implement at all because that's what I do every day. Even when we're talking about here, this is going to cause a developer to lose their job, it's going to allow that developer to innovate even more. I think that's what we get back to that stat that you mentioned earlier of increase innovation because they're getting more time. You give a developer some time, you're going to get something, it might not be great but you're going to get something. You're going to get something from them. Go ahead Alan.

The value work is going to be increased. It's not this mundane audit responses to audits and getting reports back and so on. So automation, why does it matter?

I think for two reasons. One, it's way too hard and modern environments to do a manual audit. I think if you're doing a manual compliance assessment you're guaranteed to miss things. It's just the organization's environment sprawl, way too far out, there's way too many resources out there, there's way too much going on, like we said, there's this constant up and down. So if you're just asking for screenshots at the end of 12 months I can't buy that, we actually know what's going on. So I think automation allows you to see more on a continuous basis without needing to hire a bunch of people.

The other aspect of that I think is really important and-- I think currently in the compliance phase we're not getting technically accurate evidence. I think auditors are producing reports, internal compliance personnels are giving senior leaders information to make business decisions. And it's not from accurate info because we are doing it manually, because we are given screenshots, because we're just pulling all this stuff in ad hoc manner instead of doing it continuously, instead of actually hooking into systems and seeing what's going on a regular basis.

So now the downstream impact of that is an organization says, oh, we're actually fine on patching. There's nothing wrong with our patch management process. And there's these machines out there that literally have never reported to your patch management server or whatever it may be. You don't even know what's going on, but here you got the report that says everything looks good. So I think automation is needed to get us technically accurate info. The whole point of this is to reduce management's uncertainty. And when making those decisions you can't do that with bad info, bad inputs get bad outputs. And automation allows us to change the inputs that are coming into the compliance process and produce things that are accurate, that actually can seen. And maybe at first automation is not going to show you that you're 100% compliant like you saw before but you're going to know where those skeletons are. You're going to be able to see where the gaps in our processes and then how do I automate that on top of it to make sure that, that doesn't happen again?

So I don't see a way in the next few years how we can do compliance without automation just because of the nature of these environments, it's almost impossible to do that in an accurate manner. You can get a report guaranteed, I promise you that can happen, but what the report's going to say is it can actually reflect an environment, I don't think so without automation.

Hughes, any thoughts there? Why does automation matter?

Actually I agree with everything AJ said. It's what we mentioned earlier is removing the subjective nature of the assessment and audit process and getting this verified automated output that you know is a source of truth. And then also there's a workforce factor. We're simply not going to have the workforce to allow that level of velocity that we need for organizations to have that velocity and competitive differentiation get to market faster, et cetera, address things quicker without automation. So you would have to have automation.

Any downsides to automation? Medina.

Downsides. Well, I mean there's the obvious ones. When you're directly connected in a certain things and you're making changes on the fly you've got configuration sprawl and some of the scripts that you're running, there's certain things that you just naturally have to be aware of and be disciplined on. But I bring one extra element into this, which is, hey, when you employed automation in the first place it was to go fast, it was to take the mundane, going back to what AJ said about the previous slide, the mundane tasks. I'm not looking to take away anybody's job, I'm looking a way to get rid of all the mundane stuff that you didn't want to do in the first place. And that's where we get weak because we get used to do it or seeing certain things, it's very mundane and we might miss it. I think SolarWinds is a good example of that where we just get used to a process flow, when we pull stuff down and we don't do simple things just like checksums it's just mundane.

The other element that this brings is scale. Because what Chris just said, it's not just about the five or six commodore or 64 as you get plugged up in your basement, it's about these huge multicloud environments of hundreds of thousands of servers doing completely different things, and being able to scale that vast enterprise and get you back something that's coherent, that you can verify, hey, I'm checking telnetd all of these systems. How am I going to do that? I don't have a work force that's going to be able to check 100,000 systems in a timely manner. I can go off and get them but how much is that going to cost me? So you're weighing the pros and cons there but scale is a huge part of why automation is important in terms of security and verification. Whether or not there's bad points to it there can be a case made for some but I would say large in part the pros outweigh the cons every day of the week.

Yeah, I think that's a great point from the scalability perspective that resonates to me also, but not just in preparation, we're talking a lot about precursor efforts. But the level of automation can also allow you to have a reactive or a proactive approach in terms of, OK, there's this CV let's go out and check. Let's go out and validate at an exponentially faster way that you couldn't do it. Otherwise, oh, my gosh, OK, let's go check server, by server, by server. If you're OK you can do that scan across the board, across your platforms, across your entire environment very efficiently at a scale that helps you protect your environments as well.

So I totally agree with you, I think automation is how you do it will differ I think. It's just a matter of you have to start somewhere. And we believe that through DevSecOps practices and principles, and tools, you're able to truly have that cohesive team, same language, same tools, same understanding, same agreement, but ultimately you're able to have this approach whatever tool you use to automate, , to scale to protect your environment.

Any closing thoughts? I think we're going to leave it with this last slide but any closing thoughts on DevSecOps or automation? Let's start with you Chris Hughes.

Yeah, I would just say it's a journey, it's not like a destination. So you need to start with where you are in terms of your workforce, your technologies that you have in place, the platforms that you're using, and start to innovate and automate from there. It's going to take time and it's going to take learning along the way, and don't be afraid to make a mistake. It's going to take-- you may make a mistake, you have some lessons learned, you implement some of those lessons learned, and you continue innovate on that process. But there's no denying that if you want to get to where we want to get with DevSecOps and continuous security, continuous compliance, we have to automate. So definitely start with where you are, look to industry for best practices and guidance and just go along that journey and we have an open mind throughout the process.

Yeah I would say there's a common saying in the space that, compliance isn't security. And I agree with that, but security is compliance. And if everyone can just start focusing on security, let's focus on that first, let's stop thinking about all that, stop thinking about whatever framework you're chasing, focus on security. And I think that's what's going to help us out as we move forward from a DevSecOps and automation and compliance perspective because we're just going to change our mindset about this stuff.

If you're going into a compliance audit and your number 1 goal is to just get a report you're wrong. Your number 1 goal should be to improve the security of your environment, and the way that you do that is through automation, through continuous compliance. And I would charge-- I don't know how many auditors are listening to this but I hope the auditors start to pay attention. But we really have to get the audit side of the house better and speaking the same language like we talked about using tools like Chef InSpec, and being able to understand what's coming out of these tools so that they can make the lives of-- their lives easier but also the lives of their engineers easier. So I think we have to focus on security, let's just focus on security. That's the message I hope that everyone heard from this talk as weren't just talking about security, we're talking about doing the right things at an earlier stage, and then you're going to get some of the compliance benefits later on. And I hope that's the message folks take from here, and I appreciate the opportunity.

Well, I'd have to take the opportunity to talk a little bit about tests. Because compliance has two elements, the policy by which you're going to create the standard and then it's the verification. And so with automation you can bring those both together and really do it at scale, and that is simply a test, verification means testing. Do testing early, do it often, do it frequently. Build it in as early as possible, even if you're building out a piece of code tested against the latest frameworks and have an understanding of how it might be vulnerable, assess that risk and make sure that it's visible. But testing is important all the way through that process, it's a critical part of building a compliance framework and building security into your practice. And if you have any questions I've got two great consultants here that can come out and help you with it, that are on the line, and would be happy to do that for you and make the plug for them.