In this episode, Max discusses the fundamental concepts of Control Inheritance and System Reciprocity, highlighting their differences, applications, and importance in the realms of cybersecurity and organizational governance. This topic ties in closely with his recent LinkedIn post about the need for a credit system for security work being done within different parts of the DoD.
Topics Covered
Resources
RMF Process and Reciprocal Agreements
DISA Connection Approval Process for Authority to Connect
Max Aulakh Bio:
Max is the Managing DIrector of Ignyte Assurance Platform and a Data Security and Compliance leader delivering DoD-tested security strategies and compliance that safeguard mission-critical IT operations. He has trained and excelled while working for the United States Air Force. He maintained and tested the InfoSec and ComSec functions of network hardware, software, and IT infrastructure for global unclassified and classified networks.
Max Aulakh on LinkedIn
Ignyte Assurance Platform Website
Max Aulakh: [00:00:00] Welcome to Reckless Compliance Podcast, where we learn about unintended consequences of federal compliance, brought to you by ignyteplatform.com. If you’re looking to learn about cyber risk management and get your product into the federal market, this podcast is for you. Or if you’re a security pro within the federal space looking for a community, join us.
We’ll break down tools, tips, and techniques to help you get better and faster to get through the laborious federal accreditation processes. It doesn’t matter what type of system or federal agencies you’re dealing with. If you’ve heard of confusing terms like ATOs, FedRAMP, RMF, DISA STIGs, SAP SARs, or newer terms like CATO, Big Bang, OSCAL, and SBOMs, we’ll break it down all one by one.
And now, here’s the show.
Hello everyone, thank you for tuning in. Today, we’re going to be doing a very short fundamental topic that we often get asked about. This is about control, inheritance, and system reciprocity. In this episode, we’ll be breaking down the difference between the two. We’ll talk about what is it, who uses it, how to do it, and why is it even important.
So let me first break down these concepts. If you’re tuning in, I’m primarily going to share some examples from the U. S. government perspective, but the same concepts actually apply to large non government organizations. In fact If you’re working on the corporate side, you may already be doing these things.
You just haven’t wrote them down as part of your formal security program, but organizations often do control inheritance and reciprocal agreements or not agreements, but they’ll have systems that are used by one area to another. So both of these concepts have to do with reusability and re leveraging cyber work.
That’s already been done within an organization. How do we reuse that? Work that a team has done across the board and how do we document it? And what does that process look like? So that’s what really control inheritance and reciprocity has to do with these are very important concepts for large geographically distributed organization where the budget.
The cost and the work it’s allocated based on the mission of the organization. So a great example of this kind of organization is US government. The overall US government mission has to do with protecting its people, land, amongst other things. But each agency has their own specific mission. So in the same way, a complex global organization like Dell or Google may have an overarching mission guided by the market shareholders, but individual business units and suborgs have their own agendas and missions.
And so. These types of organizations should, and they do leverage control inheritance formally or informally they have to, right? It’s all about reusing the work that we’ve done. So in case of the government, this is done formally. Now let’s talk about What is control inheritance, and what are some examples of it, and how does that work within the public sector?
So a great example of this might be a management policy that has been written, and all the business units can reuse that management policy. It seems pretty common and obvious, right? But in context to public sector, specifically around accreditation, ATOs, inheritance and reciprocity are key to getting system approved one time and having the ability to reuse it across different agencies.
So let’s talk inheritance. So inheritance, this is when you have a set of controls. That are approved and a single control is managed by an organization and that single control is used to offer protection against other systems. So let’s look at a working example. So identity management, single sign on.
You can have a single system that has that capability and that control and this is designed as an offering and it’s used across all the other agencies or the other organizations. So I’m speaking in general terms here, these are very simple concepts, but we would simply want to inherit these types of capabilities.
So in context of the government, these capabilities and controls, they come out of what’s called a control catalog. In the government, this means a variation of NIST 800 53, but in a commercial organization can also use a concept of control catalog. But obviously, you have different types of standards, but for the government, this is the 853 variation FedRAMP control set, and so on and so forth.
So, you may also hear a term called a CCP, or a Common Control Provider. This is a general term for a system or an organization that might be providing the control inheritance, or list of controls that are available for other systems. So, in summary, Control inheritance is when you have a single control offered as a protection against a, another system.
An example of that is, another example would be like blocking egress traffic at the corporate firewall. That is offered as a protection mechanism for all the other systems. It could be an internal ERP system. It doesn’t matter, but that is formally documented. So that blocking of egress, corporate firewall, that could be access management, which is one of the controls within the catalog.
And that is offered as an inheritable control through what’s called a common control provider. Now, let’s talk about reciprocity. So a lot of times people ask us, Hey, isn’t that the same thing as reciprocity? And these terms are often interchanged and conflated. They’re actually entirely two different concepts.
One feeds or helps the other. So reciprocity has to do with agreements between organizations. Inheritance has to do with controls at a system level being used between two systems. This reciprocity term has to do with an agreement. So, Organization A, or an Agency A, or Sub Organization A provides something to Organization B and it’s documented within an agreement and it’s called a Reciprocity Agreement or a Reciprocal Agreement.
You’ll hear other terms here, just like with Control Inheritance, there’s the term of CCP or Common Control Provider. Here, the term you’ll hear is something called a Reciprocity Agreement. ATC or an authority to connect. So what this is, is let’s say you have a system, you have already worked that system, secured that system, have applied all the compliance measures to it, and you received an approval from your management, which the government formally calls this an ATL or an approval to operate.
Now you want to take that system, let’s say the air force is using it. You want to take that system to the army. So instead of going to the army and redoing all of the work, you can establish a reciprocity agreement. That’s the concept. That’s the big idea. You could say is you can reuse the same type, a set of protection mechanisms, the ATO to single approval and re leverage that to have the army units, the Navy units connect to, and that’s why it’s called authority to connect, right?
That a stat that’s the details of the reciprocity process. So at the end of this, when you’ve gone through the connection process and things like that, you can receive a reciprocating agreement where one management has accepted. The risk statements or the condition from another. So one AO has accepted all the work AO stands for authorization official, all the work that another AO has looked at.
So in theory, all of this sounds very simple. It sounds very uncomplex, but it’s actually quite complex because of all the. Systems and. Coordination that you have to do to actually get this going. So an example system I would use here is let’s say a contract management system. Air force uses wide area workflow, or it could be a business unit.
It doesn’t matter if you have a contract management system that everybody needs to use. So let’s say the Air Force’s Wide Area Workflow Solution, which is for, within contract management, used to work on that system a long time ago. If Army wanted to use it, what would they have to do? They would have to go through this reciprocity process, ATC, authority to connect.
And now then the army would be able to use it. Same thing. You could say the same thing about DevSecOps, software factories, timekeeping systems, any kind of system that one organization uses. If another larger organization wants to use it, they have to establish reciprocity and receive an authority to connect by going through the connection process, which is managed by another organization or the testing, which is managed by a different organization.
So very. Simple, but complex to execute. Now, the other question we get is, well, what about the program offices? Who takes care of the cost? The administration of all of this, if two agencies are using it, all of that is managed separately from this reciprocity and control inheritance, those kinds of things.
But the security of it is handled through the reciprocity process. So, so what do we mean by security of it? So when you go through the reciprocity process or the authority to connect, at this time, all of the controls that you have answered to receive your ATO may be Looked at by another agency and they might say, you know what, the system is cutting across firewalls, cutting across different areas of the government, and therefore your common controls are changing, you know, the firewall examples, a common control provider is changing, right?
So you need to, you know, Inherit your controls from another organization or part of them need to come from another organization. So many times the holdup could be that your prior inheritance is no longer valid because now you’re cutting across from one agency to another. So this is why many times organizations conflate inheritance with reciprocity.
So, very short lesson, very important. I’ve got a complimentary blog on this somewhere. Try to tie it to this podcast and then also have, of course, some guidance. There’s very little guidance. Unfortunately, a lot of this stuff happens. It’s quite a bit of tacit knowledge that lives within the system security management community, compliance community, risk management community.
And it needs to get out there because a lot of people that are innovating in the space are actually struggling. They they’ve gotten an ATO yet. They don’t know how to reuse it. So I hope you found it helpful. If you did, please leave a comment or connect with me. And just as a summary, right, just as a summary control inheritance is where you have a single control out of the catalog that is used as a protection mechanism.
For other systems firewall is an example. Reciprocity is not at the control level. It’s an agreement between two organizations. And the other operative word you’ll hear is authority to connect. You already have your ATO, now you need an authority to connect from that ATO, from let’s say the Air Force One agency to another agency.
And that’s what reciprocity is. Alright, well have a wonderful day and thank yoUSo much for listening. Thank you for tuning in. If you enjoyed the podcast, head over to ignyteplatform.com/reckless. You’ll find notes, links, and additional content. Head over to iTunes to subscribe, rate, and leave a review.