EP#72 – Brian Hajost – How Configuration Management Makes Security Simple

Time-Stamped Transcript

This transcript was generated primarily by an automated voice recognition tool. Although the accuracy of the tool is 99% effective you may find some small discrepancies between the written content and the native audio file.

Narrator(intro/outro) (00:06):

You are listening to The Virtual CISO Podcast, a frank discussion providing the best information security advice and insights for security, IT, and business leaders. If you’re looking for no BS answers to your biggest security questions, or simply want to informed and proactive, welcome to the show.

John Verry (00:25):

Hey there and welcome to yet another episode of The Virtual CISO Podcast. With you as always, John Verry, your host. And with me today is Brian Hajost. Hope I got that right, Brian. From SteelCloud. Brian, good afternoon, sir.

Brian Hajost (00:40):

You’re welcome. Welcome. Good to talk to you.

John Verry (00:43):

Yeah. same here. Glad to have you on today. Always like to start super simple. Tell us a little bit about who you are and what is it that you do every day.

Brian Hajost (00:53):

I’m the COO of SteelCloud. I’m primarily responsible for product development, product strategy, customer support, and every once in a while I’ll pinch hit in sales.

John Verry (01:09):

Do you like pinch hitting in sales or not like pinch hitting in sales?

Brian Hajost (01:11):

I love pinch hitting in sales, especially when I get brought in to kind of talk about the product I’m so passionate about.

John Verry (01:19):

It’s so funny you should say that because… And you wouldn’t hear most CEOs, COOs actually say that, but I consider myself… I mean, I’m at Virtual CISO, so I do all this other stuff. But I mean, at the end of the day, I’m a sales guy. I love jumping on the phone with a customer and helping them solve problems. I’m an engineer by training. So an engineer solve problems for a living. So I look at what we do is just being the way that we solve a problem for a customer. And who wouldn’t want to promulgate this wonderful idea, how I can make your life better. Right?

Brian Hajost (01:48):

Sure. Absolutely.

John Verry (01:48):

So, I think you view the world the same way I do that way.

Brian Hajost (01:51):

Yeah.

John Verry (01:52):

All right. So before we get down to business, I always like to ask, what’s your drink of choice?

Brian Hajost (01:57):

Well, that one’s easy. It’s beer. Matter of fact, I’m a founding member of a small brew pub in the Northern neck of Virginia on the Potomac River. And they’ve actually created a beer for me and named it after me. And it’s a English brown ale.

John Verry (02:14):

Is it the Hajost?

Brian Hajost (02:16):

No, It’s actually CP Skipper. I sail out of a small development called Cabin Point, so I’m the Cabin Point Skipper. That’s what the beer is.

John Verry (02:27):

And what’s the name of the brewery?

Brian Hajost (02:29):

Montross Brewery. It’s in Montross, Virginia about halfway down the Northern neck.

John Verry (02:35):

So, so I’m a big, big craft beer fan and drinker. So, and always wherever I go, I always try to get a local beer. So my daughter goes to school in Virginia, so I drink beer down there fairly frequently. And I always look and I have not seen Montross, but I will look for it.

Brian Hajost (02:51):

It is a tiny little town of about 400 people and the quaintest, wonderfulest small brewery you’ll find.

John Verry (03:00):

Yeah, I love that. We just went this past weekend… I spent a couple days in DC and I went to the DC Beer Fest. If you’re familiar with that.

Brian Hajost (03:07):

Yep.

John Verry (03:08):

They held it at that Nationals Park, and there’s, I don’t know, something like 80 or 90 breweries, each brewing. And it’s so wonderful. All these little breweries. And you’re walking around and you got your little tasting glass. Yeah. I love it. Does Montross specialize in any particular type of beer?

Brian Hajost (03:24):

They do a lot of flavored beers and they do a lot of stouts. So they have a coffee stout, a breakfast stout, an oyster stout.

John Verry (03:31):

Oh, you’re preaching to the choir, baby. Stouts are my favorite. I mean, everyone does an IPA and I’m not that big of an IPA fan.

Brian Hajost (03:40):

Yeah. I’m a multi beer drinker not a hoppy beer drinker, so.

John Verry (03:44):

Me too. Me too.

Brian Hajost (03:45):

And next to the stouts, my English brown ale is the next most heaviest, darkest. It’s a little sweeter.

John Verry (03:53):

Yeah.

Brian Hajost (03:53):

Than a stout.

John Verry (03:54):

Yeah. You get a… That gets funny. There’s a place up here called the Neshaminy Creek. It’s not far from our house. And they do a brownish ale called JAWN, Juicy Ale With Nugget.

Brian Hajost (04:05):

Ah.

John Verry (04:06):

So you get that slight sweetness. Most brown ales, and I don’t know if it’s just a traditional brewing style, but most brown ales do have a little bit of that sweetness to it.

Brian Hajost (04:14):

Yep.

John Verry (04:14):

Little bit of honey, a little bit something to bring up the flavor profile. So yeah, it sounds like you and I would be very happy to drink together, so we’ll have to do that someday.

Brian Hajost (04:21):

Anytime you’re in town I’ll have you in.

John Verry (04:25):

All right. So I could talk forever about beer, but I don’t think most of the people listening would like to hear me talk forever about beer. So let’s get down to why you are here.

John Verry (04:34):

So vulnerability management and configuration management are absolute foundational elements of any security program. To me, when I think about foundational elements, I always use that the CISCSC as a relative measure. How high up on the list are they?

Brian Hajost (04:50):

Yeah. Right.

John Verry (04:50):

Where they are? Right? And they’re actually number 4 and number 7. I looked it up in preparation for today’s meeting. So, and most of their controls within those are in implementation group one, which also speaks to how important these two areas are. So not only is it critical, not only is it foundational, but it’s also a notable pain point.

John Verry (05:09):

So I was interested in talking with you today because SteelCloud, and I know some of the guys on our team are excited about your product, which is how this podcast originated. You have the, potentially, a better way for people to deal with this painful point. So, let’s get to that.

John Verry (05:26):

So before we talk about solving the problem, let’s define a couple terms to make sure we’re all on the same page. So would you be so kind as to define configuration management and then if you could also explain at the same time how configuration management is similar to vulnerability management and how it’s different from vulnerability management?

Brian Hajost (05:45):

Sure. Think of configuration management kind of three buckets. One is on a system or an App Stack. Does it have all the components it needs? Does it have the right operating system, right browser, the right other components, the right application so it operates? So that’s one, it has to be configured to operate.

Brian Hajost (06:05):

And then when you look at other configuration it where kind of links into vulnerabilities management is, are there any of the components on the system have vulnerabilities? So, that’s where you get into patching. And does it have… Is everything, all the components on the system patch properly? So a lot of times you’ll think of configuration management as all the applications on the App Stack, are they all the right version and are they all secure? The other side of configuration management are the kind of system controls. Is the operating environment, the cocoon in which the application lives, is this configured securely? And, this is where you get into the standards for secure configurations.

Brian Hajost (06:50):

And in the windows side, those configurations are typically in registry keys, advanced audit policy, advanced security policy, Linux configuration files, and the editing of configuration files. So that creates a cocoon. So again, back to configuration management are the right components there to make the App Stack run? Then from vulnerability standpoint, do you have the right versions or they patched properly? And then you have the actual system configurations, which are low level system files.

John Verry (07:25):

Gotcha. And so that third bucket, would we think of that as being configuration management towards compliance with a prescriptive standard, or even if it’s our own internal security objectives?

Brian Hajost (07:39):

Well, if I could put on my CISO hat, when we look at compliance, sometimes we set it on a shelf that’s different then security. But if you bring those two things together, secure configurations, yes, it is compliance, but it’s compliance because these are the configurations that have been deemed to be secure. So it is the hundreds of elements you would apply to an operating environment so that you would make it secure. And that’s kind of where compliance and security, they have to be glued tightly together.

John Verry (08:16):

Gotcha.

Brian Hajost (08:16):

If you think of them separately as an organization, no one will ever have enough money for compliance. They’ll always have enough money for security. But when you look at the compliance and security as being synonymous with each other, then you’ll look at it in, I think, a healthier light.

John Verry (08:33):

Gotcha. So, going back to your original three buckets. So the first bucket would be, do I have all the components that I need? So do I have, let’s say, a TLS? Because I want to have some type of secure communication.

John Verry (08:45):

The second question would be on the vulnerability side, do I have the most current version with no known vulnerabilities in it?

John Verry (08:52):

And then third question is it configured to enforce TLS at a level that’s appropriate to the risk of this particular system?

Brian Hajost (08:59):

Sure.

John Verry (09:00):

Okay, cool.

Brian Hajost (09:01):

Yep.

John Verry (09:02):

That’s an excellent visualization of that. Thank you. So, you do this every day, all day. What does configuration management look like in most organizations? What are the key challenges that you see? And what are some of the risks that you see that are based on what you are seeing?

Brian Hajost (09:19):

Well, I think we see two types of organizations. One in where configuration management STIGs or CIS controls are mandated in which they have reporting requirements, they have percentages. And their outlook is very different then organizations that say, “Hey, we’re going to kind of try to follow some of the best practices for configuration control and kind of do a good job.” So, two very different. The people that have compliance… And we believe the federal government spends about 8 billion a year just on system and level controls. They have a very onerous task of making sure their systems are in compliance.

PART 1 OF 4 ENDS [00:10:04]

Brian Hajost (10:03):

… of making sure their systems are in compliance and are secure. They do it in a myriad of different ways today. Manual, a lot of times it is find and fix, do a vulnerability scan with one of a Nessus, a Qualys, a Rapid7, gives you a list of things to fix, you hand it to an engineer and they go away and fix them.

Brian Hajost (10:25):

They use scripts, they hand jam, they use GPOs, a whole myriad of things, and it tends to be a fairly foggy environment in which they try to get to the destination they’re trying to get to.

Brian Hajost (10:41):

In the non-mandated world they kind of do what’s easiest. They pick off the top 10, do those kinds of things. What we’re seeing though is more and more mandates from the federal government into industry. And we’re seeing more industry partners looking at standards-based, and in North America there are only two standards for system level controls, standards-based and moving voluntarily toward a more rigid energized configuration management philosophy.

John Verry (11:13):

Gotcha. So you mentioned that… You started that by forking into folks that have these configuration requirements that are mandated. So can you give me some examples of the groups right now that you see as being in that mandated bucket?

Brian Hajost (11:28):

Yeah, I can give you some examples. Every computer in the federal government. So start with that. Then the federal government now, especially the DOD are mandating on their contractors to create secure supply chains that their contractors apply the same types of controls to their internal systems that they control.

Brian Hajost (11:50):

And then the federal governments has a few things where they’ve reached out, the IRS has reached out to state and local governments to enforce security mandates on them. And the states have then reached out to the major or tax preparers.

Brian Hajost (12:04):

We recently had the Department of Education mandated into a purely commercial customer that they stig up or apply the STIGs to their infrastructure that houses student loans. And I think everybody have seen what the president’s EOS, cyber EOS and a lot of work that’s being done by the Cyber Solarium Commission out of Congress of critical infrastructure. What are we going to do with pipelines and electric infrastructure and that kind of thing? So we see there’ll be a whole host of federal mandates that’ll come that will cause people to follow standards and report on those standards.

John Verry (12:47):

Yeah, so obviously one you didn’t mention explicitly of course, is CMMC, which we see with regards to CUI. And then I think if you follow what’s going on, I think I couldn’t agree with you more CISA the Critical Infrastructure Systems Agency is becoming, I think one of the more important organizations in the federal government and more responsible for enforcing these types of things.

John Verry (13:08):

And then even if you follow what’s happening with the presidential executive order, I don’t think there’s any doubt that we’re going to see more people have either a mandated requirement or call it an implicit requirement to do a better job with this stuff.

Brian Hajost (13:21):

Yeah, the other wild card is cyber insurance. So if you’re CISO, or you’re a CEO, or CIO, and there is a best practice that exists and you have a cyber issue, are you going to be able to say that you followed a best practice, a standard, or did you leave it up to Johnny or Sally to determine what the standard is?

John Verry (13:48):

Right. Anytime you can align yourself with a trusted framework, I think that you’re putting your organization in a better situation, a better capacity. Like you said, in the event of something happening it’s certainly due diligence-

Brian Hajost (14:01):

Absolutely.

John Verry (14:01):

… versus negligence. Can you do me a favor? Let’s real quick, just in case someone is not familiar, we’ve talked about the CIS benchmarks, we’ve talked about the STIGs, will you please define the two of those?

Brian Hajost (14:14):

They’re both very similar. The STIGs are the Security Technical Implementation Guides, they’re produced out of Fort Meade, Maryland out of a component of the Department of Defense, DISA, and there are manuals and controls on how to implement almost any piece of technology, switches, routers, copying machines, operating systems, almost anything.

Brian Hajost (14:40):

CIS is the Center for Internet Security, out of Upstate New York. It’s a not for profit. And they build their controls out of kind of crowdsourcing all over the world. So they have individual organizations and consultants that contribute to their controls. They’re very similar, we looked at Windows 10 operating system and the STIGs and the CIS controls, there’s about a 96% overlap between the two. Because when you look at security professionals and they look at the kinds of controls that you would apply to make a system secure, it’s pretty similar if you really look at it.

Brian Hajost (15:22):

So we have customers that use both of those, typically CIS is used in state and local government and commercial organizations, and STIGs are used in organizations that are in the federal government, or are addressing the federal government, like CMMC typically would use STIGs versus CIS.

John Verry (15:46):

Gotcha. So at a very simplistic view, it’s a checklist of things that a well-configured system, a secure system, would have in place. You should enable full disk encryption, you should enable passwords of at least this length profile, you should have local firewalls turned on, things like that.

Brian Hajost (16:07):

Yeah. One of my favorites, for your audience, because I always ask my staff if connecting these thousands of controls to actual breaches that organization would see, and one is shutting down, being able to open application in a Microsoft Word document. That’s an individual control that would not… If an organization got malware embedded in a Word document and they opened the Word document, the malware could not execute. So a simple control.

Brian Hajost (16:36):

And all the STIGs and CIS controls are sprinkled with all little types of things that stop drivebys, that stop individual types of hacks. And in speaking with the staff at CIS, they’re actually producing documents that more align in actual malware or an actual cyber event with the kinds of controls that would do it, so that they’re better aligned as opposed to it’s just a vitamin that’ll keep you healthy.

John Verry (17:09):

Right, yeah try to trace the medicine to the poison.

Brian Hajost (17:15):

Yes.

John Verry (17:15):

Right?

Brian Hajost (17:15):

Absolutely.

John Verry (17:16):

Trace the risk to the control, right? Controls are mechanisms that reduce risk, what particular risk does implementing this control help me manage?

Brian Hajost (17:22):

Yep.

John Verry (17:23):

That makes a lot of sense. So we’ve talked about the problem. So tell me about how SteelCloud’s approach to configuration management is different. So talked about the problem, we talked about how most people deal with it. How do you deal with it, which is different?

Brian Hajost (17:37):

Well, two ways. One is we looked at all the existing technologies, all of the automation technologies out there like Active Directory, Puppet, Ansible, Chef all of the things that automate things and looked and say, “Can we bend these in a way that we can effectively implement these controls?” And we determined we could not.

Brian Hajost (18:03):

Some are very good in the production environment, but they don’t help at all in the development environment, integration, authorization, in the creation of policy and the hardening around your application stacks.

Brian Hajost (18:16):

So we started kind of with a whiteboard from scratch and develop from the ground up technologies that will help an organization in every phase of DevOps insert security, and in every kind of environment from air gap classified environments to regular on-prem environments to the cloud. And so I think we took a holistic and a unique approach to address all of the problems around implementing and supporting these types of controls.

John Verry (18:50):

Gotcha. And the big thing though is what you did is you came up with a new idea, but then you figured out a way to automate it, right?

Brian Hajost (18:57):

Well, and the automation is, the part of it is, the automation of the creation of policy because every app stack will interface or be broken by policy in different ways. So you have to create policy around your application stacks and some of those are old and legacy. And then you have to implement that in the whole DevOps process, development integration, out to sustainment, inheriting controls from left to right. So it is every infrastructure, every type of application, in every phase of development through production.

John Verry (19:35):

Gotcha. And just to be clear, you’re, at this point in time at least, SteelCloud supports CIS benchmarks and STIGs. So if I have any systems that can be governed by those, I could use your tool and say, “I want my systems to conform with this,” and you will automatically make all of my systems conform with that. And then you will periodically review that, and then update-

PART 2 OF 4 ENDS [00:20:04]

John Verry (20:03):

… Will periodically review that and then update things if they’ve changed the way, which would no longer be consistent with the implementation. Did I get that right?

Brian Hajost (20:09):

Kind of. You’ve given us some more credit than I think you should.

John Verry (20:12):

Take it, take it, take it, take it and run with it.

Brian Hajost (20:15):

We provide technology that allows an organization to manage their own infrastructure. SteelCloud itself doesn’t touch computers. We provide technology and we provide the technology that allows the people to do this work with as little energy, with as much consistency and there as little expense as possible. So it isn’t kind of artificial intelligence, but it is easy as you can get in doing it. In terms of all platforms, we don’t do all platforms. We don’t do mainframes and we don’t do legacy platforms like Solaris. But all of your Linux variants, all of your Microsoft variants and a lot of the components like SQL Server and IIS and browsers and that kind of thing, we do do. So just a little clarification there.

John Verry (21:02):

Gotcha. And you do this from my server infrastructure all the way down to my desktops?

Brian Hajost (21:09):

Absolutely. Yep.

John Verry (21:11):

Okay. Okay. So and I’m curious, so A, we’re making things more… Well, one question first before I ask that question. Do you publish or have you ever calculated how much time? Like there should be a return on investment based on security, improved security posture, which is harder to quantify. Which return on security investment’s very hard to quantify, but there should also be a return on investment relating to time savings, right?

Brian Hajost (21:40):

Sure, absolutely.

John Verry (21:41):

So have you guys ever quantified that?

Brian Hajost (21:43):

We have and it’s different depending on the step in the process you’re at. So one of the largest steps that requires without technology like ours, highly qualified engineers to do. Hardening around an app stack, taking these thousands of controls that have to be apply to a given set of applications and components. We’ll reduce that by about 90%, that’s both timeline and it’s also labor hours. And that’s, in the work that we do, that is one of… That’s really the constricting point in the entire higher process, because the engineers that do that just are not available. So we can take something that would take a qualified engineer two weeks to two months to do and we can do it in 60 minutes, to give you an idea.

John Verry (22:36):

So time to market if you’re in the SaaS space, time to market would be another value proposition.

Brian Hajost (22:43):

Yeah, you’re absolutely right. The thing we haven’t qualified is the thing that’s going through this process to get deployed might be the latest security software that’s going to protect you. So everything that an organization would buy goes through a process before it’s deployed. If you can speed up the process to deployment, the investments that any organization makes to secure themselves will get deployed faster, right? Beyond just a better application that satisfies a user, there’s a whole bunch of security components that get deployed through the same process.

John Verry (23:20):

Right. So your excitement is the excitement I heard from our guys, which is why you’re on the podcast is they’re excited about using this product for a couple of our clients. So I’m sitting here listening to you and I sat and listened to them. And I have one question, you’re going to save me money. You’re going to make me more secure, you’re going to make me faster time to market. So why I are you talking to me instead of sitting on your yacht? Right. Because I would think everyone wants to automate configuration management. So why not, right? Is there resistance? Is there a lack of awareness? Are there challenges getting stuff to run in a CIS or state environment? Are they concerned that automation’s going to disrupt business operations? Are you guys insanely expensive? Why isn’t everybody a SteelCloud customer if it does all these wonderful things?

Brian Hajost (24:04):

I get that asked all the time and I don’t have a good answer, but I’ll try to give you-

John Verry (24:09):

You need a good answer. [inaudible 00:24:12]. You’re going to have that 400, like two barrel. You are going to own Anheuser-Busch, a size micro brewery if you can answer that question, Brian.

Brian Hajost (24:22):

Well, part of it is tradition and their traditions. You have business leaders that say, how should it be done? And they ask their technicians and their knowledge leaders, their SMEEs and their SMEEs say, this is how it’ll be done. It’s based on tradition or they’ll call Gartner up. Gartner on what we do, Gartner’s literally written one piece of analysis on hardening security controls. And that was done in 2017 and it has been archived. And I liken it to auto manufacturing in the 1970s in the US. It was assumed that every car would come off of the manufacturing line and would be full of defects. And you’d go into the QC process and they’d fix a whole bunch of stuff before that car was shipped to the dealer.

Brian Hajost (25:17):

And that’s just the way it had to be. The greatest minds in Detroit, that’s the way it was done. And then the Japanese came and taught us what we taught them, that you can build something that was perfect. If you think about, if you design, you build processes to manage and fix ahead of time, as opposed to fix afterwards. So I think it’s a psychology change that is starting to happen, but we’ve been hand plowing behind an ox for the last 20 years. And SteelCloud is a tractor over here, waving our arms into a very noisy kind of web space saying, “Hey, there’s a better way. There’s a better way.” But almost everybody to your point, I see you laughing, you to your point though.

John Verry (26:04):

No, you know why I’m laughing? Yeah, you’re going to think this guy’s a nut. I’m laughing because for some reason I thought you should have Jeremy Clarkson from… You mentioned farm, the [inaudible 00:26:16] and I immediately thought of Clarkson’s Farm on Amazon Prime, which if you haven’t watched it is brilliant. And I can’t explain why it’s brilliant but it’s brilliant. And I just had this image of Jeremy Clarkson promoting your product.

Brian Hajost (26:29):

And it is every customer that finds us and usually is not a senior leadership. It’s usually the young whipper snappers been asked to do something and they see someone should have fixed this. There’s got to be a vendor. There’s got to be somebody and their boss says there’s nobody. And they get on, they do a Google search and they find us and all of a sudden, where have you been all my life? And so it really is a surprise when we are found. But it’s not only when we’re found, because when we do a presentation demonstration, the majority of the audience comes to us with crossed arms saying, okay, we are going to prove that these people have no idea what the real world’s like and it’s smoking mirrors or it’s magic or something else. And they come away saying, oh my God, you’ve cracked the code. And it was so simple if you just think a different way.

John Verry (27:25):

So I just once in my life on someone to say, “Where have you been all my life?” Just once, once before I die. Please.

Brian Hajost (27:34):

We get it… Literally, we get it every day.

John Verry (27:38):

Can I come work for you? Because it’s not… I can tell you, it hasn’t happened yet and I’m not really optimistic.

Brian Hajost (27:45):

Well, you know, the funny thing is my sales manager came in to me today and he said, I just talked with a cyber engineer from, who’s our largest integrator partner with where have you been all my life? And this is our largest partner. So they-

John Verry (28:04):

So now you’re rubbing now you’re rubbing my nose in it, Brian. Listen, this podcast is going down around.

Brian Hajost (28:10):

No, I’m sorry about that.

John Verry (28:15):

All right. So we think it’s lack of awareness is one thing, right? We think it’s a hesitancy to change. You didn’t address, do people find when you’ve implemented CIS benchmarks at a religious level, let’s say, do we find that a lot of things that used to work don’t work anymore? Is that any part of the resistance?

Brian Hajost (28:35):

Well, if you look at traditional thinking, that’s the case. That is the big problem is these things break things so it can’t be done or availability goes down. You the mission, whether it’s a commercial company or whether it’s the DOD admission first, this is going to create a disruption. And there’s a concept that I like to kind of get people to believe in a securely, perfect environment.

Brian Hajost (29:04):

In the software world, we know that no software is without bugs, but what we’re constantly trying to do is make sure we know every bug. And when we release software, we know everything that is a defect and none of the defects are going to damage a user. In our case, we harden. When I talk about hardening around an app stack, you have to waiver control, relax a control or ignore a control or the thing won’t work at all. The idea is to use to technology like ours, to harden around an app stack so everything you’ve done to relax and control or ignore control is known and accepted. And there are no unknown defects in that process. So that’s what we want to get to. So, absolutely without technology, everything breaks. With technology, I can push the button, harden everything and break nothing. That’s and that’s the environment that our technology allows an organization to-

PART 3 OF 4 ENDS [00:30:04]

Brian Hajost (30:03):

… that our technology allows an organization to get to.

John Verry (30:05):

Gotcha. Now just to be clear, right, there might be… As we’re getting to that initial gold standard, if you will, we’re going to find some things that do need to be relaxed or do need to be ignored. But once we’ve figured those out, then from that point forward, we’re going to run in a highly reliable state, even through change.

Brian Hajost (30:25):

Thousands of systems an hour, reliably. You’ve kind of pointed out… I didn’t discuss at the beginning of the podcast that this concept of defect and breakage… If you build technology with the understanding that we aren’t in control of the app stacks, the vendors who did them, whether it’s customer, whether it’s an OEM, that there’s going to be breakage. Everything has to be built around the thought that there will be breakage. You automate around it before you go into production. Once in your production, no breakage, no availability impact. That’s the kind of process that you’re going to go through.

John Verry (31:08):

Cool. So what about cost? Is cost a big factor, or can you demonstrate a near immediate ROI based on some of the things we’ve talked about?

Brian Hajost (31:19):

Well, if it’s mandated. Let’s assume that whether the ROI that… I want to apply STIGs or CIS controls, this is something my organization either needs to do or wants to do. Once you’ve made that decision, which that’s kind of a hairy decision as to, do we want to apply these things? Once you’ve decided you want to do it, the cost justification is instant. Our software costs less than it costs an engineer to touch an endpoint once. The payback is immediate. The first time the controls are applied to a production workload, you’ve paid for that license. And certainly larger customers pay less per endpoint than smaller customers, but I have customers that have two endpoints and I have customers that have tens of thousands of endpoints in their infrastructure. And every one of them can cost… It’s instant. In the federal government, it’s absolutely instant. There is eight years of not one question about cost or cost justification.

John Verry (32:24):

Gotcha. So if we’re talking about cost, how is it… Relatively ballpark pricing, if someone’s listening… So if someone’s got an organization with 100 desktops and 30 servers or 40 servers, is it a million dollars a year? Is it a dollar a year?

Brian Hajost (32:43):

You’re in the kind of low tens of thousands maybe.

John Verry (32:47):

Oh, that’s cheap. Yeah. You’re talking fractions of what the person who’s doing this work costs.

Brian Hajost (32:55):

Yeah, yeah. Absolutely. Absolutely.

John Verry (32:56):

All right. All right. Cool.

Brian Hajost (32:57):

The other thing that the technology… It reskills the workforce they already have. They can take a competent system administrator who’s never heard of a STIG or CIS, use the tool, and in two weeks they’re a STIG ninja.

John Verry (33:14):

Yep. Well, the other thing too is that also lost in this is you’re taking a dreadful task that most engineers don’t want to do, don’t enjoy doing, don’t do well, and what you’re doing is you’re taking that off their plate, which increases job satisfaction, and now they’re working on something that they, A, enjoy, so you’re more likely to retain them, B, hopefully they’re working on something that’s going to create technological competitive advantage for your organization. So you have that as a benefit as well, right?

Brian Hajost (33:45):

Sure. Absolutely.

John Verry (33:47):

Cool. We beat this up pretty good. Anything else we should discuss with regards to SteelCloud?

Brian Hajost (33:51):

I don’t think so. No, I think we’ve gone the full gamut here.

John Verry (33:55):

Cool. So hopefully you prepared for this question, because I gave you the warning, give me a fictional character or real person you think would make an amazing or a horrible CISO and why.

Brian Hajost (34:09):

I have an example of both. Do you want both of them?

John Verry (34:10):

I want both.

Brian Hajost (34:10):

Okay. Horrible, Sherlock Holmes.

John Verry (34:13):

Really? Sherlock Holmes? All right.

Brian Hajost (34:15):

Is a horrible CISO. CISO should have Sherlock Holmes working for them. They shouldn’t be one. Sherlock Holmes is too ADD, they don’t plan, they can’t organize, they can barely get anyone to follow them. They’re a great individual contributor, but they can’t kind of bring the whole thing together. Not a great cheerleader.

John Verry (34:36):

All right, so hold on a second. I’m sensing a pattern here, English ales, Sherlock Holmes. Yeah, you didn’t grow up in England, did you by any chance, Brian?

Brian Hajost (34:44):

No, I didn’t. I didn’t.

John Verry (34:45):

All right. Just checking.

Brian Hajost (34:46):

Okay. Now the other one’s going to surprise you, Herbert Hoover, because he’s known as being a horrible president and failing during the depression. But if you look at his work before that in really saving Central Europe after World War I, assembling all of the resources necessary to get food and material in there, and also the work he did after the ’27 Mississippi flood. He is a great organizer of people he doesn’t directly manage, and when I look at a CISO’s job, it’s a cheerleader. It is to get an organization that they don’t directly control to get on a mission and point everybody in the same direction. So Herbert Hoover I think is a great example of a great CISO, or would be.

John Verry (35:41):

Yeah, I think that’s a really, really good point you just made and something I hadn’t really technically thought about is… I’ve used the phrase, “Hurting cats,” but I never really quite thought about it in exactly the way you just spoke about it. I think that’s a really good observation. Last question for you is… You’re chatting every day with folks like I’m chatting with. Any other topics you think would be interesting for the podcast?

Brian Hajost (36:05):

I do, and it’s one that I’m really interested in because I think it’s really problematic, especially for anyone dealing with cyber, and that’s artificial intelligence. Cyber people want to plan. They want to execute something. They want to test results. They want to report. And artificial intelligence by its very nature morphs and the results change based on the data sets. I think cyber and AI is really, I wouldn’t say problematic, but it’s a really interesting topic.

John Verry (36:42):

Well, it is, because by definition cyber is about applying controls to reduce risk, and business is about applying controls to reduce risk as well, right? But when you look at AI, AI becomes a true AI, becomes a black box, right? We know what we put in and we know something comes out, but there’s really no way to control what happens in the middle.

Brian Hajost (37:09):

Right. Think of The Terminator, think of 2001: Space Odyssey, you think of AI going awry, and how do the cyber folks deal with even a little awryness?

John Verry (37:22):

Yeah. It is an interesting idea that I think, to some extent… And I think your analogy of, you’ve been pulling a plow behind a horse and there’s a tractor over there holds true because I think when you look at many of the theoretical great developments in information security, like intrusion, IPS-style technologies, things like SOAR, is there’s still such a resistance to letting these tools actually take actions on someone’s behalf because of mission and fear of it being disrupted that I think from a security perspective, we don’t have to worry that much because none of us are actually… We’re all scared to death of letting anybody else do these things automatically.

Brian Hajost (38:09):

Right. Right.

John Verry (38:11):

All right. Well, listen, this has been a ton of fun. If somebody’s interested in SteelCloud and understanding a little bit better about what you guys do, what would be the best way for someone to get in touch with your team?

Brian Hajost (38:22):

Well, they can connect with me through LinkedIn, but probably the most direct thing is directly through email, bhajost, H-A- J-O-S-T, @steelcloud.com.

John Verry (38:34):

Awesome. This has been fun, man. Thanks for coming on.

Brian Hajost (38:37):

Okay. Thank you.

Narrator(intro/outro) (38:39):

You’ve been listening to The Virtual CISO Podcast. As you’ve probably figured out, we really enjoy information security, so if there’s a question we haven’t yet answered or you need some help, you can reach us at [email protected]. And to ensure you never miss an episode, subscribe to the show in your favorite podcast player. Until next time, let’s be careful out there.