IT Risk Management Class 9 SU2024 copy.pdf

Risk Reporting and Development of Mitigation Plans CLASS #9 FOR IT RISK MANAGEMENT By JIANG HE, PH.D., CISSP, CCSP, CISA, CRISC Agenda 1. Articulating an information security risk 2. Risk reporting vs. security metrics 3. Key considerations in the development of mitigation plans  Articulating a...

Risk Reporting and Development of Mitigation Plans CLASS #9 FOR IT RISK MANAGEMENT By JIANG HE, PH.D., CISSP, CCSP, CISA, CRISC Agenda 1. Articulating an information security risk 2. Risk reporting vs. security metrics 3. Key considerations in the development of mitigation plans  Articulating an information security risk Definition of information security risk and the goal of information security risk management Depending on its context, the terminology of “risk” could mean many different things for different types of audience. From a quantitative perspective, it can be described with the following formula: Risk ($/year) = potential impact of an event on the business ($ amount of lost revenue) * estimated frequency of such events (# of events per year) When applied to the domain of information security, a risk would be defined as the expected loss of information confidentiality, integrity, or availability. Accordingly, the goal of information security risk management is to control the probable frequency and probable magnitude of future loss of information confidentiality, integrity, or availability.  Articulating an information security risk (cont’d) Leverage a tool (or framework) to identify threat scenarios, i.e., Before identifying an information security risk, the risk finding links between vulnerabilities and threat agents assessor would need to perform certain activities which typically include but not limited to: - understand asset profiles and their (sensitivity) classifications (i.e., what business/technical functions are supported by the asset? Who owns/manages the asset?) - for the selected assets (or asset containers), identify threat scenarios by mapping threat actors onto relevant vulnerabilities. (i.e., what could go wrong? And should this happen, then what?) OCTAVE – “Operationally Critical Threat, Asset, and Vulnerability Evaluation Methodology”, developed by Carnegie Mellon University Articulating an information security risk (cont’d) Convert a finding into an information security risk. Keep in mind that a security finding (or issue) may not always lead to a material risk! Consider the following example security finding (or issue): “Network administrators use Telnet to manage network devices remotely and their passwords never expire.” It is a significant finding with two major issues, which are obviously worth reporting and investigating further. But what would be the real risk? Several factors need to be considered before you write up the final risk report: - What (business) assets are we speaking about? – Sensitivity - Who would be the threat agent? – Threat agent - How would the vulnerability be exploited? - Vulnerability - What would be the likelihood that the vulnerability is being exploited? - Likelihood - What would be the damage if the assets get compromised? – Severity, and Inherent risk - Do we have other controls in places to reduce either the likelihood or the level of damage? – Compensating controls - Given the compensating controls in places, are we still worrying about the net risk? – Residual Risk  Articulating an information security risk (cont’d) Break down the finding into few scenarios which you believe are highly relevant, for example Scenario 1: External attackers sniffing network traffic obtain the passwords for accessing the network devices as Admins, and then take full control of the devices. Step 1: Evaluate the likelihood and impact, without considering the existence of compensating controls Step 2: Estimate the level of inherent risk Step 3: Review the compensating controls in place Step 4: Estimate the level of residual risk  Articulating an information security risk (cont’d) Break down the finding into few scenarios which you believe are highly relevant, for example Scenario 2: External attackers manage to brute-force into the network devices following a large number of failed attempts, and then take full control of the devices. Repeat the same steps described in the previous slide! Try it yourself and demonstrate your analysis results  Articulating an information security risk (cont’d) Focus on one risk at a time! “Network administrators use Telnet to manage network devices remotely and their passwords never expire.” Key takeaways for the assessment finding: 1. Although this is one statement, there are actually two issues presented. 2. It would be better if we break it down into two separate risks as each of them has a unique root cause. Also, the compensating controls are likely to be different for each of the issues. 3. Security finding (or issue) is not always equal to a material security risk. Before writing up your risk report, ask your self the “so what” question.  Articulating an information security risk (cont’d) Come up with a risk description for each risk, and the description should include the key elements as below: 1. Root cause of the risk, i.e., a specific type of vulnerability < > may be exploited successfully by a threat agent < >. 2. As a result, confidentiality, integrity, or availability of < > may be compromised. 3. Should this happen, the organization will observe a high / medium / low business impact, and the business impact will be financial, regulatory, or reputational, or a combination of them?  Articulating an information security risk (cont’d) Now a risk has been identified, so what? 1. Look at (and document) the compensating controls 2. Are the compensating controls sufficient to bring down the residual risk within the pre-defined risk appetite? 3. If not within risk appetite, then it needs to be “treated” (or “responded”) immediately. A common mistake is to document only the immediate outcome from a technical perspective and the actual “business impact” has been not analyzed. With Scenario 1, using Telnet may lead to a compromise of the administrative credentials. But, as a risk professional, you still need to understand the role of the network devices within the organization, i.e., what business functions/processes would be disrupted should the network devices are brought down or controlled by the attackers? What would be the real damage for the business?  Responding to an identified risk After examining the compensating controls and estimated levels of control effectiveness, if “the level of residual risk is higher than the organization's pre-defined risk appetite”, then the risk needs to be treated! 1. Four distinct approaches could be considered when responding to a risk – avoid, transfer, mitigate and accept. 2. Mitigating is the most commonly used approach. Cost-benefit analysis may be necessary, particularly for the mitigating efforts requiring significant business investment or manpower. 3. Mitigation plans, if recommended by the risk professional, would require sign-off from business owners (or senior management) to become official. Otherwise, it is only a proposal or recommendation. 4. Keep in mind that the residual risk will remain exist until the mitigation plans are successfully implemented. During the interim, the underlying assumption, unless explicitly expressed with a separate clause, is that the business owner would accept the residual risk before complete execution of the mitigation plans. Under certain circumstances, temporary measures may need to be taken during the interim. Responding to an identified risk(cont’d) Example of action (remediation) plans 1. A risk analysis on a critical database concluded that, the unencrypted tables (data-at-rest) containing Personally Identifiable Information (PII data) poses a material risk to the business (i.e., residual risk > the risk appetite defined by the business) 2. The risk assessor recommended a mitigation plan – to implement a file-level database encryption tool on the concerned database 3. The business owner accepted the proposed remediation plan and agreed to complete the remediation work within 90 days. 4. During the 90 days interim, the database owner agreed to assign a temporary resource to closely monitor/review security logs and events associated with the concerned database on a weekly basis. As a detective (compensating) control, this temporary measure is leveraged to reduce the residual risk until the permanent solution gets in place. Key takeaway – before a risk finding is being presented or reported in a formal manner, it is important to consult with the stakeholders (e.g., business owners, designated IT custodians) in order to understand what compensating controls may be available. It will take time to implement a remediation plan; during the interim, something may need to be in place to bring down the residual risk on a temporary basis.  Continuous monitoring – risk is a moving target Re-assessment will become necessary at some point, and the intervals should be aligned with the risk profiles of the assets. Generally speaking, mission-critical assets and assets with an elevated level of residual risk should be re-assessed with a shorter interval. There are additional factors to be considered when determining the cycles of risk assessments. Such factors include but are not limited to: 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 Newly emerged vulnerabilities Newly deployed controls Key takeaway: A risk assessment/analysis is always based on a snapshot of the in-scope assets and corresponding threat landscape. Many of the risk elements keep evolving over time. As a result, a risk identified/documented today could become invalid next day and a re-assessment may become necessary. Risk Register Organizations should maintain an IT risk register, which is a centralized repository of all potential and known IT risk issues. Each risk item should be documented for its key attributes. At a minimum, the following attributes must be documented clearly: Brief risk description – e.g., vulnerability X could be exploited by threat actor Y Risk rating – e.g., high/medium/low, based on two major factors, likelihood of the risk event & level of severity Why a rating was given – e.g., level of impact on data confidential, integrity, or availability. As a result, what damages the business would have to face? Financial loss, reputational damage, regulatory/legal issues, etc.? Compensating controls considered – e.g., any compensating controls in place? If yes, how effective they are in reducing the residual risk? Risk owner – someone needs to be accountable for the risk identified. Usually it is a senior executive representing the business unit. Risk decision – action plans (mitigate/accept/transfer/avoid), and timeline for implementation. Be careful when risk owners try to “accept” a risk. For the short term, “accepting the risk” may look like an attractive option and therefore it could be abused by some risk owners, particularly those individuals without sufficient knowledge on risk management. It is the risk professional’s responsibility to make sure that risk owners have been well informed and their decisions are in line with the organization’s objectives and risk appetite. Security Metrics vs. Risk Reporting Understanding the difference between risk reporting and security metrics 1. In the domain of Information Security, risk reporting has a clearly defined objective. The output measures only one dimension of the security landscape, which is the level of information security risk for a particular issue (risk event). Its value depends on two parameters only, likelihood of a risk event, and severity of a risk event. Of course, multiple security risks can be aggregated into a consolidated view for reporting purpose. 2. Security metrics, on the other hand, can be developed to measure many different dimensions/aspects of an organization’s information security posture. The parameters of security metrics can vary greatly from one organization to another. Depending management’s preferences, security metrics can be developed to measure an organization’s: a) efficiency of security operations, e.g., patch management, incident management, endpoint security posture, etc. b) compliance status for industry regulations or standards, such as PCI (Payment Card Industry) Data Security Standard c) employee awareness on information security and/or security staff’s competence d) progress/status of security projects e) capabilities on various domains of information security f) others  Security Metrics vs. Risk Reporting (Cont’d) “Security Metrics” is a loosely defined concept and it can cover a broad range of measurements, and Risk Reporting can be one component of an organization’s security metrics program 1. Security metrics can be developed to measure many different things, and risk could be one of the things being measured. For example, a quarterly security scorecard may include a chart showing a) number of high/medium security risks identified through the recent annual security risk assessment b) number of new IT projects carrying high/medium security risks, etc. 2. At the end of the day, security metrics and/or risk reports are just measurement tools, which enable an organization to identify its weaknesses (sometimes strengths as well) for information security. When such tools are used properly, the organization can efficiently allocate its limited resources to address security- related problems with a prioritized approach. Key considerations in the development of mitigation plans Risk needs to be assessed not only from a technical perspective, but also from a business perspective 1. Assess the sensitivity of the asset, factors to be considered: a) Type of information being processed/stored – PII (personally identifiable information such as Social Security Number, etc.), personal medical records, credit card information, bank account information, intellectual property, HR records (e.g., salary data, date of birth, etc.), critical business information (e.g., client information, strategic decisions, etc.) b) Importance of the business processes supported by the assets, e.g., what would be the consequence if the process is interrupted by the risk event c) Applicable regulations and the organization’s liabilities for non-compliance, e.g., HIPAA, PCI, etc. 2. Assess the likelihood of the exploit and the severity of the risk event a) assess the inherent risk – estimate the likelihood and severity without considering the existing controls b) assess the residual risk – examine the existing controls and then carefully review how effective they are in reducing either the likelihood or the severity. Only effective controls will lead to a lowered risk, i.e., residual risk < inherent risk. Key considerations in the development of mitigation plans (cont’d) Remediation efforts should address the root cause of the issue, whenever possible “Network administrators use Telnet to manage network devices remotely and their passwords never expire.” Root cause causing the risk event – in this case, two vulnerabilities, which are separate from each other: a) Telnet is a vulnerable out-of-date network protocol, and therefore it should be replaced by SSH, which is a secure protocol. b) “Passwords never expire”, is a process type of vulnerability which needs to be addressed. Most modern IT systems/applications, including Windows Active Directory, can be configured to enforce password changes periodically. Two action plans can be considered to address this issue: 1) Review the security policy of the organization. “Passwords set to expire” should be one of the security requirements within policy. If not, then the policy needs to be updated accordingly. 2) Based on the security policy, system configurations need to be modified to meet the policy requirement.  Key considerations in the development of mitigation plans (cont’d) In some cases, root cause of a risk event is less obvious and it may involve multiple factors which interact with each other. A level of ambiguity may need to be dealt with. This happens often when the assessment is done at a higher level (e.g., business unit level or organizational level) rather than at a system level. For example, a risk scenario might state: “Financially motivated insiders could steal company’s intellectual property (IP) information to make a profit by selling it to the competitors.” In this scenario, the motivated insider would leverage all methods available to him/her in order to make a successful attack. Thus, we are talking about lots of possibilities: Before developing any mitigation plans (if one is needed), a careful review of existing controls as well as their effectiveness would be necessary. Some key questions should be answered first: a) Where the IP data is stored internally? b) What are the data flows while the IP data moves internally and externally? c) What controls are in place preventing a malicious insider from stealing the data? e.g., logical access controls, network zoning, detection of abnormal user behaviors, disabled USB drives, monitored email usage, etc.? d) How effective these controls are, individually and collectively?  Key considerations in the development of mitigation plans (cont’d) Key takeaways from the case of “malicious insiders stealing IP information for profit” 1. When addressing a risk event which is defined at a higher level without specifics, we need to put ourselves in the shoes of attackers in order to identify the weakest links within our defense system. 2. In line with the principle of “defense in depth”, you (the risk assessor) may recommend multiple remediation activities. For the above-mentioned example, your recommendations may include: a) enhanced monitoring of user behaviors b) implement a comprehensive Data Loss Prevention program c) mapping of data flows involving company’s IP data d) etc. 3. Since there are multiple remediation plans being recommended, it would be important to “prioritize” them, i.e., distinguish the “quick wins” from those requiring significant resources. To work out the priority ranking, cost-benefit analysis on each of the recommended solutions may be necessary. 4. To summarize - resources are limited, and therefore mitigation efforts must be implemented with efficiency maximized. Case Study (Group Work)