IT Risk Management Class 5 SU2024

Threat Modelling and Key Considerations CLASS #5 FOR IT RISK MANAGEMENT By JIANG HE, PH.D., CISSP, CCSP, CISA, CRISC Threat modeling – why it is needed? 1. Threat Modeling is a tool developed for identifying information security risks facing an organization 2. Managing information security risk is...

Threat Modelling and Key Considerations CLASS #5 FOR IT RISK MANAGEMENT By JIANG HE, PH.D., CISSP, CCSP, CISA, CRISC Threat modeling – why it is needed? 1. Threat Modeling is a tool developed for identifying information security risks facing an organization 2. Managing information security risk is a complex and challenging task for any organization, largely due to the facts below: a) there could be a wide variety of threats and vulnerabilities which need to be taken into consideration, and some of the threats and/or vulnerabilities may not be well understood by the organization. b) threats and vulnerabilities are moving targets and constantly changing, e.g., new software and hardware are being introduced into the network, new vulnerabilities are being discovered, new employees on-boarding and old employees leaving, new toolkits are being developed by malicious groups/individuals to exploit old vulnerabilities, etc. c) Lack of established processes to manage information security risks in a cost-effective way Threat Modelling – A comprehensive view of Offence and Defence Threats Common Common Data Vulnerabilities Containers Inadequate Poor Physical Logging & Operating Servers Crime Organizations Monitoring Environment or Nation States Inadequate Workstations Segregation of Insecure Code Duties Portable Devices (Smart External Individual Phones/Pads, USB Drives,) Attackers Inadequate Asset Lack of Data 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 Vulnerability Practices of 3rd Peripheral's Insider (Malicious and Management Party Vendors Non-malicious) Lack of User Third-party Vendors and Services Poor Security Security Act of God Governance Awareness (Earthquake, Databases Flooding, etc.) Inadequate 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.) Threat modeling – key questions to be answered before getting started 1. Where do we get started? At which level will the threat modelling be performed? e.g., at the organization level, or at the system level, or somewhere between? “Risk Assessment” vs. “Risk Analysis” “Risk assessment” is typically conducted at a higher level, e.g., organization level, or business unit level; while the “risk analysis” is typically conducted at a granular level, e.g., system level. For both Risk Assessment and Risk Analysis, the end goal would be the same – to help organizations to identify the most relevant information security risks, and then properly manage them (i.e., mitigate, transfer, accept, or avoid). 2. Are we going to conduct threat modelling on a regular basis (e.g., annually) with a well- defined scope? Or it will be conducted as an ad-hoc project covering specific systems? Understanding the Risk Management Lifecycle A variety of models existing for risk management for the domain of IT or non-IT. Fundamentally, they all consist of 4 common elements. 1. Identify a risk 2. Measure a risk 3. Respond to a risk 4. Continuous monitoring Cybersecurity risk management is no exception; and ideally, it would be integrated into the organization’s existing framework for risk management. Information Security Risk Management Process The ISRM process can be implemented at various levels, e.g., business unit level, or system/application level. *Figure 3.1, Page 46 of your textbook, Security Risk Management Multiple frameworks for the same objective – OCTAVE approach OCTAVE – “Operationally Critical Threat, Asset, and Vulnerability Evaluation Methodology”, developed by Carnegie Mellon University, and there are multiple versions published. TARA (Threat Agent Risk Assessment) Approach developed by Intel: This model concentrates on threat agents and their motivations, methods, and objectives, and how they map to existing controls, not on the weak points themselves. Key Components to be Created/Maintained: 1) Threat Agent Library (i.e., who would be the bad guys, and their skill levels). Such attributes could be industry-specific 2) Common Exposure Library – Known security vulnerabilities and exposures at the organization 3) Methods and Objective Library (i.e., what are the bad guys trying to achieve? and most likely methods to be employed by them) Do not be confused by the variation between different models, the basic elements are the same! 1. Identify the most critical assets for the business. Depending on the granularity of your assessment, they could be high-level business processes, or lower-level infrastructure systems & data containers. 2. For the concerned assets, link the threat agents to the applicable vulnerabilities, and then assess the potential damage, i.e., what would be the consequence if a weakness/vulnerability is exploited by the bad guy? 3. A valid link between a threat agent and an applicable vulnerability indicates that something bad could happen, i.e, an inherent risk has been identified. However, if your controls are effective, we are looking at a relatively low residual risk, i.e., we would be OK given the protections in place! 4. The end goal of an security risk assessment/analysis is to understand the level of residual risk.  Security Risk Analysis Example Example Analysis: Attributes for App “C”: 1) Home Grown Web Application (non-distributed Critical Business Task “XYZ” deployment) 2) Web Server sitting in DMZ, HTTPS Client Authentication App Level IT Required Application “A” Application “B” Application “C” 3) Processing Sensitive User Assets Data (e.g., Financial, Personal, etc.) 4) Service Interruption can be tolerated for one or two days Threat Scenarios with a High Probability of Attacks: 1) Deliberate External Attackers > Lack of Validation of Input/Output Data > Disclosure Database of Information with the Threat Level IT Scenario “Tampering with Oracle DB IBM DB2 Assets Software/Hardware” 2) Deliberate External Attackers > Inadequate Password Management > Disclosure of Information with the Threat Windows 2012 Server Level Unix Server “X” Scenario “Unauthorized Access Server “Y” IT Assets to Information Systems” 3) Deliberate External Attackers> Poor Practices for Vuln Management > Disclosure of Information with the Threat Scenario “Espionage.”  Security Risk Analysis Example (Cont’d) Example Analysis: Attributes for the Oracle DB: 1) One of our most critical information assets Critical Business Task “XYZ” 2) Sitting behind firewalls and only interact with specified apps App Level IT 3) Service Interruption cannot be Application “A” Application “B” Application “C” tolerated but redundancy has Assets been considered in design 4) Vendor released security patches are not implemented in a timely manner 5) Database access profiles (DBAs) are not reviewed regularly 6) Server maintenance is done by a third-party Database Threat Scenarios with a High Level IT Probability of Attacks: Oracle DB IBM DB2 Assets 1) Deliberate Internal Users > Inadequate Segregation of Duties> Disclosure of Information with the Threat Windows 2012 Scenario “Abuse of User Priv.” Server Level Unix Server “X” 2) Third Party Vendors> Lack of Server “Y” IT Assets Security Control in 3rd Party> Disclosure of Information with the Threat Scenario “3rd Party Misconduct” 3) Deliberate Internal Users > Inadequate Security Logging> Disclosure of Information with the Threat Scenario “Fraud.”  Security Risk Analysis Example (Cont’d) Example Analysis: Attributes for the Server “Y”: 1) A very critical IT asset due to its role supporting the DB2 database Critical Business Task “XYZ” 2) Sitting behind firewalls and company’s standard hardening procedure has been followed 3) Service Interruption tolerance App Level IT Application “A” Application “B” Application “C” level is minimum Assets 4) Microsoft Security Patches are installed on a monthly basis 5) Server maintenance is done by a third-party 6) Server access profiles (e.g., local admin accounts, IDs within Domain Admin Group, etc.) are not reviewed regularly 7) Anti-virus installed and updated in a timely manner 8) Security Logs are not reviewed Database Level IT Threat Scenarios with a High Oracle DB IBM DB2 Probability of Attacks: Assets 1) Deliberate Internal Users > Inadequate Segregation of Duties> Disclosure of Information with the Threat Scenario “Abuse of User Priv.” Windows 2012 Server Level Unix Server “X” 2) Third Party Vendors> Lack of Server “Y” IT Assets Security Control in 3rd Party> Disclosure of Information with the Threat Scenario “3rd Party Misconduct” 3) Deliberate Internal Users > Inadequate Security Logging> Disclosure of Information with the Threat Scenario “Unauthorized Access to Information Systems.” Case Study and Group Discussion