Common, System and Hybrid Controls

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

2 hours 11 minutes
Video Transcription
Okay, so for a lesson 2.5 talk about common system and hybrid controls. This another important
concept in inner 53 4 Managing risk.
So for this lesson, you'll learn how to define common system hyper controls, explain some of the examples of each one, differentiate between each one of the control types and understand what we mean by three different types
to kind of visual. To understand. Common controls are really inherited, and they're implemented the organization level.
So we talked about those Dash one controls a lot of times those air implemented by the organization
and they flowed down through the through the systems.
And then the system controls are just what they say. These is at the application operating system, whatever parts of the accreditation boundary, that system is what it's implementing to control.
And then you have the idea of a hybrid control, which is that overlap. So that means the system may implement some of it. I'm sorry to cut, the organization may implement a CZ part of a control, and then the system has to do a little bit more on to that kind of explained before, maybe an example of the data center, where there might be some physical controls
that the state that the organization implements. But then the system has some additional. So
in the security plan, you would actually say, Here's how the organization meets or here's the common part of it. I take that that's taken care of. And here's how my system actually implements it and there's additional tears. I'm talking about two levels. I've seen other organizations that they actually have multiple tears.
It gets a little complicated, but you could have an organization again doing policy.
Maybe have the operations staff or the operations division that does controls for the data center, maybe down the operating system. And then you have the system level is actually doing just the application. They're taking some of the controls it again. It gets a little complicated, but it all depends on the size of your organization.
What does a common control these air mention typically implemented? Organization Level A. C 18
81 eh? You want things like that? These are policies, procedures,
But the key here got a little practitioner note is ripped risk Acceptance is the key.
You can't stay. Oh, that's a common control and the organization's gonna take care of that. It has to be the organization, the highest level organization. The authorising official has to say This is a common control and I accept the risk for that by accepting it, saying I'm gonna
I'm gonna take ownership of making sure that that control is is in place
and it has the proper funding. The resource is to that. And if anything ever happens with that control or somebody realized it's not
doing what you expected to do, it's the organization that actually has to take care of that control.
So you're some examples mentioned. 81 is security awareness training policy. This is an obvious one you don't want. You don't have a common training across the *** organization for all the people you could actually maybe look at this or some of the lower 80 level ones where systems may need some specific cybersecurity training.
But this is a common one.
See, a one is a real obvious one as well. This is the security assessment authorization. You obviously don't want
every system creating their own authorization you want at the organization level because they're the ones that are accepting this risk and looking at their portfolios of systems and managing this risk. So you want to define
who looks at Who's the independent ancestor who can approve who passes that information up to exit through the risk assessment.
And we talked about this before again, is that the P E, which is the physical controls mostly implemented by the organization? But every once in a while he may have a like a disaster recovery side or something that's specific to a system.
So here's some some system controls on again. The system controls is defined by the accreditation boundary, which is the authorising official. It says
These are the systems are these are the physical systems virtual what everyone talk about. This is the boundary you are. You must implement these controls
and they're not gonna be implement implemented by the organization. So, for example, I five authenticator authenticator management thinks, would be obviously at the system level, whether it's in the application or the operating systems, how you authenticate how you manage those controls, that's gonna be very specific.
A U two event
are a star a you to audit events, which would be again the system level. So the delineation here, you might notice, is that a U one sets the policy that says you must audit controls and maybe says no defined variables and these thistles what has to be in there. But when you get to the specific event or sorry, the specific control,
the system is the one that actually
implementing that control and making sure that their systems are operating systems, whatever it's actually generating events. And they contain what the policy mandates. And again, the S C seven, which is the boundary protection part of that, maybe the organization. But most of time say this boundary protection is how do I protect my system from
other systems or from
from the malicious actors?
So we're gonna talk about hybrid controls, which is the moving on the blueberries. All that overlap between common and system controls
implemented at multiple tears in the organization, said spending a size the organization, it might just be one could be more, but
there may be a portion of it, except that organization doesn't in the system has to implement a CZ well
through the system security plan or the SSP Well, you'll have. Tiu would define This is what the common control implements are. This is the boundary, and then here's what my system is going to implement.
So, for example, we have CME eight, which is information system component inventory. You may have, for example, at least at a data center, and the organization may keep an inventory of the physical assets even down the operating system. It doesn't matter,
but they may not be interested in the software or the system has his own budget to manage the inventory for the software. So you would, you would say, Here's what Here's the inventory for the organization. Here's what I need to as the Implements system owner. Here's what I take care of.
The other one is this SC two, maybe application partitioning again You may have. The organization may have a larger application or may database. It may have databases something like that, where they
they partition or keep the customers or the data separately. But then that the system level, you may have additional requirements for separating. Maybe based on users of that of that system,
there's another quick quiz. Common controls are selected by the system owner based on the budget they allocate for security. Is this true or it's false.
This was false. As we mentioned, coming controls are defined by the organization based on acceptance of risks that you can't just say I don't want to do this control. Or I think my organization does this. So I'm just gonna comic called a common control and not implemented.
Up Next