Introduction to DevSecOps - The CTO Advisor Episode 111

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to episode, let's call it the 111 of the CTO Advisor. I don't know if you guys really care about the episode numbers. Get back with me and let me know. Today, we have a guest that I, who actually took advantage of the CTO Advisor open hours or open office hours. And we had a really fascinating conversation about DevOps and DevOps security. And I thought, you know what? Why not have him on the CTO Advisor to talk about DevOps security in his company.

Michael Frazier, thank you and welcome to the program. Yeah, thanks for having me, Keith. Can you give the audience a quick intro of you and your career? Snapshot is pretty interesting. Yeah, thanks. I started out in the Air Force. I actually worked on, as a weapons specialist, loading up missiles on F-15s and F-22s at Nellis Air Force Base in Las Vegas. And then I transitioned to become a cybersecurity engineer. I got out of the Air Force full-time and went into the Guard.

So I became a cybersecurity engineer and I've had multiple technology companies. I was doing the hyperconverged infrastructure before that was even a term, before Nutanix or any of the current products out there for the SMB market. And realized that that was way before its time. And so I got out and actually was doing cloud and cybersecurity consulting for a few years. And then about three years ago, I got into the software world and was doing workspaces as a service right between my bachelor's and master's that I wanted to transition what we were doing in the workspace world and focus on more general purpose automation in the DevOps and DevSecOps space.

And so that's when I founded Refactor or started what is now Refactor about three years ago and formally started a couple of years back and have been pushing full steam ahead on that. We've gone through a few iterations, major iterations of what we're doing, some pivots, but we've learned a lot of really valuable things from really awesome partners and customers and vendors in the space. So now that everybody's completely up to speed and understands DevOps and we are all DevOps experts, I need to forward slash the sarcastic chasm, the hashtag.

DevSecOps, not the first time I've heard of this and practically one of my former employers are full steam ahead with DevSecOps. In a nutshell, what is DevSecOps? Yeah, so I think it's kind of to your point. It depends on who you're talking to about it at what hour of the day. But my definition on DevSecOps, it kind of has to go back to what is even DevOps. DevOps originally 10 plus years ago was called agile infrastructure and it was an extension to the agile software delivery of being able to quickly deploy and iterate on your software releases.

That was the agile approach. Do things quickly, get things done in two to four weeks for and so on. And then we added agile infrastructure saying, well, if I can do that with a software release, why not do the same thing with the infrastructure piece of it? And because of the public cloud, everything that's becoming, everything in the public cloud is software defined, it made it something that was a fairly easy thing to add in, I didn't say easy, but something that was easy to add into the overall, what is now considered DevOps story and principles.

And then on top of that, now security. So DevSecOps is now saying, instead of a normal traditional DevOps environment, you have your DevOps engineers building stuff out and then you have your security guys come in afterwards and go, okay, what did you break or what's not configured correctly? We need to make sure that these controls are in force so it's a proactive instead of a reactive approach. DevSecOps really is about just kind of a holistic view or a holistic process of end to end, not just the automation piece of it, but just thinking about everything from a high level standpoint saying, all right, if I'm going to automate it, I should also have security as something that's built in and not an afterthought or something that's reactive to the process that I throw at it.

And so that's really where DevSecOps comes. But a lot of people think DevSecOps has to be, has to be specifically cloud native or has to be specifically container based. And while yes, absolutely, DevSecOps can include both of those things. My opinion is DevSecOps is more of a practice that you're trying to incorporate as many different technical teams in an organization together to be able to do the same thing, which is to build repeatable solutions that you can iterate on for any of the people inside or anything you're trying to do inside your organization technically.

So I guess to help further wrap our heads around this topic, what problem is DevSecOps solving, especially because you interested me when you said that, a lot of people think you have to have some, a CICD DevOps pipeline and place to take advantage of DevSecOps. I would love to hear your opinion of what value the practice has for someone who hasn't adopted a full end-to-end CICD pipeline. Yeah, absolutely. So I think, kind of your point, when it comes to CICD or continuous integration, continuous delivery, most organizations, or if you're creating software, then you're thinking about that because you wanna be able to get updates to your software out quickly.

You wanna get bug fixes out quickly. It's just something inherently that you wanna be able to do if you're releasing software. But what there's this bigger opportunity out there in the same space is that traditional IT teams or ops teams and security teams need to be able to do the same thing, which means that they need to take the very same type of approach where they can build and iterate on, deploy and iterate on software-defined, they're doing software-defined instead of releasing software, they're doing software-defined things, right?

So they're building out, say the infrastructure is code, or they're building out the configuration, or they're building out the security controls, and they're doing it within the constraints of the different products that their organization uses. And so being able to take that same approach, but apply it to no matter what you're doing, whether it's software release, or you're just trying to deploy some infrastructure internally, or you're trying to deploy some security tools that you're doing things with, you should be able to have the same approach when it comes to that, which is very much like you would expect from, like you were saying, a CICD pipeline, being able to apply that to other things.

And the only way you can do that with the traditional ops or security teams is that everything has to become software-defined or IT as code, because you can't take that same approach unless it's, you know, it's defined as, you know, it's software-defined, because that's the key to all of this is as we're moving towards modernizing IT, we're able to have these type of processes with teams you wouldn't traditionally think about using DevOps tools or these type of approaches, or this type of approach. So as we think about kind of, you know, these teams, I love to pick on the firewall guys, because, you know, they've just made my life so, so, so difficult the past 20 years.

And, you know, you're talking about testing rules and defining rules and making sure that rules are still relevant. You know, a big part of that, a big practical challenge is audit time. You know, I'm getting, whether it's my SOX audit or some relevant audit, and the auditor comes to me and says, show me your firewall rules and show me, one, how do you validate the rules? And then two, part of validation is show me that the rule is still relevant, it's still needed.

So these are practical problems we run into from an audit perspective. How does DevSecOps help with some of these practical audit problems we run into? And it'd be great if you can just relate it back to the firewall, like firewall rules. Yeah, absolutely. And actually, firewall vendors or vendors in that space are ones that I, myself too, coming from the ops side first, have definitely felt the good, the bad and the ugly when it comes to having to deal with firewalls and firewall vendors as they, and also as they've matured.

And to your point, the capabilities around being able to go, to look at, say, a firewall and saying, okay, I wanna be able to not only know what exactly is configured on that firewall, but I also wanna be able to abstract away the underlying infrastructure, because if I'm gonna roll out, if I'm gonna go deploy a firewall, I could do it on premise, on the gear that the manufacturer provides to me. But I may also wanna be able to spin up an instance of that firewall in the public cloud, but the configuration can be the same.

And then knowing what that configuration too is, right? So understanding the state at any particular point in time of a configuration on a firewall, not just for audits purposes, but also for the fact that you may wanna be able to configure a firewall rule or do some security remediation. Something comes up that you find out that there's a threat internally and all of a sudden an IP address gets flagged or something happens, you wanna be able to programmatically be able to also make changes, which is what's considered security automation.

So looking at this holistically, there's different moving parts to this. So in a traditional, so we take a back step back from DevSecOps and we look at just traditional security orchestration automation in response or SOAR that we've seen a lot of products out there like Phantom and Domisto and Swimlane and so on. They're all focused on the security piece of it only, but what we're finding is that there's a holistic view of everything that needs to come into play, which is there is most likely an infrastructure component, especially as people are moving to the cloud.

So can I have a infrastructure component that I can programmatically deploy and update as I need? Can I also do the same thing with the configuration? So even a lot of the tools out there right now, like you can take Red Hat Ansible, for instance, if I wanna deploy a Fortinet firewall and I wanna be able to configure that, I could use the existing Ansible modules out there, not only to run them against the firewall, but also know exactly what my state is now.

And then if I make some changes or I need to remediate something in the future, know what the state is then. And as long as I have something that can keep track of that, I have the ability to know what that configuration was at that point in time. And that's no different than if I'm doing, say, on two different commits of my code, if I'm releasing software, to being able to do the same thing, except being applied towards, to your point about firewalls, where I can say, hey, look, now I know exactly what the infrastructure was deployed at this point in time, the configuration of it.

And then I can also know what the actual configuration that I applied to that particular firewall at that point in time. And then I can go one step further than that too and add additional pieces into that pipeline where I may wanna drop that configuration somewhere else. So I know exactly what was done there in that particular configuration. Or I may want to be able to tie into my CMDB service now or whatever it may be, so that I'm doing additional things, adding value to the pipeline, no different than, hey, I wanna open up a ticket in JIRA.

There should be no different than if I, or update a service board. There should be no different doing that and doing the same thing in service now, which is much more ops focused, but the same process. So I'm gonna put on my trust, but verify head. Obviously this is a super powerful capability for me to replicate my configure, one use case for me to replicate my configuration state across multiple platforms. So if I wanted to replicate my SAP production environment and my DR environment, make sure those two firewall configuration states are consistent, DevSecOps seems like a methodology to use to do that and it's a sound practice.

But how do I ensure that the tools that I'm using, that the configuration of the tool themselves are compliant with my security policy? Yeah, that's a great question. So it depends on the tool and who's behind the tool and then who's adopting said tool too. So that's why a lot of organizations like adopting open source tools and technologies like for infrastructure as code, HashiCorp Terraform is the most popular one out there right now. In the configuration management space, Red Hat Ansible.

And so behind these tools, you have not only large communities, but you have large, you have corporations that are spending the time and the money to make sure that the customers are using them whether it's a DOD customer or say a financial customer, a bank that has different, certain compliance requirements, whatever they may be, are able to be able to use these tools knowing that they can utilize them because they've already been vetted by other organizations that have certain compliance requirements or the companies that are producing them or at least behind them if they're open source projects are providing support and capabilities behind it, even if they're commercializing some things around the product offerings to make them compliant.

So a lot of companies like HashiCorp and Red Hat have enterprise versions of their products. So they can put their stamp of approval on them to say, yep, we got this. This is something that you can say could be certified. But at the end of the day, no matter what you still have to be audited somehow, some way. And so it still comes down to the audit. So it's really about, what do you have to be able to give you visibility and govern the policies around the tools and then are the tools themselves, can they provide you the visibility to ensure that you can provide what you need to to show an auditor during audit.

And then at the end of the day, the other piece of it is usually these tools are chained together and then there's other something else that's gonna give you back some sort of reporting for what exactly they're being utilized for and what you're using. So for instance, like the Center for Internet Security, they have a Syscat pro tool that you can use to scan and that tool itself, you can get reports from in conjunction with, obviously using Ansible or Terraform to run stuff and then giving yourself visibility on what you're getting from there.

So I would say that the other piece of this is to be able to utilize tools from organizations that are providing the standards or frameworks around what you're trying to do, which will give you the visibility and something that you can deliver to an auditor too because they'll take something from, hey, if I'm using like the Syscat pro tool and I scan, I can use that in an audit to present to an auditor on, hey, here's my score. This is what it was before, this is what it's afterwards and being able to start leveraging stuff and tools like that in conjunction with DevOps tools.

So how does refactor help companies on this DevSecOps journey? Yeah, so we built something pretty interesting from a standpoint of we are huge proponents of open source technologies, but what we've realized is that there needs to be a layer on top to help bridge the gap between those who know how to produce this automation content, DevOps engineer, DevSecOps engineer, knows the tools out there like HashiCorp Terraform or HashiCorp Terraform or Red Hat Ansible. But the problem is that you need to be able to share and collaborate with other teams like the security team and the IT team.

So our philosophy was, okay, well, we can provide a layer on top of that to have a cohesive platform to enable you to still use the tools in their native format. So like a HashiCorp Terraform configuration is in its native format or Red Hat Ansible playbook is in its native format, or if you wanna do something with Kubernetes API or any cloud native templates. And so any of those tools are in their native format and we wanted to make sure that what we do would be decoupled from anything that you would run in any external system so that those systems still work without our platform having to be involved.

But as you continue to want to iterate on them very much like you would in a CI, CD and software development you wanna be able to continually be able to update the configuration of what you're pushing out there from any of the tools you're using and then being able to focus them on a particular vendor content kind of back to what we were talking about firewalls. So for instance, if you wanna be able to, hey, deploy a Fortinet FortiGate firewall in a particular scenario, you should be able to do that in our platform.

You could do that with a pipeline, but you may use a one pipeline to build out the infrastructure using say Terraform or even the cloud native templates. You may use another pipeline to run, you know, use like a Red Hat Ansible to be able to run playbooks with configurations mapping to the Fortinet modules that set the configuration. And then you may have additional pipelines that you can actually, you know, be able to tie into other external systems like, you know, creating a ticket or doing other things.

And one of the biggest things of all in any of this is that if you're gonna deploy a firewall, do you ever deploy a firewall by itself? Usually in any capacity, you're always doing, you know, things that you deploy usually do them with multiple other products or services. And so that's kind of the longer term vision of what we see is that organizations wanna be able to tie together different products and services they're already using, but as they become software defined, being able to tie them in.

So for instance, maybe I wanna Fortinet Fortigate with a Kubernetes cluster, you know, and so can I do that? And the answer to that question with our platform is yes, because of the fact that you could have a Kubernetes deployment pipeline and then add in the Fortinet pipeline and have the ability to do that. Because you wanna be able to have multiple products and services together, because at the end of the day, you're trying to package up solutions for your organization that bridge across many different products and services that you would use.

So Mike, I really appreciate you, one, accepting the invite to be part of the CTO Advisor, open office hours. com. Michael, where can people find the company and you online if you do the whole social media thing? Most security people don't. Yeah, as a startup founder, I kind of have to. But yeah, so you can find me on Twitter on ITIScode. My handle's ITIScode, you can find me on LinkedIn, ITIScode. So that's kind of my handle anywhere you wanna find me on pretty much any social media is ITIScode.

it, because we're refactoring IT. So it's a play on words. And you can find any information about us on the platform. And then if anybody wants to reach out to me personally, feel free to do, I get pinged all the time on LinkedIn. And I think, that's where I pinged you, Keith. Yeah, exactly. All right, that's it for this episode of the CTO Advisor. com. Rate us in iTunes, it really helps us out. Rate us in iTunes, it really does help.

I think I saw a review, we only have one review, and it said that we really care about these guys. And you know what? We really care about you too. Until then, follow me on Twitter at CTO Advisor. Talk to you next CTO Advisor podcast.