Awareness of your organization’s threat environment should be maintained so that appropriate mitigation actions can be planned and executed. Information relating to security threats should be collected and analyzed to determine actions that need to be performed to prevent the identified threats from causing harm to the organization or reducing the impact of such threats. Threat intelligence should be relevant, insightful, contextual, and actionable. It can be divided into three layers:
- Tactical: Information about attacker methodologies, including the tools and technologies involved in attacks
- Strategic: High-level information about changes to the threat landscape
- Operational: Details about specific attacks, including technical indicators or an attack
Analysis of Threat Intelligence Information
Once threat intelligence information is analyzed, it can be used to implement processes into the risk management program to address threats that apply to your organization. This information may also serve as an additional input into your technical preventive and detective controls such as anti-malware, intrusion detection system, and other security system configurations. Your organization may choose to share threat intelligence information with other organizations similar to yours as part of a mutual agreement to help improve overall threat intelligence in your industry.
Someone within your organization should be assigned the responsibility for threat monitoring activities to support an effective threat awareness program. At a minimum, threat awareness procedures should address the following:
- Identification and prioritization of threat information sources, for example:
- Vendor notifications
- Industry security groups
- Weather alerts
- Law enforcement alerts (e.g., FBI InfraGard)
- US-CERT
- Industry-specific ISACs
- Monitoring frequency
- Threat analysis and validation
- Threat communications
- Impact and trend analysis
- Information categorization by criticality, likelihood, and timeframe
- Reporting findings that apply to the organization
Insider Threats
Processes should be implemented to address insider threats. Any organization that manages or processes classified information is required to develop and implement an insider threat program as a result of Executive Order 13587 as well as the National Insider Threat Policy. The same standards and guidelines that apply to insider threat programs in environments with classified information can be used to improve the protection of controlled unclassified and other sensitive information in non-national security systems.
Risk management program components that address insider threats should include controls to detect and prevent malicious insider activity. This can be accomplished through the centralized integration and analysis of both technical as well as nontechnical information to identify potential insider threat concerns. Be sure that a senior leader, such as the CISO or potentially a standalone risk leadership role, is assigned the responsibility of implementing and providing oversight for the program.
Security Alerts, Advisories, and Directives
Many sources of security alerts and advisories are publicly available to all organizations. The United States Computer Emergency Readiness Team (US-CERT) and the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) generate security alerts and advisories to help maintain situational awareness for federal government and non-federal organizations. Software vendors, subscription services, and industry-specific information sharing and analysis centers (ISACs) are also reliable sources for security alerts and advisories.
Security directives, such as those issued by OMB or other designated organizations, contain detailed threat information with which compliance is essential due to the critical nature of the threat described in the directives, along with the potentially immediate adverse effects the threat may have on operations, assets, individuals, and other organizations.
Procedures should be developed for obtaining, monitoring, assessing, and responding to evolving threat and vulnerability information. The identification of threats should include the source of each threat, its capabilities, and the objectives of the threat. Knowledge of threat sources is particularly important to help identify vulnerabilities. Vulnerabilities can occur in multiple areas, such as system design, system operation, security process, line of business controls, and system implementation.
Once a threat is identified and potential vulnerabilities are assessed, a response should be triggered. The response should be commensurate with the risk posed by the threat. Appropriate remediation options should be defined for response activities. When vulnerability information is received from external groups or individuals, appropriate processes and procedures should be followed to evaluate the credibility of the information, assess applicability to your environment, and take appropriate steps to address the threat. Processes should allow for immediate and consequential threats to be dealt with expeditiously, while less significant threats may be addressed as part of a broader risk management process.
Security Categorizations
Security categories for information systems need to be defined within your organization to enable appropriate risk decisions to be made. Without this categorization, you could potentially expend valuable time and resources to protect a lower impact, lower risk system instead of focusing attention on a higher impact or higher risk system. It is important to protect all systems, but protection levels should be based on the level of risk associated with various groups of information systems.
Security categorization is a type of asset loss characterization that should be performed throughout the system development life cycle (SDLC) for assets. Security categories describe the potential adverse impacts or consequences to your organization’s operations, assets, and individuals if information and information systems are compromised through a loss of confidentiality, integrity, or availability.
Information systems should be categorized based on the information they process, store, or transmit by applicable laws, directives, policies, regulations, standards, and guidance. Additionally, categorization should be based on the information systems’ business importance or criticality. A system authorizing official, or a designated representative, should review and approve all security categorization decisions.
Pro Tip:
IT assets may have different security categories throughout their lifecycle. Be sure to review and update security categorization assignments as assets transition from one phase in the SDLC to another to maintain appropriate controls.
Security categorization results, including the supporting rationale, should be documented in a System Security Plan (SSP) or your overall security program plan. Even if an SSP is not a regulatory requirement for any of your organization’s systems, implementing an SSP is an effective way to identify a system’s security categorization. An SSP also contains information about your security program controls, along with specific details on how control requirements are being addressed. This can be an effective tool used to describe how you protect critical systems.
Assumptions or constraints that could affect risk assessments, risk responses, and associated risk monitoring should be identified. The risk tolerance for your organization defined by the risk appetite statement should take priorities and trade-offs into consideration for managing risk throughout the SDLC.
The security categorization process should be performed as an organization-wide activity. Senior leadership, system owners, business owners, and information owners should all be involved. During the categorization, you should also consider the potential adverse impacts to other organizations and, by the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives, potential national-level adverse impacts.
