Название: (ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide
Автор: Mike Chapple
Издательство: John Wiley & Sons Limited
Жанр: Зарубежная компьютерная литература
isbn: 9781119786245
isbn:
Competition is often a key part of business growth, but overly adversarial competition can increase the threat level from individuals. In addition to criminal hackers and disgruntled employees, adversaries, contractors, employees, and even trusted partners can be a threat to an organization if relationships go sour.
Potential threats to your business are broad and varied. A company faces threats from nature, technology, and people. Always consider the best and worst possible outcomes of your organization's activities, decisions, and interactions. Identifying threats is the first step toward designing defenses to help reduce or eliminate downtime, compromise, and loss.
Determining and Diagramming Potential Attacks
The next step in threat modeling is to determine the potential attack concepts that could be realized. This is often accomplished through the creation of a diagram of the elements involved in a transaction along with indications of data flow and privilege boundaries (Figure 1.4). This image shows each major component of a system, the boundaries between security zones, and the potential flow or movement of information and data.
This is a high-level overview and not a detailed evaluation of the coding logic. However, for more complex systems, multiple diagrams may need to be created at various focus points and at varying levels of detail magnification.
Once a diagram has been crafted, identify all of the technologies involved. Next, identify attacks that could be targeted at each element of the diagram. Keep in mind that all forms of attacks should be considered, including logical/technical, physical, and social. This process will quickly lead you into the next phase of threat modeling: reduction analysis.
Performing Reduction Analysis
The next step in threat modeling is to perform reduction analysis. Reduction analysis is also known as decomposing the application, system, or environment. The purpose of this task is to gain a greater understanding of the logic of the product, its internal components, as well as its interactions with external elements. Whether an application, a system, or an entire environment, it needs to be divided into smaller containers or compartments. Those might be subroutines, modules, or objects if you're focusing on software, computers, or operating systems; they might be protocols if you're focusing on systems or networks; or they might be departments, tasks, and networks if you're focusing on an entire business infrastructure. Each identified element should be evaluated in order to understand inputs, processing, security, data management, storage, and outputs.
FIGURE 1.4 An example of diagramming to reveal threat concerns
In the decomposition process, you must identify five key concepts:
Trust Boundaries Any location where the level of trust or security changes
Dataflow Paths The movement of data between locations
Input Points Locations where external input is received
Privileged Operations Any activity that requires greater privileges than of a standard user account or process, typically required to make system changes or alter security
Details about Security Stance and Approach The declaration of the security policy, security foundations, and security assumptions
Breaking down a system into its constituent parts makes it much easier to identify the essential components of each element as well as take notice of vulnerabilities and points of attack. The more you understand exactly how a program, system, or environment operates, the easier it is to identify threats to it.
Once threats are identified, they should be fully documented by defining the means, target, and consequences of a threat. Consider including the techniques required to implement an exploitation as well as list potential countermeasures and safeguards.
Prioritization and Response
After documentation, the next step is to rank or rate the threats. This can be accomplished using a wide range of techniques, such as Probability × Damage Potential ranking, high/medium/low rating, or the DREAD system.
The ranking technique of Probability × Damage Potential produces a risk severity number on a scale of 1 to 100, with 100 the most severe risk possible. Each of the two initial values can be assigned numbers between 1 and 10, with 1 being lowest and 10 the highest. These rankings can be somewhat arbitrary and subjective, but since the same person or team will be assigning the numbers for their own organization, it should still result in assessment values that are accurate on a relative basis.
The high/medium/low (1/2/3 or green/yellow/red) rating process is even simpler. It creates a basic risk matrix or heat map (Figure 1.5). As with any means of risk assessment, the purpose is to help establish criticality prioritization. Using a risk matrix, each threat can be assigned a probability and a damage level. Then when these two values are compared, the result is a combined value somewhere in the nine squares. Those threats in the HH (high probability/high damage) area are of the highest priority and concern, whereas those in the LL (low probability/low damage) area are of least priority and concern.
FIGURE 1.5 A risk matrix or risk heat map
The Disaster, Reproducibility, Exploitability, Affected Users, and Discoverability (DREAD) rating system is designed to provide a flexible rating solution that is based on the answers to five main questions about each threat:
Damage Potential How severe is the damage likely to be if the threat is realized?
Reproducibility How complicated is it for attackers to reproduce the exploit?
Exploitability How hard is it to perform the attack?
Affected Users How many users are likely to be affected by the attack (as a percentage)?
Discoverability How hard is it for an attacker to discover the weakness?
Once threat priorities are set, responses to those threats need to be determined. Technologies and processes to remediate threats should be considered and weighted according to their cost and effectiveness. Response options should include making adjustments to software architecture, altering operations and processes, and implementing defensive and detective components.
This process is similar to the risk assessment process discussed in Chapter 2. The difference is that threats are the focus of threat modeling, whereas assets are the focus of risk assessment.
Supply Chain Risk Management
Applying risk-based management concepts to the supply СКАЧАТЬ