Risk basically risk has two definitions now:
- The likelihood of something bad happening.
- An event that has a negative impact. An example would be a breach, or DDOS attack.
This is typical of how the industry discusses risk, and we don’t think that the rote definition will play into your exam too much (except for maybe presenting scenarios as risks on occasion), and for that reason we prefer to focus on the older definition (number 1 above), because it aligns better with concepts like “acceptable risk” and “risk mitigation” (because think about it, you wouldn’t say “acceptable DDOS” would you? – – and the related concepts aren’t changing).
Acceptable risk – is the amount of risk that senior management is willing to accept, for example, every business has the risk of a break in happening. If your business manufactures valuable goods like TVs or electronics, and if it’s located in a high crime area, there is a high risk of break-ins. If management decides not to put any locks on the doors and not hire any security guards, they are accepting the risk of a break in.
Vulnerability is a weakness, or lack of a safeguard, such as a broken fence. Again, a safeguard is a control.
Threat is something that can take advantage of the vulnerability, such as a thief in our case of the broken fence. It can also be a circumstance, such as the weather.
Hazard is basically a natural disaster like an earthquake or tornado.
Mitigation refers to the action taken to reduce the risk, such as fixing the fence. Mitigation can be partial or whole. Mitigation basically reduces the risk to an acceptable level. A related term is Residual Risk, this refers to the remaining risk after mitigation is performed. For example, people can still use a ladder to climb the fence, or use a tank to plow through the fence.
Risk exposure is another key concept in risk management, encompassing three distinct meanings:
An exposure estimate implies what the risk is in terms of high or low, and requires you to know what the category it is, or minimally what type of risk (for example: insider threat). In addition, exposure estimates require you to know the risk level by categories for the organization. For example, if the company’s employees do not have access to the top secret information, then the exposure estimate for insider threat may be ‘low’ or ‘none’.
Exposure factor has to do with the amount of reduction to the asset’s value (or the amount of damage). An exposure factor of 0.25, or 25% would mean that the asset’s value would be reduced by ¼ if a risk event were to occur. An exposure factor of 1, or 100% would indicate complete destruction of the asset.
Exposure window refers to the time period that an asset or organization is exposed to the risk. The CBK gives the example of car crashes. If you have a 1-hour commute each day, your exposure window is 2 hours. If you have data in transit that sits on a server for 1 hour in plaintext before it gets encrypted, the exposure window is 1 hour.
Risk perspectives
Is the approach an organization can take in managing its risk.
Asset-based is identifying risks based on what can happen to your assets.
Outcomes-based is identifying what can happen to your desired outcomes, such as profits, income, or sales.
Process-based is focused on safety outcomes.
Vulnerability-based is centered around inherent weaknesses.
Threat-based revolves around who can perform the attacks.
Risk Analysis
Management makes two decisions about risk. The decisions are:
- Prioritize.
- Decide how to handle the risk. This is where the four sub-decisions come into play:
a. Mitigate – This refers to reducing the amount of risk to an acceptable level.
b. Accept – This refers to not doing anything. Management simply accepts the risk as-is and is willing to suffer the consequences.
c. Transfer – This refers to having someone else accept the risk, typically through insurance.
- ISO 27005 redefines “risk transfer” as “risk sharing” to emphasize the distribution of risk elements between parties, commonly seen in service-level agreements (SLAs) for cloud services and other third-party providers.
In the realm of cyber insurance, coverage for ransomware attacks is a primary concern for many CISSPs. Key areas of coverage that should be clearly understood include:
- Claims made against the organization by third parties
- Email fraud protection
- Properly trained personnel to manage ransom payments, should the organization decide to pay
Cyber insurers also require proof of a cybersecurity program before issuing coverage. They expect organizations to have taken reasonable precautions to mitigate cyber threats. However, the definition of “reasonable” must be supported by agreed-upon evidence, typically outlined in the insurance contract.
d. Avoid – This refers to abandoning the activity that creates the risk altogether, for example, if your users keep clicking links in phishing emails, avoidance would be achieved by disabling or uninstalling email altogether and not allowing anyone to use it.
Risk is sometimes rated using three factors, impact, likelihood, and exposure.
Impact is the monetary effect that will occur, or it can be expressed as the impact to human health. In our case of the broken fence, the impact would be the cost of making the TV that was stolen.
Likelihood is the measurement of possibility, usually calculated from historical data on past occurrences. For example, the likelihood of one person running through our broken fence to steal a TV could be a %.001 chance based on how many similar thefts have occurred in the past.
Exposure is when an organization becomes vulnerable to a threat, for example, the broken fence creates an exposure to the threat of burglary.
Risk analysis can be done in two ways, qualitative and quantitative:
- Qualitative –is opinion based and more of a narrative discussion – a lot of organizations try to pretend they are using quantitative methods when in fact they are using qualitative methods. The solution is to use factor analysis of information risk (FAIR) method, which is a simple way of keeping analyses quantitative.
- Quantitative –is numeric and value based; this is the preferred method because it is more objective.
- Simulations are a way to get numbers and samples in order to be quantitative. Some examples are penetration testing, desk checks, fuzz testing, and walkthroughs.
The Business Impact Analysis (BIA) is a tool used to help understand the criticality of assets within an organization, and remember that assets typically refer to data in the CBK, but not always. The BIA aims to answer the questions of which assets or data are critical to the business, and level of criticality.
Risk Measurement Model
Now we move on to the traditional risk measurement model, which is a bit outdated, and ISC2 admits this, but it still has value in understanding how it works
Asset Value (AV) is of course the asset’s value
Exposure factor (EF) is the percent of the asset that can be lost from a certain event
Single loss expectancy (SLE) is the AV x the EF, measured in money
The annual rate of occurrence (ARO) is how many times in a year the event occurs, typically a decimal but it can be more.
The Annual loss expectancy (ALE) is the SLE x ARO, which shows how much the business is currently losing without implementing safeguards. If the safeguards are cheaper than the ALE, it’s best to implement the safeguards.
Via Contracts
Some additional terms you’ll need to be familiar with are:
Minimum security requirements are a collection of settings and standards that comprise the baseline security configuration. It’s important to consider the following:
- Including stakeholders in developing and planning of the minimum security requirements.
- Ensure that minimum requirements are specific, realistic, and measurable.
- Do not choose solutions before the requirements are understood – requirements must be understood before purchases are made, and before preferred technologies are selected. The solution should not drive the requirements and business functions.
Service level agreement (SLA), part of the overarching contract – the SLA should contain minimum requirements and is a financially enforceable part of the contract, meaning the metrics contained therein can be used to withhold funds from the vendor. The SLA should contain specific numeric metrics to decide whether the vendor has failed or succeeded in delivering the service or product. For example, the contract would say “Web applications must be reasonably available to the public,” whereas the SLA would say “Web application downtime must not exceed ten seconds.”
Note: understand the difference between a contract and the SLA. The SLA should have continuous or recurring items, such as data volumes, uptimes, and specific reports; whereas the contract should have singular events, such as recovery plans, testing those plans, or specific laws/regulations that govern the method of security.
Additional Terms
Silicon Root of Trust – Security begins at the foundation, with systems relying on firmware as their starting point. Organizations like LowRISC are developing a Silicon Root of Trust using open-source principles to bring transparency to an area that has traditionally been opaque. This approach enables organizations to inspect firmware as a trusted foundation for security. LowRISC plays a key role in stewarding the OpenTitan reference design and integration guidelines for silicon root of trust chips.
Physically Unclonable Function (PUF) – A Physically Unclonable Function (PUF) leverages the unique physical microstructure of electronic components instead of a cryptographic key to identify a device. Since no two electronic components are manufactured identically, this natural variation serves as a unique identifier. However, PUF implementations vary in strength, and like all cryptographic methods, their security often depends more on implementation quality than the algorithm itself. Vulnerabilities in PUF designs have been exploited through side-channel attacks.
Software Bill of Materials (SBOM) – Understanding the components within a software stack is essential for managing security. A Software Bill of Materials (SBOM) helps organizations plan upgrades, optimize acquisitions, and quickly respond to zero-day vulnerabilities by identifying where specific software components are deployed. While security teams may be asked to manage an organization’s software library, a CISSP’s time is better spent advising software librarians and integrating security into the acquisition process. By being involved in procurement decisions, CISSPs can enhance the security of software components over time.
Layered defense or defense in depth – this refers to relying on multiple controls, and multiple types of controls to protect the organization’s assets. For example, if you have firewalls in place but no ACL, no configurations, and no locks on data closet doors, you are not using a layered defense.
Risk Framework refers to the model that your organization adopts to manage its risk.
Supply chain – this refers to the flow of assets or data. Audits, surveys, reviews, and testing can be done in the supply chain, but the CBK says that it’s also acceptable to simply view the resulting reports of those reviews for entities within the supply chain, and recommend enhanced or reduced security to those entities.
For example, if your business contracts with IBM for custom computer parts, and there is an intermediary company that delivers those parts especially for you, they may be subject to certain types of audits or reviews. By reviewing their findings, you can discuss additional or more effective approaches to security.
Organizations face various risks due to the interdependencies between hardware, software, and services:
Hardware. Businesses invest in hardware such as laptops, desktops, servers, cameras, and other devices. Manufacturing facilities often rely on specialized, and sometimes outdated, systems that are crucial for assembly lines. These legacy systems present multiple risks: a hardware risk due to operational dependency, a software risk as they often run outdated programs, and a service risk since maintenance is typically handled exclusively by the system provider. In one case, such vulnerabilities enabled attackers to alter the code in payment entry devices, which were later integrated into point-of-sale systems—allowing them to skim and steal credit card data.
Software. Commercial off-the-shelf software can contain bugs or poorly designed features that attackers can exploit. A particularly dangerous threat arises from vulnerabilities that remain undiscovered until after a product has been released. These are known as “zero-day” exploits, as cybercriminals can take advantage of them until a patch or fix is developed and deployed.
Services. Targeting a smaller supplier with fewer security measures can be much easier than breaching a well-protected large company. This tactic was used in the Target breach, where attackers exploited vulnerabilities in a third-party vendor. Similarly, the SolarWinds attack demonstrated the widespread impact of compromising a single service provider, as it allowed bad actors to infiltrate thousands of organizations.
Threat modeling, but specifically STRIDE. STRIDE is a classification system developed by Microsoft in which threats are categorized into one of the following components:
- Spoofing – faking an identity
- Tampering – modifying the data
- Repudiation – maintaining the ability to deny that they’ve done anything (remaining undetected)
- Information disclosure – the release or theft of protected data
- Denial of service – the impact to availability
- Elevation of privilege – typically escalation to administrative rights on a system
Risk vs. Business Need
Security professionals are simply advisors. In other words, security doesn’t dictate what the business does. Security professionals must understand what the business drivers are, and then evaluate the associated risks and advise management on how to mitigate those risks. There are four steps that a business might take to identify its needs. The security architect is the one most likely to participate in this process:
- Consult or ask
Use of discussions, questionnaires and workgroups, the business should consult its stakeholders on:
• What they do
• What they think they provide to the business and
• What tools they might use to accomplish their goals - Evaluate
Evaluate answers recorded from the previous step. - Agree
Produce and agree upon a set of business plans based on the evaluated answers from 1 & 2. - Document
Document a working model for the business.