(ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide. Mike Chapple
Чтение книги онлайн.
Читать онлайн книгу (ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide - Mike Chapple страница 63
TABLE 2.2 Quantitative risk analysis formulas
Concept | Formula or meaning |
---|---|
Asset value (AV) | $ |
Exposure factor (EF) | % |
Single loss expectancy (SLE) | SLE = AV * EF |
Annualized rate of occurrence (ARO) | # / year |
Annualized loss expectancy (ALE) | ALE = SLE * ARO or ALE = AV * EF * ARO |
Annual cost of the safeguard (ACS) | $ / year |
Value or benefit of a safeguard (i.e., cost/benefit equation) | (ALE1 – ALE2) – ACS |
Yikes, So Much Math!
Yes, quantitative risk analysis involves a lot of math. Math questions on the CISSP exam are likely to involve basic multiplication. Most likely, you will be asked definition, application, and concept synthesis questions on the exam. This means you need to know the definition of the equations/formulas and values (Table 2.2), what they mean, why they are important, and how they are used to benefit an organization.
Most organizations have a limited and all-too-finite budget to work with. Thus, obtaining the best security for the cost is an essential part of security management. To effectively manage the security function, you must assess the budget, the benefit and performance metrics, and the necessary resources of each security control. Only after a thorough evaluation can you determine which controls are essential and beneficial not only to security, but also to your bottom line. Generally, it is not an acceptable excuse that the reason the organization did not protect against an unacceptable threat or risk was solely because of a lack of funds. The entirety of safeguard selections needs to be considered in relation to the current budget. Compromise or adjustments of priorities may be necessary in order to reduce overall risk to an acceptable level with available resources. Keep in mind that organizational security should be based on a business case, be legally justifiable, and be reasonably in line with security frameworks, regulations, and best practices.
Countermeasure Selection and Implementation
Selecting a countermeasure, safeguard, or control (short for security control) within the realm of risk management relies heavily on the cost/benefit analysis results. However, you should consider several other factors when assessing the value or pertinence of a security control:
The cost of the countermeasure should be less than the value of the asset.
The cost of the countermeasure should be less than the benefit of the countermeasure.
The result of the applied countermeasure should make the cost of an attack greater for the perpetrator than the derived benefit from an attack.
The countermeasure should provide a solution to a real and identified problem. (Don't install countermeasures just because they are available, are advertised, or sound appealing.)
The benefit of the countermeasure should not be dependent on its secrecy. Any viable countermeasure can withstand public disclosure and scrutiny and thus maintain protection even when known.
The benefit of the countermeasure should be testable and verifiable.
The countermeasure should provide consistent and uniform protection across all users, systems, protocols, and so on.
The countermeasure should have few or no dependencies to reduce cascade failures.
The countermeasure should require minimal human intervention after initial deployment and configuration.
The countermeasure should be tamperproof.
The countermeasure should have overrides accessible to privileged operators only.
The countermeasure should provide fail-safe and/or fail-secure options.
Keep in mind that security should be designed to support and enable business tasks and functions. Thus, countermeasures and safeguards need to be evaluated in the context of a business process. If there is no clear business case for a safeguard, it is probably not an effective security option.
Security controls, countermeasures, and safeguards can be implemented administratively, logically/technically, or physically. These three categories of security mechanisms should be implemented in a conceptual layered defense-in-depth manner in order to provide maximum benefit (Figure 2.4). This idea is based on the concept that policies (part of administrative controls) drive all aspects of security and thus form the initial protection layer around assets. Next, logical and technical controls provide protection against logical attacks and exploits. Then, the physical controls provide protection against real-world physical attacks against the facility and devices.
FIGURE 2.4 The categories of security controls in a defense-in-depth implementation
Administrative
The category of administrative controls are the policies and procedures defined by an organization's security policy and other regulations or requirements. They are sometimes referred to as management controls, managerial controls, or procedural controls. These controls focus on personnel oversight and business practices. Examples of administrative controls include policies, procedures, hiring practices, background checks, data classifications and labeling, security awareness and training efforts, reports and reviews, work supervision, personnel controls, and testing.
Technical or Logical
The category of technical controls or logical controls involves the hardware or software mechanisms used to manage access and provide protection for IT resources and systems. Examples of logical or technical controls include authentication methods (such as passwords, smartcards, and biometrics), encryption, constrained interfaces, access control lists, protocols, firewalls, routers, intrusion detection systems (IDSs), and clipping levels.
Physical
Physical controls are security mechanisms focused on providing protection to the facility and real-world objects.