Known Documented and Implemented

A Risk Management Framework (RMF) professional is tasked with auditing and assessing an organization's risk. To assess the risk of an organization, audits must be performed. In a practical sense, most people do not retain every National Institute of Standards and Technology (NIST) special publication, or people do not retain every Department of Defense regulation or executive order. We only sometimes have every organization's policy memorized. Because human brains are not computers with vast archives, we work with methodologies and frameworks. We know where repositories of knowledge are stored to search when we need specific information.

There is a very good methodology that can identify the risk severity of a vulnerability finding at a glance, and it's called the "Known, Documented, and Implemented methodology." The Known, Documented, and Implemented methodology is a framework that an auditor will keep in mind while performing a risk assessment, addressing security controls, and performing various RMF duties. Then, when a vulnerability is found, the RMF professional, such as the ISSO, ISSM, SCA, or AO, can quickly identify if the risk is high, medium, or low. High risk being CAT 1 vulnerabilities, Medium risk being CAT 2 vulnerabilities, and low being CAT 3 vulnerabilities.

It should be noted that the test results linking KNOWN, DOCUMENTED, and IMPLEMENTED to a risk severity level, such as CAT 1, 2, or 3, can be adjusted according to the particular assessment and how it connects to other related assessments in the eMASS package. The assigned risk level methodology is a starting point. For instance, if an assessment has a finding type of IMPLEMENTED because of a STIG result, and the STIG declares it as a CAT 3 finding, then the final vulnerability would be a CAT 3, not a CAT 1.

Risk vulnerabilities are rated CAT 1, 2, and 3 based on DISA STIGs, commonly called STIGS. STIGS refers to the Defense Information Systems Agency DISA organization that provides technical security technical implementation guide STIGS from the Department of Defense (DoD). Each control within the STIG has a compliance level associated with it, helping to assess the level of risk from the vulnerability.

CAT 1 STIGS (HIGH)

Controls from STIG category 1 cover the most serious vulnerabilities to major exploitation if left unchecked. It is highly probable that CAT 1 vulnerabilities can directly cause data breaches or service disruptions. Therefore, these are considered to be of great importance and must be addressed as soon as possible.

CAT 2 STIGS (MEDIUM)

CAT 2 applies to scenarios or flaws that may result in a cyber security problem. Compared to CAT 1, these are less serious and won't lead to an immediate decline in system integrity. Still, if not monitored, they could turn into a CAT 1 issue, making them mid-level threats in terms of risk and severity.

CAT 3 STIGS (LOW)

STIG category 3 controls encompass settings that can weaken the safeguards of a system or network if left unmanaged. These may escalate the danger of system breakdown or cyber assaults but will not directly result in either of them. Therefore, these are weighed as low risk and low gravity, though they can give rise to a CAT 2 vulnerability.

How To Use

This Methodology

With Examples

KNOWN (CAT 3, Low risk)

This level of risk is normally created by people with a lack of training, often due to human errors or lack of adherence to Standard operating procedures (SOPs). STIG category 3 settings can reduce the security of a network if left unattended. In addition, they increase the chances of a cyber-breach or system collapse. However, these will only occur indirectly as a result. Generally, these are classified as minor risks and low impact, though they can contribute to a CAT 2 vulnerability. To verify that an organization's employees are properly informed of the security protocol and regulations, interviews of system administrators or engineers, user education sessions, ATCTS an online repository website of training used by the DoD, and security checklists are conducted. The associated security regulations will be protected if personnel are coached well and abide by the guidelines.

An example of a "Known Risk Vulnerability" being non-compliant is when a Server administrator carries out incremental backups instead of following the differential procedure outlined in the SOP. Although backups are being done, this issue harms the BCP/DRP plans since the incremental backups cannot meet the restoration timeframes needed for the Recovery Time Objective (RTO). This can lead to a weakened state of security for the system or network if ignored. It can also lead to more storage space being used up, thus leaving less room for other storage requirements. This is why it is essential to have proper training and to review SOP/TTPs and policies regularly to ensure people carry out operations according to the prescribed guidelines rather than what they think is right. The most frequent difficulty is locating SOP/TTPs and seeing that they are checked and updated regularly.

An example of a "Known Risk Vulnerability" being compliant could be an ISSO interviewing IT personnel, such as server admins, system engineers, and Platforms, Operations, and VDI Teams. Everyone should have their certifications at the appropriate ATCTS Level, and all paperwork (PLAA, AUP, and appointment letters) should be up to date. Additionally, all personnel should be aware of where the SOPs are hosted on the SharePoint server. And finally, the SAs should be asked to show they can perform certain tasks that were outlined in the SOPs, and they should be able to do it with aplomb.

Documented (CAT 2, Medium Risk)

This level of risk is normally created by processes, operations, SOPs, policies, or other documents that do not confirm reality. STIG category 2 involves settings or flaws that could eventually lead to a cybersecurity concern. These issues are potentially not as dire as those outlined in CAT 1 but still present a medium risk and can transform into a CAT 1 vulnerability if not dealt with in time. Documentation is only as effective as how accurately it reflects the implementation and how timely it is. Artifacts demonstrate compliance, and artifacts like SOPs, policies, and so on are the documents that explain the needs and the processes to meet those needs of an organization. Artifacts have to be signed and dated to hold authority.

An example of a "Documented Risk Vulnerability" being non-compliant might be when a Server admin calls it quits after being part of the team for more than five years. Due to the absence of cross-training and several tasks only done by the now-departed Server admin (SA), the rest of the team is left to figure out how to complete functions quickly. There's no quick access to the documentation of the current software version, and the SOPs available are for old, outdated versions of the organization's systems, services, or processes. This leads to delays in task completion which could cause cybersecurity issues. Unfortunately, this situation is a common occurrence and serves as an illustration of why job rotation, examination of SOPs, and policy reviews are important for ensuring people are working according to instructions and requirements. Ensuring that when a team member leaves the company, or a new version is implemented, there's continuity with appropriate training and paperwork.

An example of a "Documented Risk Vulnerability" being compliant would be if an ISSO reviewed the SOPs with the Server administrators, network engineers, management, and any other relevant departments, then ensured all documentation is current and the version control log is updated to mark today's review. Finally, the artifact is uploaded, and the changes are reflected in a centralized place like the DoD's eMASS web tool.

Implemented (CAT 1 High Risk)

This level of risk is normally created by technology not being implemented or technology that is implemented that should not be implemented. Evidence such as STIG CKLs, Security Checklists, Reports, Screenshots, etc., can prove that security controls are in place to limit the window of opportunity for attackers and reduce exposure to vulnerabilities. These check-ups should be done frequently.

An example of an "Implemented Risk Vulnerability" being non-compliant could be a Server admin performing scans and a scan discovering major issues across a firewall. The same scan also reveals major issues across newly deployed Network Intrusion Detection Systems (NIDS) and Host Intrusion Detection Systems (HIDS). The lack of proper execution of configuration management and change management has resulted in an environment where tasks were not completed or not being performed as they should have been. These deficiencies have occurred since the last security audit, and now the system is exposed to major exploitation. Defense in Depth is only effective when multiple layers of security are being implemented sufficiently. STIGs help fortify systems and reduce the attack surface. Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) assist in identifying/blocking attacks. Other security services can offer some coverage where solutions may be lacking to cyber security concerns or vulnerabilities.

An example of an "Implemented Risk Vulnerability" being compliant is when an ISSO, SCA, AO, or other cyber security professional takes a look at the DISA STIG CKL files. CKL files are records that report if STIGS are being complied with or implemented. Further reviews reflect system reports, checklists, scans, and screenshots, all demonstrating compliance. All these CKL files, scans, screenshots, and reports are then uploaded onto eMASS.

Tying Everything Together.

The down and simple way to use this methodology is to ask yourself if this cyber security vulnerability is something that falls under "Known?, Documented?, or Implemented?" The answer to that question will point you in the right direction and help you grasp the risk severity the vulnerability it creates. As an ISSO, SCA, AO, or other RMF professional working in cyber compliance or cyber security, having a methodology like this can give you the tools to understand the underlining intents of cyber security principles and can give you an edge against those with malicious intent against your organization. Having a mental framework for understanding the underlining principles of cybersecurity immediately makes any cybersecurity professional respond faster to cyber security incidents, makes them decisive, and makes our cyber terrain more secure.