Perspectiva de los egresados

Risk is a function of the likelihood of a given threat source exploiting a potential vulnerability and the resulting impact of exploiting this vulnerability. Risk assessment is the process of identifying risks to an organization’s operations, assets, and individuals by determining the probability of occurrence that an identified threat will exploit an identified vulnerability and the resulting impact. An assessment includes an evaluation of security controls that can mitigate each threat and the costs associated with implementing them. A risk assessment must also compare the cost of security with the costs associated with an

incident.

Achieving an acceptable level of risk is a process of reducing the probability of an incident that is accomplished by mitigating or eliminating vulnerabilities that can be exploited as well as consequences resulting from an incident. Prioritization of vulnerabilities must be based on cost and benefit with an objective to provide a business case for implementing at least a minimum set of control system security requirements to reduce risk to an acceptable level. A mistake often made during a risk assessment is to select technically interesting vulnerabilities without taking into account the level of risk associated with them. Vulnerabilities should be assessed and rated for risk before trying to select and implement security controls on them.

The security controls that fall within the NIST SP 800-53 Risk Assessment (RA) family provide policy and procedures to develop, distribute, and maintain a documented risk assessment policy that describes purpose, scope, roles, responsibilities, and compliance as well as policy implementation procedures. An information system and associated data is categorized based on the security objectives and a range of risk levels. A risk assessment is performed to identify risks and the magnitude of harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of an information system and data. Also included in these controls are mechanisms for keeping risk assessments up-to-date and performing periodic vulnerability assessments.

In the FISMA Risk Framework shown in Figure E-1 in Appendix E, the risk assessment process is applied after the Security Categorization activity and baseline Security Control Selection activity. Risk assessment is performed in the Security Control Refinement activity to determine if the selected security controls need to be enhanced or expanded beyond the baseline security controls. NIST SP 800-30, Risk Management Guide for Information Technology Systems (currently under revision) provides a risk assessment methodology, which includes the following steps:

1. System characterization – produces a picture of the information system environment, and delineation of system boundaries

2. Threat identification – produces a threat statement containing a list of threat-sources that could exploit system vulnerabilities

3. Vulnerability identification – produces a list of the system vulnerabilities that could be exercised by the potential threat sources

4. Control analysis – produces a list of the planned controls used for the information system to mitigate the likelihood of a vulnerability being exercised and reduce the impact of such an adverse event.

5. Likelihood determination – produces a likelihood rating (High, Medium, or Low) that indicates the probability that a potential vulnerability may be exercised

6. Impact analysis – produces a magnitude of impact (High, Medium, or Low) resulting from the exploitation of a vulnerability.

7. Risk determination – produces measurement for risk based on a scale of high, medium, or low 8. Control recommendations – produces recommendations of security controls and alternative

solutions to mitigate risk

9. Results documentation – produces a risk assessment report that describes the threats and vulnerabilities, measures the risk, and provides recommendations for control implementation. Supplemental guidance for the RA controls can be found in the following documents:

NIST SP 800-12 provides guidance on security policies and procedures [39].

NIST SP 800-30 provides guidance on conducting risk assessments and updates [19]. NIST SP 800-40 provides guidance on handling security patches [40].

NIST SP 800-42 provides guidance on network security testing [41].

NIST SP 800-60 provides guidance on determining security categories for information types [24].

ICS Specific Recommendations and Guidance

Organizations must consider the potential consequences resulting from an incident on an ICS. Well- defined policy and procedures lead to mitigation techniques designed to thwart incidents and manage the risk to eliminate or minimize the consequences. The degradation of the physical plant, economic status, or national confidence could justify mitigation. For an ICS, a very important aspect of the risk assessment is to determine the value of the data that is flowing from the control network to the corporate network. In instances where pricing decisions are determined from this data, the data could have a very high value. The fiscal justification for mitigation has to be derived by the cost benefit compared to the effects of the consequence. However, it is not possible to define a one-size-fits-all set of security requirements. A very high level of security may be achievable but undesirable in many situations because of the loss of functionality and other associated costs. A well-thought-out security implementation is a balance of risk versus cost. In some situations the risk may be safety, health, or environment-related rather than purely economic. The risk may result in an unrecoverable

consequence rather than a temporary financial setback

6.1.2 Planning

A security plan is a 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. The security controls that fall within the NIST SP 800-53 Planning (PL) family provide the basis for developing a security plan. These controls also address maintenance issues for periodically updating a security plan. A set of rules describes user responsibilities and expected behavior regarding information system usage with provision for signed acknowledgement from users indicating that they have read, understand, and agree to abide by the rules of behavior before authorizing access to the

Supplemental guidance for the PL controls can be found in the following documents: NIST SP 800-12 provides guidance on security policies and procedures [39]. NIST SP 800-18 provides guidance on preparing rules of behavior [17].

ICS Specific Recommendations and Guidance

A security plan for an ICS should build on appropriate existing IT security experience, programs, and practices. However, the critical differences between IT and ICS addressed in Section 3.1 will influence how security will be applied to the ICS. A forward-looking plan is needed to provide a method for continuous security improvements. ICS security is a rapidly evolving field requiring the security planning process to constantly explore emerging ICS security capabilities as well as new threats that identified by organizations such as the US-CERT Control Systems Security Center (CSSC).