Building Cybersecurity Ecosystems in the DoD with Chris Hughes

[00:00:00] Chris Hughes: I think sometimes we tend to kind of be afraid of new technologies or new ways of doing things. Like you've seen some around AI, for example, banning its use in certain organizations. Uh, that actually causes more problems than solutions. Because what it is, is we don't get familiar with it.

We don't get comfortable with it. How can we possibly secure something if we don't even know how it works? We haven't gotten any experience with it. So I think being out there being experimental, as you call it, tinkering with new technologies, new methodologies, new services and capabilities is critical when it comes to actually learning how to secure them. 

[00:00:49] Ryan Connell: Hello, this is Ryan Connell from the Chief Digital and Artificial Intelligence Office, here today with Chris Hughes. Chris, how you doing?

[00:00:55] Chris Hughes: I'm doing awesome, man. I'm excited to be here and chat. 

[00:00:57] Ryan Connell: Yeah, no, appreciate, you coming on. Uh, you want to start off with an intro, talk about yourself a little bit?

[00:01:02] Chris Hughes: Yeah, sure. I've been in the federal IT cyberspace about 20 years. I started off in active duty air force myself and got out and was a federal civilian a couple of times. Once with the Navy team doing cloud and DevSecOps for Navy and defense health agency. And then once with the GSA FedRAMP team doing a lot of cloud security and compliance work there, and then have bounced around the ecosystem with different software factories like Pulse, Platform one and on the Air Force side, some organizations like centers for Medicare, Medicaid, VA.

so I have been around the ecosystem quite a bit and do a lot of work with different software startups, as well as being the founder and CEO at a company named Acquia, our service disabled veteran owned small business focused on cyber and digital services.

[00:01:42] Ryan Connell: Awesome. Yeah, I was just going to ask, what are you up to these days? But that kind of helps. So, uh, talk to me a little bit about that start, how long you've been in business.

[00:01:48] Chris Hughes: Yeah, we've been around a little bit over three years now. We're up to about 70 people, uh, doing work both on the DOD and the federal civilian side of things. Like I said, a big focus on cyber. so everything from zero trust, software supply chain security, continuous ATO, application security, DevSecOps, you name it, as well as a broader kind of digital services, bent as well doing like cloud engineering and architecture and software development as well.

[00:02:11] Ryan Connell: Very cool. Uh, a lot of buzzwords, but we'll get into it here. Uh, I'm excited. You know, this is an area that's, I'll say new to me, but as quickly become an Achilles heel, uh, for me personally, or professionally, I want to look at it. so let's just like dive in. So when we're talking about, experimenting with some software, right?

I want to try something. what's your take on just like cybersecurity? is it something that you start there or you end there or somewhere in the middle or is it continuous? Like how do we get there?

[00:02:38] Chris Hughes: Yeah, I think, obviously like we've heard terms, like you said, buzzwords like DevSecOps and, you know, hear a lot of phrases like building security inverse, bolting it on and secure by design, you know, whatever the mantra of the day is, but I'm a big proponent of security being involved from the onset, so rather than, you know, coming in after the fact and shutting everything down and saying, no, you can't do this or this.

And, uh, you're not compliant and so on and so forth, having security, there's a partner working with you through that process and understanding what you're doing. I think a lot of times where we go wrong is security is not working hand in hand with engineers, developers, the business, you know, procurement and so on.

and that causes a lot of problems down the road. and also, you know, I'll just say like, you know, I think sometimes we tend to kind of be afraid of new technologies or new ways of doing things. Like you've seen some around AI, for example, banning its use in certain organizations. Uh, that actually causes more problems than, solutions, because what it is, is we don't get familiar with it.

We don't get comfortable with it. How can we possibly secure something if we don't even know how it works? We haven't gotten any experience with it. So I think being out there being experimental, as you call it, tinkering with new technologies, new methodologies, new services and capabilities is critical when it comes to actually learning how to secure them.

[00:03:42] Ryan Connell: Yeah, that makes a lot of sense, you know, and the banning thing is interesting, uh, in addition to just what you said in terms of like familiarity and getting used to it. 

[00:03:50] Chris Hughes: If I could jump in real quick, um, you know, I, I didn't mention this in the beginning, but I do run a substack called Resilient Cyber, where I write a lot and I talk, a lot, right? I I talk a lot about different things in cyber and IT, and compliance. and one of those is we hear a lot of, the phrase shadow, it was like shadow it, right?

And then shadow cloud, and now shadow ai. And I think the behaviors in cybersecurity of coming around being punitive and being, you know, not being collaborative, not building relationships, building trust among the organization. Leads to that shadow usage. Like the business is going to, it's like water.

It's going to find a way in. They're going to do what they're going to do. but if you haven't built those relationships, you haven't built that trust, where they come and work collaboratively with you, it's going to lead to shadow usage, which is actually, you know, more nefarious and a lot more risky than just working hand in hand from the onset.

[00:04:31] Ryan Connell: Yeah. That makes a lot of sense. awesome. Is there like a, a difference of approach? So I'm thinking of my ecosystem, right? I have some things that I'm, experimenting from a build standpoint, but then there's also some things that I'm experimenting with there that are more like commercially available solutions that I'm buying, but also still like put the experimental stamp on it because either how I'm using it or whatever, is it, are those other different approaches to how we do cyber in those two?

[00:04:56] Chris Hughes: Uh, yes, definitely. For sure. There's some nuance there in the build approach. You know, you're, you're obviously going to have a bit more insight and in terms of control, you know, what technologies are being used, how they're configured, how they're set up, think about cloud in the shared responsibility model context, right?

You don't have a lot of visibility into the underlying infrastructure and the physical security and the media, you know, sanitization and so on and so forth. Uh, that's going on there, but you're also able to lean into core competencies of a provider who do things at a level. One. level of proficiency that you maybe you can't do.

And it's not your core focus, right? Your core focus is delivering value to the mission owner, the warfighter, you know, whatever the case is. So leaning into services providers, for example, in commercial technologies, that's a benefit in that regard. And then on the build side of it, like I said, you have some more control.

Uh, you can see what's being used, how it's configured, how it's set up. You have more, more granular control, but also with that control comes a great amount of responsibility. and as we know, in the government, we often struggle to attract and retain technical talent. So that means somebody has to maintain these things, secure them, configure them appropriately, you know, maintain them, all those kinds of things.

so there's kind of that, that, you know, pulling, pulling push, you know, dynamic at play there. And also. You know, I'll say we have a weird incentive based ecosystem here where it's not the commercial space where, you know, people lean into technologies and they don't often necessarily build something unless they have the proficiency, proficiencies and resources and capabilities to do that.

We have a weird ecosystem where there's a lot of incentives to influence things to be built rather than using commercial technologies that are available because that could be a contract that could be resources that could be growth, you know, for a government contracting company, which I have one, but I see this happen often on the government side and commercial side of things throughout my time in government.

so I think that that's something that's at play. That's not at play as much in the commercial space, for example. so just thinking about the resources, you know, Do you have the expertise in house, the capabilities, you know, those kinds of things to actually man and configure, you know, operate these technologies?

If not, is it, does it make sense to lean into a service provider or, you know, a commercial technology rather than recreating the wheel? you know, these are all core things that should be considered. And then often, You know, one last plug. I've been chatting with the CTO of Palantir, you know, he has some really great commentary recently, a testimony that he gave, and he kind of used this analogy around vendor lock where you're like, you know, you're going to get vendor lock if you use this commercial, you know, provider, right, or technology.

but in our ecosystem, all you've kind of done is locked yourself in with a system integrator or a government contractor, you know, that now operates this, platform or technology or whatever the case is that's been built for you. so there is another side of that vendor lock equation in our ecosystem, basically.

[00:07:24] Ryan Connell: Sure. Yeah. That makes a lot of sense. Interesting. So, on the commercial side, like in terms of, when I say commercial side, I mean, like we're buying a solution that has non governmental users. what are we like looking for? So I'll give you a, maybe really first grade type elementary, right.

Like, things I'm not supposed to do at work, right. Take an email that potentially let's see why email and forwarded to my Gmail. Can't do that. but I always laugh at like, I assume Google's pretty good at security. Right. So like, help me unpack that a little bit.

[00:07:53] Chris Hughes: Yeah. Again, that goes back to, you know, I see a lot of these behaviors, like you talked about, like just that, that simple example you gave and we all know, like the fix, fix our computers memo. a lot of times I think these, you know, security risky, behaviors actually start to happen because people just don't have functional systems and they want to use like their own laptop or phone or, a device or application that they're used to using that's, seamless and capable.

And so they work around. The constraints of the ecosystem and the constraints of the technology that they have access to in the government, uh, naturally creates a lot of risk because now, like you said, you have, you know, sensitive data, perhaps UI data going on the commercial devices that aren't governed and controlled by the government or, you know, don't have the proper safeguards in place like a hundred one 71 or CMMC, you name it, that kind of thing.

so I think a lot of that comes back to just, Having capable, functional technologies that people can efficiently use. They don't have to work around just to get their job done. You know, we see people taking the linked in saying, say, Hey, I've been waiting to log in for, you know, 18 minutes or whatever the case is.

Right. and people often seek those workarounds, which introduce again, security risks. so I think, you know, sometimes we're our own worst enemy in that regard, you know, of how we approach this. And also, like you said, you assume Google's pretty good at security. That's a conversation I've had a lot around cloud security, whether it's, you know, Azure AWS, Google, you name it, not that they're infallible and don't make mistakes and there aren't security concerns there that we definitely know there are, we've seen many incidents, but there's something to be said about leaning into, you know, world class providers of technologies and platforms and software and capabilities, rather than, you know, are you telling me that you're, you know, say your three person contract team is going to secure.

The installation of some application better than say, you know, GitHub or something like that, like some commercial enterprise, you know, with millions of users worldwide. so that's something to consider there is, is really thinking through, like, you know, and it's a spectrum, right? you have some software startups, maybe they're just trying to get to market.

They don't really have a security team. They have no CISO. They have no really secure. Security in place. They're just trying to get some initial product market fit, you know, get some adoption, get some users and so on. Maybe they are not in a good position to secure something for you. And you, maybe you do want to self host it and, configure it and secure it yourself where others are, have a world class team of engineers that we can only dream of hiring, for example.

so it really is a spectrum of, you know, that you need to look at the use case, the technology, the provider, you know, and see what the situation is.

[00:10:05] Ryan Connell: Yeah, that makes a lot of sense. You know, it's just interesting, right? So like take like a, an AI example and I'll say, a use case that I'd say is fairly common at this point is kind of general rag, like read my files. Let me ask questions against it. Let me, summarize in something, a document for you, like those kinds of things, potentially integrate to SharePoint, right?

Like those are things that there's a lot of companies in this space already. the challenge is like, if I want to experiment with one of them, like here's 10 K here's 20 K, like, what can you do with my data? Um, it seems like I'm running into potential roadblocks there with like, here's 10 K, but Oh, let me go give a million dollars to figure out how to get an ATO.

Right. Like, like that proportion, obviously those aren't real numbers, but you get where I'm coming from. Is there a better answer to what I'm trying to solve from that perspective?

And it's not just me, obviously a lot of people are trying to solve.

[00:10:54] Chris Hughes: Yeah. No, I think this is really, you know, this comes down to the expertise and nuance of understanding the use case. If it's a pilot or a prototype or an MVP or something like that, you know, having some consideration for what type of data are we going to put in there, you know, it doesn't have to be production sensitive data, for example, CUI type data, you know, can we take safeguards to put non sensitive data, non critical data, things that let us explore technology, tinker with it, build proficiencies, things like that, but don't put us at risk if it, Leads to an incident of some sort, right?

who's accessing it? Under what context, what type of data are they putting there? You know, just thinking through that kind of threat modeling, as we call it, of what can go wrong and what are we going to do about how we prepared, you know, those kinds of things, what are we building and so on, those considerations are key so that you can go out there You know, experiment, as you said, tinker around, play with something, you know, see how you use it, see if it fits your use case.

And then from there starts a scale. And then maybe things like an ATO, you know, those come on the horizon of, Hey, Hey, we want to take this to the next level. We want to put some sensitive data in there. You know, we want to kind of, you know, move this to a production ready, type implementation. Now you start talking more rigorous security, more rigorous compliance requirements and so on.

but if security is killing it out the gate, again, it's back to that point of what we talked about, where the business is likely going to go experiment with it anyways. And I'd rather be involved in working with them collaboratively and understanding how they're using it, who's accessing it, what type of data they're putting in that environment or that, you know, service and application rather than them going and doing it without me because they just see me as a roadblock and I'm going to say no and I won't work with them and I'm going to be a pain in the butt.

You know, they just see me as someone that's not going to help them, you know, use what they want to use and do what they want to do. So I'd rather build that relationship with them, so that they work with me rather than, you know, kind of without me.

[00:12:29] Ryan Connell: Yeah, that makes a lot of sense. I know we've, tinkered around ATO and you mentioned the cloud topic earlier, uh, FedRAMP, ATO. What's the difference?

[00:12:38] Chris Hughes: Yeah. So for folks not familiar, like I mentioned, I spent some time previously at an agency called GSA and doing FedRAMP. Uh, FedRAMP is a program designed for commercial cloud that wants to be used in the federal marketplace. so if I'm looking to use like a, you know, IaaS or a PaaS or a SaaS provider that, you know, is in the commercial side, I need to look to someone that has a FedRAMP authorization.

For example, uh, it's authorized to be used for the federal government. And then the DoD side, you have something called the SRG. Where DISA is going to come and kind of add on to that with what we call FedRAMP plus, or, you know, D O D S R G additional security requirements at different impact levels and use cases and so on.

Where ATO is more for traditionally like, internal federal IT systems. Like I'm working with, you know, us air force and, we want to stand up a system, for the air force on their own. Infrastructure or on a commercial cloud provider that's fed ramped, you know, those kinds of things. Then we'll go and get the system and ATO, for example, uh, where FedRAMP is, I'm a commercial, you know, cloud service provider, and I have a cloud service offering.

And I want to offer that to someone, uh, via the FedRAMP marketplace, for example. So seeking that FedRAMP authorization is key

[00:13:41] Ryan Connell: Got it. Okay. That makes sense. So you might not have an answer to this question.

And if you don't, just that's fine. I just, I feel like I got to ask you can leave the companies and all the situations out so that it's publicly available. But do you have any numbers to like, if I were to ask you for the cheapest and or the fastest ATO that you know of?

[00:13:58] Chris Hughes: So, I mean, there, there is some nuance there. Like, you know, we've seen the, budding, you know, software factory ecosystem, for example, where people are building on underlying, you know, infrastructure and platform as a service type environments that are inheriting security controls, like they're able to bring in, you know, for example, it's happening on the commercial side with FedRAMP too.

Uh, they're able to bring in just their application or just a container, you know, that kind of thing, get it authorized much faster, you're talking, you know, months or even weeks, maybe, versus, you know, a year, 18 months, 24 months, as in some cases, with more legacy, you know, where you kind of do it all yourself from scratch.

I will say. And this is a tricky topic, but you know, best, cheapest, fastest doesn't always mean most rigorous, most secure, most safe. Cause I have seen a lot of ATOs and both in the government and the commercial side, I won't name any programs or agencies, et cetera, where I come in and I'm like, wait, what?

This has an ATO, like nothing's documented, nothing's actually set up. you know, how did this even happen? but it happens because people just want to move fast. so yeah, obviously we're looking to use technologies like inheriting controls from underlying, you know, cloud providers, platform providers.

you know, streamline the process around things like continuous ATO and security control inheritance and use gen AI and LLMs to generate some security compliance documentation. For example, these are all great things that we should be doing. but we still need to make sure that we're actually.

actually implementing security and compliance and not just kind of, you know, checking the boxes without even doing the work and just, you know, throwing production data in there because that's not a good solution either.

[00:15:26] Ryan Connell: Yeah, no, a hundred percent. So, the formal or full, I'm not going to use the right words, but a formal ATO is a continuous process, right? Like Hey, it's been three months. Let's make sure people aren't putting secret information in a CUI system or whatever. Right. it's an ongoing thing.

[00:15:41] Chris Hughes: Yeah, it is. And like, if you go to, you know, NIST 800, uh, 137 and look at the risk management framework, for example, it is a life cycle that moves, from system, categorization all the way through to what we call,continuous monitoring where you're starting to monitor the system in an ongoing fashion and, you know, see if it's still implemented appropriately.

The controls are still in place. You know, has there been any, introduction of things that can cause significant risks or, you know, kind of significant changes that need to be considered and so on? I will say though, the way we've historically done that, despite the evolution and introduction of, you know, cloud and APIs and infrastructure as code and, iterative software development and so on and so forth, GRC and ATOs and compliance largely still live in the dark ages.

You're talking Excel, Word documents, PDF, static documentation, snapshot in time assessments of, Hey, once a year, we're going to come in and evaluate these controls, our subset of the controls. And then next year we'll do another subset. And every three years we go through this kind of cyclical dance.

We know that that's not the way the, you know, malicious actors operate, attackers operate. It's not the speed at which the software is developed and deployed. and that's where things, you know, you see the push for continuous ATOs coming into play is trying to use automation, APIs, you know, cloud native services and so forth, to really kind of streamline that process and, just bring GRC along on, on what we've seen around cloud and DevOps and so on.

[00:16:52] Ryan Connell: Yeah. So let's, get into that. Right. So we're talking, we kind of pivoted from what I'd call, Cyber security of AI or of systems of software systems to now using AI for the purposes of cybersecurity. So what's that environment like? Like, is there, are there, is the market pretty saturated?

Are there a lot of solutions? how well do they work? Are any of them ATO themselves?

[00:17:13] Chris Hughes: Yeah, I know. I mean, there's definitely some that are ATO themselves. I don't want to name any, providers or vendors, but you know, We've seen them, right? We see them on platforms like LinkedIn and who are touting about their federal authorization or working with different service agencies, army, air force, you know, there's some, a lot of innovative things underway when it comes to using these technologies and for security and compliance.

Um, you know, and that's a good thing in my opinion, like I said, the malicious actors, we know, They're certainly going to use these technologies to, you know, accelerate exploitation of vulnerabilities or, gathering intelligence about systems or social engineering, you name it. so we should be looking to do the same.

If we could speed up the way we generate and create compliance artifacts, the way we conduct, you know, assessments around, uh, system authorizations and so forth, you know, we should definitely be doing the same type of activity. And there are a lot of service providers that are trying to tackle this because I think it's an area of, uh, you know, our industry that's ripe.

For disruption, the way we've done it traditionally has been very manual, very burdensome, time consuming, cumbersome, and costly. Um, so using these technologies has a lot of promise and people are really excited about it. I mean, I'm in that party as well.

[00:18:12] Ryan Connell: Awesome. Uh, very cool. you mentioned offline, uh, this idea of. Like supply chain, supply chain risk. and when I think of things like that, I grew up in like a systems world, right? So I'm thinking like I have an aircraft that has supply chain with parts that go on the parts and there's parts that go on those parts.

what's supply chain look like in this world?

[00:18:31] Chris Hughes: Yeah, it's, uh, safe to say it's, complicated. I didn't mention this in the intro, but I wrote a book. called Software Transparency, and it's about software supply chain security. And, you know, just the way software powers everything right now from consumer goods, the critical infrastructure to, as you know, weapons systems, national security.

and it's a very complex ecosystem, whether we have, you know, systems that we're building natively, as you talked about internal IT systems. we have open source software, which all of those have direct and then transitive dependencies, you know, way down analogy where it just keeps going and going and going.

Uh, you have these dependencies of dependencies. Uh, and then you have a commercial services and software providers. Maybe you're building on top of a cloud service provider or you're using external software providers providing as a SAS, or you're even, Receiving a piece of software and then deploying it in your environment.

All these are considerations around software supply chain security. And we've seen a tremendous activity, in the last few years from the cybersecurity executive order that has really drove a lot of attention to this space because of incidents like SolarWinds and Log4J and XE utilities. And there's a lot of them and, you know, they just keep coming.

So people are starting to take a look at, you know, what are we using? Where's it from? You know, how was it created? What kind of rigor and, you know, governance and security was in involved in the process. So we see things like, NIST secure software development framework. we've seen CISA start to issue, requirements around self attestation to show that you're following secure software development practices, for example, if you're selling software to the federal government.

that came via a couple of different OMB memos, like OMB 2316 and 2218. I believe they are. and so starting to. You know, kind of make all software suppliers that are signed to the federal government start to self attest, that they're producing secure software and following secure software development practices and having either the CEO or someone that does it, they designate, um, sign off on that and attest to it.

But as you know, self attestation like we had with AHARM 171 has its challenges too. because. We had that was 871 and we kept having security incidents around defense industrial based systems. So now we've moved to this kind of third party model with CMMC, for example. not to take us out of tangent, but just drawing some parallels there is, you know, FedRAMP has a three PAO model, a third party assessment model.

And it's been around for over a decade. And there's only about 350 authorized services in tens of among tens of thousands. so, you know, you got to kind of pick your poison between self assessment, self attestation, and self assessment. And then third party attestation, which is costly and time consuming and, you know, may be a constraint in terms of accessing innovative software and services for the government.

[00:20:53] Ryan Connell: Yeah, that is super interesting. so I'm not a technologist, you probably tell what my questions that I'm asking. but when it comes to, you know, these types of solutions and you have, and maybe you'll correct me here, but you have your, various, I'll call them cake layers, but you kind of have infrastructure data and then kind of like the platform or app, as the top layer, There's probably a loaded question, but like, how agnostic are those three layers? Well, obviously the app isn't because that's what they're really selling from a UI perspective. But you know, if it comes down and someone's using like, you know, Chinese cloud.gov probably can't do that, right? So, is it, are things movable like a solution or is it, are you scrapped from that standpoint?

Like, if you find a thing that you really like, you wanna buy it, but there's an error somewhere in that equation. What's that process like?

[00:21:33] Chris Hughes: Yeah. again, I hate to say it depends, but these things depend. So like we talked a little bit earlier about like, you know, the build versus buy scenario, right. And I talked about skills and competencies and resources and availability of. Service providers and so on. The same thing applies in the, kind of cloud context.

If I'm building on top of an AWS and I'm using a lot of native services from AWS, and I look to migrate to say Azure or GCP or an infrastructure that I own as a data center or whatever the case is, I need to look at what services am I using? Now, what services do I need to replace? You know, on this end from AWS or Azure or whomever on the other end, when I try to move this, and that's why you see a lot of discussion around vendor lock and you see a lot of, prevalence for, example, containers and Kubernetes, because it does offer you use immutable, you know, uh, software components that you can start to kind of move around different environments.

but there are considerations around what services are you using? You know, what would be the implication or impact if I move this? You know, I need to either find another suitable service to do what this service does, or I need to start to try and do some of these things myself, for example, and that has a compliance aspect to I may be inheriting security controls or activities from a certain cloud service provider.

And now I need to do the same with wherever I go to move that, and that might be a cloud service provider. It might be on premise. It might be on the edge. As we start to see more edge use cases around cloud computing too, especially in the national security space. so all these things are considerations that you need to look at, you know, when you go to build something and then when you need to move something, I will say, I see a lot of, you know, kind of false dichotomies where people will make adamant declarations around why this needs to be, movable and portable, and we need to be able to move this to another environment and then you dig down and you see that, It likely may never move.

It's not, you know, we're not talking about something that's going to be forward deployed on the edge. We're talking about an enterprise ERP system or, you know, something like that, that they tend to not move. so it really depends on the use case. And that's kind of should dictate on how you approach it in terms of how willing you are to be kind of locked into a certain platform or provider or services.

You know, those all need to be key considerations of when you're building something, in my opinion.

[00:23:25] Ryan Connell: Yeah. Okay. No, that makes a lot of sense. Um, as you were responding, I was thinking about something that you said earlier with the conversation that you had last week with, like about vendor lock. and you're not really truly solving it, right. Because you potentially can open some competitiveness at that kind of app platform layer.

But if you're trying to, and you brought up earlier, like the, uh, more enterprise type environments are quicker with the ATO because you're kind of just adapting something in. Right. So like, At some point, you know, we have some approved cloud providers. That's a small list compared to the number of companies that sell apps.

Right. I don't want to say vendor locked, but you're kind of, because of the ones that have been approved in that approval process, you're kind of limiting, who can play in all of those layers of the cake, if that makes sense.

[00:24:06] Chris Hughes: Oh, it definitely makes sense. Um, you know, I don't want to use like the term regulatory moat, but it certainly is like, you know, if you're say, if I'm a FedRAMP high authorized cloud service provider, I have an advantage over maybe others that are not FedRAMP high authorized because they simply aren't,allowed or authorized to host certain type of data or certain type of use cases.

The same could be said if I have a DOD, you know, provisional authorization at impact level five or six. these are competitive advantages for service providers that, you know, have them versus those that don't. And it's good, right? Because it means that that provider has went through the process.

They've put in the, you know, blood, sweat and tears and financial resources to get authorized at certain levels. but it also can be a problem too. We hear a lot about trying to bring commercial technologies and innovation to the government. If I'm a small software startup that has an innovative solution, but I can't afford to spend 18 months and, you know, 700, 000 or, you know, just throwing random numbers out to go through FedRAMP and DISA and so on.

now I can't really play in that market and maybe the government can't access me. because of, I don't have those, you know, authorizations or I haven't met those compliance processes and so on. so it can be both a benefit and a constraint when it comes to accessing commercial innovation and software and technologies as well.

so it's a double edged sword for sure. But you know, at the same time, we don't want mission owners, a DOD, you know, system owners going out and just using whatever they want. With no understanding of how compliant it is, how secure it is, where it's hosted, who has access to it, you know, all the things that are involved in an ATO.

so it's a, double edged sword for sure.

[00:25:27] Ryan Connell: I have what I'll call a dumb acquisition question from someone that doesn't speak cyber. Is there like a document that if someone just said like, all right, if you're on, GCC high and you do this and you do this and you do this, like you're safe enough to play with in the interim.

There's nothing like that, right?

[00:25:46] Chris Hughes: yes and no. So like the cloud service providers, like just saying, you know, Azure, like you do our QCC high and like AWS and so on, they're going to have, what they call services and scope where they'll break down what services are authorized across, you know, different compliance regimes, whether it's, you know, things that we're familiar with, like FedRAMP and DoD or kind of commercial stuff like, You know, sock two and high trust and HIPAA.

And so, you know, those kinds of things as well. and then there'll also be, uh, what they call a customer responsibility matrix where they'll show like, Hey, we're doing these controls, you know, you're responsible for these controls and here's controls that we share. and a good cloud service provider who's very mature around compliance will have that very well documented.

So you can understand, Hey, here's what I'm responsible for. Here's what I need to do. you know, to say that there's a FedRAMP marketplace, for example, you can go and look at that. But to say that there's any kind of single overarching one that breaks down all compliance frameworks, all kind of scenarios, use cases, data types, it, that would be tricky, just because there's so many different scenarios involved.

But, you know, I would lean into looking at the service providers, you know, showing what services they have authorized it. Under different compliance frameworks, a lot of companies are starting to create what we call a trust center where they'll go out and they'll put, external facing on a website.

You know, here's our compliance frameworks that we've met. Here's, you know, things that we're doing that you don't need to do. They're laying all that information out for you and you can download it and start to look through it if you'd like to. so yeah, it's going to take a little bit of elbow grease to, kind of understand what you can or can't do under what type of situations with what type of data.

And that's where you got to start talking to some compliance nerds like myself.

[00:27:08] Ryan Connell: Perfect. No, good stuff. Yeah. I mean, of course, I'm looking, I'm the acquisition guy. I'm looking for the template, the one pager, right? 

[00:27:14] Chris Hughes: It goes both ways. It goes both ways. I'll say like starting a services company. I was like, Oh, I can do this work. And I'm like, wait, there's like a whole complicated procurement process that I need to go through to get, to be able to get to the work. Um, so like it goes both ways.

[00:27:28] Ryan Connell: fair, fair. I love it. Um, I want to leave you with a, an opportunity to just kind of, you know, call yourself king or queen, or, if you were the D O D a O for the day, um, one of those types of roles. what are you changing? Like what, what in your perspective is a worthy improvement?

[00:27:46] Chris Hughes: Yeah, there's a lot. And I think we touched on a lot of them throughout the conversation. But honestly, I would, you know, a big one that I think about a lot is the workforce. I think a lot of the struggles around compliance and cybersecurity is, because we kind of have a workforce that's oriented around itself, around controls and documentation and, uh, spends a lot of time in things like Excel and Word and doesn't get a chance to actually get down into the technologies, you know, get hands on, with the engineers, with the people building things, architecting things.

And, that lack of proficiency in that domain causes a lot of problems because I'm trying to assess something that I just, you I don't really understand how it's built or how it works, or, you know, that causes a lot of problems. And then, you know, in the government side, you know, just throwing this out, like we see a lot of like LPTA and the, you know, things like that.

Like I need a competent, capable workforce. I don't necessarily, you know, there's a lot of costs that come with, you know, making decisions around simply the cheapest option. For example, I need a proficient workforce that has the You know, skills around these knowledge, you know, knowledge, skills, and abilities around these emerging technologies,

and that'll have a lot of cost savings in my opinion, down the road, and also build better relationships between the cybersecurity compliance people. And then the engineers and developers and so on.

[00:28:49] Ryan Connell: Yeah, that's awesome. Great response. I appreciate that. Hey, before we wrap, anything else you want to share with the audience that's a tip of mind for you?

[00:28:57] Chris Hughes: I don't think so. Like I said, I'm pretty active in the community on LinkedIn. I'm always talking or speaking or writing about something cyber compliance and everything they're in, uh, really passionate about this space and just trying to bring capabilities to warfighters, whether it's, people on the DOD front, making their life better, letting them do their job better, keeping us competitive as a nation.

And then also on the federal civilian side of just providing services that our citizens deserve, honestly, when it comes to technology and, keeping us competitive in that respect too.

[00:29:22] Ryan Connell: Awesome, Chris. Hey, thanks so much for being here today. I appreciate your time.

[00:29:25] Chris Hughes: Thanks. Take care.