Management Lifecycle Chapter 3 Lecture PDF
Document Details
Uploaded by Deleted User
Dr. Muath AlShaikh
Tags
Related
Summary
This lecture covers the Management Lifecycle (Chapter 3) focusing on risk analysis and management. It details what risk is, how it is managed, and the stages of the risk management life cycle. The presentation also addresses risk evaluation and mitigation strategies.
Full Transcript
Management Lifecycle Chapter 3 Risk Analysis and Management Edited by: Dr. Muath AlShaikh What is Risk? An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result...
Management Lifecycle Chapter 3 Risk Analysis and Management Edited by: Dr. Muath AlShaikh What is Risk? An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result OR The possibility of loss because of one or more threats to information https://www.rfc-editor.org/rfc/rfc4949 What is Risk Management? The process of identifying, measuring, and controlling (i.e., mitigating) risks in information systems so as to reduce the risks to a level commensurate with the value of the assets protected. OR The process of controlling uncertain events that may affect information system resources. https://www.rfc-editor.org/rfc/rfc4949 Stages of Risk Management Lifecycle Risk management life cycle is made up of several point in time assessments that need to be continuously re-evaluated: Identify critical resources that need to be protected. Identify threats and vulnerabilities for these resources Rate the risk exposure Determine appropriate mitigation strategies Implement controls Evaluate effectiveness of controls Monitor changes over time Risk is a Moving Target Your environment is always changing which means you need to consider shifts in threats and exposures. This leads to re-evaluating the risk (starting the assessment cycle over). Factors that may start the re-evaluation process include: A change in the sensitivity of the target resource A significant shift in the threat landscape A change in legal/regulatory requirements A change in security policy On a schedule, based on the resource’s sensitivity to risk Risk is a Moving Target (Cont’d) The resource owner should notify the security team of changes that might require an out-of-cycle assessment Security team should be aware of changes in the threat landscape Risk Assessment /Re-evaluation is like managing the classification of a document. Risk is a Moving Target (Cont’d) Avoid the fix-everything mentality, the assets does not have the same value. You need to reassess critical resources on a periodic basis according to their importance The most critical assets might require an annual evaluation, whereas less sensitive resources might be assessed every 2 to 5 years. Risk Management Culture (Embedding risk management into organization) Changes in the intended use of a resource Would require change in its security control. Most breaches occur when controls are not updated according to shifts in the usage purpose of resources. It is important to have a mixture of preventive and detective controls to catch scope creep situations. Success of risk management useful metric How many issues are self identified versus those discovered by the security team. Resource owners should take responsibility for protecting their own resources. Comprehensive Risk Management Workflow Stages Business Impact Assessment 1. Resource Profiling: Before any risk assessment can be preformed a security risk profile for a resource should be created. Create categories/levels/tiers for your resources. The security risk profile gathers information about a resource to help rate its sensitivity to security risks. Profile should be independent of particular threats or vulnerabilities. EX Application internal or on internet. 2. Risk Assessment Risk assessment is the function of: identifying the threats and vulnerabilities for a given resource, articulating the risk, and rating that risk exposure on a given scale. In this workflow, the risk assessment step includes: Risk Analysis, which is considered the process of measuring (or rating) the likelihood of the undesirable event occurring and the expected severity of that event. Some kind of vulnerability assessment is generally used as part of the risk assessment to identify technical weaknesses, along with threat modelling. 2.1 Vulnerability assessment Identify weaknesses and flaws through scanning or configuration analysis. No real analysis of applicability or threat analysis is included. a vulnerability assessment assumes a single finding per vulnerability, but in reality, there could be different threats with a single vulnerability and this is not captured in a vulnerability assessment. Vulnerability assessments are good tools to be used as part of an overall risk assessment process: They can produce good metrics to measure the effectiveness of current control measures like patch management processes or hardening of server. Identify resources that are susceptible to a particular exploit or running a prohibited service (vulnerability scan). Attackers typically use vulnerability scans as part of their reconnaissance, so it is good to run the same tests yourself to identify which weaknesses would be visible to an attacker. 2.1 Vulnerability vs Risk assessment Nessus scanner. Example organization with no central identity with 100 servers. How about the accounts ? Vulnerabilities are identified and rated based on a very general knowledge of How they might be exploited. Part of risk assessment. A risk assessment is the superset of activities for taking: Taking vulnerability data and mapping it to likely threats, evaluating the severity for the given environment, and articulating the risk(s) that might result. Take into account the sensitivity level of the resource that has the vulnerability, whereas a typical vulnerability assessment would assume the same risk level no matter where it is found. If Microsoft announces a new vulnerability in Windows, they don’t list it as a high risk for servers and moderate risk for desktops. 2.2 Risk Exposure The risk exposure describes the outcome of a successful exploitation of the vulnerability by the threat. (This is done in risk assessment not vulnerability assessment) The combination of the likelihood that the threat will exploit the vulnerability, and the severity of the exploit, combined with the sensitivity of the asset itself yields the risk exposure rating. “communications could be intercepted in transit and decrypted by a malicious party resulting in an unauthorized disclosure of sensitive data for all customers in the United Kingdom, which would require a breach notification to regulators and affected clients, (affects reputation, costs money, and could expose the organization to civil legal action) costing the organization 2 million dollars in lost revenue and financial sanctions.” (A dollar value of financial loss is also stated in order to quantify the impact to the organization) We need to be careful not to assume the solution when describing the risk 3. Risk Evaluation After you have assessed all the risks, you also need to weigh and prioritize them, so that you can make well-informed decisions about which risks need to be addressed There are several options for addressing a risk: Accept A decision to accept the risk. Avoid Ceasing (or not engaging in) the activity that is presenting the risk altogether. Transfer Shifting the responsibility or liability for a risk to another party. Mitigate Limit the exposure in some way. Making Risk Decisions Rule no1 of Risk management is that you can’t eliminate all risk, Rule No2: of risk management is that you shouldn’t try to “fix” every vulnerability. Making Risk Decisions (Cont’d) There is more to consider than just the direct financial impact of a risk; in addition, it is important to strongly consider these indirect control costs: Implementation Additional support resources Education and training Reduction in operational effectiveness due to complexity or performance degradation All these costs need to be balanced against the likely cost of not implementing the recommended control. The total expense of the controls should never cost more than the asset is worth or the potential impact of the risk. Making Risk Decisions (Cont’d) 4. Documentation The documentation of risk is listed as an explicit stage in the workflow, but really you need to be documenting your assessment and evaluation steps all along the way. At a minimum, you want to capture the following details of your analysis for each risk finding: Why a rating was given Compensating controls considered Business justification Mitigation plans—long- and short-term Policy exceptions/risk acceptance Enough for today 5. Mitigation Planning and Long-term Strategy There are many options for mitigating a risk, and again the focus is not always on trying to eliminate the risk, but rather to reduce the risk exposure to an acceptable level. To mitigate a risk, you either have to reduce the likelihood of occurrence, or limit the severity of the impact, or decrease the sensitivity of the resource. Mitigation Planning and Long-term Strategy The most common risk decision is mitigation, which involves limiting the likelihood or effects of the exposure in some way. Most controls in this category will be detective and recovery focused. An Example Imagine a Web server in your DMZ with credit card numbers and client names on it. To reduce sensitivity of resource: Just by removing the credit card numbers from that server and placing them on an internally protected database tier instead, you could reduce the sensitivity of that Web server significantly without addressing any vulnerabilities or threats. To reduce likelihood of occurrence: to reduce the threat universe by implementing firewall rules to limit source networks that are allowed to connect to the Web server or to implement authentication controls to limit access to a smaller user community. Again, this option would not limit the severity of the exposure or change the sensitivity of the Web server, but it would reduce the likelihood of abuse by reducing the number of entities who can access the server. An Example To limit severity of the impact: An active alert triggered from a log file that detects brute forcing of user account passwords may be too late to prevent someone from compromising a single account, but: you can quickly disable the account before any damage is done or the attacker is able to move to another system. Or originally, limiting the scope of access the attacker would have when exploiting the account. If you can limit the access to a standard “user privilege” level as opposed to an “administrative privilege” level, then you have reduced the potential magnitude of the exposure. Mitigation Planning and Long-term Strategy In contrast, risk remediation refers to the actual removal or patching of the vulnerability. If you remediate a risk, you would be fixing the underlying issue, whereas a mitigation action reduces the exposure but does not eliminate the vulnerability. Mitigation Planning and Long-term Strategy (Cont’d) 6. Validation Once controls have been implemented to mitigate a risk, you need to verify the adequacy of these controls through active testing or review. There are many different levels of testing: including vulnerability scanning, penetration testing, or even configuration review. The intent of testing is to detect any areas where the controls don’t satisfactorily mitigate the risk or may have been misconfigured. Often organizations will establish a certification and accreditation (C&A) process to formally document the controls and validation of those controls before the application/system is allowed to “go live” or be released. Mitigation Planning and Long-term Strategy (Cont’d) 7. Monitoring and Audit This final step of the risk management lifecycle represents all the time after the formal risk assessment has been performed and the execution of the mitigation plans. The most common triggers for a reassessment of risks are as follows: Significant resource changes Changes to the threat landscape Shifts in business focus Changes to the regulatory or legal requirements Detected weaknesses in current controls Predetermined period of time has passed 7. Monitoring and Audit a predetermined schedule is established for each resource to catch any changes that should have prompted a reassessment along the way. The schedule should be based on the sensitivity level of the resource: High sensitivity: 1 year Moderate sensitivity: 3 year Low level: 5 years Regular assessments of the threat landscape to determine any areas that require additional focus Process Ownership There are a lot of different teams and roles involved in the risk management lifecycle. (Business owner, Resource custodian, Information security.)