Chapter 08: Responding to Vulnerabilities Flashcards
ERM
Enterprise Risk Management
Organizations take a formal approach to risk analysis that begins with identifying risks, continues with determining the severity of each risk, and then results in adopting one or more risk management strategies to address each risk
Reasons We Use ERM
* Keep data confidential
* Avoid financial losses
* Avoid legal issues
* Maintain positive brand image
* Ensure COOP (continuity of operations plan—BCP/DRP)
* Establish trust and mitigate liability
* Meet stakeholder’s objectives
NIST 800-39
* Managing Information Security Risk
* Great starting point for applying processes to risk identification and assessment
* Assess, Respond, Monitor—Frame
Risk Identification
* Takes place by evaluating threats, identifying vulnerabilities, and assessing the probability / likelihood of an eventt affecting an asset or process
Threats
Any possible events that might have an adverse impact on the CIA of our information or information systems
Vulnerabilities
Weaknesses in our systems or controls that could be exploited by a threat
Risks
The interesection of a vulnerability and a threat that might exploit that vulnerability
A threat without a corresponding vulnerability doesn’t pose a risk, nor does a threat without a vulnerability
Once you identify threats and vulnerabilities, through threat intel, vulnerability scans, etc, you can identify the risks that exist in your organization
Risk Calculation
When evaluating risk, use two factors:
1. Probability: Likelihood that a risk will occur
2. Magnitude: Impact the risk will have on the org if it occurs
Risk Severity = Probability x Magnitude
This equation doesn’t always have to be interpreted literally—think of this conceptually as combining the two to determine the severity
NOTE: For any question on the exam that deals with risk, keep these two things in the back of your mind and ask what the probability and magnitude are
BIA
Business Impact Analysis
A formalized approach to risk prioritization that allows organizations to conduct their reviews in a structured manner, and follow two methodologies:
1. Quantitative Risk Assessments: Analysis that uses numeric data to provide very straightforward prioritization of risks
2. Qualitative Risk Assessments: Substitute subjective judgments and categories for strict numerical analysis, allowing the assessment of risks that are difficult to quantify
MTD (Maximum Tolerable Downtime)
* How long you can be down without going out of business
* Each business process can have its own MTD, such as a range of minutes to hours for critical functions, 24 hours for urgent functions, or up to 7 days for normal functions
* MTD sets upper limit on the recovery time that the system and asset owners need to resume operations
RTO (Recovery Time Objective)
* The length of time it takes after an event to resume norrmal business operations and activities
* Not a full recovery though, just to get a point where you can provide services
* MTTR is full repair
WRT (Work Recovery Time)
* The length of time in addition to the RTO of individual systems to perform reintegration and testing of a restored or upgraded system following an event
RPO (Recovery Point Objective)
* Longest time you can tolerate lost data being unrecoverable
Page 297
Quantitative Risk Assessment
Most quantitative risk assessment processes follow a similar methodology that includes the following steps:
1. Determine the AV (asset value) affected by risk: AV is expressed in dollars and may be determined using the cost to acquire the asset, cost to replace, or depreciated cost of the asset depending on the org’s preferences
2. Determing the likelihood the risk will occur: Risk analysts consult subject matter experts and determine the likelihood that a risk will occur in a given year. This is expressed as the ARO (annualized rate of occurrence)—a risk expected to occur twice a year has an ARO of 2.0 while a risk expected once every 100 years has an ARO of 0.01
3. Determine the amount of damage that will occur if the risk materializes: This is knonw as the EF (exposure factor) and is expressed as a percentage of the asset expected to be damaged—the EF of a risk that would completely destroy an asset is 100% while an EF that destroys half is 50%
4. Calculate the SLE: SLE (single loss expectancy) is the amount of financial damage expected each time a risk materializes—calculated by multiplying the AV by EF
5. Calculate the ALE: ALE (annualized loss expectancy) is the amount of damage expected from a risk each year—calculated by multiple SLE and ARO
Repeat this process for each threat-vulnerability combination
Qualitative Risk Assessment
Qualitative risk assessment techniques seek to overcome the limitations of quantitative techniques by substituting subjective judgment for objective data
They still use the same probability and magnitude factors to evaluate risk severity, but do so using subjective categories
It’s not possible to directly calculate financial impacts of risks that are assessed using qualitative techniques, but a risk assessment scale / risk matrix makes it possible to still prioritize risks:
Risk Matrix
* Impact along one axis, likelihood along the other
* 3 x 3: low, medium, high
* 4 x 4: low, medium, high critical
Why Qualitative Would Be Preferred
* Complexity of cybersecurity risks
* Unknowns
* Limited data
* Resource constraints
* Communication
Many orgs will combine quantitative and qualitative to get a well rounded picture of their tangible and intangible risks
Supply Chain Assessment
Risks can occur based on third-party relationships as well, don’t overlook these
Performing vendor due diligence is a crucial security responsibility—if they don’t have adequate security controls in place, your data is at risk
Risk Management
After you’ve completed a risk assessment, you can focus on risk management, which is the process of systematically addressing the risks facing your org
The risk assessment serves two important roles in the risk management process:
1. Provides guidance in prioritizing risks so that the risks with the highest probability and magnitude are addressed first
2. Helps determine whether the potential impact of a risk justifies the costs incurred by adopting a risk management approach
Things to Know for Controls
* If control is required by a framework, best practice, or regulation
* Cost of control
* Amount of risk a control mitigates
Risk Mitigation
The process of applying security controls to reduce the probability and/or magnitude of a risk
This is the most common risk management strategy, and the majority of work for security pros revolvees around mitigating risks through the design, implementation, and management of security controls
When you choose to mitigate a risk, you can apply one control or a series of controls—each one should reduce the probability of the risk, magnitude of the risk, or both
EXAM NOTE: Adding controls
Risk Avoidance
The changing of business practices to completely eliminate the potential that a risk will materialize
This may seem like a highly desirable approach, but there’s a major drawback—risk avoidance strategies often have a serious detrimental impact on the business
EXAM NOTE: Changing plans
Risk Transference
Shifting some of the impact of a risk from the organization to another entity
The most common example is purchasing an insurance policy that covers a risk—the customer pays a premium to the insurance carrier who agrees to cover losses from risks specified in the policy
Many general business policies exclude all cyber risks, so purchase cyber insurance separately or as a rider on an existing business policy
EXAM NOTE: Insurance
Risk Acceptance
Deliberately choosing to take no other risk management strategy and simply continuing operations as normal in the face of risk
This approach may be warranted if the cost of mitigating a risk is greater than the impact of the risk itself
This should not be taken as a default strategy—risk acceptance without an analysis isn’t accepted risk, it’s unmanaged risk (which is bad bad bad)
EXAM NOTE: Low risk
Technical Controls
AKA: Logical controls
Security controls that are implemented as a system (hardware, software, or firmware) to enforce CIA in the digital space
- Firewall rules
- ACLs
- IPS
- Encryption
Operational Controls
A category of security control that’s implemented primarily by people rather than systems—these are the processes we put in place to manage technology in a secure manner
* User access reviews
* Log monitoring
* Vulnerability management
* Security guards to ensure people don’t break into the building
* Train employees on how not to fall for phishing scam
Managerial Controls
Security controls that provide oversight of the information system
These are procedural mechanisms that focus on the mechanics of the risk management process
* Periodic risk assessments
* Security planning exercises
* Incorporation of security into the org’s change management, service acquisition, and project management practices
Preventive Controls
Security controls intended to stop a security issue before it occurs
* Firewalls
* Encryption
Detective Controls
Security controls to identify security events thave have already occurred
* IDS
* Logs
Responsive Controls
Security controls that help orgs respond to an active security incident
* 24x7 SOC that can triage and direct first responders
Corrective Controls
Security controls to help remediate security issues that have already occurred
* Restoring backups after a ransomware attack
* Patch management system
Compensating Controls
Security controls designed to mitigate the risk associated with exceptions made to a security policy
STRIDE
Microsoft’s STRIDE classification model is one method you can use to calssify threats based on what they leverage:
* Spoofing of user identity
* Tampering
* Repudiation
* Information disclosure
* Denial of service
* Elevation of privilege
Other models include:
* PASTA (Process for Attack Simulation and Threat Analysis)
* LINDDUN CVSS
Classification tools provide two major benefits
1. Allows you to use a common framework to describe threats, allowing others to contribute and manage threat information
2. Serves as a reminder of the types of threats that exist and can help analysts perform better threat analysis by giving a list of potential threat options
Threat Modeling
Threat modeling takes many factors into account, but the common elements are:
* Assessing adversary capability, or the resources, intent, and ability of the likely threat actor or organization
* The total attack surface of the organization you’re assessing—this means any system, device, network, app, staff member, or other target that a threat may target
* Listing possible attack vectors, the means by which attackers can gain acces to their targets
* The impact if the attack was successful
* The likelihood of the attack or threat succeeding
Threat Research
Once the threat model is complete, you conduct threat research
There are many different types of threat research you can conduct:
Threat Reputation
* Look at the reputation of a site, netblock, or actor to determine whether they have a history or habit of malicious behavior
* Often paired with IPs or domains, but file reputation services, data feeds, and other reputation-based tools also exist
Behavioral Assessments
* Use for insider threats because insider threat behavior is often difficult to distinguish from job or role related world
* Detecting interal threat behaviors relies heavily on the context of the actions that were performed, a broad view of the insider’s actions across all systems, apps, and networks, and the availability to provide insight over time
* Many insider attacks rely on privileged account abuse, leveraging access to sensitive information and use of shared passwords
* They also occur outside of normal business hours or may require more time, making it possible to identify insider threats through differences in behavior
IOC
* IOC are forensic evidence or data that can help to identify an attack
* Unlike other assessment methods, IOC are used exclusively after an attack has started, but may still be ongoing
* Knowing which IOC are associated with a given threat actor, or common exploit path, can help defenders take appropriate steps to prevent further compromise or even identify the threat actor
* Can help limit the damage or stop the attack from progressing
Page 306
Attack Surface Management
Your attack surface is the combination of all systems and services that have some exposure to attackers, and might allow those attackers to gain access to your environment
Managing the attack surface includes:
* Edge Discovery: Scanning that identifies any systems or devices with public exposure by scanning IPs belonging to the org
* Passive Discovery: Techniques that monitor inbound and outbound traffic to detect devices that didn’t appear during other discovery scans
* Security Controls Testing: Verifies that the org’s array of security controls are functioning properly
* Pentesting and Adversary Emulation: Seeks to emulate the actions of an adversary to discover flaws in the org’s security controls
Use the results of these discovery and testing techniques to make changes to the environment and improve security—this is called attack surface reduction
Bug Bounty Programs
A formal process that allows orgs to open their systems to inspection by security researchers in a controlled environment that encourages attackers to report vulnerabilities in a responsible fashion
Security testers probe the systems for vulnerabilities, and if they find one they can choose to:
* Disclose publicly
* Exploit
* Disclose responsibly
* Take no action
Bug bounties incentivize testers to disclose responsibly, usually by offering cash
Configuration Management
Tracks the way that specific endpoint devices are set up, both the OS settings and the inventory of software installed on a device
Configuration management should also crerate artifacts that may be used to help understand system configuration
Baselining
* An important component of configuration management
* It’s a snapshot of a system or application at a given point in time
* May be used to assess whether a system has changed outside of an approved change management process
* System admins may compare a running system to a baseline to identify all changes to the system and then compare those changes to a list of approved change requests
Together, change and configuration management allow tech professionals to track the status of hardware, software, and firmware, ensuring that change occurs when desired—but in a controlled fashion that minimizes risk to an org
Change Management
Change management programs provide orgs with a formal process for identifying, requesting, approving, and implementing changes to configurations
Version Control
* A critical component of change management programs, partiuclarly in the areas of software and script development
* Versioning assigns each release of a piece of softwrae an incrementing version number that may be used to identify any given copy
Together, change and configuration management allow tech professionals to track the status of hardware, software, and firmware, ensuring that change occurs when desired—but in a controlled fashion that minimizes risk to an org
Dion’s Notes
* Change management is the process where changes to the configuration of information systems are monitored and controlled as part of the organization’s overall configuration management efforts
* It ensures that all changes are planned and controlled to minimize risk of a service disruption
* Each individual component should have a separate document or database record that describes its initial state and subsequent changes—configuration information, patches installed, backup records, incident reports or issues
* Changes are categorized according to their potential impact and level of risk—major, significant, minor, normal