What is Risk?

Risk can be defined in a number of ways. For example, the National Institute of Standardsand Technology (NIST) defines risk as the following:

  • A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.

The SysAdmin, Audit, Network and Security (SANS) Institute often defines risk in another way:

  • Risk is the potential for loss or harm that is realized when a threat intersects with a vulnerability in an organization.

In layman’s terms, risk is the chance you take when you drive a vehicle without insurance. If you wreck your vehicle, you won’t be reimbursed for the repairs. It’s a financial loss that comes straight out of your pocket because you didn’t minimize the financial risk by purchasing insurance. Regardless of how it’s formally defined, risk is the chance that something bad could happen anda loss is realized. As such, risk needs to be managed to reduce the likelihood and impact that could result.

What is Risk Management?

Risk management is a process in which an organization constantly assesses the level of risk it faces and takes action to reduce that risk to a measure that is acceptable to senior management. For example, if you own an e-commerce business and you have one Internet-facing web server to host your online store, there’s a risk that you would lose money if suddenly that web server was inaccessible and your e-commerce site was no longer online. If such a loss is costing your business tens of thousands of dollars a day, you’d gladly spend a fraction of that to pay for a second or third web server at another data center to provide failover capability for your business. If the primary e-commerce site suddenly is inaccessible, you can switch to your second or third web site without losing the ability to operate and conduct business.

That’s how risk management works. You look at the threats and vulnerabilities that your organization faces. You then take steps to reduce the resulting riskby mitigating the vulnerabilities and planning for the threats. The goal is to successfully mitigate such risks before the associated threat(s) can manifest and harm the organization.

At UAB, risk management related to information technology is used in a variety of ways, including:

  • Protecting valuable information technology assets, such as Sensitive and Restricted data,
  • Guiding decisions on how best to apply information security controls, and
  • Prioritizing strategic initiatives aimed at reducing the level of risk the university faces.

How Should Risk Be Managed?

NIST’s Risk Management Framework provides a cyclical, six-step process for assessing and managing risk that is embraced by many organizations and federal agencies. In Special Publication (SP) 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, NIST lays out its recommended plan for identifying, controlling, and continuously monitoring risk tied to each information system in an organization.

This framework, illustrated above, is designed to create a repeatable process that accomplishes the following tasks using a variety of publications and guidance provided by NIST:

  1. Categorize the sensitivity of the system’s data, followed by the enumeration of risks that might compromise the confidentiality, integrity, and availability of both the data and the information system. Associated NIST publications: FIPS 199 and SP 800-60.
  2. Select a specific set of security controls based on the sensitivity of the data and implement these controls while architecting the information system during the software/system development life cycle (SDLC). Associated NIST publications: FIPS 200 and SP 800-53
  3. Implement and test the security controls as the information system is built. Associated NIST publications: SP 800-34, SP 800-61, and SP 800-128
  4. Assess the performance and effectiveness of both the information system and the security controls to provide assurance that they are working as intended. Associated NIST publication: SP 800-53A
  5. Gain authorization and approval for the information system to begin processing, transmitting, and storing data to accomplish its mission. Associated NIST publication: SP 800-37
  6. Continuously monitor the security controls to ensure they are effective during the life cycle of the information system. Associated NIST publications: SP 800-37, SP 800-53A, SP 800-137.

How Do UAB Policies and Standards Apply to Risk Management?

In addition to following NIST guidance when utilizing the six steps of the Risk Management Framework, UAB employees also must follow policies and standards thattie directly to steps 1 through 4 of the Framework. In Step 1, Categorize the System, employees must use the UAB Data Classification Rule in addition to FIPS 199to classify the data and its associated information system(s). UAB classifies data using the following taxonomy:

  • Public Data: Data that may be disclosed to the general public without harm. Examples include public phone directory, course catalogs, public research findings, enrollment figures, public web sites, general benefits data, press releases, newsletters, etc.
  • Sensitive Data: Data that should be kept confidential. Access to these data shall require authorization and legitimate need-to-know. Privacy may be required by law or contract. Examples include FERPA, budgetary plans, proprietary business plans, patent pending information, export controls information and data protected by law. When mapping to a security classification level for FIPS 199 and 200, Sensitive data at UAB likely will be classified as Low, and the appropriate Low security controls detailed in SP 800-53 are required.
  • Restricted/PHI Data: Sensitive Data that is highly confidential in nature, carries significant risk from unauthorized access, or uninterrupted accessibility is critical to UAB operation. Privacy and Security controls are typically required by law or contract. Examples include HIPAA PHI, Social Security numbers, credit card numbers (PCI DSS), GLBA data, Export Controlled data, FISMA regulated data, log-in credentials, and information protected by non-disclosure agreements. When mapping to a security classification level for FIPS 199 and 200, Restricted/PHI data will be classified as Moderate, and the appropriate Moderate security controls detailed in SP 800-53 are required.

In Steps 2 and 3 of the Framework, Select and Implement the Controls, employees must use the UAB Data Protection Rule and ensure that any security controls that UAB requires also are selected and implemented when applying the appropriate controls mandated by SP 800-53.

That’s a lot to absorb, so let’s look at a couple of examples of how the Risk Management Framework could be applied at UAB.

Scenario: An information system is going to created and deployed to process and store patient health data for a federal grant. Here are the general steps of how the Risk Management Framework is applied:

  1. Categorize the Data and the System: UAB classifies the patient health information tied to this grant as Restricted/PHI. This means that, according to FIPS 199 and 200, the data will be considered Moderate in regard to the levels of confidentiality, integrity, and availability that must be applied to protect the data and the system.
  2. Select the Security Controls: Now that the data has been classified, the UAB employee(s) consults the UAB Data Protection Rule to see what security controls are required for all Restricted/PHI data. These controls are applied to the architecture and design of the information system that is being built for this project. The UAB employee(s) also refer to SP 800-53 and ensure that all of the Moderate security controls are applied to the architecture and design of the information system. Note: Some of these controls will overlap.
  3. Implement the Controls: The combined controls from UAB’s Data Protection Rule and the Moderate set of controls from SP 800-53 will be used to secure the information system.
  4. Assess the Controls: The required controls for Restricted/PHI and Moderate data detailed in both the UAB Protection Rule and SP 800-53 will be tested and validated.
  5. Steps 5 and 6: These two steps will be conducted as described earlier in this document.

Where Can I Learn More About Risk Management?

NIST’s various special publications can be found at the following links:

DOCUMENT TITLE LINK
FIPS 199 Standards for Security Categorization of Federal Information and Information Systems Link to NIST FIPS 199 Guidance
FIPS 200 Minimum Security Requirements for Federal Informationand Information Systems Link to NIST FIPS 200 Guidance
NIST SP 800-30 Guide for Conducting Risk Assessments Link to NIST SP 800-30 Guidance
NIST SP 800-34 Contingency Planning Guide for Federal Information Systems Link to NIST SP 800-34 Guidance
NIST SP 800-37 Guide for Applying the Risk Management Framework to Federal Information Systems Link to NIST SP 800-37 Guidance
NIST SP 800-50 Building an Information Technology Security Awareness and Training Program Link to NIST SP 800-50 Guidance
NIST SP 800-53, Rev. 4 Security and Privacy Controls for Federal Information Systems and Organizations Link to NIST SP 800-53, Rev. 4 Guidance
NIST SP 800-53A Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans Link to NIST SP 800-53A Guidance
NIST SP 800-60 Guide for Mapping Types of Information and Information Systems to Security Categories Link to NIST SP 800-60 Guidance
NIST SP 800-61 Computer Security Incident Handling Guide Link to NIST SP 800-61 Guidance
NIST SP 800-64, Rev. 2 Security Considerations in the System Development Life Cycle Link to NIST SP 800-64, Rev. 2 Guidance
NIST SP 800-128 Guide for Security-Focused Configuration Management of Information Systems Link to NIST SP 800-128 Guidance
NIST SP 800-137 Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations Link to NIST SP 800-137 Guidance

Glossary

This is a list of acronyms and NIST-specific terms that readers likely will encounter when reviewing NIST Special Publication documentation.

Assurance (or Information Assurance): Measure of confidence that the security features, practices, procedures, and architecture of an information system accurately mediate and enforces the security policy.

Authorization to Operate (ATO): The official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls. An ATO must be issued to a research organization before it can begin working with federal data associated with a grant or contract.

Authorizing Official (AO): A senior (federal) official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.

Availability: Ensuring the timely and reliable access and use of information.

Business Impact Analysis: An analysis of an information system’s requirements, functions, and interdependencies used to characterize system contingency requirements and priorities in the event of a significant disruption.

Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

Configuration Control Board (CCB): A group of qualified people with responsibility for the process of regulating and approving changes to hardware, firmware, software, and documentation throughout the development and operational life cycle of an information system.

FIPS: Federal Information Processing Standard

FISMA: Federal Information Security Management Act

Information: Any communication or representation of knowledge, such as facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual.

Information Security: The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

Information System: A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

Information System Security Officer (ISSO): Individual who is assigned responsibility for maintaining the appropriate operational security posture for an information system or program.

Integrity: Guarding against improper information modification or destruction, which includes ensuring information non-repudiation and authenticity.

IT-SP: Information Technology Security Plan; see System Security Plan

NIST:National Institute of Standards and Technology

Personally Identifiable Information (PII): Information which can be used to distinguish or trace the identity of an individual (e.g., name, social security number, biometric records, etc.) alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual (e.g., date and place of birth, mother’s maiden name, etc.).

Plan of Action & Milestones (POA&M): A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.

Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.

Risk Assessment (RA): The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses,and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis.

Risk Management: The program and supporting processes to manage information security risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, and includes: (i) establishing the context for risk-related activities; (ii) assessing risk; (iii) responding to risk once determined; and (iv) monitoring risk over time.

Risk Management Framework (RMF): A six-step process created by the National Institute of Standards and Technology, detailed in NIST Special Publication 800-37: Guide for Applying the Risk Management Framework to Federal Information Systems.

RiskMitigation: Prioritizing, evaluating, and implementing the appropriate risk-reducing controls/countermeasures recommended from the risk management process.

SSP: See System Security Plan

Security Assessment Report (SAR): This deliverable is one of three key documents in the security authorization package developed for authorizing officials. The assessment report includes information from the assessor/auditor that is necessary to determine the effectiveness of the security controls employed within or inherited by the information system based upon the assessor’s findings.

Security Control: A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.

System Owner (SO):Official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system.

System Security Plan (SSP):Formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements.

Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.

Vulnerability: A weakness in a system, application, or network that is subject to exploitation or misuse.