risk identification

Risk identification is done with a risk assessment.  NIST SP 800-30, Guide for Conducting Risk Assessments breaks down the entire process of risk determination, risk identification.

As described in the earlier post DIACAP Process:

Risk = ((Vulnerability * Threat) / Countermeasure) * Asset Value at Risk IT Risk

Risk is the likelihood that a threat will compromise the weakness of an asset.  So risk identification is based on knowing the threat, the vulnerability and the asset.

The better you understand these factors, the better your chances of risk determination and risk identification.

NIST SP 800-39, Managing Information Security Risk is a document that defines risk management as the process of not only identifying risk but also, assessing risk, and taking steps to mitigate risks for fit within one of the types or risk, risk acceptance.

Risk identification starts off with identification of the asset.

1)  System characterization – Gather information into a System Security Plan (SSP).  Identifying risk requires a deep understanding of the asset and its environment.  Asset information for the SSP will cover the following:

• Hardware
• Software
• System interfaces (e.g., internal and external connectivity)
• Data and information
• Persons who support and use the IT system
• System mission (e.g., the processes performed by the IT system)
• System and data critical (e.g., the system’s value or importance to an organization)
• System and data sensitivity

2)  Threat Identification – Without a defined threat, there is no way to quantify or identify a threat.  Threat identification starts with looking at the threat sources and events.  An example to look for threat sources historical data.  When has the asset or similar assets from other related organizations in the same industry been attacked or suffered disaster.  Remember a threat source is not just criminal-hackers and malware, it can be a natural disaster or unintentional destruction of data or a power outage.

3)  Vulnerability Identification – Once the asset and threat are identified, you can more easily determine if your system has a weakness for that particular disaster or exploit.  Again, you can look at historical evidence that suggest weakness.  You can use scanners to find open ports that are exposed to the Internet.

4)  Security Control Analysis – If your system already has security controls in place, you must take that into account because this may lower your risk.

5)  Likelihood determination – The probability that your asset will be exploited is based on the threat source motivation, threat capability, your vulnerability and the security controls you have in place.   Based on all these factors you can calculated the likelihood of an attack or disaster.

6)  Impact Analysis – This where you gather all the data from asset identification, threat source, vulnerability identification, security controls, likelihood of attack and figure you what would happen if something really did happen.  How important is your system and its data?  What would happen to the mission or bottom line or profits if the system went down for a few hours?  a few days? a few weeks?  Some system are so important that they cannot be down for even a minute.  Impact is very important to the level of risk.  The more important the system is, the high the risk.

7)  Risk Determination / Risk Identification – Based on all the data gathered you can make a pretty good risk determination.  You should have defined the systems components and what data is important, made a pretty good conclusion on threat sources and likelihood of the vulnerability exploits and know exactly what kind of impact there will be if the system goes down.

Who does risk identification:

Ultimately it is the information system owner and authorizing official that must make a determination on what kind of risk they will accept, but they rely heavily on the expertise of an information security engineer, information system security manager,  information system security officer and technical professionals to articulate what is happening on the ground.

The ISSO/ISSM/ISSE typically document the process mentioned above or the DIARMF process.  Security professionals coordinate with IT professionals to “get into the weeds” of technical security controls and vulnerabilities.