Many more videos on https://www.youtube.com/convocoursesshort videos at https://www.tiktok.com/@convocourses?lang=enand https://www.instagram.com/convocourseqs/https://www.facebook.com/ConvoCourses-108091850619388Podcast version of the content:https://podcasts.apple.com/us/podcast/convocourses/id1500188278http://www.nist80037rmf.com/google_podcast
The interpretation of baseline controls and enhancements is one of most common question that I get. That’s why I made that other course about it:
This course interprets and breaks down NIST security controls. We explain what’s going on in a simple practical way. This is something that I wish somebody would have done for me but as if you’ve been looking out there’s not a lot of people doing this.
Sign up for free:
Risk mitigation can only be done by first identifying the risk. And risk identification can only be done by characterization of the assets, discovery of vulnerabilities of those assets and determination of threats and/or possible harm to that system.
So risk mitigation is based on the results of risk assessments.
Risk assessment is a 9 step process.
1) System characterization – a system is an organization asset. So the first step is to discover all the features of that system and understand why it is important.
2) Threat Identification – risk is determined by the likelihood of a threat affecting the weakness of an asset. To limit the risk (risk mitigation), a security practitioner must determine the possible threat, find the weakness and then come up with a way to protect that system.
3) Vulnerability Identification – The security practitioner (information system security officer, information system security analyst, system security engineer etc) must find the weakness of a system.
4) Security Control Analysis – The security control protecting the vulnerability is the actual risk mitigation. Analysis is determining what is needed, when and how much it will cost.
5) Likelihood determination – The importance of risk mitigation is directly proportionate to the likelihood of the threat impacting the organization and its assets vulnerabiltiy.
6) Impact Analysis – The bottom line of risk is the impact that will occur if harm should come to an asset. If the asset ceases to function, what happens to the organization? That question should drive how and why risk is mitigated.
7) Risk Determination / Risk Identification – Based on all the data gathered you can make a pretty good risk determination. You should have defined the systems components and what data is important, made a pretty good conclusion on threat sources and likelihood of the vulnerability exploits and know exactly what kind of impact there will be if the system goes down.
8) Control Recommendation – This is where the actual RISK MITIGATION comes in. All data is gathered from the risk assessment and risk has been identified and evaluated. Risk is mitigated by applying to correct security controls.
9) Results Documentation – The mitigation of risk must be documented for future reference. Sometimes it can only be mitigated later and documented in a Plan of Action and Milestone.
Who does Mitigates the Risk:
First of all, risk cannot always be mitigated. In this cases it is documented in something called a Plan of Action and Milestone (POA&M). And sometimes risk is simple accepted because there is just nothing that can be done. The mitigation of risk is the responsibility of the system owner. The system owner will sometime have a right hand adviser on matters of security, a Chief Security Officer who is not afraid to say NO and will always give the system owner (CIO) the facts no matter how gruesome. The CSO (or equivalent) delegates risk mitigation (implementation of security controls) to security practitioners (DoD 8140 compliant professionals) who hopefully know what they are doing.
The physical risk to an information system is perhaps the most important to consider. You MUST limit physical access to a system or any technical or administrative controls you implement are meaningless because they can be bypassed easily. With direct physical access ANYONE can boot a server into a Kali Linux Live CD/USB or do a Password Recovery on your Cisco Router PWNAGE!!!! If you can physically touch a system, then you can own it.
Additionally, you should have a contingency plan for the most likely avenue of physical disaster to a system. This limits the potential of intentional and unintentional harm to the system.
To limit the physical risk to an information system the NIST SP 800-53/DIARMF prescribes “Physical and Environmental Protection” Controls:
- PE-1 Physical and Environmental Protection Policy and Procedures
- PE-2 Physical Access Authorizations
- PE-3 Physical Access Control
- PE-4 Access Control for Transmission Medium
- PE-5 Access Control for Output Devices
- PE-6 Monitoring Physical Access
- PE-7 Visitor Control
- PE-8 Access Records
- PE-9 Power Equipment and Power Cabling
- PE-10 Emergency Shutoff
- PE-11 Emergency Power
- PE-12 Emergency Lighting
- PE-13 Fire Protection
- PE-14 Temperature and Humidity Controls
- PE-15 Water Damage Protection
- PE-16 Delivery and Removal
- PE-17 Alternate Work Site
- PE-18 Location of Information System Components
- PE-19 Information Leakage