Running head: RISK MANAGEMENT PROCESS OVERVIEW 1

The Company Risk Management Process: An Overview

G. Logan Gombar

University of San Diego

The Company Risk Management Process: An Overview

Ensuring the overall security of a network, and therefore the security of the company at

large, requires a standard process to validate all considerations are addressed when a change is

made to the network. To address this, we turn to the Risk Management Framework (RMF),

currently being maintained by the National Institute of Science and Technology (NIST). RMF

provides a generic scaffolding upon which a specific security plan can be built. The process

walks through categorization, control selection, implementation, implementation assessment,

system authorization, and continuous monitoring. The importance and beneficial impact this

level of standardized process provides cannot be overstated. This paper will discuss the

overarching process at a high level, delving into examples only where they provide a benefit.

Security Categorization Styling & Definitions

Per FIPS 199, this is the standard format: SCsystem={(confidentiality, impact), (integrity,

impact), (availability, impact)} (NIST, 2004). This is drawn out and can be simplified to increase

readability with the understanding that impacts are listed in the order of Confidentiality, Integrity,

Availability (CIA). Therefore, the format this paper will use is as such: (HML), where the letters

H, M, and L stand for High, Moderate, and Low, respectively.

A key to understanding the categorization is knowing what delineates High, Moderate,

and Low impacts. These are described well in FIPS 199 (NIST, 2004) - a Low impact “[has] a

limited adverse effect on organizational operations, organizational assets, or individuals” (NIST,

2004, p. 2). Moderate impacts bring the danger up to a “serious adverse effect” (NIST, 2004, p.

2), and a High impact finishes out the scale with “catastrophic” risk that could “involv[e] loss of

life” (NIST, 2004, p. 3).

Categorization

The first step of making a change to a system is categorizing the risk the change

introduces. In this discussion, we will examine the case study of introducing new computer

systems for employees into a workspace occupied by contractors. The Program Management

(PM) Department will use these systems for contractor oversight and receipt of deliverables. This

discourse will focus on only the highest levels of risk, but comprehensive process documentation

will contain a description of all data types processed.

To start we consider what data types are going to be processed and the risk created based

on the environment. Looking to NIST 800-60 Volume II for provisional categorizations, the type

of “Labor Relations Information” has a categorization of (LLL) (NIST, 2008). As this is

provisional, we will provide rationale to adjust these categories. Since these systems will be

processing contracting data near the contractors under those contracts, Confidentiality and

Integrity are key, where Availability is less critical. By the above definitions, and the concerns

listed, the final categorization is (MML).

Control Selection

With that final categorization, the process of control selection begins, shaping the

required actions for securing the systems. This process is crucial in the design of the security

stance, as it drives the implementation, assessment, and monitoring steps. Those, in turn, inform

the authorization decision that determines if the risk has earned the right to operate. Therefore,

the selection of controls and augmentations is integral to the success of the process.

Given the high-level nature of this paper, only the controls AC-3, AC-11, and AU-2 will

be discussed here. These controls are in the families of “Access Control” and “Audit and

Accountability” (NIST, 2017), with families being a high-level groupings of series of controls.
RISK MANAGEMENT PROCESS OVERVIEW 4

The discussion will enumerate reasons to implement these controls, desired control

enhancements, and their impact on the overall security stance.

AC-3: Access Enforcement

This is a crucial control to implement because it focuses on limiting access to legitimate

users. The intent of this control is to restrict access to specified resources to only legitimate

users. RBAC does this by providing a way of assigning roles to accounts, and giving those roles

specific sets of permissions (NIST, 2017) – as in a shared drive set to only be accessible by

employees in the Finance Dept., done by assigning user accounts a role of “Finance”. This is

crucial in this case study by providing a way to increase sensitive documentation Confidentiality

and Integrity, while maintaining Availability.

AC-11: Device Lock

A regular occurrence seen in the PM Dept. is employees dashing away from their

terminals to grab a document. These actions may seem innocuous, but their terminal is left

unlocked. This gives unfettered access of network materials to any adversary nearby. The

likelihood of an external adversary making their way into this area is slim, but if the adversary

were a disgruntled employee or malicious contractor, there would be no trouble getting near

these terminals. For this reason, it is advised to implement a device locking group policy object

on the network. AC-11 provides two recommendations – both are vital to success in this scenario

(NIST, 2017). Compelling employees (via policy) to lock their devices manually as well as only

displaying irrelevant information on the lock screen (date, time, a pretty picture) (NIST, 2017)

will prevent illegitimate access to sensitive data, and upkeeping Confidentiality and Integrity,

with negligible impact on the overall Availability.

AU-2: Audit Events

This control leaves the Access Control family and moves onto Audit and Accountability –

another critical series for keeping security high in this scenario. The rationale in emphasizing this

control is tracking predetermined events – this would include illicit access attempts as well as

other events such as network intrusion attempts (NIST, 2017). Tracking these events lays out a

trail to follow in the event of network-related infractions. If a contractor attempted to access

sensitive data, and the audit logs tracked this, this could be grounds to seek legal action against

the contractor. Keeping an audit log allows the company to retrace the steps of an event, as well

as potentially fix any issues that arise from the event (e.g.- document rollback to before a specific

event). This maintains the Confidentiality and Integrity of the system, albeit in a more

roundabout way than the previous controls.

Implementation & Assessment

Deploying all the needed controls is no small feat, and nothing is more critical than the

implementation – except, perhaps, assessing if they even work. These two steps are grouped here

as a simplification – explaining how a control is implemented drives directly into how to test it,

and having them side-by-side reduces repetition. Implementation and assessment are a

continuous process because security is not a one-and-done process. For this reason, regular

assessments and upkeep of a Plan of Actions and Milestones (POAM) are critical to the security

of a system. In this vein, the next section will go over the controls from above, but study how to

implement and test them for accuracy.

AC-3: Access Control with RBAC

The specifics of implementing RBAC are beyond the scope of this paper, but discussing a

reasonable timeline for implementation is square within said scope. The scale of a company will
RISK MANAGEMENT PROCESS OVERVIEW 6

definitely drive exactly how long it will take to set the correct permissions up, and assigning the

needed roles to the proper people will take a while as well. However, for a company of our size,

two months should be appropriate. Testing if the roles are accurate will be a severe up-front time

sink in setting up the permissions/roles/personnel mappings, but will be easy to maintain over

time so long as no changes are made to the roles themselves. The greatest long-term time sink

will be ensuring that personnel that leave the company (for any reason) are immediately removed

from the system, and that there are periodic scrubs of the role mappings. However, in the long

run, these periodic reviews will prevent any resentful ex-employees from wreaking havoc in the

network, ensuring a significant increase in Integrity.

AC-11: Device Locking with Smart Cards

Where most controls in this scenario are technical in nature, the device lock control is

almost entirely policy based. An aspect of terminal locking that is time-based, but the vital

enhancement is based on personnel manually locking their devices when leaving the terminal,

and is a company policy. Using a smart card is the solution implemented in the case study at

hand – the relevant policy is that the computers will lock when a smart card is not present, and

that employees will remove their smart card when they leave their terminal. Testing this

implementation can be done by observing unattended terminals – if there is no smart card and the

terminal is locked, the assessment is positive. Implementing the smart card system and relevant

policies will be included in the POAM as a six-month milestone.

AU-2: Audit Log Reviews

Network events are occurring by the thousands every second on every active network.

Deciding what events to keep track of and how to keep track of them is on each company to

determine, and is far beyond the scope of this paper. However, testing if the audit logs accurately
RISK MANAGEMENT PROCESS OVERVIEW 7

capture the desired information is very simple, and could even be automated. Have a person or

system attempt to access data or resources they aren’t authorized to access, and look for the

corresponding log entry. By ensuring the entries are where they are expected to be in an exercise,

the company can be positive that the same entries will be found in the event of a true event. The

bottleneck for implementing audit logs is often secure storage space, but our company already

has the ability to purchase that. Therefore, the execution timeline on this will be six weeks.

Authorization

After the above work is completed, it is compiled into a standard package and presented

to the Authorizing Official (AO). This package contains all relevant information the AO will

need to make a decision on the authorization given to the system, providing one of the following:

“Authority to Operate (ATO), … Common Control Authorization, Authorization to Use, and

Denial of Authorization” (NIST, 2018, p. 73). By putting sensible items on the POAM, valid

rationale for categorizations and alterations to the network, the company can expect the

authorization to be reasonably quick and end with the desired outcome.

The AO is the risk accepting authority, the responsibility for the integrity of the network

is on their shoulders, and all systems require their approval to operate on the network. For this

scenario, with the provided categorization, controls, and assessment of the implementation, the

risk is relatively low. The POAM provides a roadmap for the system to further reduce risk at

expected intervals, allowing for a calculated risk assessment. Given this information, the AO

would provide the system with a full ATO, given the caveat of adherence to the POAM.

Continuous Monitoring

Mentioned previously, security is not a one-time effort. The threat landscape is constantly

shifting as old threats are made obsolete and new threats emerge from their ashes. To combat this
RISK MANAGEMENT PROCESS OVERVIEW 8

fluctuating battlefield, security experts are constantly updating policies and reviewing their

security stances against emerging dangers. This review is to be done periodically, if a review

hasn’t already occurred in the last three months, or if any system or environment changes occur

(NIST, 2018). Patches and updates to current system hardware and software need to be reviewed,

but are often an action taken as part of the continuous monitoring process rather than as

something reviewed after-the-fact. Reassessments are a vital aspect of this process as they

provide up-to-date information on the effectiveness of the controls and security stance as a

whole. As these reexaminations are completed it is critical to update plans and documentation,

and provide updates to the POAM, as needed. If any changes are so drastic that they change the

risk stature of the network, it is integral to start a new ATO package for review. An ATO has a

small tolerance built into it (security patches, updates, etc.) but adding new sources of risk

requires a full review and re-authorization to ensure overall security remains.

Summary

In the case study presented above, we walked through the steps of the Risk Management

Framework, with some high-level examples. Using the scenario to drive the discussion through

the cycle of RMF, we documented a myriad of important information – the risk categorization of

the system, relevant controls, and how their implementation drives their assessment. From there

the POAM was generated and provided to the AO in the ATO package, and a full ATO was

granted based on the AO’s risk assessment. This began the final cycle of continuous monitoring

that will continue the rest of the system’s lifecycle, providing ever-changes adaptation to the

instabilities of the threat landscape. RMF provided the guiding hand to prevent millions to

billions of dollars in losses by providing the foundation to build a stable security plan upon.
RISK MANAGEMENT PROCESS OVERVIEW 9

References

NIST. (2004). Standards for Security Categorization of Federal Information and Information

Systems (199). Retrieved from https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf

NIST. (2008). Volume II: Appendices to Guide for Mapping Types of Information and

Information Systems to Security Categories (800-60 Vol. 2 Rev 1). Retrieved from

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v2r1.pdf

NIST. (2017). Security and Privacy Controls for Information Systems and Organizations (800-

53r5). Retrieved from https://csrc.nist.gov/CSRC/media//Publications/sp/800-53/rev-

5/draft/documents/sp800-53r5-draft.pdf

NIST. (2018). Risk Management Framework for Information Systems and Organizations (800-

37r2). Retrieved from https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

37r2.pdf