Risk Management Topic 03 Overview. PDF

Risk Management Topic 3 Overview Three Pillars Standards Risk, Touchpoints, Knowledge Orange Book and Common Risk Management Criteria Assessment and Cost Metrics Identify, Collect, C...

Risk Management Topic 3 Overview Three Pillars Standards Risk, Touchpoints, Knowledge Orange Book and Common Risk Management Criteria Assessment and Cost Metrics Identify, Collect, Compose, Identification, Synthesis, Mitigation, Measuring and Visualize Reporting Three Pillars of Software Security 1. Applied Risk Management 2. Software Security Touchpoints 3. Knowledge Applied Risk Management How much effort to invest in security Consequences of security breaches Acceptable-level of security Tracking and mitigating risk throughout the full SDLC Risk = probability x impact Software Security Touchpoints System-wide activity: from design to testing and feedback Touchpoints: Code review Architectural risk analysis Penetration testing Risk-based security testing Abuse cases Security requirements Security operations Knowledge Gathering, encapsulating, and sharing security knowledge Knowledge catalogs: principles, guidelines, rules, vulnerabilities, exploits, attack patterns, historical risks Knowledge categories: Prescriptive knowledge Diagnostic knowledge Historical knowledge Applied along the SDLC Overview Three Pillars Standards Risk, Touchpoints, Knowledge Orange Book and Common Risk Management Criteria Assessment and Cost Metrics Identify, Collect, Compose, Identification, Synthesis, Mitigation, Measuring and Visualize Reporting Risk Assessment Real Cost of Cyber Attack Damage of the target may not reflect the real amount of damage Services may rely on the attacked service, causing a cascading and escalating damage Need support for decision makers to Evaluate risk and consequences of cyber attacks Support methods to prevent, deter, and mitigate consequences of attacks Ransomware Q4 2019 Data Defense: Back up Avoid Suspicious Emails and Links Patch https://www.msspalert.com/ cybersecurity- research/ransomware- payouts-coveware-findings/ Risk Management Framework (Business Context) Understand Business Context Identify Business Carry Out Fixes and Technical Risks and Validate Synthesize and Rank Define Risk Risks Mitigation Strategy Measurement and Reporting 12  Understand the Business Context Who cares? Identify business goals, priorities, and circumstances, e.g., – Increasing revenue – Meeting service-level agreements – Reducing development cost – Generating high return investment Identify software risk to consider 13  Identify Business and Technical Risks Why should business care? Business risk Technical risk – Direct threat – Runs counter to planned – Indirect threat design and Implementation Consequences Consequences – Financial loss – Unexpected system calls – Loss of reputation – Avoidance of control – Violation of customer or (audit) regulatory constraints – Unauthorized data access – Liability – Needless rework of artifacts Tying technical risks to the business context in a meaningful way 14  Synthesize and Rank the Risks What should be done first? Prioritization of identified risks based on business goals Allocating resources Risk metrics: – Likelihood – Impact – Severity – Number of emerging risks 15  Define the Risk Mitigation Strategy How to mitigate risks? Available technology and resources Constrained by the business context: what can the organization afford, integrate, and understand Need validation techniques 16  Carry Out Fixes and Validate Perform actions defined in the previous stage Measure “completeness” against the risk mitigation strategy – Progress against risk – Remaining risks – Assurance of mechanisms Testing – Measure the effectiveness of risk mitigation activities 17  Measuring and Reporting Continuous and consistent identification and storage of risk information over time Maintain risk information at all stages of risk management Establish measurements, e.g., – Number of risks, severity of risks, cost of mitigation, etc. 18  Outline Three Pillars of Software Security Risk management Standards on Evaluating Secure System Security Analysis using Security Metrics 19  Standards on Evaluating Secure System Trusted Computer System Evaluation Criteria (TCSEC) , also known as “Orange Book” Common Criteria (ISO 15408) 20  National Computer Security Center 1981: National Computer Security Center (NCSC) was established within NSA – To provide technical support and reference for government agencies – To define a set of criteria for the evaluation and assessment of security – To encourage and perform research in the field of security – To develop verification and testing tools – To increase security awareness in both federal and private sector 1985: Trusted Computer System Evaluation Criteria (TCSEC) == Orange Book Obsolete, replaced by Common Criteria 21  Objectives of Orange Book Orange Book objectives – Guidance of what security features to build into new products – Provide measurement to evaluate security of systems – Basis for specifying security requirements Trusted Computing Base (TCB) security components of the system: hardware, software, and firmware + reference monitor 22  Orange Book Set of criteria and requirements Three main categories: – Security policy – protection level offered by the system – Accountability – of the users and user operations – Assurance – of the reliability of the system 23  Orange Book Levels Highest Security – A1 Verified protection – B3 Security Domains – B2 Structured Protection – B1 Labeled Security Protections – C2 Controlled Access Protection – C1 Discretionary Security Protection – D Minimal Protection No Security 24  Common Criteria (ISO 15408) January 1996: Common Criteria – Joint work with Canada and Europe – Separates functionality from assurance – Nine classes of functionality: audit, communications, user data protection, identification and authentication, privacy, protection of trusted functions, resource utilization, establishing user sessions, and trusted path. – Seven classes of assurance: configuration management, delivery and operation, development, guidance documents, life cycle support, tests, and vulnerability assessment. 25  Common Criteria Evaluation Assurance Levels (EAL) Lowest Security EAL1: functionally tested EAL2: structurally tested EAL3: methodologically tested and checked EAL4: methodologically designed, tested and reviewed EAL5: semi-formally designed and tested EAL6: semi-formally verified and tested EAL7: formally verified design and tested Highest Security 26  Outline Three Pillars of Software Security Risk management Standards on Evaluating Secure System Security Analysis using Security Metrics 27  Introduction How to quantitatively measure and demonstrate the amount of security for a computer/network? – Meaningful security metrics for networked (e.g., enterprise) systems are significantly more difficult to define, analyze, compose, and use intelligently. Challenges – What security metrics are meaningful and useful? – How to collect security metrics? What to measure? – How to compose enterprise-level security metrics? – How to present the security metrics in a clean manner? “Automatic security analysis using security metrics”, Kun Sun et al., MILCOM 2011. 28  System Architecture Develop a toolkit including security metrics collection, security metrics analysis, and security metrics visualization using security metrics. 29  Step 1: Identify Security Metrics Summarize exiting security metrics and identify new security metrics. – Collect existing security metrics: financial metrics; application security; configuration management; network management; asset management, etc. – Identify new security metrics Patch risk Security score Criticality Time series 30  Patch Risk There is a risk to apply patches to fix vulnerabilities in applications. – When an operating system is patched, the software may or may not function properly from that point forward. – The patches themselves may contain vulnerabilities which require patching. – The risk of a patch may be derived according to the trustworthiness of its provider, and how long the patch has been released and verified. 31  Security Score Security score provides an explicit number to evaluate the security of a computer or a network. Three types/levels of security scores: – Security score for individual vulnerability (e.g., CVSS score**). – Security score for one computer with multiple vulnerabilities. – Security score for a network with multiple computers. A “one-shot” security score may not be meaningful or useful for mission-awareness situations, in which different missions rely differently on the available services and applications. 32  Criticality Criticality is a combined metric to evaluate the importance of one computer in the network. It depends on – Location (intranet, DMZ, internet) – Service (HTTP, FTP, SSH) – Role (Firewall, Desktop, Router) – Asset (database, financial files) 33  Time Series Time series is to show the changes of security in a period. – It tells whether the security of a computer is improved or falls below a pre-determined threshold. Security changes can be triggered by many factors – Vulnerability changes over time (CVSS Temporal Metrics) – Network configuration – Security training – Financial problems 34  Step 2: Collect Security Metrics We focus on collecting security metrics about vulnerability and network reachability automatically. – Scan vulnerabilities on computers using Nessus scanner. – Obtain vulnerability score based on NVD/CVSS. – Obtain firewall rules, network configuration files, and network topology to derive network reachability information. 35  NVD/CVSS http://nvd.nist.gov/download.cfm#CVE_FEED Provides XML database on CVSS score and Vector. 36  XML Parser for CVSS Dataset Raw CVSS vulnerability record in XML format. We develop an XML parser to extract security metrics from the database and save the metrics in a table. Entry Identifier CVE-2009-0022 Score 6.3 Severity Medium Vector (AV:N/AC:M/Au:S/C:C/I:N/A:N) Vuln_Types Conf Range Network Vuln_Soft Samba 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6 Description Samba 3.2.0 through 3.2.6, when registry shares are enabled, allows remote authenticated users to access the root files ystem via a crafted connection request that specifies a blank share name. 37  Network Reachability Network reachability captures the interactions among all attack possibilities in a network, so it has direct impacts on security scores for interdependent computers. It consists of three components: – Network topology Import network topology from OPNET network design software. JANASSURE tool by IAI can automatically obtain network topology information. – Router Configuration We can import router configuration files from CISCO routers. – Firewall Rules We can import firewall rules from CISCO routers. 38  Composing Security Score Use AHP (Analytic hierarchy process) to decide different weights for exploitability (access vector, access complexity, authentication) and impact (confidentiality, integrity, availability). Vulnerability Score 1.0 Exploitability Impact 0.4 0.6 Access Access Authenticatio Confidentiality Integrity Availability Vector Complexity n 0.2 0.2 0.2 0.13333 0.13333 0.1333 39  Step 4: Visualize Security Metrics Use an example bank system to show the security metrics Dashboard for the whole network and individual computer. 40 Main Dashboard 41 Host Dashboard 42  Limitations We assume vulnerabilities are independent to each other, which may not be true in real world. What if the vulnerabilities on one computer are correlated to each other? – E.g., one user who installs application A (with vulnerability v1) always install the application B (with vulnerability v2). – How to obtain this correlation information? – How to take the correlation into calculating the security score? 43  Limitations Summary/Average/Max/Min of the scores on the computers are not good enough Combine vulnerability dependent information and network reachability information to measure the security of a network. – Assume we know the reachability information of the network from firewall rules, network configuration. – From NVD, we know one vulnerability may lead to or facilitate another vulnerability. In simple cases, assume all the vulnerabilities on one computer are independent to all the vulnerabilities in all other computers. If vulnerability Va on computer A is a pre-requisite for vulnerability Vb on computer B, how do we change the score? 44