DSS Risk Assessment: Terminology Defined and Steps Explained
In accordance with Executive Order 12829, the Defense Security Service (DSS) administers and implements the defense portion of the National Industrial Security Program (NISP). To this end, it publishes the DSS Assessment and Authorization Process Manual (DAAPM) providing a comprehensive Risk Management Framework (RMF) for government agencies and their partners.
In June of last year, the DAAPM was updated to reflect the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37. The new RMF has several steps that organizations must take to define, assess, report, and manage risks to the security of their systems and business.
In this article, we’ll give a brief overview of the new requirements, with a special emphasis on conducting risk assessment and creating proper documentation.
The Steps of RMF
The SP 800-37 RMF is divided into six steps:
- System Security Categorization
- Security Controls Selection
- Security Controls Implementation
- Security Controls Assessment
- System Authorization
- Security Controls Monitoring
As noted in the SP 800-30 guide to risk assessment,
“A single risk model (consisting of a fixed set of factors, a fixed assessment scale for each factor, and a fixed algorithm for combining factors) cannot meet the diverse needs of the organizations in the public and private sectors”
Every organization has unique systems, risk factors, and predisposing conditions which must be properly identified for a risk assessment to be useful. This takes place in the first four steps which can take up to 90 days to complete, and they will be our primary focus.
1. Security Categorization
Under the RMF, organizations must apply appropriate categories to each system assessed, as this will determine appropriate security controls. The DSS recognizes three security categorizations: low, moderate, and high.
Systems to which this hierarchy applies include:
- Single-User Standalone (SUSA)
- Multi-User Standalone (MUSA)
- Wide Area Network (WAN)
- Contractor-to-Government (C2G)
- And several others discussed in the DAAPM.
2. Controls Selection
Appropriate security controls must be selected and applied to each system based on risk categorization. While there are an indefinite number of controls that can be applied, NIST (SP) 800-53 maintains a helpful library that can be used for selection and documentation purposes.
While controls are mostly selected at an organization’s discretion, the RMF does maintain a certain number of mandatory controls that must be applied to every system. These include:
- Local/network security policies
- System security configurations
- System automated log management
- System automated vulnerability scanner
3. Controls Implementation
Of the first four steps, this is the most arduous. First, an organization must prepare appropriate security policies and more than 25 required documents, including a System Security Plan, Access Control Policy, Incident Response Plan, and more. Second – and more obviously – the organization must implement the controls it selected in step #2.
A full list of required policies and documentation can be found in the DAAPM.
4. Controls Assessment
Organizations following the RMF must conduct periodic risk assessments and generate a Risk Assessment Report (RAR). The report should include,
- Security audit results
- Vulnerability scanning results
- Remediation activities
- Plan of Action & Milestones (POA&M)
A RAR provides crucial information to the DSS and other authorized individuals. From the perspective of governance, it is the main point of the RMF, and for that reason, risk assessments should be conducted with great care.
Fortunately, NIST provides a comprehensive guide for conducting risk assessments (SP 800-30), and in the section that follows, we will summarize its methods and terminology.
NIST Risk Assessment Summary
The NIST guide provides five steps for preparing and conducting a risk assessment. “Risk” is not to be equated with “threat” or “vulnerability,” as both these terms represent discrete risk factors among many which are defined and distinguished in the first two steps.
1. Identify Threat Sources and Events
A “threat” is defined as,
“any circumstance or event with the potential to adversely impact organizational operations and assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service”
It can be further broken down into “threat sources,” which include the motives, actors, and structural origins of a threat, and “threat scenarios” which can be statistically modeled for better analysis of risk factors.
Threat sources can include,
- Human error
- Natural disasters and accidents
- Malicious actors
- Political motives
2. Identify Vulnerabilities and Predisposing Conditions
A “vulnerability” is defined as,
“a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source”
Vulnerabilities range from the obvious – deprecated software, weak passwords, etc. – to the technical – coding flaws, zero-day exploits, etc. For moderate and high-risk systems, thorough identification of vulnerabilities will likely require penetration testing and other technical vulnerability assessments.
A “predisposing condition” is defined as,
“a condition…which affects (i.e., increases or decreases) the likelihood that threat events, once initiated, result in adverse impacts to organizational operations and assets, individuals, other organizations, or the Nation.”
As the definition shows, a predisposing condition can either exacerbate or reduce the likelihood of a threat event. Therefore, positive conditions should be identified in addition to negative ones for an accurate risk assessment.
3. Determine Likelihood of Occurrence
“Likelihood of occurrence” is defined as,
“a weighted risk factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability (or set of vulnerabilities)”
To some extent, determining likelihood is an educated guess. If available, however, the organization can refer to statistics from its history of security incidents and from the industry as a whole.
In addition to estimating the likelihood that an event will occur, organizations typically factor in the likelihood that an event will result in any harm once initiated.
4. Determine Magnitude of Impact
“Impact” is defined as,
“magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability”
The impact of a threat event is obviously far-reaching, affecting stakeholders, employees, dependents, stewards, and many other parties. To analyze adverse effects without tracing them across the globe, an organization should define its priorities and values, outlining the key parties to which it is responsible.
5. Determine Risk
Depending on the system, risk may be reported discretely or as an aggregate. For Tier 1 and Tier 2 systems (organizational and business/mission processes), it is common to aggregate multiple risk factors and assess them cumulatively. For Tier 3 systems (information systems), aggregation can be used, but assessing and reporting risks individually is more common.
At this point, you have taken all the requisite steps to generate a RAR by following the reporting template outlined in the DAAPM. It can be found in Appendix C, page 61.
Risk Management Software
Keep your information all in one place and conduct risk assessments with peace of mind. MathCraft’s Access Commander is an all-in-one risk compliance solution for FSOs and government partners. Our Risk Management Framework (RMF) module provides a comprehensive platform for RMF Assessment and Authorization. Contact us today for a free demo!