IT Risk Management, Planning and Mitigation TCOM 5253 / MSIS 4253 Quantifying Risk – the $$$

1. IT Risk Management, Planning and MitigationTCOM 5253 / MSIS 4253Quantifying Risk – the $$$ 25 October/1 November 2007 Charles G. Gray (c) 2007 Charles G. Gray

2. Qualitative vs. Quantitative • We used the Qualitative approach first to: • Identify risks • Prioritize the work • Avoid time-consuming quantitative analyses early in the process • Extensive time and effort needed to agree on monetary estimates • Avoid delays in the analysis due to disagreements among stakeholders • Attempt to strike a balance between accuracy and efficiency (c) 2007 Charles G. Gray

3. The Hard Work Begins - $$$ • Task one - Assign a monetary value to each asset class • Task two - Identify the asset value for each risk • Task three - Produce the single loss expectancy value • Task four - Determine the Annual Rate of Occurrence (ARO) • Task five - Determine the Annual Loss Expectancy (ALE) (c) 2007 Charles G. Gray

4. A New Industry Developing • The insurance industry is just beginning to insure IT risks • Actuarial tables may soon be available • Aid in estimating asset value • Assign risk probabilities • Financial risk management team may have insurance valuation and coverage for specific assets • Stay tuned – call your insurance broker (c) 2007 Charles G. Gray

5. Assigning Monetary Values • Begin with the “HBI” assets • Assign monetary values for • Tangible assets • Equipment, facilities, software, etc. • Intangible assets • Intellectual property, personnel skills, “goodwill”, corporate image, etc. • Be warned! - This is not easy (c) 2007 Charles G. Gray

6. Categories of Values (TCO) • Replacement cost • Maintenance cost • Redundancy/availability • Organization/market reputation • Organization productivity • Annual revenue/profit generated • Competitive advantage • Internal operating efficiencies • Legal/compliance liability (c) 2007 Charles G. Gray

7. Choosing an Asset Value • From slide 6, total the values to determine the TCO estimate for the asset • Repeat the process for EACH HBI asset • The Risk Management Team should plan to devote considerable time to this effort – it is not simple • From all HBI assets, select one monetary value to represent the worth of the asset class • Most conservative is to choose the lowest, but a company may also use an average (or other) value • Value must be meaningful to the organization • This is a management/stakeholder decision (c) 2007 Charles G. Gray

8. An Alternate Approach for HBI Assets • Use FASB guidelines for the definition of “materiality” in financial statements for publicly traded companies as a reference pointonly (no “formula” approach) • General rule of reference is “5% of financial statement values” • For a $5B company = $250M • Values vary significantly between organizations • May NOT work for MBI and LBI values (c) 2007 Charles G. Gray

9. MBI and LBI Asset Classes • Repeat the activities on slides 5, 6, and 7 for the MBI and LBI classes • May choose the current costs of security-specific controls for each asset class • Example: estimated total cost for software, hardware and operational resources in order to provide antivirus services for the organization • Or any other value that the stakeholders/business owners agree upon (c) 2007 Charles G. Gray

10. Identify the Asset Value • Assign an asset value to each asset class • HBI = ?? (e.g., from slide 8, $250M) • MBI = ?? (e.g., could be HBI / 2) • LBI = ?? (e.g., could be MBI / 2) • It has to be supportable with documentation or experience of the stakeholders, and agreed by all • Note: Each organization should plan to revise value estimates based on experience (c) 2007 Charles G. Gray

11. Single Loss Expectancy (SLE) • SLE = Asset value * Exposure factor • Use the same exposure ratings that were developed for the detailed risk analysis • May require adjustments as more experience is gained • Exposure factor is the estimated percent of damage to an asset (c) 2007 Charles G. Gray

12. SLE Example (c) 2007 Charles G. Gray

13. Annual Rate of Occurrence (ARO) • What is the probability of the risk occurring? • In today’s environment, are these “description examples” adequate? Should time frames be shorter? • The Information Security Group must still select ONE value to represent the ARO. (c) 2007 Charles G. Gray

14. Annual Loss Expectancy (ALE) • Annualized Loss Expectancy • ALE = SLE * ARO • Attempt to annualize the potential cost of the risk • NOT an annualized expense that can be budgeted for (such as depreciation) • Useful for estimating cost/impact ONLY • IF the risk is realized, the impact may occur in its entirety (regardless of the exposure rating and ARO estimates) (c) 2007 Charles G. Gray

15. ALE Example (c) 2007 Charles G. Gray

16. Summary • Planning, data gathering and prioritization steps seek to balance accuracy and efficiency • Use a hybrid approach applying qualitative steps first to triage risks, and then use financial techniques (quantitative analysis) to provide further definition (c) 2007 Charles G. Gray

17. The Result of the Risk Management Assessment Phase • A prioritized list of risks to the organization’s most valuable assets • Estimates of financial impact (c) 2007 Charles G. Gray

18. Risk Management Project Status Check • At this point, all concerned must acknowledge the results obtained thus far, and agree to the ongoing process • Stakeholders/business owners • Security Risk Management Team • Executive Sponsor • Next step is to determine appropriate mitigation actions (c) 2007 Charles G. Gray

19. Next Objective • Develop clear plans to control, accept, transfer, or avoid each of the top risks identified in the risk assessment process (c) 2007 Charles G. Gray

20. Risk Mitigation Options (1) • Assumption – Accept the potential risk and continue to operate the IT system • Also known as “self insurance” • Avoidance – Eliminate the risk cause and/or consequence • Add controls to prevent risk from occurring • Remove certain functions • Shut down the system • Not highly likely – so avoidance is not considered to be a viable option for most organizations (c) 2007 Charles G. Gray

21. Risk Mitigation Options (2) • Limitation – Implement controls that minimize the adverse impact of a threat • Use of supporting, detection or preventive controls • Limited system operation pending implementation of additional mitigation actions • Transfer – Use other options to compensate for the loss (e.g., insurance) (c) 2007 Charles G. Gray

22. Process Overview Security Risk Management Team 1 3 4 Define functional requirements Estimate risk reduction Review solutions Mitigation Owner 5 Estimate cost of solution 2 Identify control solutions Security Steering Committee 6 Select the risk mitigation strategy (c) 2007 Charles G. Gray

23. Roles and Responsibilities (1) • Business Operations • Identify procedural controls available to manage risk • Business Owner • Owns the cost/benefit analysis for the assets • Finance • Assists with the C/B analysis and with budget development • Human Resources • Identifies personnel training requirements and controls (c) 2007 Charles G. Gray

24. Roles and Responsibilities (2) • IT – Architecture • Identifies and evaluates potential controls • IT – Engineering • Determines cost of control solutions and how to implement them • IT – Operations • Implements technical control solutions • Internal Audit • Identifies compliance requirements and review control effectiveness (c) 2007 Charles G. Gray

25. Roles and Responsibilities (3) • Legal • Identifies legal, policy and contractual controls and validates value estimates created for brand impact, corporate liability, and other business issues • Public Relations • Validates value estimates created for brand impact, corporate liability, other business issues (c) 2007 Charles G. Gray

26. Roles and Responsibilities (4) • Security Steering Committee • Selects control solutions based on recommendations from the Risk Management Team • Risk Management Team • Defines functional requirements for the controls for each risk, communicates project status to stakeholders and affected users as needed • SME/security technologist assigned to each identified risk (c) 2007 Charles G. Gray

27. Keys to Success • Players must recognize that significant resources will be required ($$ and heads) • RM team must clearly explain expectations • Build consensus • Underlying dissention may undermine RM team recommendations even after presentation to the security steering (executive) committee • Avoid filibusters • Refusal to agree to a recommendation • Seek to impose a minority position on the majority (c) 2007 Charles G. Gray

28. Process Overview Security Risk Management Team 1 3 4 Define functional requirements Estimate risk reduction Review solutions Mitigation Owner 5 Estimate cost of solution 2 Identify control solutions Security Steering Committee 6 Select the risk mitigation strategy (c) 2007 Charles G. Gray

29. Define Functional Requirements • Defined clearly for each risk • Functions desired, not technologies to be specified • Define what the controls must accomplish • Define what needs to be done – not how it is to be done • Review at least annually, or when a risk is perceived to change (c) 2007 Charles G. Gray

30. Key Words in Requirements • MUST, REQUIRED, SHALL • An absolute requirement • MUST NOT, SHALL NOT • An absolute prohibition • SHOULD, RECOMMENDED • Consider particular circumstances • Weigh full implications of choosing a different course of action (may apply to LBI risk) • SHOULD NOT, NOT RECOMMENDED • Understand the full implications • MAY, OPTIONAL • Only if truly “optional” (c) 2007 Charles G. Gray

31. Process Overview Security Risk Management Team 1 3 4 Define functional requirements Estimate risk reduction Review solutions Mitigation Owner 5 Estimate cost of solution 2 Identify control solutions Security Steering Committee 6 Select the risk mitigation strategy (c) 2007 Charles G. Gray

32. Identify Control Solutions • List of potential controls for each risk • Assistance from the Information Security Group, consultants, SMEs • Two basic methods (covered on the following slides) • Informal brainstorming • Identify potential controls by: organizational, operational, technical, subdivided into • Prevention, detection/recovery, management (c) 2007 Charles G. Gray

33. Brainstorming Questions • What steps could be taken to resist or prevent the risk from occurring? • What could the organization do to recover from a risk exploit? • What could be done to detect a risk exploit while it is occurring? • How can controls be audited and monitored? • How can effectiveness be validated? • What else could be done to manage a risk? (c) 2007 Charles G. Gray

34. Organizational Controls (1) • Preventive controls • Clear (documented) roles and responsibilities • Separation of duties – least privileges • Compartmentalization • Documented security plans and procedures • Security training/awareness campaigns • Controls for granting/terminating access • Processes for granting access to contractors, vendors, partners and customers • Compartmentalization (c) 2007 Charles G. Gray

35. Organizational Controls (2) • Detection Controls • Ongoing risk management programs • Recurring reviews of controls to ensure continued effectiveness • Background investigations on candidates for employment • Consider internal promotions with different responsibilities • Rotate duties • Ferret out possible nefarious activities by members of the IT staff (c) 2007 Charles G. Gray

36. Organizational Controls (3) • Management Controls • Incident response planning • Quickly react to and recover from security violations • Minimize impact of the incident • Prevent the spread to other systems • Business continuity planning • Aids in recovering from catastrophic events that might impact a large portion of the IT infrastructure (c) 2007 Charles G. Gray

37. Operational Controls (1) • Preventive controls • Physical protection for computing facilities • Locks, fences, guards, intrusion detection • Physical protection for end-user systems • Mobile computer locks, encryption for mobiles • Emergency backup power • Fire protection – automatic fire suppression • Temperature and humidity control • Media access control and disposal procedures • Off-site backup storage facilities (c) 2007 Charles G. Gray

38. Operational Controls (2) • Detection and recovery controls • Physical security • Sensors, • Alarms, • Cameras, • Motion detectors • Environmental security • Smoke/fire detectors • Alarms • Sensors • Flood detectors (c) 2007 Charles G. Gray

39. Technological Controls (1) • All of the technological components of an organization’s IT systems • System architecture/design • Engineering • Hardware • Software • Firmware • Controls vary considerably in complexity and effectiveness (c) 2007 Charles G. Gray

40. Technological Controls (2) • Preventive controls • Authentication • Validating the credentials of a person, process or device • Digital signatures, smart cards, biometric data, combination of username/password • Authorization • Granting a person, process or device access to certain information • Derived from the identity of the person or device requesting access, verified through authentication (c) 2007 Charles G. Gray

41. Technological Controls (3) • More preventive controls • Nonrepudiation • Ensure that an IT system user cannot falsely deny that they performed an action • Undeniable proof that the user took a specific action, such as money transfer, authorizing a purchase, or sending a message • Access control • Limit user access based on identity or membership in a predefined group • Protected communications • Encryption to protect the integrity and confidentiality of information transmitted (c) 2007 Charles G. Gray

42. Technological Controls (4) • Detection and Recovery controls • Audit systems • Monitor and track system behavior deviating from standards • Fundamental tool for detecting, understanding, and recovering from security breaches • Antivirus programs • Detect and respond to malicious software • System integrity tools • Detect unauthorized system changes • Should run automatically in the “background” (c) 2007 Charles G. Gray

43. Technological Controls (5) • Management controls • Security administration tools included in some operating systems • Maintain, support and troubleshoot security feature • Cryptography • Foundation for many other controls • Create, store and distribute crypto keys • Identification • Accountability • Access control (discretionary, role-based, mandatory) (c) 2007 Charles G. Gray

44. Next Week • How well do the proposed solutions meet the requirements? • Estimating the risk reduction • Estimating the solution cost • Cost/benefit analysis • Selecting solutions and preparing for implementation (c) 2007 Charles G. Gray