AUTOMATING NIST RISK MANAGEMENT FRAMEWORK WITH REBECCA ONUSKANICH

Kip Boyle:                          
Hi, everybody. Welcome to Your Cyber Path. I’m Kip Boyle. Today, I’m here actually without Jason Dion, who is typically here to share what he knows with you, but he’s taking a well-deserved vacation. We’re pressing on with the next episode. This is episode 83. The working title is Automating the NIST Risk Management Framework.

We’ve got a guest who actually works with the risk management framework a lot, and has some insider knowledge on a particular tool that advertises itself as a way of automating the risk management framework. Her name is Rebecca Onuskanich. I hope to heck I said that right, Rebecca. Welcome. We’re so glad you’re here. Would you please tell the audience a little bit about yourself and the work that you do?

Rebecca Onuskanich:    
Hey. Thanks, Kip. Thanks for having me. As you mentioned, I do work with the risk management framework. Particularly, at this point in time, I’m working specifically in the Department of Defense. Most of my work is the Department of Defense’s interpretation of the RMF process. I have worked in the federal agencies for quite a bit of years, but now I’m back in the DOD.

I started working in this space long before it was ever called the RMF process. I’ve been in DOD security compliance and information assurance for well over 20 years. I’ve seen it transition from very much paper work process to where we’re getting to this point of trying to automate the security configuration and compliance requirements.

Kip Boyle:                        
Again, I’m really happy you’re here, because you’re bringing a real depth of expertise to this topic for the benefit of our audience. I recall my first experiences working in this space, when I was on active duty in the Air Force. Let’s just say it was primitive compared to what we’re attempting to do now. Well, listen, everybody. As a reminder, we’ve covered what RMF is in depth back in episode 80.

I’m going to do a quick recap, but if you want to really go into RMF, as far as what it is and what does it require, I really encourage you to go back to episode 80 and listen to that. Just to give you a thumbnail sketch, in case you haven’t listened to that episode, or it’s been a while. RMF provides a process that integrates security, privacy, and cyber supply chain risk management activities all into a systems development life cycle.

There’s seven steps in the process. I’ll recap them now. Rebecca, you can chime in and tell me if I get any of this wrong, because I know you have more experience with it than I do. The first step is you have to prepare your organization to manage security and privacy risk. The second step is you have to categorize your system and the information that it processes, stores, and transmits.

The third step is you’ve got to get into NIST Special Publication 800-53, which is a catalog of controls. You have to select the ones that are going to help you reduce risk. Step number four is you implement the controls and you document how they’re deployed. Step number five is you assess to determine if the controls are in place, that they’re operating as they’re supposed to, and that you’re getting the correct results from them.

Step number six is a senior official then is asked to make a risk-based decision to authorize the system to operate, to become a production system. And then, the seventh step is to continuously monitor the implementation of your controls, and to make sure that the risks to your system stay reasonable. What do you think, Rebecca? Was that an okay summary?

Rebecca Onuskanich:    
That was perfect. Yes.

Kip Boyle:                        
Great. All right. Now, what I want to do is, I want to really get into the essence of this episode, which is to talk about using a particular tool to automate some of this work. Because there’s a lot to do here.

When we were doing pre-show prep, Rebecca was saying to me, “Kip, this tool called eMASS, it probably doesn’t automate as much as people might think,” which was surprising to me. I haven’t used eMASS, but Rebecca, I was hoping you could unpack that a little bit and tell people … What does that mean?

Rebecca Onuskanich:
EMASS does definitely support the framework in walking through the actual RMF process. You can do things like … When you put your system into eMASS, once you have a hardware list and a software list and you do your Nessus vulnerability scanners, you do your security technical implementation guide or your STIG checklist. You can import that data into eMASS, and then it will correlate those findings.

Let’s say that you run an ACAS scan and there is a vulnerability associated with the software or a piece of hardware. It will associate that security control with that piece of software as a non-compliant item, but it’s not going to actually do things like write all of your security documentation for you on how you do identification and authentication. You’ve actually got to do that work to put it into eMASS.

Kip Boyle:                           
I see. Maybe eMASS would be better characterized as a data store? Just a way to organize yourself. Do you think that’s a more accurate description of what it does?

Rebecca Onuskanich:      
It does definitely keep all of your data, all of your system identification information. You do security categorization in there. When we’re talking step one, preparing, that’s when we build our system in eMASS … Or step zero, prepare it. Step one, we start to look at actually getting our team together.

That’s when we assign all of the individuals in eMASS. And then, we add things like our system name. Start looking at, “What version are we working on? What network is it going on?” And then, when we move into that categorization phase, eMASS does a very good job of helping us categorize our system based on the NIST Special Publication 800-60 Volume II. And then, we select our security controls from there.

Kip Boyle:                          
Okay, “eMASS is helpful,” is my takeaway from this part of our conversation. And so, it’s worth us spending some more time on the episode now to understand it a little bit better. I suppose I should probably stop at this point and tell people that eMASS is an acronym. It actually stands for Enterprise Mission Assurance Support Service.

I’m sure, Rebecca, you probably have other names for it. Probably, in frustration. But I think that’s the proper name. Let’s talk about how you use RMF in your work before we really start talking about eMASS. My understanding is RMF and eMASS are a one-size-fits-all sort of thing, but not everybody’s doing the same kind of work at the same scale. How do you use RMF? Let’s start there.

Rebecca Onuskanich:      
I come from a tactical world. I come from, “We’ve got a mission coming up. It starts on Sunday. We have to get a system authorized and out to the field for a military user.” And so, when we use RMF in that process, it’s much more agile. It’s how to be adapted to be flexible. And it’s all mission-focused.

When we start looking at system categorization, it’s more based, not only just around confidentiality, integrity, and availability, but we are also looking at the mission aspect of that. When you start thinking about things like weapon systems, IoT, you have very unique requirements in those systems, where they can’t necessarily implement what would be selected from a baseline categorization from a CIA perspective. That’s when tailoring comes in.

Tailoring is a key part of the control selection process that … In my experience, a lot of people forget that RMF is a framework that is to be adapted by organizations. And it provides the executive leadership in those organizations to make decisions on how they’re going to adapt that framework for their systems and their missions. That’s really what’s left out a lot in the DOD’s implementation and interpretation of the RMF.

Kip Boyle:                          
Is this tailoring aspect that people are expected to adapt the RMF to their specific situation? Is that right?

Rebecca Onuskanich:  
That’s correct. Yes.

Kip Boyle:                          
I would think that especially newer people to RMF would actually find that maybe a little bit intimidating. Or maybe a little bit like scary. Because it’s like, “No. I want a checklist. What do you mean it’s not a checklist?” Do you think that’s part of maybe what’s going on?

Rebecca Onuskanich:    
Like you, I was Air Force before I enlisted. Everything is standard operating feature. A TTP. We follow a checklist. You don’t deviate from the checklist, because there’s safety concerns. There’s machine concerns.

When we talk cyber security and RMF and it being such an interpretable process, it’s very difficult for us to adapt our mindset. To be able to say, “Wait. We can actually critically think about the system design aspects, the security requirements, the mission, the users.”

Put all that together and as a team, sit down and decide, “What is the tailoring aspects of the system? The baseline in the tailored controls?” And then, get that authorizing official or that AO’s buy-in very early, so we design the system where it’s not over-engineered from a security perspective, but it’s also protecting the data, the users, and the mission.

Kip Boyle:                          
Do you think there’s a risk, as people try to tailor RMF for their situation, that they might make some big mistakes? As far as they might leave things out that they really shouldn’t leave out? Is there a lot of risk that people are really going to mess up the tailoring?

Rebecca Onuskanich:      
Yes. Tailoring is one of those things. And that’s why we have such a hard time with it. The DOD. I have seen instances where things have been tailored out that actually increase the risk to the user on the system. That has to be sent to the authorizing official to help make that determination, because there is a cost to all this. Especially, as someone who’s worked as a security manager or a security engineer.

We all think costs. We all think budget. We all think schedules. That’s where we’re having a pretty large disconnect in the DOD. We have our main area of expertise and our focus. We’re concerned on securing data, connections, users. Cost and schedules? That’s program managers. That’s the program office. That’s not our concern. And that’s where we really start to disconnect in the DOD.

Kip Boyle:                          
Okay. This is so helpful. I think for anybody who hasn’t worked with RMF for very long, or maybe they have, and they just find it really frustrating … I would hope this conversation would be really helpful to them. To get them grounded on how you actually do this stuff.

I’m interested though, Rebecca. Would you tell us how you got into RMF? Where did RMF start for you? Because to your point, you started doing this work before RMF came along. How did you and RMF meet?

Rebecca Onuskanich:      
I was actually military intelligence and I took an assignment networking for central command. I got into it when it was still called information insurance. Before the cybersecurity terminology.

Kip Boyle:                          
I remember that.

Rebecca Onuskanich:      
Yes. Back in the pre-DITSCAP, then DITSCAP, and then DIACAP days … Actually, I got into RMF when I separated from the Air Force and started working for the federal agencies. And so, they were already following the 800-37 framework at that time.

And so, I had to learn their process and how they do things. And then, once I learned that and the DOD switched to the 8510.01 under the RMF, I started getting a lot more clients who were selling to the DOD, who needed to understand this new RMF process and how to secure and sell to the Department of Defense.

Kip Boyle:                          
That’s another interesting story that I would love to talk with you about. Probably, not during the episode today. But I think what you said is that you’re actually a business owner. You launched your own company in order to help, but from a civilian point of view. Is that right?

Rebecca Onuskanich:  
That’s correct. Yes.

Kip Boyle:                          
You know what? I don’t see a lot of people who leave the military who start their own businesses. I think that’s a fairly uncommon thing. That’s what I did eventually, but it took me a while to get there. I just want to congratulate you for taking the road less traveled. I just think it’s really cool.

Rebecca Onuskanich:
Thanks.

Kip Boyle:                        
You’re welcome. Let’s move on. Let’s continue to unpack this. How does RMF work in the real world? I think a big part of that is something you said earlier, which is, “Well, we’ve got RMF. It’s documented. We have to tailor it, but it’s kind of a one-size-fits-all thing.” It doesn’t really anticipate every use case. How do you actually use it? How do you make the best use of it given that it’s such a slippery thing?

Rebecca Onuskanich:  
Right now, I’m in a situation that I am actually starting to help the acquisition community. The acquisition community puts on government contracts the requirements for security. Typically, in the past, you’d have to comply with the DoDI 8510.01. Okay. A very large assumption is made there. That anyone even understands the instruction to begin with, and then how to interpret it, how to select their baseline, and then tailor it.

What we’ve been working on recently is developing acquisition language, so that when something gets put on contracts, the contractor, the integrator, developer, municipal business like me … I understand exactly what I’m selling to the government. Something as simple as encryption type that I have to build into software can vastly change the cost.

If I have to bring in someone that understands a Type 2 encryptor versus a FIPS 140 encryption mechanism … The cost of that type of engineer varies significantly. The amount of time it’ll take to develop. Actually, getting into the acquisition cycle is going to be key to actually being able to implement RMF directly across the DOD.

Right now, there’s a lot of … I don’t want to say, “Animosity,” but there is quite a bit of frustration with the RMF process in the DOD. I really think that’s because when it was rolled out, the way it was trained to all of the security managers, it was very much checklist mentality. “Let’s categorize the system.” No real tailoring was implemented. And it was a very rigid interpretation of the framework.

Kip Boyle:                          
We’re kind of our own worst enemies. Going back to a previous part of our conversation, where we were talking about how necessary it is to tailor it, but the dominant culture is to not do that. The dominant culture is to be very rigid and to follow checklists.

What I’m hearing you say is, “That’s actually how they trained us to do it,” which is not very enabling of the intent. I could see a lot of people would be frustrated by that. For sure. Is that how you were trained? How did you work through that to be able to use RMF the way it was intended versus the way you were trained?

Rebecca Onuskanich:      
For me, I think it was my leadership and the fact that I come from a tactical environment. It was fast-moving. Our leadership all the way up the chain understood that security is a priority, but also mission effectiveness is a higher priority. Trying to balance those two things, we were able to have those very open conversations as to, “That’s fine. We don’t have time to acquire this encryption that we need.”

Or, “We don’t have time to implement this AV solution.” And if you want to field it, that’s a risk. Then, we have to understand, “What are the consequences of those risks?” And so, having the leadership in place that understood that we could make these straight-offs, but we needed to understand what we were trading on. To ensure that we are doing our due diligence to protect the data, the users, and the missions.

Kip Boyle:                          
In other words, my interpretation of what you just said is, “Well, I went and got this training on RMF. And then, I went to the real world.” The real world said, “You have to do things a little differently.” Because real world, we’ve got to balance all these competing priorities. At the end of the day, we’ve got to accomplish the mission. Whatever that takes.

And so, those are the real world trade-offs that a person has to make. Maybe something that I would say to people is, if you’re learning RMF, or maybe you’ve already been through the training and you’re struggling with it … What I’m hearing is, “Lean into the reality of the situation that you’re in and draw what you can from RM, but don’t be such a slave to RMF that you can’t get your mission accomplished.” Is that a reasonable way to summarize what you were saying?

Rebecca Onuskanich:    
Yes. It is. The one thing I’m always very adamant about telling people is, “Make sure you’re truthful.” Even when you’re putting together your security plan. If you’re not doing something, annotate it in there. Document it. Be truthful. Do a risk analysis on it.

Determine what risks that brings to the system and what are some of mitigations that could be put into place. And then, document all of that, so you can communicate that up to leadership. Because as you mentioned earlier, that authorizing official has to sign off on it. They need to actually understand the reality of the situation. Not a clouded view.

Kip Boyle:                          
And it’s not reasonable to expect an authorizing official to really even understand RMF. Is it?

Rebecca Onuskanich:      
Yes. A part of their training … Being an authorizing official, they’re supposed to actually take training in the RMF process. Those that I have worked with recently are pretty aware of the process and frustrated with it, because it is holding up some progress. It is making the system development life cycle take longer.

Kip Boyle:                          
Okay.

Rebecca Onuskanich:  
From my experience, all that hold up is in the middle tier. It’s all of those middle … The leadership, they want to be able to make those decisions quickly. They want to be able to move quickly, but we’re holding it up in the middle with this whole checklist mentality problem we’re having.

Kip Boyle:                          
Right. You’d mentioned that before. Now, in DOD anyway … You had told me previously, when we were talking about the episode here, we were doing our preparations. You said the DOD has some initiatives to try and address these issues and to actually revise RMF. What are you seeing?

Rebecca Onuskanich:  
We’re seeing what’s called RMF 2.0. We’re seeing the Fast Track RMF. Or Fast Track ATO. We’re seeing Continuous ATO. Depending on where you’re at in the DOD, it’s being called a different name.

But really, to peel all of the layers to it … What it means is, do very good system security engineering, design systems that can be continuously monitored, monitor those systems, monitor the risk, continue to report that risk up. And then, your ATO should continue to flow.

Kip Boyle:                          
Now, let’s define that term for a moment. ATO. Because I don’t think we’ve defined it yet, but we’ve been using it. What’s ATO?

Rebecca Onuskanich:    
Your ATO is your authorization to operate. For the DOD, it’s what allows you to take a system and actually use it as a DOD entity. Whether that’s a standalone system or it’s connected to some type of network or cloud environment.

Kip Boyle:                          
Got it. Do you have an opinion of your own, as far as RMF 2.0, Fast Track ATO, Continuous ATO? Do you think that they’re headed in the right direction, in terms of addressing what the real issue is with RMF and making it more useful?

Rebecca Onuskanich:      
Any steps for an improvement are helpful. Obviously, some of those processes have a subset of controls in the beginning that are implemented. And then, as you move through your ATO process, you implement more and more security controls. But really, a lot of that should have been done in the development life cycle.

We’re developing software for a system that has multiple pieces of software. We should have already done most of that. I think the initiatives are good. I don’t think they’re the final deal that’ll get us to where we need to be. I honestly believe that a lot of it is coming down to the training.

Kip Boyle:                          
That’s really interesting. Again, it’s not that RMF itself is so much of an issue. It’s just the culture. The institution trying to evolve itself to this more flexible approach. Well, that’s fascinating. Hopefully, with time, maybe these two things will meet in the middle. RMF will change a little bit and the culture will change a little bit, and we’ll be able to get someplace.

One thing that I was curious about. This is a little off the cuff question here to you, but I’ve been thinking about the difference between RMF and the NIST Cybersecurity Framework. Some people have said to me, “Well, actually, they’re complimentary.” And I think to myself, “Well, they’re definitely different.”

And so, I suppose they could be complimentary. Whereas, RMF is focused on the development life cycle and the cybersecurity framework is really more about an incident orientation. Do you think that the NIST Cybersecurity Framework would be a good way to do step seven? The continuously monitor step in RMF. How do you think about the way these two frameworks fit up to each other?

Rebecca Onuskanich:    
They definitely have their place. They’re both a little bit different from each other, but they do compliment each other. I do think that I am actually seeing more entities in the DOD start looking at the CSF, so the cybersecurity framework, and MFL to bring that into that continuous monitoring crit phase.

Kip Boyle:                          
You do think that’s a natural touchpoint for these two frameworks, is that step seven continuous monitoring. Okay. Thanks. I appreciate that. I was trying to figure that out for myself. All right. Let’s see. When we were doing show prep, you had mentioned a few other things that I think our audience would really benefit from hearing about, which is some examples around some of the difficulties of legacy systems in RMF.

The fact that you’ve got systems that are no longer in a development state. Their development is finished and maybe they’ll never be enhanced again. Yet, you’re still expected to use a SDLC style approach to achieving approval to operate. What’s that been like for you? How do you deal with this situation?

Rebecca Onuskanich:      
It’s been a struggle for everybody involved. We have systems in the DOD that are designed and deployed in the 60s, the 70s.

Kip Boyle:                          
Back when they’re not new.

Rebecca Onuskanich:
Exactly. A lot of them weren’t running on the web form. And so, when you take something that can only take a six digit password and you try to say, “Well, you have to put a 14 character password on it.” How much development expense do you put in finding a developer, first of all?

And then, are you actually improving the security of that system? Is it really a necessary requirement for that system? A lot of that, as we’re going through … That’s where I believe the training problem is coming into play. Because those that are saying, “You have to come to my organization as a security controls assessor. And I’m doing your independent assessment, and you only have a six character password or even pin on your system. You fail.”

Well, do you really fail if the system isn’t capable of doing that? And so, that is where we’re really struggling in the DOD. That’s why I said earlier, that middle tier, where I have to send my system to an assessor who has no idea. They’re right out of college, maybe. They’re a new airman. This is a new position. I’m trying to explain. And that’s why it’s very important that in that documentation you clearly state the system is legacy. It can’t support 14 character passwords. And this is a very simple example.

Kip Boyle:                          
Right.

Rebecca Onuskanich:  
That’s very true, but …

Kip Boyle:                          
It is. Rebecca, as you talk about this, I’m reminded of some experiences I’ve had in the private sector. I had a customer who was going through a payment card industry, data security standard audit, because they wanted to conform to the PCI DSS. Similar things. This was a while ago, but there would be a mainframe computer that was processing credit card transactions, and it was legacy.

Whether it was a password or just some other things, it just could not perform to all of the requirements in PCI DSS. And so, we had to figure out how to create compensating controls and do other things in order to meet the intent of the requirement. Knowing that the requirement itself was not going to be met inside that system. And so, that sounds very similar to what you said. Right? That’s the same. Isn’t it?

Rebecca Onuskanich:
Absolutely. It’s the same. Everyone’s having the problem. Medical community is having it. Anybody that is trying to meet compliance standard that is built on modern development processes and platforms are having the same issue.

Kip Boyle:                        
Listen, for anybody out there who has experience working in PCI DSS or HIPAA or what have you, where you’re trying to take a framework, and you’re trying to get a legacy system to conform to it … Well, if you come over to RMF, welcome to the party. Because it sounds like it’s going to just be more of the same.

RMF does another thing too, which I thought was really interesting. These days, we talk about advanced persistent threats. We talk about zero trust. Those things really bring up this idea of, “Assume breach,” as a philosophy.

Because for so long, we’ve been in this mindset that we are assuming that a system is not breached, so we can build nice walls around it and keep it pure. We’ve realized that’s just not the way the world works anymore. During the show prep, you were saying, “Unfortunately, RMF hasn’t really caught up to the reality of assume breach.” Did I get that right?

Rebecca Onuskanich:      
Yes. It’s not looking at advanced persistent threat. That’s why in the DOD … Not to throw us off track at all. But we are really starting to look at resiliency and survivability in our systems.

Kip Boyle:                          
The NIST cybersecurity framework is really designed around resilience. I don’t know that they ever used the term, “Assume breach,” in there exactly, but they certainly do emphasize the fact that it’s not all about prevention. You have to detect, respond, and recover as well, and be prepared to do those things as fast as you can.

Because that really matters in terms of being able to survive. Now, we get to the part that we really were aiming at, which is eMASS. What is eMASS? Who should use it? What are its limitations? What are the things that are really good about it? Hi, Rebecca. I’m new. What’s eMASS?

Rebecca Onuskanich:      
The first thing to understand about eMASS, because it is what we call a government off the shelf. That’s not to say you can’t go and buy it from a commercial vendor. It is developed for the DOD, by DOD contractors. Available to DOD users on DOD systems. If you were an integrator or a small business trying to use eMASS, or teach yourself how to use it, you can’t do that. It has to be from a DOD network.

And so, really what it does is it helps walk you through those seven steps. You start by registering your system. It’s very access control oriented. Restrictions are pretty tight around permissions. Right now, one of my organizations I work with is very small. There are two of us. And so, we have to get multiple roles in eMASS to be able to do all the jobs and work the system through the process.

Kip Boyle:                          
Are you having to log out and log back in, depending on what step you’re trying to accomplish? Is it that complicated?

Rebecca Onuskanich:      
No, they’re able to actually give you the permissions under one account. Thankfully.

Kip Boyle:                          
Okay.

Rebecca Onuskanich:      
But it’s very permission-based, which it obviously should be. We’re trying to prevent me from being able to say, “I’m doing this for this control, and I do it really well. Let me just go ahead and assess myself.” You’ve got to have a separation of duty.

Kip Boyle:                          
Right. Listening to you talk about using eMASS when you’re such a small organization makes me think about … Maybe a two person startup who says, “Let’s use Salesforce for our CRM.” And it’s like, “Wait a minute. That’s a highly-scaled system.” Probably, not the best place for you to start.

When I talk with mid-market companies about doing different things for cybersecurity, sometimes they’ll say to me, “Well, what if we get X, Y, Z product? Because that’s very popular and all the big companies use it.” And I say, “I understand why you say that, but that’s like putting your 14-year-old son into his dad’s suit and sending him off to the junior high dance.”

It’s really not going to work. That suit was never designed for such a small kid. He’s going to look silly. Worse yet, it can be so expensive to use something that’s been sized beyond the scale that you’re operating at. And so, what I’m hearing is, “If you’re a small organization, eMASS can feel like you’re wearing too big of a dress.”

Rebecca Onuskanich:      
But on the other end … We work a lot with system of systems. I don’t know if you’ve ever talked about that in any of your podcasts.

Kip Boyle:                          
I haven’t. We haven’t. Tell us what that is please.

Rebecca Onuskanich:    
A system of systems is … If you think about Navy ships. That’s a good example. It is a system. The ship is a system in its own, but there are thousands of systems on that ship that have to work together. Some have order of stand-alone, some are working together, some are communicating back home.

That is what we call a system of systems. These all have to work together. So eMASS doesn’t do a great job of looking at risk across that entire enterprise of system of systems either. It’s really right in that mid-level development size of system that it works really well in.

Kip Boyle:              
Interesting. In my brain, I think of subsystems.

Rebecca Onuskanich:  
Right.

Kip Boyle:                          
You can’t really operate a ship without all these subsystems and how they integrate with each other. If Jason Dion was here, he’d be all over this. Because as a person who has just retired from the Navy, he could probably tell us all kinds of really cool stories about how subsystems on ships don’t work the way they’re supposed to. Or what have you. But let’s get back to eMASS.

What I’m hearing is eMASS is not something you can buy without a prescription. I’m hearing that eMASS is complicated and a little difficult to get your arms around. And the only way you’re going to get into eMASS is if you apply to somebody in the government to issue you an account. They probably won’t do that unless you’ve got some kind of contract you’re working on. Is that about right?

Rebecca Onuskanich:      
Yes. Typically, you have to have a DOD CAC. It is a CAC.

Kip Boyle:                          
Okay. And that’s a common access … Is it common access card?

Rebecca Onuskanich:  
Card.

Kip Boyle:                    
Common access card. That’s like a smart card. Is it not?

Rebecca Onuskanich:      
It is.

Kip Boyle:                          
They didn’t have these things when I was on active duty. I’ve heard about them, but I’ve never actually had one. Is eMASS web-based? Or is it like a piece of software you install on your local computer?

Rebecca Onuskanich:      
It is a web-based app. Yep.

Kip Boyle:                          
Okay. Got that. Cool. Now, what else about using eMASS? Are there, in your experience, any particular, “Got you’s?” Or tips or tricks? Again, hi, Rebecca. I’m new. I’m using eMASS for the first time. What should I know? What else would you tell me so I can be successful?

Rebecca Onuskanich:      
It’s going to depend on when you come in and the life cycle of your system. If you come in new to an organization and all of their systems are already built in eMASS … Let’s say you already have an ATO. You’ll all be working on continuous monitoring. There are requirements to review the security controls at a perscripted time. Let’s say, every three years, you’re required to review your security policies. Every year, you’re required to review your access control rosters.

In eMASS, we actually go in there and validate that we reviewed those. But if you’re building a new system in eMASS, you have to request the access. You’ve got to have somebody build the initial system for you. Let’s say, your system is … Whatever you want to call it. A new DOD system too. And then, you sit down and you categorize the system and tailor it in there. And then, that gets approved.

Once, we call it your security controls baseline, is tailored … Once that’s been approved, then the work starts. The implementation. You’ve got to write security policies. You’ve got to have SOPs and TTDs. You’ve got to, what we refer to as, “Harden the system,” where you utilize the STIGs. The security technical implementation guides.

You’ve got to have a software and hardware baseline. You put that into eMASS, actually. You actually put it there, “I’m using this Dell version. This model. This is the OS that’s running on it. This is the patch level the OS is on.” You put all of that information in there, and you start to build your hardware and software list.

You’ll build what they call the authorization boundary. You have to actually say, “Here’s all the components, hardware, software, firmware. Here’s how they’re connecting. Here’s all my ports I’m using. Here’s all the protocols we’re using.”

Kip Boyle:                          
Wow.

Rebecca Onuskanich:      
All of this data that supports the system security plan goes into eMASS. You’re essentially building your system security plan in eMASS.

Kip Boyle:                          
This also sounds like a really heavy duty configuration control approach too. Because I’m hearing you say, you’re putting all these component items in there. Down to the patch level. Getting this all in. I can see why that would be an advantage, but I’m also fatigued, just thinking about all of the information that I’m going to have to pound into eMASS.

Fascinating. Well, then that actually brings up a question that I wanted to ask you, as we get to the end of our episode today, which is … Is there any risk to using eMASS to manage risks?

Rebecca Onuskanich:    
The number one concern right now. It’s, “Now, I’m putting all of my systems, all of the software, the versions, IP addresses, boundary diagrams, ports, protocol, services, how I’m authenticating my users, my encryption type …” I’m putting every single design and system security engineering aspect into one web-based application, which in itself has some of vulnerabilities. That it’s web-based.

Now, you want me to put all of that together, along with everyone else’s stuff, and really you have built a treasured chest for the adversary. It is a crown jewel piece of software on the web.

Kip Boyle:                          
Huh? I wonder if anybody used eMASS to assess eMASS?

Rebecca Onuskanich:      
I do know it has an ATO.

Kip Boyle:                          
Well, that’s good. Okay. That’s eMASS. Quick question. Are there other ways that you can automate RMF? Or just make it easier for yourself other than eMASS?

Rebecca Onuskanich:
EXACTO is one of the tools that you’ll see being used across the DOD. The federal side has their own tools. They have CSAM. I could not tell you what it stands for.

Kip Boyle:                          
Okay.

Rebecca Onuskanich:    
And then, some organizations develop their own internal systems, where they’ll use things like SharePoint. I’ve seen custom-built workflow processes. I’ve seen CRM be leveraged to build a workload process for this.

Kip Boyle:                          
Okay so, eMASS is really optional then is what I’m hearing. RMF doesn’t require you to use eMASS. You can bring whatever automation you’d like to the party. Is that right?

Rebecca Onuskanich:    
Well, that was correct. Now, more services are starting to require it. Across the Air Force, Army, Navy, and Marine Corps. Because like I mentioned, RMF is an interpretable process. Every community has decided what tools and which processes they’re going to use.

EMASS is just a DOD-funded tool. I do have a couple organizations I work with now who don’t use eMASS, but they have been mandated to move to it. They are on a large initiative to move everything over to eMASS. They’re very nervous about it.

Kip Boyle:                  
Probably, in a couple of years, we’ll be talking about how everyone’s using eMASS now and different sets of problems. The whole thing really strikes me as a bit of a moving target. Right?

Rebecca Onuskanich:      
It’s been moving for 20 years.

Kip Boyle:                  
Welcome to cybersecurity. Because that’s just sort of the nature of the beast. Isn’t it? Everything is always moving. Well, we’re running out of time. Rebecca, this has been a fantastic conversation.

Again, really thankful that you’ve decided to spend some of your valuable time talking with me today. Making this recording of this episode, so that people can benefit from your experience. Is there anything else you want to share? A final word before we wrap up?

Rebecca Onuskanich:      
My biggest thing when it comes to cybersecurity, RMF, in the DOD is really, “Do good system security engineering.” Think through problems, do risk assessment, document the outcomes and be honest, so our leadership can make the best decisions for their community.

We’ve really got to start looking, one, at training people better. And, two, making more mission-focused decisions when it comes to cybersecurity and risk management in the DOD.

Kip Boyle:                      
Putting the mission first and putting RMF and all these other things in a supporting role. Not making them the point of the work that we do. I absolutely agree with that. Rebecca, if anybody wanted to contact you after they listened to this episode, would that be okay? How would you like them to do that?

Rebecca Onuskanich:
Absolutely. You can email me. It’s Becca, becca@icyberi.com. International Cyber Institute. That’s probably the best way to get ahold of me.

Kip Boyle:                          
And that’s the name of your organization that you started. Right?

Rebecca Onuskanich:  
That’s correct. Yes.

Kip Boyle:                          
I just think that’s fantastic. As a small business owner, I love meeting and talking to other small business owners. Thank you so much, Rebecca. Everybody, as with every episode that we create, you can access a full transcript of everything we talked about right on our website.

All you have to do is put www.yourcyberpath.com, forward slash, and then just put the episode number. This is episode 83. Put 83 in your favorite web browser. And then, you’ll be able to actually pull up the page dedicated to this episode and access all the show notes and all of the transcript. It’s a complete transcript.

You can also sign up for my mentor notes. Now, if you don’t know what mentor notes are … Every two weeks, I send out an email. About 500 words and I just tell you something that’s going on. For those of you trying to get into cybersecurity. Something that’s going on that I think will help you. And so, I focus on being very short to the point and practical.

Listen, give it a try. You can unsubscribe any time. There’s no trouble with that. If you go to yourcyberpath.com, you’ll find the sign up there. Like I said, give it a try. But in any event, we’re happy you were here. Thanks for listening. We’re going to see you next time on Your Cyber Path.