IT Risk Management Class 6 SU2024 PDF

Threat Modelling and Key Considerations (Part 2) CLASS #6 FOR IT RISK MANAGEMENT By JIANG HE, PH.D., CISSP, CCSP, CISA, CRISC How to describe an Information Security Risk 1. What platform (or system) is being assessed? 2. How important is the platform (or system) to the organization, i.e., level of...

Threat Modelling and Key Considerations (Part 2) CLASS #6 FOR IT RISK MANAGEMENT By JIANG HE, PH.D., CISSP, CCSP, CISA, CRISC How to describe an Information Security Risk 1. What platform (or system) is being assessed? 2. How important is the platform (or system) to the organization, i.e., level of sensitivity, ? 3. Threats (or threat agents) who is going to launch an attack? Could be intentional or non- intentional (e.g., natural disaster, etc.) 4. Vulnerabilities weaknesses in systems, processes, or human beings which may be exploited 5. Inherent risk the value of the unmitigated risk exposure 6. Existing Controls and Control Effectiveness what mechanisms are in place to protect 7. Residual Risk the value of the net risk after mitigation  Qualitative measures for risk level Severity High Moderate Low Likelihood High Critical High Moderate Moderate High Moderate Low Low Moderate Low Low Still remember the quantitative risk formula introduced earlier? ALE = SLE * ARO The theoretical model above is rarely used for estimating cybersecurity risks, mainly because of lack of reliable data. This might change in the future though, when more organizations start to share incident and threat data with each other.  Cyber attacks - Immediate outcome vs. business impact Disclosure of information Financial Loss Corruption of information Legal Consequence Denial of service Reputational Impact Theft of service Regulatory Impact Escalated user privilege In many cases, the links between the left and the right may not be obvious or well understood by cyber incident investigators. As a risk professional, if you cannot articulate the business impact, then the risk cannot be well communicated! Threat Modelling reality vs. expectation 1. Although the theoretical framework such as OCTAVE has been established for a number of years, threat modelling is still a relatively new concept (or practice) for many industry players. 2. For real-world usage, there are few barriers in implementing the T-M tool: has been classified and documented track of the moving parts, there needs to be a formal program in place. c) Lack of internal resources for cybersecurity risk management a common approach for mitigating would be outsourcing Key questions to be answered before a Threat Modelling exercise 1. Who is requesting and sponsoring the exercise? And why it is requested? - Threat modelling can be performed at a high level, e.g., business unit level, as part of a risk assessment. Technical details for information systems may not be available in such a high-level risk assessment. - When a high level risk assessment is requested, in many cases, the assessment results will be ultimately communicated to senior management for supporting strategic level decision-making, e.g., how to allocate business resources to address various types of risks within an organization. - When T-M is to be conducted at a high level, it usually involves the following activities: Interviews with key stakeholders such as IT security managers, internal auditors, operational risk officers, etc. Review of existing documents such as previous IT audit reports, SOC2 reports (applicable for publicly listed companies), incident reports, internal policies/standards/procedures, previous risk assessment reports, network architecture documents, etc. Workshops with key stakeholders to validate preliminary T-M findings Key questions to be answered before a 2. How much time is given to perform the T-M exercise? - For a Threat Modelling exercise to be successful, information needs to be collected from a variety of sources, and the dependency issues have to be considered carefully before a completion date is promised. 3. Is the scope well defined and understood by all stakeholders? - A T-M exercise may be conducted to cover the whole organization, a specific business unit, a specific IT application/platform, or a specific project. - Make sure you are able to explain the difference between Risk Assessment and Risk Analysis to your audience (and stakeholders). - T-M, as a tool of identifying & quantifying cybersecurity risks, can be leveraged for both scenarios (assessment and analysis). Key questions to be answered before a 4. Is there any specific requirement for T-M methodology? - Is the sponsor of the engagement requiring a particular industry model such as OCTAVE to be used? - It is important to note that - Although multiple industry methods are available in the public domain, their fundamental elements and concepts are quite similar one to another. If the sponsor has no preference for one method over another, then your job is to clearly communicate your proposed methodology to the engagement team and make sure any concerns raised by stakeholders will be addressed before the exercise begins. Key questions to be answered before a 5. Has the sponsor specified certain IT assets to be included in the review? Or it is up to the discretion of the assessor? - Obviously, this would be related to the scope of the exercise. If the T-M is to be conducted at a higher-level of organization, then this question becomes more relevant and the assessor will need to obtain a consensus with all stakeholders. - If the scope is confined to a single IT system or application, the sponsor typically expects the assessor to conduct an in-depth technical review on the system/application. For example, before a new IT application is brought into the Production environment, the project manager may request a Risk Analysis to be performed. In such cases, since IT assets have been clearly defined and the scope is rather limited, technical vulnerability scans and/or penetration testing would be conducted to identify the technical vulnerabilities for the specified system/application. The subsequent T-M exercise would be focused on evaluating controls (and control effectiveness) for the identified vulnerabilities. Building Asset-based Threat Profiles Unless you are performing an extremely high-level risk assessment with a very short timeframe, it is often inevitable for the assessor to ask beginning of the assessment. As an assessor, you could face one of the two scenarios below, depending on the nature of the engagement: a) The organization has well-documented IT assets, and/or the sponsor of the T-M engagement dictates which assets will be the focus of the exercise, e.g., IT assets which support a specific payment transaction process, etc. b) The sponsor of the T-M engagement expects the assessor to identify the in-scope assets for the assessment.  Building Asset-based Threat Profiles As a risk assessor, oftentimes you will be challenged by the lack of specifics from the engagement sponsor and some degree of obscurity. This is also part of the reason that many organizations turn to external consultancy for help they want security experts to tell them what assets involve higher risks for cybersecurity and need to be examined with an elevated priority! Typical items to be considered when you are tasked with determining the in-scope assets: a) Internet-facing services b) Common infrastructure services like DNS, DHCP, etc. c) IT systems supporting critical business processes d) Systems (e.g., servers, databases, applications, and network devices, etc.) which process and/or store sensitive information e) Desktop environment and other end user devices including mobile f) Network infrastructure components and security devices g) Physical facilities, e.g., data centers, backup locations, offices, etc.  Mapping of Vulnerabilities to Threats Threat Actors Common Vulnerabilities Common Asset Containers Inadequate Poor Physical Scenario 1 Threat Actor ( ) Logging & Operating Servers exploits Vulnerability ( ), as a Crime Organizations Monitoring Environment or Nation States result, ( ) would take place. Inadequate Workstations Segregation of Insecure Code Duties Scenario 2 -- Portable Devices (Smart External Individual Phones/Pads, USB Drives,) Attackers Inadequate Asset Lack of Data Scenario 3 -- Classification Encryption Operating Systems Lack of Inadequate Political/Religious Validation of Security Applications (Internal, External, Activism Input/output Hardening SaaS, etc.) Inadequate Poor Security Telephones, Printers, and other Note: For each type of asset Insider (Malicious and Vulnerability Practices of 3rd Peripheral's container, there would be a Management Party Vendors Non-malicious) number of scenarios; as a risk Lack of User Third-party Vendors and Services assessor, your job is to identify the Poor Security Act of God Governance Security most relevant scenarios based on Awareness (Earthquake, Databases two factors: probability of Flooding, etc.) Inadequate exploitation and business impact! Recovery Inadequate Access Control Infrastructure Devices (Active System Malfunctions Capability Directory, DHCP, etc.) (e.g., Power Outage, etc.) Inadequate Inadequate Incident Intrusion Security Devices (SIEM, IDS, IPS, Management Detection etc.)  Scenario 1 Threat Actor (A) For Scenario 1, what controls are in For Scenario 1, what would be the exploits Vulnerability (B), as a place? How effective they are, residual risk level? Is it acceptable result, (XYZ) would take individually and collectively? (i.e., within risk appetite)? place. Scenario 2 -- Scenario 2 -- Scenario 2 -- Scenario 3 -- Scenario 3 -- Scenario 3 -- Make sure the internal stakeholders To answer those questions, the The key objective of a risk including the engagement sponsor risk assessor needs to consult assessment is to identify the will eventually reach a consensus on with control owners. Evaluating (residual) risks which are beyond the selected scenarios, as well as the the overall control effectiveness the risk appetite. In such cases, a ratings of probability and business for an identified scenario could risk response (e.g., mitigate, impact. As a risk assessor, you can become a subjective matter. To help propose initial ratings but the help mitigate the individual final ones need to be agreed upon biases, workshops can be (signed off) by internal key conducted to review the stakeholders. outcomes with a team effort. Team Exercise! Assuming that the e-class application (the web app you use on a daily basis for your study at YorkU) is based on a three-tier architecture. Based your own knowledge/experience with e-class (e.g., functionality, application criticality, information being processed, etc.), for each of the tiers described below, can you please come up with one or two cyber attack scenarios base on your own experience with e-class? Presentation tier / Web Server The presentation tier is the user interface and communication layer of the application, where the end user interacts with the application. Its main purpose is to display information to and collect information from the user. This top-level tier can run on a web browser, as desktop application, or a graphical user interface (GUI), for example. Web presentation tiers are usually developed using HTML, CSS and JavaScript. Desktop applications can be written in a variety of languages depending on the platform. Application tier / Application Server The application tier, also known as the logic tier or middle tier, is the heart of the application. In this tier, information collected in the presentation tier is processed - sometimes against other information in the data tier - using business logic, a specific set of business rules. The application tier can also add, delete or modify data in the data tier. The application tier is typically developed using Python, Java, Perl, PHP or Ruby, and communicates with the data tier using API calls. Data tier / Database Server The data tier, sometimes called database tier, data access tier or back-end, is where the information processed by the application is stored and managed. This can be a relational database management system such as PostgreSQL, MySQL, MariaDB, Oracle, DB2, Informix or Microsoft SQL Server, or in a NoSQL Database server such as Cassandra, CouchDB or MongoDB. In a three-tier application, all communication goes through the application tier. The presentation tier and the data tier cannot communicate directly with one another.