Understanding FedRAMP Exception Cases

Cole French:

FedRAMP is, by just about any measure, the most comprehensive cybersecurity compliance framework you’ll find, and for good reason too. It is designed to provide assurance that cybersecurity is properly implemented by cloud service providers providing services to the federal government.

The federal government often means you and me as federal agencies are leveraging cloud resources to carry out their missions which benefit each of us in some way or another. A problem that regularly arises in the compliance world is that of exception cases. How should situations in which a particular issue that cannot be fully addressed be handled? Are there alternative implementations or other workarounds that don’t impede the ability to get an ATO or authorization to operate?

In today’s episode, we’re going to discuss such cases in the world of FedRAMP. In particular, the situations we’re going to discuss are those in which a particular cloud service provider is doing something that would fail to meet one of the FedRAMP controls, but may not be feasibly practical to address in a reasonable timeframe.

This could be for many reasons, but often is because a cloud service provider is using a commercial offering or corporate resource on behalf of their proposed federal offering. While there are no guarantees in getting an exception, we’re going to talk today about how to look at these exception cases and develop a strategy to move forward.

Joining us for today’s conversation is John Santore, who leads Kratos FedRAMP capability and has been successful in navigating these sorts of issues within FedRAMP and across many customer environments and use cases. Welcome to the Cyber Compliance and Beyond Podcast, John. It’s a privilege to have you on today to hear your perspective on FedRAMP exception cases.

Now, for those of you out there working with other compliance frameworks and asking, “What about exceptions for my framework?” Don’t worry, we’re going to branch off and talk about exceptions in the broader compliance world as well. But John, thank you again for joining us. And can you get us going here by talking about why an exception might be needed? And then, give us a couple of an examples of an exception.

John Santore:

Sure. So, first of all, thank you for having me on here, Cole, always a pleasure kind of talking compliance. Whenever you’re dealing with any kind of a system where you’re doing an audit, you’re applying a compliance framework, you’re always going to have weird edge cases that don’t always fit exactly as the control is written or exactly as the control was intended to be written.

And so, to try and get the spirit of the control and to try and get the spirit of having an underlying compliance posture or security posture, you have to look at those on a case-by-case basis. But sometimes, you come across where you’re building a cloud offering and it’s based off of a commercial offering. And so, your organization has baked in old technology that doesn’t necessarily translate to some of the newer requirements, and you don’t want that to be a barrier to getting this out to a particular customer.

So, you’ve got to deal with, “Hey, I know it’s going to take me six months to add this piece because it requires engineering tooling.” Sometimes, particularly in this day and age with new technology, particularly in the cloud, there’s new stuff. So, nobody’s thought about the best way to apply these controls to a new paradigm.

A good example of that, what happens when we start moving to more serverless stuff? So, Lambda functions and AWS, and similar on Azure, there’s a control that talks about inventory. What does an inventory mean when you’ve got a bunch of Lambda functions and not a bunch of servers? What does vulnerability scans mean when you’ve got a bunch of Lambda functions and you don’t have any servers?

And so, you’re breaking new ground. A lot of that stuff isn’t clear. Sometimes, you’re integrating with a third-party and the third-party may not have fixed the flow on their end, so it’s out of your control. What can you do? And so, all of those things come into a situation where for whatever reason, you may have to go down an exception case, and there’s a lot of different ways to do that. So, does that make sense? And any questions there?

Cole French:

Yeah, no, that makes perfect sense. So, what about some examples? Could you give us a real-world example? I guess you’ve seen as to one of these needs for an exception that you’ve discussed. What does it look like in the real world? So, something maybe folks would identify with?

John Santore:

So, one thing that I’ve seen a lot of is, I’m guessing the readership, viewership is familiar where there’s a tool called Jira by Atlassian. And JIRA is largely like an industry leader sort of issue tracking thing. It’s used by a lot of folks for SDLC type bugs features, that kind of thing.

And so, a lot of organizations have Jira baked into their culture. And unfortunately, the cloud-based version of Jira is not yet FedRAMP authorized. So, if you’re trying to use that to track, for example, change records for your FedRAMP environment and you’re using Atlassian Cloud, you’ve got... There’s an issue there.

And so, because it’s so ingrained in your culture, how do you handle that? Is there a way to tweak how you’re doing with Jira? Some particular agency customers may be okay with it because everybody’s familiar with Jira. That one comes up all the time. There’s some nuances to how to use Jira in a way that anonymizes and make sure there’s no sensitive information stored in it. That’s one example.

Sometimes, you come across an encryption thing. So, FedRAMP requires FIPS validated encryption means it needs to align with a NIST test of a given encryption module. So, FIPS 140-2 and it’s moving to 140-3. What if you’re using an old piece of technology or you have to connect to a government customer who’s using old technology and the device on their end isn’t able to run the latest encryption stuff. What do you do in that case? So, I’ve seen both of those cases arise and a lot of them are unique to the service being offered.

Cole French:

Yeah, definitely. Yeah, we’ve seen the encryption example come up in some other frameworks, particularly CMMC, where FIPS 140-2 is a required encryption standard, particularly for any information that may leave the particular boundary that’s being assessed. And yet, that gets into all kinds of tricky things like you just said, most often what we see is vendor dependencies.

So, leveraging a technology like you described that we don’t have any control over that particular technology and how it’s maintained and developed, but it doesn’t comply with the requirements. Going back to your Jira example, so is the reason that it wouldn’t be compliant because of the type of data that’s within Jira? Or is that because it’s not FedRAMP authorized and it’s being leveraged within that environment that’s going to be FedRAMP authorized?

John Santore:

So, FedRAMP has some strict rules about third-party services, and I’m specifically speaking the Atlassian Cloud version. A FedRAMP offering can only use FedRAMP authorized third-party products for anything that contains government data or metadata. And in many cases, the use of Jira is to track change records.

So, hey, we’re going to update this particular system, host one to patch this. Well, now, the fact that we called it host one at IP address whatever is government metadata. So, you have to make sure that if you’re using Jira, there’s a way to sanitize that.

And sometimes, that’s by taking Jira and just saying, “Hey, there’s an issue point to this location where there’s more details with that location in a secure place,” either a FedRAMP authorized third-party repository like a Google Drive or perhaps some mechanism inside the boundary. But yeah, I think one of the big things are either legacy stuff. And Cole, you and I worked on that one project where somebody had a really old database structure that they couldn’t easily migrate.

So, that’s a really great example of one of these things. It was so old that there was patching related stuff, and we had to deal with that in a unique way. We built an enclave around it and we’re absolutely transparent that it was an issue, explained why it needed to be there or what the road map to get out of there was, and what steps we were taking to mitigate that along the way.

Cole French:

Exactly, yeah, I remember that use case and that particular project. And yeah, and also, which we’ll talk more about I think as we get into this a little bit more, but alternative implementations or maybe compensating controls we might call them, right?

John Santore:

Yeah.

Cole French:

So, things we can’t fix, but we can put solutions A, B, and C in place and that mitigates a lot of the risk or issues that may come from not being compliant with the control as it is stated. One other example that kind of comes to my mind, I was wondering if maybe you could talk a little bit about, and that’s container scan findings. And I think we’re going to see this in other compliance frameworks, but I know it’s something we see a lot within FedRAMP and just based on cloud environments in general.

John Santore:

So, container scans are tricky because it’s relatively new. When I say relatively new, I mean, containers have been around a while. FedRAMP has issued guidance on container scanning stuff that’s two or three years old now, I think. But one of the things that’s happened, and this goes to my talk about things that are already ingrained in a corporate environment.

So, we’re building things on third-party container images where you’re pulling them from some third-party repository and using that in your environment. And there’s a lot of vendor dependencies there. There’s a lot of things that are out of your control. I think FedRAMP is maybe changing how they’re looking at that. But right now, one of the things we’re seeing when we’re doing assessments is an uncharacteristically high number of findings associated with containers, and there needs to be ways to address that.

Even I think DoD has got a thing called Iron Bank, which is sort of a container repo. Even those, if you use them, they’ve got to be vetted by the DoD to be an Iron Bank, but if you run a vulnerability scan against that it doesn’t necessarily mean that it’s completely clean.

So, that’s its own unique technological use case because of the third-party container stuff. And in a perfect world, I’d say, “Hey, build your own containers, take these things, vet them as part of your SDLC before you deploy them.” But because that may be so ingrained in the culture or you’ve been doing it so long, that’s not a turn on a dime kind of change. So, you can’t let perfect be the enemy of good and you still want to get a product out there.

Cole French:

Okay, so we’ve talked about why an exception might be needed, and we’ve just discussed several examples of exceptions. So, now why don’t we jump into how do I actually address these exceptions? What is the process? How do I go through this? What do I need to be aware of? What are risks that there may be in play when it comes to putting exceptions together? If you could just talk to how do we actually put together an exception case?

John Santore:

Sure. So, I mean, I think anytime you’re dealing with the government... But I think, in this kind of world since we’re dealing with security, I think this is probably true in general, is always seek permission, not forgiveness. We want to make sure everything is transparent, everything is documented, everything is clear.

So, we’ve analyzed the issue, we know why this is an exception. We know why it’s either difficult to address or what it will take to address. And the more we know about that, the more we can speak to the potential risks associated with those issues. So, you always want to start off being as transparent as possible.

So, that’s sort of the first piece. The second thing is you want to be careful. I’ve seen some folks you’re like, “Oh, I’ll just do this as an exception.” Exceptions should be exact, precisely that an exception, not a... I don’t want to go fix a bunch of things. There should be very few. If you have a whole bunch of them, arguably, did you even try? Did you try to address these or you just didn’t want to go there?

The exception should be truly things that you cannot easily fix for legitimate reasons. Either the technology doesn’t work or it will break something in the actual application or the roadmap to address this is fairly long, and that’s why being transparent and explaining those reasons gives you the ability to address ways to mitigate it and to address concerns. If I read about a risk, any potential government customer may have the opportunity to risk accept that. They’re making an informed choice based off of a clearly defined risk. And I think that’s sort of the first piece there.

So, there’s that piece of it. I think the second aspect is come up with... Sure, we’ve got this exception case, here’s what we think it would take to fix it. Let’s talk this through with our customers, be it FedRAMP, be it an authorizing agency who’s kind of going through the FedRAMP process as sort of the end customer. “Hey, we were in this situation, what can we do to satisfy your risk appetite to make you feel comfortable with this?”

And usually, I recommend a path, if we do A, are you good? If we do B, are you good? Can we declare this an operational requirement? But we expect it’s going to take us six months of engineering time. We’re happy to track this on our issues list. In the FedRAMP world, it’s called a plan of actions and milestones, which POA&M, maybe, maybe one of the top 10 goofiest government acronyms. I don’t know. But...

Cole French:

I would agree with you on that.

John Santore:

POA&Ms, it is. And so, you’re keeping track of it, you’re not burying it. It’s very clear. Anybody who might want to use your system is aware that you’re tracking this as an issue. You’re tracking this as an exception. And you’re consulting with your authorizing agency. You’re talking with FedRAMP.

In some cases, you’re getting input from the vendor. If it’s something that’s a third-party that you can’t deal with. You’re, “Hey, we checked in.” They said they’re expecting a patch in two weeks or whatever. So, I mean, that’s kind of the approach.

There is a formal mechanism in FedRAMP to get something declared an operational requirement. And what that means is, you keep the risk on your POA&M, it’s got its risk rating, you want to put as many mitigating factors as possible there, and that has to be approved by the agency or the JAB or whatever organization, mission owner. In the case of the DoD stuff, they have to approve that.

So, you want to make sure you’ve got a pretty compelling case as to why this isn’t an easy thing to fix or why in the context of what we’re trying to do here. It makes sense to let this hang out there for a little while until we get it addressed.

Cole French:

So, are you saying that an operational requirement or, well, let me back up on that. So, to get an exception, must that particular exception, must the requirement associated with that exception be deemed an operational requirement? Or can you obtain an exception without it also being an operational requirement?

John Santore:

So, operational requirement is kind of the excep... That’s kind of the way they call it exception. So, that’s a nomenclature thing. So, it’s deemed an operational requirement because in order for the system to operate as designed, we need this here, at least in the short-term.

It’s worth mentioning that... And particularly lately, the expectation is in most cases, operational requirements are not supposed to be there in perpetuity. It’s not an excuse to never fix something. So, it can be there for a while as you’re working through it, and while it’s accepted, but every time you’ve got an annual assessment, we want to reevaluate that. Where are we?

It’s one thing to say, “Hey, we can’t fix this in year one.” But if you’re at year five, you could have moved the technology stack or you could have done something else. You’ll laugh if it’s going to be a really long-term thing, you need a really good reason. You can get a little bit of grace in the short-term, but you don’t want things out there for really long periods of time, that came up with a customer recently and negotiating through that now, actually.

Cole French:

Yeah, actually, we often come up upon really just exceptions in general. I mean, we’re talking compliance framework type stuff where this is directly impacting an authorization to operate as it relates to FedRAMP. But in some other frameworks, and I’m sure even in FedRAMP, but getting more down into the weeds, there’s exceptions for user-based exceptions and things like that. And we get that all the time.

And what we always tell customers is, exceptions, it’s not that exceptions are bad or that you can’t put exceptions in place. The real key though, and the hard part with exceptions is, they shouldn’t exist forever, right? There should be a process in place to initiate some review, hopefully, on an annual basis, but perhaps even sooner depending on what the exception is. But yeah, a process in place to review those exceptions and to remove them.

A lot of times, we see stuff where it’s, “Hey, we put this firewall rule in place for some temporary purpose.” And then, it just sits there forever, right? There’s an opening in the firewall that is completely unnecessary after a period of time. So, I think expanding the conversation more broadly when it comes to exceptions, I think you hit a key point there that you got to make sure whatever exceptions you put in place, whether it’s to get an authorization to operate for FedRAMP or it’s some particular use case for a user within your environment, you need to have a process in place to review those exceptions and remove them when they’re no longer necessary.

John Santore:

Yeah, and the FedRAMP POA&M process does in fact have some requirements, particularly if there’s a vendor dependency involved to check in periodically and document that you’ve checked in. But to your point, an exception isn’t necessarily bad, but you want to make sure it’s transparent and documented.

And there’s one other case that I think may come into play here where, and you see this particularly with third-party external services that aren’t necessarily authorized. And Cole, I think you see this in the CMMC world with FedRAMP equivalent, which I’m happy to circle back on. That’s its own kind of animal.

Cole French:

Yup, yup, definitely.

John Santore:

But when you’ve got a third-party solution, I’ll use an example. There’s a lot of times where a service has got an optional component where let’s say you want to integrate with your text messaging and SMS tool like Twilio. As of right now, I don’t believe Twilio is FedRAMP authorized, but it’s not core to the functionality of your application.

So, you can basically document that as a customer optional solution. And that customer, again, transparently documented, can choose to accept the risk and say, “Oh, based on our use case, I’m okay using Twilio for SMS. I don’t have to worry about that being FedRAMP authorized.”

So, there’s a way to push some of this down as a customer responsibility. If you choose to use this disclaimer, disclaimer, disclaimer, recognize that it’s not FedRAMP authorized. And there’s a part of FedRAMP, and I don’t know if you have this in CMMC called the Customer Responsibility Matrix. When you’re using other tools, when you’re using IaaS, here’s what you get from Azure or AWS, and here’s what you’ve got to configure yourself. If you’re on AWS, you don’t have to worry about data center humidity controls and that kind of thing.

And so, whenever you’re doing that, make sure that your customer responsibility matrix for your application clearly outlines what the customers are responsible for, and what the customer choices are in that perspective. If you choose to use this, know that it’s not FedRAMP authorized, it’s optional. You can still use our application without it.

Cole French:

Right. So, is the example you’re citing is, let’s say, I’m a customer and I decide I’m going to use an AWS offering that’s FedRAMP authorized. So, what you’re talking about is, if I’m the customer leveraging this environment, but I also want to use additional tools within that environment, but some of those tools might not be FedRAMP authorized. Are you saying that that’s a risk that as the customer, I’m accepting that risk? But it doesn’t have an impact on the authorization as it relates to the AWS environment that I originally procured before I started using the different applications within the environment? Is my understanding correct there?

John Santore:

Yeah, let me rephrase that a little bit, right? So, let’s pretend I’m the fictional Department of Forestry. There is a forestry service in the US government under Department of Interior, I think. But the Department of Forestry doesn’t exist, so it’s a hypothetical thing.

Let’s say, I’ve got a solution that does tree population analysis, it’s a cloud service. And as the Department of Forestry, I want to use this tool, this cloud service offering, but I also want to be able to have it integrate with some other tool. Let’s use SMS stuff like a Twilio. I want to be able to get text messages that say, “Aha, new trees have arrived in the Pacific Northwest or whatever.” That’s a piece of functionality that I want as the Department of Forestry and is not necessarily something that can be built by the actual vendor.

So, it’s like, “Hey, we can integrate with this thing that you want to integrate with, but it’s not FedRAMP authorized. If you’re okay with it, that’s on you.” So, it is kind of aligning with what are the customer’s desires and features and functionality in the context of the architecture of the service offering.

Cole French:

But it doesn’t impact the FedRAMP authorization...

John Santore:

Correct.

Cole French:

... the original offering though, right? Yeah, okay.

John Santore:

Correct.

Cole French:

That’s what I thought, just wanted to make sure.

John Santore:

I don’t know if I made that more complicated or simpler, but...

Cole French:

No, no, I think stuff like, nuance like that is important to cover and to discuss. I mean, we see... I think that’s one thing honestly, customers don’t think about a lot. They see an environment... They purchase a product, say it’s FedRAMP Authorized, they’re like, “All right, I’m good to go.” But then, they don’t really think about the fact that, well, I want to use these 10 to 15 different applications or services that this cloud service provider also offers. But that doesn’t necessarily mean something to keep in mind.

I think even more broadly to what you’re saying, John, is just because the base environment that I purchased as FedRAMP Authorized does not mean all of the products that come with it or applications that I can leverage inside of there are also FedRAMP authorized.

And I think, we can maybe come back to the FedRAMP equivalency thing as it relates to the CMMC, but that is especially important right now, at least from a CMMC perspective, is making sure that everything you are leveraging in a cloud, or sorry, in a FedRAMP authorized environment is also FedRAMP authorized. Because if it’s not, then you run into the FedRAMP equivalency issue.

John Santore:

Yeah. I mean, a really good example of that and why this comes up, and hopefully, we’re not belaboring the point here. But a lot of people are building an offering based off of an existing commercial thing. And so, I’ve got a cool product like widget.com and I’m selling to everybody, just commercial companies, whatever. And now, I realized that Department of Forestry wants to take widget.com and use it for the government.

So, they need to get FedRAMP authorization, and we’re going to build a new federal instance of widget.com, and here’s the parameters around that. And oh, something cool got released into the commercial version that for reasons due to technology controls and restrictions, we can’t put in the federal environment unless it becomes an optional thing where a customer can choose to do it.

So, it’s really the commercial versus a federal offering, federal instance really comes into play with feature sets and that kind of thing. That’s probably the best way I see that.

Cole French:

Yeah, and we get that question a lot, the commercial versus government. And definitely, I think on the FedRAMP side it’s a little different, but when we’re talking things like CMMC where it’s exclusively federal, it gets a little bit trickier. So...

John Santore:

Why I had a question there. So, how do you handle government versus government adjacent organizations? So, it’s one thing to work for the Department of Forestry, it’s another thing to work for a defense contractor and perhaps such as Kratos who is doing things under with government contracts, but isn’t themselves a government entity? How does that apply in a CMMC sense?

Cole French:

Yeah, good question. So, really at least, and we’ll keep the conversation here to FedRAMP, but it all comes down to what happens with the government data. So, with CMMC, it’s federal contract information, FCI, and then CUI or Controlled Unclassified Information. Those are kind of the two information designations that we’re most concerned with protecting. And those are considered to be government data for the most part, we’ll save the definitions and all that. That’s kind of outside the scope of what we’re talking about here. But FCI, CUI, we want to protect those two types of information. The FCI, less stringently, the CUI, more stringently. So, for leveraging a FedRAMP environment, it is required per the DFARS clauses that come in federal contracts that organizations like Kratos are performing work on behalf of the DoD.

In those contracts, there’s language that requires what’s called FedRAMP Equivalency, which for a long time had not been really defined. It was FedRAMP Moderate Authorized or Equivalent. And earlier this year, there was a memo released the FedRAMP Equivalency memo that defined what FedRAMP Moderate Equivalent means.

So, really, if you’re an organization, a private commercial organization providing services to the federal government via a contract specifically with the DoD, and you’re working with either FCI or CUI and you’re thinking, “I want to leverage FedRAMP environments or FedRAMP services,” it needs to be FedRAMP Moderate or Authorized or higher.

So, not FedRAMP ready. And John, you can jump in a little bit more on this. But FedRAMP Moderate, Authorized or higher, or it can undergo a three PAO assessment, which basically means the environment would be assessed by a third-party assessment organization.

John Santore:

Such as us, such as us.

Cole French:

Yup, such as Kratos. And essentially, we would assess the environment just like you would assess it for FedRAMP authorization. And then, the results of that 3PAO assessment would then be submitted to and reviewed by the DIBCAC, which is DoD’s auditing organization. And then, there would be a go, no-go decision as to whether that particular cloud service offering as used within the boundary that’s been defined would be considered FedRAMP equivalent, and then it would be approved to be used for that particular use case or for delivering the services on that particular contract.

John Santore:

So, is that based off of the January memo? I’ve seen that, and I know on the FedRAMP side, what does it mean to be FedRAMP equivalent? And it talks about no operational POA&M items. I don’t know if it calls POA&M or findings, but...

Cole French:

Yeah, yeah.

John Santore:

You can have scan findings, but you can’t have control findings. It has to be totally clean, but I don’t recall the discussion that the DIBCAC had to approve that, which is interesting, like you and I need to take that offline.

Cole French:

Yeah, and as far as whether that’s in the memo or not, I don’t recall right off hand, but we did have a particular service provider recently, had their product go through a 3PAO FedRAMP Equivalency assessment. And what we were told was, they went through the assessment. And then, the DoD or the DIBCAC reviewed all of the materials that came out of that 3PAO assessment. And essentially, signed off on that particular product and service offering as being FedRAMP equivalent. I don’t know if the memo, if that requirement for the DIBCAC review was part of the memo’s requirements. I would definitely need to look back. I need to double check.

John Santore:

I’m pretty sure it isn’t. But yeah, double check.

Cole French:

Yeah, but it may be in this case just that the DoD may have been using that particular product. I’m not really sure. But I just felt like it was good to point it out because always something good to keep in mind when you’re going through stuff like this, and as a commercial organization and thinking about what products or what cloud products to leverage, just know that if you make a decision to not use FedRAMP Moderate, Authorized or higher products and services, you’re definitely opening yourself up to... And John, maybe you can speak to a 3PAO Equivalency assessment. And the bar, from what I understand is much higher, and you may be subject to DoD actually, reviewing that package and signing off on it as well, which is another layer of scrutiny and could cause delays, et cetera, et cetera.

John Santore:

Yeah. So, and for those who may be more familiar with SOC 2, this is kind of like a subservice organization review. You’ve got a subservice third-party, CMMC. It’s got to be either CMMC good or CMMC good(33:48). It’s got to be either FedRAMP authorized or deemed FedRAMP Equivalent because FedRAMP Equivalent hadn’t necessarily been defined until this memo that we’re talking about. It was not entirely clear what that meant.

And it looks like the memo sort of said, you can have... This is my take on it. You can have operational findings, but you cannot have control findings, which is a hard threshold because it doesn’t really give you the ability to throw things on a POA&M from a control perspective, which you can do in a traditional FedRAMP assessment.

And the traditional FedRAMP agency review process doesn’t apply to FedRAMP Equivalent. And as Cole said, maybe that’s a DIBCAC review or a DoD review. So, watch this space. It’s not entirely clear how that’s going to be long term, but this seems to be the initial foray into that.

Cole French:

Yup, yup.

John Santore:

Should we nudge ourselves back onto safe ground here?

Cole French:

Yup, yeah, I was just about to kind of steer us back. But I was able to pull up the memo, and we’ll obviously drop a link to the memo in the show notes, but it does appear as though a FedRAMP Moderate Equivalency assessment is subject. The body of evidence out of that assessment is subject to review by the DIBCAC, including any annual assessment or annual review of that package. So, yes, it does appear as though DoD or DIBCAC’s review of that package for a 3PAO equivalency assessment is required or could take place. I guess they could choose, to accept it on its phase.

John Santore:

There’s a difference. Yeah, because I’ve heard some quirky things where, again, we’re completely sidetracked. Sorry folks. The customer consuming the FedRAMP Equivalency thing wanted to see the body of evidence, and then there was issues with sharing CUI with a non-government thing. But if it’s at the DIBCAC... The DIBCAC has now just signed up to do apparently FedRAMP reviews. Happy days. Good luck guys.

Cole French:

It would appear. So, as you said, we kind of sidetracked there, But kind of jumping back to what we were talking about, so exceptions in the FedRAMP world.

So, we’ve talked about the type or what cases there might be for an exception, some examples of exceptions, and we’ve talked about agency risk, things like that. So, I know within FedRAMP there is the joint authorization board, and then there’s also the agency. Can you talk a little bit about, I know that you can get an authorization from either the JAB or an agency? Is there a different... Is risk tolerance different with either of those organizations?

John Santore:

So, let me preface this by saying the JAB as it exists in its current form, is likely to change with the OMB memo regarding FedRAMP governance. So, some of those details have yet to be hashed out. But the gist was, if you are a single agency, any single agency can choose what risk to accept. And we use that in some of the earlier examples where there is a multiple agency, be it a JAB or somebody on behalf of other agencies like the FedRAMP. The expectation is, we’re not going to accept any risk because we’re speaking for multiple agencies. And so, the threshold is a little bit higher there.

And so, again, when you’re dealing with an organization such as the JAB or whatever’s going to replace it, whenever you’ve got these exception cases, you talk to them and figure out, “Hey, what is acceptable at that higher threshold? Hey, JAB...” I’ll use the term JAB just because they’re still around for now. But “Hey, JAB, here’s this weird use case, are you good with allowing this as an operational requirement? If you’ve got some things that need to happen, what do those steps need to be? How long do we have to comply with them? Here’s our roadmap” and work with them to get their take on it because they’re speaking on behalf of multiple agencies.

So, again, it does get a little bit trickier there. An individual agency can say, “Yeah, I don’t care that’re using Jira.” Or technically, they’re not supposed to say, “I don’t care that you’re not using FIPS-validated encryption. But arguably, they could.”

Cole French:

So, to summarize then, the JAB is less likely to accept operational requirements while agencies may have more of an appetite for operational requirements, since in theory, they’re sponsoring this particular cloud service offering for authorization. So, they have really a vested interest in getting that authorization. Would that be a fair summarization?

John Santore:

Yeah. So, if you’ve got an agency, they already want to be a customer if they’re a sponsor, right? Whereas, the JAB is kind of taking a neutral view, not at an individual agency’s needs, wants or desires and saying, “Hey, you’ve got to satisfy this threshold.” And so, yeah, it’s stricter at the JAB level for precisely that reason. They don’t want to accept risk on behalf of somebody else who may not agree to it basically.

Cole French:

one other thing I kind of wanted to talk about that you and I had talked about offline, and that was this weird use case, new technology, new problem. So, it’s kind like this exception adjacent concept. Could you dive into that?

John Santore:

Oh, yes. So, a lot of these controls were derived from years ago where technology used to be hubs before there were switches and plug into the wall jack in the office instead of wireless. And so, there are residual things of that all throughout security in general, but the NIST controls in particular, what happens if you’re doing something new and the controls don’t speak to them? That’s a case I think I used earlier where if you’re using a serverless environment and we’re starting to see some of these things emerge, what is deemed to be acceptable in the context of controls that are looking at vulnerability scans or baselines or anti-malware, anti-malware even apply to a serverless type environment?

And I think for all of those, there’s nuances there. You want to make sure that you’re not getting dinged on a control that doesn’t apply because you’re doing something in a non-traditional sense. So, again, you document it. Maybe, if you’re going to say that it’s not applicable, you want to justify why it’s not applicable. If you’ve got an alternate implementation, you kind of talk about it from that perspective... I’ll give you another example. This kind of falls into the same thing.

I’ve seen a couple of cloud providers where they’re not building code at all. They’re aggregating a bunch of third-party products and putting it together in a sandbox to provide a customer the ability to use a bunch of related tools, so that each customer doesn’t have to go out and buy licenses for 16 different things. They can come here and use all of them.

So, they’re not developing code at all. So, all of the software development lifecycle-related SA controls, system and services acquisition don’t apply the same way because they don’t have developers following development at all.

Cole French:

Right.

John Santore:

It’s more... We we’re taking product A, product B, product C, putting this in an environment, so you as a customer can use all three of them, and we’re handling all the license pass-through stuff. So, again, what do you do? It looks like that control doesn’t apply, does it? Does it not? And those are the things you want to make sure you’re very explicit in how you document, so that anybody looking at it doesn’t feel like it’s been glossed over.

It’s exactly clear what’s happening, here’s why this isn’t relevant. And you want to have an open dialogue with FedRAMP or the agency because you say, “Why aren’t you doing dynamic code analysis?” Well, there’s no code and here’s why. And because here’s what we’re doing with our environment. We’re integrating these three products, that kind of thing.

Cole French:

But it may be on a customer to do dynamic code analysis, the customer who’s using that environment and doing development within that environment, right?

John Santore:

If they’re using those tools for development, sure. If they’re using those tools for something else, let’s say, you’ve got a suite of medical things. Here’s the thing to check blood sugar. Here’s the thing to do this. There may be anything custom whatsoever. It’s this reference library and this reference library and this blood sugar analysis thing all stuck together. There may be nothing custom at all. It just allows you to use the entire suite of controls.

Again, weird use cases. I saw another situation where sort of like a high-performance computing situation with parallel nodes, and if you added the overhead of encryption, the high-performance would take such a hit. So, what do you do there? Do you build an enclave? There’s a bunch of different ways that you can deal with that, but it’s a unique situation where how do you protect it without encryption? Is that an exception? Is that an alternate implementation? Kind of drill into those, is the same. Document them, get them in front of the agency and talk through the risks and concerns and mitigate around that.

And maybe, there’s a way to do something that ultimately the agency FedRAMP, whoever is comfortable with from a risk acceptance perspective. Hey, whatever you’re doing is makes sense and satisfies our risk posture.

Cole French:

The serverless environment is particularly interesting to me. I know, again, speaking from a CMMC standpoint, but I know most compliance frameworks, you’re doing your compliance efforts against a particular inventory or asset inventory, and that’s a key component. But if you’re working in a serverless environment, that’s really interesting to think about, right? Because how do I... And especially, like CMMC, it’s data. It’s all about the data. It’s confidentiality of the data.

Well, if cobbling together an inventory is tricky because I’m using serverless environments, then how do I actually prove my data is where I say it is? I see how that could be very, very problematic when pursuing compliance against all these frameworks, really.

John Santore:

Yeah, no, I mean, if you look at... Let’s take a step, go back in time, historical thing. One of the areas where inventory had to change was what happens when you have a lot of autoscaling or ephemeral systems? So, I know I’m going to have a host of type X. I may have one of them, I may have 20 of them. From an inventory perspective, do I care that there’s however many, 16, 17, 20? Or do I only care that I know that there’s a component of type X and I vetted all of my security hardening on that type, and I know that if that type spins up more or less, you’re good.

And so, when that first became a thing, it was a little bit tricky to figure out some of the nuance. So, I think serverless will have kind of the same thing. In that particular case, the way I’ve always looked at it is unique images regardless of how many there are. I care that each of the unique images or host types have been hardened and scanned and tested and what have you.

Cole French:

That’s a good summary.

John Santore:

Cool.

Cole French:

And speaking of summaries, we’ve talked through a lot of specifics. We’ve gone in the weeds a little bit and given some good examples. So, just for our listeners out there, I think looking for strategic approaches to exception cases, could you just quickly summarize like four bullets, four or five bullet points, what needs to happen if there is a need for an exception? What do I need to do? What are the things I need to do to get that exception approved as an requirement?

John Santore:

Right. So, you want to be very clear in what’s going on. So, transparently document, the what, the why, the how. In particular, what data is being addressed by it? Do you want to explain what it would take to migrate off? Or why you can’t migrate off? You want to address how you’re mitigating any risks associated with that. And ultimately, get approval for this.

And there’s some give and take there. Just remember that some things are harder to do, but doable. And so, that’s where you’ve got that sort of, “Hey, I can do this, but I can’t do it tomorrow. I can do it in six months.” So, take that into account. You also generally don’t want to have things that are sitting around in perpetuity because at some point you can phase off the old operating systems or whatever because you shouldn’t be running things that are really, really old necessarily. Or when you do like, Cole, we had that one example. You have to deal with that in its own sort of way.

Cole French:

Yeah, yeah. That’s the kind of compensating control, you need to put other implementations in place to support securing that environment that can’t or requires an exception, I should say.

Well, thank you for the summary there. We’ll make sure to drop those items in the show notes, so that folks out there can refer to them when thinking about exceptions. And I think to be quite honest, any kind of exception, I mean, I know we’re talking specifically about FedRAMP, but really any exception, any security exception you’re looking to put in place, whether that’s organizational or in a FedRAMP context, I think those steps that John just outlined are relevant.

So, as we wrap things up here, John, the exception case always gets me thinking, exceptions are a reminder that security and compliance are hard. And because they’re hard, there’s a default mentality kind of a checking the box. I don’t want to figure out how do I check the box on this and just move on from it.

So, again, as we wrap up, I just wanted to open it up and offer you the opportunity to share some thoughts on where do you see us, how do you see us moving away from a culture of checking the box and moving more toward a security or toward a culture of doing security really well?

John Santore:

A couple of things here, and there’s obviously my opinion and a philosophical discussion. But compliance in a way is somebody certifying that you satisfy a set of requirements, and it’s almost marketing in a sense. You can’t use anything with credit cards unless PCI came in. Or you don’t want to go use a toaster at home unless Underwriter Labs certified it or the Good Housekeeping seal of approval.

FedRAMP is the same thing, right? It’s a seal of approval that the government can use it. What that’s saying is not that you are necessarily secure or bulletproof, it’s that you have a mature process in place. You’re doing the right things. You’re trying to keep it as secure as possible, but in the event that something happens, your organization has the processes in place to react to them.

So, it’s a maturity level more than it is a bulletproof scenario. And so, whenever you’re dealing with checking the box, sometimes you need to do that to get that seal of approval. But you always want to look at the big picture, what are we trying to do here? We want to do the right thing for the right reasons, which is protecting risk, protecting the data, protecting whatever it is that we’re there entrusted with to keep it as safe as possible within the parameters of how safe it is.

Obviously, missile keys are a lot different than tree inventory is my example with the Department of Forestry. So, make sure that that security is commensurate with the risk and the value of the assets. But look at it that way, it’s a maturity thing, which is overarchingly covering. We’ve got processes to address things if things happen.

Cole French:

And I think important to what you were just saying, we’re identifying risks, right? We’re looking at all the different things that are in front of us in our environment, in our use cases, our customers, all the different things. We’re taking all of that into account, and we’re identifying what the risks are associated with them. And then, that’s how we build or we can build maturity on its own to stand on its own, but then we mold that maturity to match the risks that are in play in our environment.

And I think that’s exactly, I think we do. We look at it from a secure perspective. We want to lock things down, and I think that’s valuable that that’s a tool. But I agree, maturity is where we really want to get as organizations. We want to drive towards having firm, risk-informed processes in place that drive the different activities that we do that are informed by what the risk is to us.

And then, that mature process and that mature assessment of risk will actually drive us more towards security within, I think, the space that we’re in versus just a, here’s my checklist of things. I’m going to run through that checklist, check each of them off, and then I’m good to go. And I think CMMC is going, that’s really the intent of CMMC, particularly CMMC 1.0.

For those of you out there who’ve worked in the CMMC space, you’ll know what I’m referring to. But the CMMC 1.0 framework actually, had controls around resource planning and policy and procedure for every single control family, and we went away from some of that in CMMC 2.0. But there is still... We’re still trying to come at it from a maturity perspective. We’re looking at what is your process less? What is that one thing or two things that you’ve done? We’re looking at, do you have a process in place, so that you’re maintaining this implementation, whatever it is over time?

John Santore:

Yeah. And are you... It’s not necessarily just what you do, but how you do it. And there’s never any guarantee that there won’t be a security event. But hopefully, if there is a security event, you know how to address it as quickly as possible. So, it’s managing... It’s mobilizing your forces to manage that risk, to contain it and isolate it and minimize it, and all the things associated with that, and inform all the people that need to be informed. It’s responses as well as...

Cole French:

Yup, I think that’s a great summary, John. And I think that’s a good sort of period to put on this particular episode. So, I appreciate you again for taking the time to join us on the Cyber Compliance and Beyond podcast today. We’re grateful for your perspective really on this particular topic, the FedRAMP exception case. But also, really just your perspective and thoughts on really compliance as a whole. So, thanks again, I appreciate your time.

Thank you to all of you out there for joining us for today’s episode. The Cyber Compliance and Beyond podcast is dedicated to answering as many unanswered questions as we can. If you have a question you’d like answered or you’d like to offer some feedback, we’d love to hear from you. You can find us on Twitter and LinkedIn at Kratos Defense, or you can shoot us an email at ccbeyond@kratosdefense.com.

Be sure to check out the show notes for additional material related to today’s episode. We hope you’ll join us again for our next episode. Until then, keep building security into the fabric of what you do.