[00:32] Solving the Big Problem

Petko: It's great having you on this podcast with some great guests here. And talking about not just cybersecurity. How do we stay clean and compliant, and everything that has to do with maintaining our hygiene and our cybersecurity?

Rachael: Seriously. I love the compliance topic too, so I am so excited for today's guest. Welcome to the podcast Brian Hajost. He is the founder and COO of Steel Cloud. 

Brian: Thank you so much for having me. I really look forward to today.

Rachael: So, where to start? Do we want to open with the big reveal? Because I love that you've coined this term Compliance Bill of Materials. I think that's a nice opening-up point. Let's talk about what that is because I think a lot of people have heard of software bill of materials. But we come to the compliance topic, this is meaty stuff here that you're talking about.

Brian: Sure, we can jump in. Let me first start with everything that's worth talking about is solving a big problem. Let's start with what the big problem is. For 20 years we've tried to marry up the compliance and cyber world. The people responsible for that, with the operational world and more IT side, and both camps really aren't very well-connected.

We do a lot of work in RMF. Building and approving all of the things that we want to happen once it goes into operation. And how we're going to maintain the system. It gets put in a book and is never looked at again many times. The system's put into operation and the things that are determined in the RMF process aren't actually implemented in the production process.

 

[3:15] The Compliance Bill of Materials (CBOMs)

Brian: We do all kinds of assessments. We're scanning for all kinds of things. We're building big databases and dashboards. And we're trying to correlate what's happening in the IT world with what we think should have happened in the compliance world. We keep trying to build better dashboards and scan for more information and we haven't fixed the problem.

We at SteelCloud took a look at this and said, "Well, if we haven't fixed it after 20 years, it must be a fundamental issue." The fundamental issue, and certainly a frustration that has been voiced by a lot of folks on the compliance side is they spend all this time building the book, they put it on the shelf, and nothing happens with it.
CBOM or Compliance Bill of Materials really is taking the machine enforceable or the machine scannable things that come out of RMF.

Those could be certainly all of your CIS or state controls. Those are the big things in terms of numbers. Other things, the software stack, things that can't be there, things that can be there, ports and protocols, any of the things that were approved, waivers, and it puts them in a basic list.

These are the things that we expect production to implement or production to manage. When we get reports back, we want them in this format. Well, a list doesn't create automation, so automation is you take the list, and you create compliances code. If out of the RMF process you can create compliances code that will stand up and force all the machine enforceable and scannable items, then the reports back naturally.

One correspond and correlate with the things that were decided.

 

Compliance Bill of Materials and Change

Brian: The big issue we're looking at is how do we go. We've done a lot of work with Xacta, CSAT, some with CSAM, and with eMASS. The big government processes that manage RMF. And popping out a list, creating compliances code, then driving it into production. Doing all that with little or no human intervention. That creates a closed loop between RMF, the operational organization back to RMF. 

Operations are enforcing what's in RMF. Operations are reporting back scanned information, monitoring information basically in the exact same format. That's what CBOM is. It is a concept that we think will take a great step forward in fixing this problem we've been working on for 20 years.

Rachael: That's crazy though, 20 years. Why has it taken so long? We just like to keep beating our heads against a wall until like, "Wait a minute, there's got to be a better way."

Petko: I like this because the risk management framework is really the government process for authorizing and allowing your system on a network to store government data. They're very stringent about what controls are there. But a lot of times they'll go through, they'll build it, they'll document it, and then you're 1,000 pages in documentation, and someone says, "Hey, look at all the documentation I created."

Later on, over time, a year later, two years, the design changes and it doesn't match what you built. And we've got to find that loop of how do we monitor the Compliance Bill of Materials and what changed? But at the security control level, at the compliance level. This really reminds me of software bill of materials and how one is for software.

This is for compliance, and so I'm really excited for what your company's doing here.

 

The Software Bill of Materials and the Compliance Bill of Materials

Brian: There's somewhat of a crossover. When you look at software bill of materials as an inventory that many times when it's built, you don't know exactly what you're going to do with it. But some of those elements get translated into the Compliance Bill of Materials in that I've authorized this operating system. That's part of the software bill of materials. 

I've authorized this version of Java. I've authorized this other control piece of software. Some of what is in a software bill of materials will actually be part of compliance. They didn't authorize it to run on any version of Linux. No, it was Red Hat 8, not 7 or 9.

Petko: The organization has a software bill of materials, and they have this compliance bill of materials. They have the traceability of the software with the machine learning configuration all the way up to the NIST controls. Wouldn't they be able to not just certify for risk management framework but say, "Look, I built this for risk, for management framework and NIST, but I can do it for others like CMMC and everything else. I can do a crosswalk to other standards."

Brian: Absolutely. CMMC is a great example. In between 800-53 and CMMC is 171. But when you look at it, there's a regimen. Decisions are being made with you, your consultant and you, and then eventually your auditor. "We've met these requirements, and this is how we're doing it."
Some of the description of this is how we're doing it is actually.

"This is how we're handing our Cisco routers. It is how we're setting up these specific applications. And this is how we're doing auditing, and much of that is implemented machine-level controls."

 

Compliance Bill of Materials and Software Inventory

Brian: These are application stacks. The biggest cyber issue is that software shows up on app stack. That was never authorized and does something you don't know what it is. So, part of the compliance bill of materials is software inventory that was approved. The things that aren't shown up, if they do, the closed loop is if operations has to install something. They go back through the process and close the loop because they'll be out of compliance, it gets built back in and approved.

That's the process. Things like CMMC, again, you're going to have just like RMF or any other framework, you're going to have decisions that are made. Some of those are machine-verifiable, machine-remediable. I mean part of what you want to do is fix as much as you can without human intervention.

Petko: Yes, I think we tend to think of this always as a government problem. This is risk management framework, it's not my problem, it's the DoD's problem, it's that other government's problem. You look at CMMC, which is the DoD's Cybersecurity Maturity Model Certification. If you do business with the DoD, which you'd be surprised there's actually a lot of companies that do any business with the DoD.

I mean there's over 300,000 different companies, and I remember when I spoke to some of them, some were selling food to the DoD. They're a food production, and they literally were asked to, "Well, show us your DFARS, show us your compliance." And he's like, "I have a factory in the middle of nowhere that just makes food, and just because I'm selling it to the DoD, you want me to comply."

 

Controlled Unclassified Information

Brian: It actually goes down to what level of information they have. If they have CUI data. If they're delivering food to a classified facility, and they have drawing. Maybe it's not even classified, maybe it's just a confidential facility, and they have drawings of the whole base and they know where to put things, those drawings are CUI materials.

That's why they have to comply because if that information gets physical attack. We can imagine all the bad things that happen. If they don't want the drawing, if they don't want the CMMC then don't accept any CUI data from the government.

Petko: Yes, Controlled Unclassified Information. It's interesting how we always think of it as a government-only problem, but there is a way that some of these decisions that get made in government do come out. I remember, and again, I will age myself, probably two decades ago when the US government came out and said you can no longer use social security as a unique identifier in your systems. Imagine being in college and everyone who was logging into their college system with their social security number as their user ID. And they said, "Stop doing that. That cannot be a user ID."

Brian: Yes, I remember the State of Virginia quit using social security as your driver's license ID decades ago. 

Petko: But that's CUI if you think about it. And that was a change that they made just because it's sensitive and they said stop doing this. I think we underestimate how much potentially data we have in our systems, and we need to be aware of it. And sometimes in order to continue doing business with certain regulated industries, we have to comply and ensure that we don't have a data spill.

 

[12:11] The Government on Cyber Hygiene

Petko: I'm thinking there are certain entities overseas that had potentially a breach, and they were storing actual images of licenses in their system. And they had a breach, and they were like, "Oh, that was..." Well, why are you storing a license, a photo of a license? You know what? I think one of the things we don't realize is data becomes in some way, data's not oil, it becomes a liability if you have certain data.

So, I think if we're going to have protecting assets like government data or sensitive data, we also have to have the right controls in place. I'd love to get your take on just the broader subsequent regulations. Am I off track thinking it applies to more than just government here?

Brian: Well, absolutely, there's a couple of things. One of my favorite documents in the entirety of the federal government, and I recommend that any of your listeners probably start with it before reading maybe 800-53, that's IRS Publication 1075.

It is the most readable government document that explains cyber hygiene, cybersecurity, RMF 800-53, and that was a government document that was foisted on state local governments and then foisted on industry to protect taxpayer information on systems to store tax returns.

So, that is a government-to-industry protecting consumers. We had another customer who one of the government agencies required that they STIG up their environments housing student loans. Again, nothing having to do with the government. It was the government protecting the citizenry and the PII, the personal information they had.

 

Protecting the People and Their Information

Brian: CISA, PSA are taking a more active role after the Colonial Pipeline shut down, and the water company in Florida protecting critical infrastructure. So, this is banking, transportation, energy, a bunch of new regulations coming out that will affect those organizations. Because it isn't government information, it's not personal information, but it's dramatic enough it can affect the economy, which affects everyone.

Again, it's the government's responsibility. We have a military to protect citizens. Protecting the economy is part of protecting citizens, and we'll see a lot of that. CMMC is probably the most publicized one of the things that government's done to protect its information, but it's doing a lot of work in secure supply chain and secure development.

Foisting regulations on their suppliers to ensure that they don't produce software that hacks on purpose because it's been breached at the vendor side.

There's a lot of things and we are a software supplier, and not only are we a software supplier, we are in the definition of critical software operating at a privilege level, and a lot of that came out of the lessons learned from SolarWinds.

Rachael: This is incredibly awesome though, so what kind of hesitancy would there be then, Brian, to an organization coming on board with this, with the CBOM?

Brian: Well, there's always automation. Automation isn't just automation, it's doing something differently, so you have inertia. There's a tremendous amount of inertia in the federal government. It's difficult because of protection sometimes Congress has put in place of doing something different and maybe not doing the right way.

 

Labor Automation

Brian: The other issue that we see is that a lot of the budgeting money is programmatically driven towards labor. When you talk about automation, you're talking about saving money through automating things that used to be manual. So, you have some friction of repurposing money meant for people to labor, and you have a lot of organizations that make money off labor.

I would say three years ago probably pre-COVID that was more of a factor. It's almost not a factor today. Zero unemployment with cyber professionals. If the customer had the budget they can't get the people with the inflation that we've seen. Federal budgets are not keeping up with the inflation of salaries, so we see almost zero resistance from some of the traditional reasons that people haven't automated.

The contractors are looking for automation because they can't find the people and they still have customers to satisfy that have budgets that are constrained. So, I would say today probably inertia is the biggest. People would like to get better, it just is hard to move a large organization.

Rachael: It really is. We've had a number of folks here who have served as CIOs at some of the big government agencies and what it takes to move things forward and get alignment, it's no easy task.

But it's amazing when it does come together because you do start seeing these strides forward, which is always really exciting and very encouraging. And it seems like they're getting faster about it with the government agencies today, which is exciting. Maybe an output of the COVID time when we had to advance digital transformation. Now we're starting to see the benefits, yes, of the acceleration.

 

Lessons Learned

Brian: COVID did a lot because they didn't have the choice to move slowly. Especially with telework, and that kind of thing. There were a lot of, I wouldn't say rules broken, but there was a lot of pressure put on the system that a lot of lessons were learned.

Petko: You pointed something. With COVID, we learned that we can move fast. We don't have to move slow. All those things that take 12 months we did in a month. They made it happen. “You want to work from home, well, hold on, we don't have a laptop. Let's get you 5,000 laptops.” “Oh, what else do you need? Let's get email working remotely because normally it was only in the building.” They made it work in 30 or 60 days. It was impressive.

Brian: The other thing that the government proved to themselves is that they can do big things and could do them well. You do not read about disasters that happen during COVID of, well, you can just imagine. No, the government actually did a really good job of moving that quickly. I think that was maybe a surprise to some people.

Petko: I think we're having less breaches now in government, at least from what I've heard. It appears that way at least. I'm being positive here, but it's definitely not in the news as often as it used to be, but I think we have other things to focus on. I think automating compliance, I think you're right, is the way we'll get out of the labor shortage we have in cyber and allow governments to deploy software faster.

Because usually they'll say bottleneck is the certification authorization or assessment authorization team, and they need X number of months.

 

[19:54] How to Start with a Compliance Bill of Materials

Brian: The dirty secret there is a lot of that slowdown is they need IT resources that are not in their organization to do all the hardening and testing. They can write all the essays and they can get the stuff approved, but someone has to do the hardening and producing artifacts. If you automate it in the preproduction then you can move right into post-production and automate it there.

Moving through RMF is a big issue because as they modernize, as they get new security technologies, they don't get the benefit of them until they get deployed. Shortening that timeline to get deployed is a critical factor.

Rachael: It's huge. So, if organizations want to start moving towards this, where do you even start, Brian?

Brian: Well, a couple of things. We can start on a STIG and we do. I mean we have government customers, civilian and DoD customers. We started with CBOM. I'll tell you what SteelCloud is doing, we're concentrating on the organizations that manage the RMF systems.

So, this is Telos and Xacta, it's Justice and CSAM, CIS and CSAT, it's the DoD and eMASS. I think one of the things that the government can do is look at their RMF processes and then potentially engage to produce a CBOM. Again, a CBOM can be as simple as a Word document with a list on it. I mean, that can be a start.

But then envisioning their own organization, if they can reduce that as compliances code, they can close that loop. And so, the move forward, you got to have a light tower you're sailing towards. If they can at least do that, and then the vendor community, folks like SteelCloud that can produce the compliances code.

 

It Takes Coordination

Brian: The RMF organizations like Telos and Xacta, they can automate their part of the process so the government when they're ready to deploy can push the button, produce the list, produce the compliances code, and go into production. We can do that. I

t's multi-parties, it's the government in partnership with their vendor community and their services community to move the concept forward and agree upon this is going to close this gap we have today.

Rachael: And it's seemingly getting, I don't know if siloed is the right word, but almost some function areas talking to each other earlier and more often perhaps. I was joking about compliance by design, but it's getting these things earlier in the process where historically we've maybe done it a little bit later.

Brian: I'm on a working group for continuous ATO, and the only way that works is if you have groups that don't typically work together. Whether that's engineering and the RMF authorization side, or authorization side in IT. All those groups have to work together if you're ever going to affect continuous ATO. I mean we have slow ATO.
We could have a little bit faster ATO, we can go to continuous.

But yes, it does require that things have better coordination and not be siloed, and not be discreet. You produce a report, you send it to me, I handle it, I get back to you if I have a problem. That can't work in any world where things need to go faster.

 

Implementing the Compliance Bill of Materials

Petko: Brian, I think Xacta and even the FedRAMP PMO they created something called OSCAL, which is for automating the SSP. CBOM is for going deeper.

Brian: Yes, CBOM is going deeper and OSCAL is typically a way a system would communicate back to. So, I'm talking about the way a system will enforce, will create rules, not just receive the rules, but create the rules and then automation will enforce the rules or implement.

This all goes back to step four of the RMF framework: implementation preauthorization. Implementation is part of the ongoing monitoring process. And so, yes, it's a lot simpler than OSCAL. You can with cloud formation, I mean you can describe almost anything in OSCAL, but CBOM would be more direct machine-level things that you can execute.

Step four is implementation. If you look at OSCAL, if you push a button, you could describe a CBOM in OSCAL. But OSCAL doesn't remediate, OSCAL does not define fixing. And so, at some point, you have to translate it into compliances code that can actually go do something.

I'm not sure there's a lot of value in outputting a CBOM in OSCAL, but maybe there is. In the concept of CBOM, the format of what that is, just like the format of SBOM has to be defined. It would be great if NIST provided a standard output so every system that does RMF work at output, a standard say JSON format that these are the rules that we want you to enforce. And then that standard format could be brought into a system, compliances code is automatically created, and then enforcement is ensured.

 

Bridging Gaps and Automation

Rachael: What are the gaps here then, Brian? As you start automating, where are the checkpoints? And by that, in terms of auditing or making sure that you're hitting all of the right boxes. What does that look like?

Brian: There are a lot of things, say in the STIGs, that are judgment calls. Things like you have to have a vulnerability assessment program. There are things that you can't. I mean you can directly address a registry key that fulfills a control, but the larger things you can't, documentation issues.
All of this goes back. When you look at all automation in the cyber world, it goes back to letting the machines do what machines do. You have people hours to do the things that only people can do, and there are things that only people can do. 

Patching, there has to be some personnel involvement in patching, just because of the testing and the other things. In order to have enough people to do threat hunting and vulnerabilities from a patching side and all the rest of the slices of cyber, the meat and potatoes foundation work have to be automated. Much the way we've automated virus, it's an afterthought. No one thinks about it. It's a base level of hygiene that we apply, and then we go and do the real work.

A lot of these system controls, managing the configurations ought to be something that is automatic, and the configurations become an even more important component of Zero Trust because when someone's coming into, they're not coming into the network once. They're coming into it every application area and they get validated both identity, and also configuration.

 

Compliance Bill of Materials and Zero Trust

Brian: If you don't have a way to keep those configurations up-to-date and compliant, you're going to have half your workforce in quarantine. And so, Zero Trust will shine a very bright light on where we are in compliance.

It's a interesting concept. If you look at it and you overlay it and map it to 800-53, it isn't all that different. It's like you're going to do all this stuff, but you're going to do it every application area, not at the network boundary. I don't think it's quite as new as some people would like to, you know.

Petko: I think it's been out for over a decade, it's just that we keep changing the name a little bit and changing the focus.Is it on the network? Is it the architecture? Is it a principle? It's evolved since '09 or so, but the US government taking a huge lead in this has done a great job documenting what data you need to make good decisions before you give access.

And when you do give access, how do you do continuous monitoring of the access?

In a way, Zero Trust is what I built. Your Compliance Bill of Materials is how do I maintain what I built and ensure that we can reuse it eventually is the goal, I think. I mean I'm sure the government does not want to be paying for the same system multiple times, or the same authorization assessment team multiple times on the same system.

So, I'm hoping the CBOM just allows us in the future to simplify our authorization process, and so, thank you for everything you do there. 

 

[30:18] Automate Compliance With SteelCloud

Petko: How can our podcast audience learn more about compliance material and how they can automate their compliance?

Brian: We're going to have some materials on our website. Again, it is more of an industry thing, it's not a product thing for us. I'm involved with a working group about continuous ATO, so we'll have output from that in that area. We hope to be meeting with NIST here in the next 30-60 days.

A lot of it is working through the vendors that would output a CBOM. I mean it starts with if you've got a RMF capability that can't output a CBOM easily, then we're stuck. Although from a pure STIG or CIS standpoint, we can handle that pre and post-authorization, but the rest of the information that would be included in a CBOM, really leaning on the vendors.

As I mentioned, we are doing our part to meet with vendors, the vendors that do RMF work, and socialize the idea with them and see if there are any blockers on their side or any areas that they think could be enhancements that they could make. For a customer, if they bought any technology that does this automation, they ought to be able to push a few buttons and output a CBOM. That's how simple it should be.

 

Getting Ahead of Attackers

Petko: I hear ChatGTP is going to fix that for us too.

Rachael: If only. I was reading something that it passed the medical boards or something. I've never really used it, I feel like, “I know, where have I been?”

Brian: I've got a gentleman that works for me who's a mandarin native speaker. He's just fascinated with it. For him it's wonderful. The English and being able to get stuff, he's fascinated with it. I only know one language. If you know two languages, that kind of stuff is fascinating.

Rachael: I definitely want to try it out. I'm scared though. It's like TikTok, once I dived in, it was whole hog. You might never see me again once I get into the chat. One final question I do like to ask some of our guests. Given your history in the security industry, we look at the path ahead. Are we ever going to get ahead of these attackers?
We're starting to automate things that are very critical.

Are you feeling positive here on the security path ahead or are we going to? Are we going to get ahead of these guys or are we going to keep following them in the next 10-20 years?

Brian: I think we'll get ahead of them in that we'll better prioritize critical things. You won't see the critical things being attacked. I don't want to make light of a credit card number dump, but that's not like penetrating privileged systems that can set up users and can do all kinds of things. We may not lessen the attacks, but the attacks are going to be more petty crimes and less homicides. Okay, let me say it over again, petty crime versus grand larceny. How's that?

 

 

The Beacon of Compliance and Cyber Hygiene

Brian: We're going to be that. I think industry as we see more, "Hey, we do it our way, we're special," more standardization. As soon as you do standardization, you can do best practices. You could then take advantage of the hundreds of millions that have been spent over the years.

We see industry coming along. I take a lot of solace in that they care about a lot of things. They're frankly following the US federal government, which has been doing this for years and the best practice is there.

Hats off to them because we travel the world. The US federal government is the beacon for the world in the work that they've done in cyber and compliance and cyber hygiene. We have a lot of people around the world following what we're doing in the US. Primarily what the federal government led with.

Rachael: Struggling with the awareness was where the industry was having a hard time. Particularly in the last several years with the current administration just really championing security and bringing it front and center. It's been exciting to see how that's also helped organizations to start better prioritizing security, making the budget for it, and looking at it through this new lens of its part of business today.

Brian: Even a small business like SteelCloud, when we pour over the presence EO on cyber, and when we moved into our new space, we organized security. We put two-factor authentication on physical doors that we only had single-factor on, and locked our signing server away in a special place that no one could get to. Lots of things, so I'm sure if SteelCloud is worrying about those kinds of things, there's lots of other vendors and contractors that are doing exactly the same thing.

 

[37:25] Eliminating Drift

Rachael: When it comes to the two-factor, sometimes I get a little annoyed because I have to find another phone to authorize. I've been a little reticent to do it everywhere. But where I do have it, I'm seeing dividends. Even the basic things, getting everyone on board with that. What a difference that could make.

Brian, thank you so much for joining us. This has been fun. I've learned a lot. My head's still reeling, but that's why I love cybersecurity. I've been in the industry for a while and every day you learn something new and get to follow the advances forward when it's been 20 years where we haven't been able to crack the code. Then you have this opening. That's why I love this industry, it's so exciting.

Brian: Can I give you an idea for another podcast? I'm not sure I'm the right one. How do you eliminate drift is a question I asked CISOs and CSOs. No one has an answer. All these that we put in place to control and manage things, and we still have what appears to be uncontrollable drift. We focus a lot on the cyber and compliance side. Why do you have compliance drift?

It's one that I'm fascinated. It really is about IT and how they manage themselves. Why could something be perfect yesterday, wait three months and you can't recognize it.

Part of it is just the patching process. We do all kinds of things. It's not like I have a secret answer, I don't really. It's a conundrum. In the manufacturing process, they programmatically remove drift from everything. The thousandth Chevy has to be just like the first Chevy. Somehow in IT and security, we drift all over the place.

 

Self-Healing

Petko: If you think about it, even the remote controls for the Nintendo Switch or the PS5, they've got drift where, "Hey, why's my guy going left? I'm not even touching the remote. I'm going to readjust it." It's almost the same thing with security, the more complex the software, and controllers used to be simple and now they're much more complex.

I think we have drift everywhere. We just have to accept it and then monitor for it.

Brian: Let me give you another example. In olden days, printers would get out of alignment. There would be a timer set. It would send you a message, align your printer. You would go hit a few buttons and it would go do something.

All new printers do that themselves. The printer itself recognizes how many pages. It aligns itself. It tells you it's aligning now. You never worry about it again. That's the way compliance has to be. Not notifications that cause a person to do something, but self-healing. Again, a lighthouse. Not exactly sure how to get there. CBOM helps because we can build compliances code. We continually automatically bring back from drift, but yes, the self-healing.

Rachael: To all of our listeners out there, Brian's laid down the gauntlet. We want to hear from you. Reach out to us if you've got some thoughts here. This is a wonderful discussion. 

Brian, thank you so much. I do want to be mindful of our time but thank you so much for joining us today. I know our listeners are going to get a lot out of this podcast, and as always, thanks to our listeners for joining us yet again.

 

About Our Guest

 

 

Brian Hajost is the founder and COO of SteelCloud, a company that develops technology for automated compliance for DISA STIGs and the CIS Security Benchmarks. Mr. Hajost has transformed SteelCloud into a recognized leader in delivering new technologies that allow government customers and commercial enterprises to effectively meet the compliance mandates of RMF, NIST 800-53, NIST 800-171, CMMC, and IRS Pub 1075.

Brian’s technical career has spanned over thirty years, primarily with leading-edge technologies in regulated industries. He holds 10 patents in IT security and two patents in mobile security. Mr. Hajost is an active contributor to AFCEA International through his membership on the Technology Committee and Secure Supply Chain subcommittee. He is also the Vice Chair of the Advanced Technology Academic Research Center (ATARC) Continuous ATO Working Group.