Sign up for free at http://convocourses.com for deeper dives.
Many more videos on https://www.youtube.com/convocourses
short videos at https://www.tiktok.com/@convocourses?lang=en
Podcast version of the content:
NIST SP 800-53, Revision 5 Security Controls for Information Systems and Organizations – 1 overview
To download the slide go to:
NIST Special Publication 800-53, Revision 5
Security and Privacy Controls
Final Public Draft: October 2018
Final Publication: December 2018
NIST Special Publication 800-53A, Revision 5
Assessment Procedures for Security and Privacy Controls
Initial Public Draft: March 2019
Final Public Draft: June 2019
Final Publication: September 2019
There are 6 major objectives for this update—
-Making the security and privacy controls more outcome-based by changing the structure of the controls;
-Fully integrating the privacy controls into the security control catalog creating a consolidated and unified set of controls for information systems and organizations
-Separating the control selection process from the actual controls: systems engineers, software developers, enterprise architects; and mission/business owners
-Promoting integration with different risk management and cybersecurity approaches and lexicons, including the Cybersecurity Framework
-Clarifying the relationship between security and privacy to improve the selection of controls necessary to address the full scope of security and privacy risks
This is an introduction to the NIST Special Publication 800-18, System Security Plan. We walk through why you need a System Security Plan and some of the main elements of the System Security Plan.
This is a quick introduction to Step 2 of the Risk Management Framework NIST 800-37 process. Step 2 involves selection of NIST Special Publication 800-53 security controls. There are (3) main tasks that you must do in this step:
1) Select the applicable baseline controls. Selection of baseline controls is based on system categorization.
2) Tailor the Security Controls to the system. Not all security controls can be used because they may break your system. And in some cases they are simply not applicable. There are also Common Controls, Hybrid controls, and system specific controls.
3) Document the Security Controls. You must document the selected security controls in a system security plan and have the security controls reviewed.
Risk identification is done with a risk assessment. NIST SP 800-30, Guide for Conducting Risk Assessments breaks down the entire process of risk determination, risk identification.
As described in the earlier post DIACAP Process:
Risk = ((Vulnerability * Threat) / Countermeasure) * Asset Value at Risk IT Risk
Risk is the likelihood that a threat will compromise the weakness of an asset. So risk identification is based on knowing the threat, the vulnerability and the asset.
The better you understand these factors, the better your chances of risk determination and risk identification.
NIST SP 800-39, Managing Information Security Risk is a document that defines risk management as the process of not only identifying risk but also, assessing risk, and taking steps to mitigate risks for fit within one of the types or risk, risk acceptance.
Risk identification starts off with identification of the asset.
1) System characterization – Gather information into a System Security Plan (SSP). Identifying risk requires a deep understanding of the asset and its environment. Asset information for the SSP will cover the following:
2) Threat Identification – Without a defined threat, there is no way to quantify or identify a threat. Threat identification starts with looking at the threat sources and events. An example to look for threat sources historical data. When has the asset or similar assets from other related organizations in the same industry been attacked or suffered disaster. Remember a threat source is not just criminal-hackers and malware, it can be a natural disaster or unintentional destruction of data or a power outage.
3) Vulnerability Identification – Once the asset and threat are identified, you can more easily determine if your system has a weakness for that particular disaster or exploit. Again, you can look at historical evidence that suggest weakness. You can use scanners to find open ports that are exposed to the Internet.
4) Security Control Analysis – If your system already has security controls in place, you must take that into account because this may lower your risk.
5) Likelihood determination – The probability that your asset will be exploited is based on the threat source motivation, threat capability, your vulnerability and the security controls you have in place. Based on all these factors you can calculated the likelihood of an attack or disaster.
6) Impact Analysis – This where you gather all the data from asset identification, threat source, vulnerability identification, security controls, likelihood of attack and figure you what would happen if something really did happen. How important is your system and its data? What would happen to the mission or bottom line or profits if the system went down for a few hours? a few days? a few weeks? Some system are so important that they cannot be down for even a minute. Impact is very important to the level of risk. The more important the system is, the high the risk.
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.
Who does risk identification:
Ultimately it is the information system owner and authorizing official that must make a determination on what kind of risk they will accept, but they rely heavily on the expertise of an information security engineer, information system security manager, information system security officer and technical professionals to articulate what is happening on the ground.
The ISSO/ISSM/ISSE typically document the process mentioned above or the DIARMF process. Security professionals coordinate with IT professionals to “get into the weeds” of technical security controls and vulnerabilities.
The risk management framework steps are detailed in NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems.
The DoD has recently adopted the Risk Management Framework steps (called the DIARMF process). There are 6 step: Categorize, Select, Implement, Assess, Authorize and Continuous Monitor.
The first risk management framework step is categorization. This step consists of classifying the importance of the information system. This is done by the system owner with FIPS 199 and NIST 800-60.
Categorization is based on how much negative impact the organization will receive if the information system lost is confidentiality, integrity or availability.
With FIPS 200 and NIST SP 800-53, the organization responsible for the systems security will select the security controls required to limit the risk to their organization. The selection of the controls is based on the categorization of your system. A system security plan is created as a guide to what will be installed and/or configured on the system.
More on DIARMF – Select
Using the System Security Plan, the organization responsible for the categorized system can begin risk management framework step 3. This step is implementation which is installation and configuration of security patches, hotfixes and security devices where necessary. Guidance for actual implantation has to come from technical manuals, system administrators, system engineers and others technically competent enough to do the work.
More on DIARMF – Implement
The organization has to make sure that the security controls are implemented properly. This is done in risk management step 4, assess. Using NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations is used to determine which controls have been fully implemented to limit the risks to the organization.
More on DIARMF – Assess
Even after implementation and assessment of the security controls that limits the over all risk to the organization, there is some remaining (residual) risk. The organization must have someone who has enough authority of over the system to accept the residual risk. This person is known as the Authorizing Official.
In risk management framework step 5, an Authorizing Official makes a formal, written acceptance of the risks. The AO makes a decision on whether or not to accept the risk based on the authorization package. The authorization package consists of the system security plan, plan of action and milestone, security/risk assessment report and any other supporting documents.
More on DIARMF – Authorization
risk management framework – Step 6. Continuous Monitoring
After acceptance of risk by the organization, they must develop a program that monitors the ongoing changes to the systems security posture. They take a proactive approach to watching for advanced persistent threats, configuration changes and new vulnerabilities. Risk management framework step 6 handles all of this.
More on DIARMF – Continuous Monitoring