Presentation is loading. Please wait.

Presentation is loading. Please wait.

Developing an Information Technology Risk Management Program Training for DHHS Information Security Officials and Backup Security Officials.

Similar presentations


Presentation on theme: "Developing an Information Technology Risk Management Program Training for DHHS Information Security Officials and Backup Security Officials."— Presentation transcript:

1

2 Developing an Information Technology Risk Management Program Training for DHHS Information Security Officials and Backup Security Officials

3 What this training covers..  What Risk Management means  What NIST says you should do  What ISO says you should do  What C OBI T says you should do  What Microsoft says you should do  What HIPAA says you should do  What NC ITS says you should do  What DHHS says you should do  What you should do and when to do it

4 “Take calculated risks. That is quite different from being rash.” General George S. Patton “Only those who risk going too far can possibly find out how far they can go” T.S. Elliot “Of course you have to go out on a limb sometimes; that’s where the fruit is” Unknown Risk

5 Information Security the protection of data against unauthorized access or modification

6 What is “Risk”?  Risk is the net mission impact considering both the likelihood that a particular threat-source will exercise (accidentally trigger or intentionally exploit) a particular information system vulnerability, and the resulting impact on the organization if this should occur (NIST)  Risk is the probability of a vulnerability being exploited in the current environment, leading to a degree of loss of confidentiality, integrity, or availability, of an asset. (Microsoft)

7 What is Risk Management?  The total process of identifying, controlling, and minimizing information system related risks to a level commensurate with the value of the assets protected  The goal of a risk management program is to protect the organization and its ability to perform its mission from IT-related risk

8 Risk Management is the Keystone of Information Security

9 Golden and Silver Rules of RM All risk is owned! Risk that is not assigned is owned by the organization’s Director

10 Why are we doing this?  Why do we do risk management?  Why does a car have brakes? An organization that can take advantage of opportunities (and the inherent risks) will outlast an organization which cannot

11 Reactive Risk Management 1) Protect human life and people’s safety 2) Contain the damage 3) Assess the damage 4) Determine the cause of the damage 5) Repair the damage 6) Review response, and update policies

12 Owners Controls Threat Sources Vulnerabilities Risk Assets Threats to reduce leading to that increase that may be reduced by that may possess to impose give rise to wish to abuse and/or may damage may be aware of that exploit wish to minimize value to Proactive Risk Management

13 Owners Controls Threat Sources Vulnerabilities Risk Assets Threats Proactive Risk Management

14 What Assets are we Protecting?  Servers  Desktop Computers  Laptops and PDAs  Switches and Routers  Application software  Development Tools  Source Code  VPN Access  Backup Tapes   Data Integrity  All Files on the Server  Consumer Information  Network Infrastructure  DHCP  Web Site Availability  Reputation  Employee Morale

15 Owners Controls Threat Sources Vulnerabilities Risk Assets Threats Proactive Risk Management

16 Protecting From What Threats?  Human Threats – Carelessness, Shoulder Surfing, User Abuse, Sabotage, Arson, Data Entry Errors, Intentional and Unintentional Procedure Violations  Technical Threats – Takeover of authorized session, Intrusion, Keystroke Eavesdropping, System Failure, Saturation of Resources  Environmental Threats – Fire, Earthquake, Hurricane, Tornado, Cable Cuts, Power Fluctuation, Hazardous Material Accident, Overheating

17 Owners Controls Threat Sources Vulnerabilities Risk Assets Threats Proactive Risk Management

18 Threats to What Vulnerabilities?  Unlocked doors  Unlocked windows  Misconfigured systems  Missing patches  Antivirus out-of-date  Poorly written apps  Vendor backdoors  Spyware  Software Configuration  Systems not monitored  Unnecessary protocols  Poorly defined procedures  Stolen credentials  Poor password protection  Poor Disaster Recovery  Violations not reported

19 Owners Controls Threat Sources Vulnerabilities Risk Assets Threats Proactive Risk Management

20 Vulnerabilities Protected by What Security Controls? ControlsPhysicalTechnicalAdministrative Preventive Key-card access to enter area System & Network Monitoring Security Awareness Training for staff Detective Seals on archive file cabinets Admin message on 3 incorrect logins Audit of employee exit procedures Deterrent Closed-circuit camera monitor Account lockout after 3 attempts Data owner approval of rights Corrective Physical Isolation of servers Firewall changes from past events Arranging for day time cleaning Recovery Electronic records recreate physical Netware’s file “Salvage” option Contact police after security breach

21 Owners Controls Threat Sources Vulnerabilities Risk Assets Threats to reduce leading to that increase that may be reduced by that may possess to impose give rise to wish to abuse and/or may damage may be aware of that exploit wish to minimize value to Proactive Risk Management

22 Two Approaches to Risk Assessment  Value your assets  Determine the SLE (total amount lost from a single occurrence of the risk) Single Loss Expectancy  Determine the ARO (number of times you expect the risk to occur during one year) Annual Rate of Occurrence  Determine the ALE (amount you will lose in one year if the risk is not mitigated) Annual Loss Expectancy  Determine the ROSI (ALE before control) – (ALE after control) – (annual cost of control) = ROSI Return On Security Investment 1) Quantitative Risk Assessment

23 Two Approaches to Risk Assessment  Estimate relative values  Determine what threats each asset may be facing  Determine what vulnerabilities those threats might exploit in the future  Determine controls which will mitigate the risks, and the approximate cost of each control  Management performs a cost-benefit analysis on the results 2) Qualitative Risk Assessment

24 Comparing the Two Approaches – the Benefits Quantitative Qualitative 1) Risks and assets are prioritized by financial values 2) Results facilitate management of risk by Return on Security Investment 3) Results expressed in terms management understands ($) 4) Accuracy tends to increase over time 1) Enables visibility and understanding of risk ranking 2) Easier to reach consensus 3) Not necessary to quantify threat frequency or determine financial value of assets 4) Easier to involve people who are not experts on security or computers

25 Comparing the Two Approaches – the Drawbacks Quantitative Qualitative 1) Impact values assigned to risks are based on subjective opinion 2) Very time-consuming 3) Calculations can be very complex 4) Results are presented only in monetary terms, and can be difficult for non-technical people to interpret 5) Process requires expertise 1) Insufficient differentiation between important risks 2) Difficult to justify investing in control implementation when there is no basis for a cost-benefit analysis 3) Results are dependent on the quality of the Risk Management Team that is created

26 Effective Risk Management Threats Potential Damage Attempts to access private information Fraud Malicious attacks Pranks Natural disasters Sabotage User error :Public’s Loss of confidence Critical operations halted Sensitive information disclosed Services and benefits interrupted Failure to meet contractual obligations Assets lost Integrity of data and reports compromised

27 Know what to do now?

28 Who Wants to Help You?

29 NIST - The National Institute of Standards and Technology  NIST is a non-regulatory Federal agency with the mission of developing and promoting measurement, standards and technology to enhance productivity and improve quality of life  They invent – an atomic clock; a cement-like substance that promotes bone regrowth  They develop - software for the 170 VA hospitals; complex computational models  The set standards – weights and measures, cholesterol testing, and... Information Security

30 Pertinent NIST PublicationsNIST SP An Introduction to Computer Security: The NIST Handbook SP SP Guide for Developing Security Plans for Information Technology Systems SP SP Security Self-Assessment Guide for Information Technology Systems SP SP Risk Management Guide for Information Technology Systems SP

31  The goal of Risk Management is to protect the organization and its ability to perform its mission  The focus is the mission ; not IT assets  Risk Management, therefore, is an essential management function of the organization NIST Says It’s a Management Function

32 NIST Says Risk Management has Three Parts  Risk Assessment - Determining where risks lie, and how big they are  Risk Mitigation - Prioritizing, evaluating, and implementing appropriate risk-reducing controls  Evaluation and Assessment – Since Risk Management is continuous and evolving, the past year’s Risk Management efforts should be assessed and evaluated prior to beginning the cycle again

33 Risk Management Process Risk Assessment Risk Mitigation RM Evaluation

34 National Institute of Standards and Technology SP The Ten Steps of Risk Assessment 1) System Characterization 2) Threat Identification 3) Vulnerability Identification 4) Control Analysis 5) Identify Threat-source/Vulnerability Pairs 6) Likelihood Determination 7) Impact Analysis 8) Risk Determination 9) Control Recommendations 10) Results Documentation

35 Risk Management Process Risk Assessment Risk Mitigation

36  Risk Mitigation is the process of identifying areas of risk that are unacceptable; and estimating countermeasures, costs and resources to be implemented as a measure to reduce the level of risk  Determining “appropriate risk-reducing controls” is a job for your Risk Management Committee

37 What is “Acceptable” Risk?  Setting your agency’s “risk appetite” is up to your Director and Senior Management  Because elimination of all risk is impossible, we must use the least-cost approach and implement the most appropriate controls to decrease mission risk to an acceptable level, with minimal adverse impact on the organization’s resources and mission

38 Risk Mitigation Options  Assume the Risk – Accept the risk and continue operating (how big is your appetite?)  Avoid the Risk – Stop running the program or sharing the data  Transfer the Risk – Use options to compensate for the loss, such as insurance  Lessen the Risk – Implement controls that lessen the impact or lower the likelihood

39 Risk Mitigation Methodology 1) Prioritize based on risk levels presented 2) Evaluate recommended control options 3) Conduct a cost-benefit analysis 4) Select additional controls, as necessary 5) Assign responsibility 6) Develop an action plan, if necessary 7) Implement the selected controls

40 Cost-Benefit Analysis  If control reduces risk more than needed, see if a less expensive alternative exists  If control would cost more than the risk reduction provided, then find something else  If control does not reduce risk sufficiently, look for more controls or a different control  If control provides enough risk reduction and is cost-effective, then use it

41 Residual Risk  The risk remaining after the implementation of new or enhanced controls is the residual risk  If the residual risk has not been reduced to an acceptable level, the risk management cycle must be repeated to identify a way of lowering the residual risk to an acceptable level  Understand that no IT system can be risk-free

42 Risk Management Process Risk Assessment Risk Mitigation RM Evaluation

43 Evaluation and Assessment  People, systems, and networks change, so risk management must be ongoing  Federal agencies must conduct risk management at least every three years  Stay flexible to allow changes when warranted

44 NIST Says Good Risk Management Depends Upon 1) Senior management’s commitment 2) Support of the IT Team 3) Competence of the Risk Management Committee 4) Cooperation and education of the userseducation of the users 5) Ongoing assessment of IT-related mission risks

45 Who Wants to Help You?

46 ISOISO - International Organization of Standardization  In the late 1990s, the British Standard Institute (BSI) developed a program to accredit auditing firms, called “BS 7799”  When demand grew quickly for an information security standard, the ISO (International Organization for Standardization) adapted 7799 and released Part 1 in 2000 as “ISO 17799”  ISO defines a set of recommended information security management practices

47 On-line Purchases of ISO %35 %18%9 %6 %Others 9%

48 ISO – A Set of Recommendations  ISO does not expect you to apply every piece of the standard  Instead ISO suggests that you consider each recommendation as you try to improve your information security program  If a particular recommendation helps you address an important security need, then accept it – otherwise, ignore it

49 ISO Says “First, Understand” Perfect security may be achievable only for networkless servers located in rooms without doors in stone buildings without people on high ground with no earth faults in areas with very little rain

50 10 Key Contexts of ISO Access control Asset classification and control Security policy Organizational security Personnel security Physical and environmental security Communications and operations management Systems development & maintenance Business continuity management Compliance Information Integrity Confidentiality Availability

51 ISO Deliverables

52 ISO 17799’s Information Security Management Process 1) Obtain Upper Management Support 2) Define Security Perimeter 3) Create Information Security Policy 4) Create Info Security Management System 5) Perform Risk Assessment 6) Select and Implement Controls 7) Document in Statement of Accountability 8) Audit

53 ISO Risk Assessment Steps 1) Identify assets within the security perimeter 2) Identify threats to the assets 3) Identify vulnerabilities to the assets 4) Determine realistic probability

54 ISO’s Probability of Event Scale Probability of Event FrequencyRating NegligibleUnlikely to Occur0 Very Low2 to 3 times every 5 years1 LowLess than or equal to once per year2 MediumOnce every 6 months or less3 HighOnce every month or less4 Very HighMore than once every month5 ExtremeOnce per day or more6

55 ISO Risk Assessment Steps 1) Identify assets within the security perimeter 2) Identify threats to the assets 3) Identify vulnerabilities to the assets 4) Determine realistic probability 5) Calculate harm

56 ISO’s Harm of Event Scale Harm of Event Degree of Harm Rating InsignificantMinimal to no impact0 MinorNo extra effort required to repair1 SignificantTangible harm, extra effort required to repair2 DamagingSignificant expenditure of resources required; Damage to reputation and confidence 3 SeriousExtended outage and/or loss of connectivity; Compromise of large amounts of data or services 4 GravePermanent Shutdown; Complete compromise5

57 ISO Risk Assessment Steps 1) Identify assets within the security perimeter 2) Identify threats to the assets 3) Identify vulnerabilities to the assets 4) Determine realistic probability 5) Calculate harm 6) Calculate risk (probability x harm)

58 ISO’s Risk Scale Risk Calculation (Probability times harm) Rating 0None 1 – 3Low 4 – 7Medium 8 – 14High 15 – 19Critical 20 – 30Extreme

59 ISO 17799’s Information Security Management Process 1) Obtain Upper Management Support 2) Define Security Perimeter 3) Create Information Security Policy 4) Create Info Security Management System 5) Perform Risk Assessment 6) Select and Implement Controls 7) Document in Statement of Accountability 8) Audit

60 Who Wants to Help You?

61 C OBI TC OBI T – Control Objectives for Information and related Technology  Created by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI)  The first edition was published in 1996, the second in 1998, the third in 2000, and the on- line edition became available in 2003  Recently found favor due to Enron scandal and the subsequent passage of the Sarbanes- Oxley Act

62 What C OBI T Says You Should DoC OBI T  C OBI T looks at information that is needed to support business requirements and the associated IT resources and processes  C OBI T has 34 high level objectives that cover 318 control objectives, categorized in four domains: 1) Planning and Organization 2) Acquisition and Implementation 3) Delivery and Support 4) Monitor

63 High Level Objectives C OBI T – Planning and Organization P01Define a Strategic IT Plan P02Define the Information Architecture P03Determine Technological Direction P04Define the IT Organization and Relationships P05Manage the IT Investment P06Communicate Management Aims and Direction P07Manage Human Resources P08Ensure Compliance with External Requirements P09Assess Risks P10Manage Projects P11Manage Quality

64 High Level Objectives C OBI T – Acquisition & Implementation AI1Identify Automated Solutions AI2Acquire and Maintain Application Software AI3Acquire and Maintain Technology Infrastructure AI4Develop and Maintain Procedures AI5Install and Accredit Systems AI6Manage Changes

65 High Level Objectives C OBI T – Delivery and Support DS1 Define and Manage Service Levels DS2 Manage Third-Party Services DS3 Manage Performance and Capacity DS4 Ensure Continuous Service DS5 Ensure Systems Security DS6 Identify and Allocate Costs DS7 Educate and Train Users DS8 Assist and Advise Customers DS9 Manage the Configuration DS10 Manage Projects DS11 Manage Data DS12 Manage Facilities DS13 Manage Operations

66 High Level Objectives C OBI T – Monitor M1Monitor the Processes M2Assess Internal Control Adequacy M3Obtain Independent Assurances M4Provide for Independent Audit

67 Who Wants to Help You?

68 MicrosoftMicrosoft Says.. Successful Risk Management Requires:  Executive sponsorship  A well-defined list of RM stakeholders  Organizational maturity in terms of RM  An atmosphere of open communication  A spirit of teamwork  A holistic view of the organization  Security Risk Management Team authority

69 MicrosoftMicrosoft Says.. Risk Management Has Four Phases 1) Assessing Risk – Triage an entire list of security risks, identifying the most important 2) Conducting Decision Support – Potential control solutions are evaluated, and the best are recommended for mitigating top risks 3) Implementing Controls – Control solutions are put in place 4) Measuring Program Effectiveness – Checking to make sure that the controls are providing the expected protection

70 From Microsoft’s Security Risk Management Guide, Chapter 2Microsoft’s Security Risk Management Guide, Chapter 2

71 MicrosoftMicrosoft Says.. Assessing Risk Phase has Three Steps 1) Planning – Align your annual process with your budget; Specify your scope; Identify and pre-sell stakeholders; embrace subjectivity 2) Facilitated Data Gathering – Identify tangible and intangible assets, threats, vulnerabilities, existing controls, probable impact 3) Risk Prioritization – Determine probabilities, and combine impact with probability to produce a risk statement

72 MicrosoftMicrosoft Says.. Conducting Decision Support Phase 1) Determine functional requirements 2) Identify combinations of controls (Organizational, Operational, Technological) 3) Compare proposed controls to functional requirements 4) Calculate the probable overall risk reduction to the organization 5) Estimate the cost of teach proposed control 6) Select which controls to implement

73 MicrosoftMicrosoft Says.. Implementing Controls Phase Good Network Design Secure Wireless Segment Disable LAN Services Remove User Rights Good Firewall Settings Least Privilege Necessary Small attack surface Frequent Backups Encryption Solid Building Structure

74 MicrosoftMicrosoft Says.. Measuring Program Effectiveness Phase 1) Ongoing – continues until next assessment phase 2) Should catch changes in the information systems environment, and in applications 3) Includes creating and maintaining a security risk scorecard that demonstrates the organization’s current risk profile

75 From Microsoft’s Security Risk Management Guide, Chapter 2Microsoft’s Security Risk Management Guide, Chapter 2

76 Who Wants to Help You?

77 The Health Insurance Portability and Accountability Act of 1996

78 HIPAA HIPAA Says Covered Entities Must  Ensure the confidentiality, integrity and availability of all protected health information the covered entity creates, receives, maintains or transmits  Protect against any reasonably anticipated threats or hazards to the security or integrity of such information Final Rule, “Administrative Safeguards” – 45 CFR Part

79 HIPAA Security Specifications 1) Security Management Process – “Implement policies and procedures to prevent, detect, contain and correct security violations” Standard: (a)(1)(i) 2) Train workforce – “Implement a security awareness and training program for all members of its workforce (including management)” Standard: (a)(5)(i) Final Rule, “Administrative Safeguards” – 45 CFR Part

80 3) Information Systems Activity Review – “Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports” Standard: (a)(1)(D) 4) Security Incidence Procedures – “Mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity” Standard: (a)(6)(2) Final Rule, “Administrative Safeguards” – 45 CFR Part HIPAA Security Specifications

81 5) Risk Analysis – A covered entity “must conduct an actual and thorough assessment of the potential risks and vulnerabilities of the confidentiality, integrity, and availability of electronic PHI held by the covered entity” Standard (a)(1)(2)(A) 6) Risk Management – A covered entity “must implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level” Standard (a)(1)(ii)(D) HIPAA Security Specifications Final Rule, “Administrative Safeguards” – 45 CFR Part

82 .. And Wh y You Should Do It  Civil Monetary Penalties for Non-Compliance $100/person/violation, up to $25,000 per person per year per violation (Section 1176)  Knowingly Misusing PHI - $50,000, 1 year  Misuse of PHI under False Pretenses - $100,000 and up to 5 years  Misuse of PHI with Intent to Sell - $250,000 and up to 10 years (Section 1777)

83 Because it’s the Law!

84 Who Wants to Help You?

85  They say you should focus on four things: What NC ITS Says You Should Do*NC ITS Based on November 2004 Risk Management policy issued by the State Chief Information OfficerNovember 2004 Risk Management policy * 1) Identification of Risks 2) Analysis of Risks 3) Mitigation Planning 4) Tracking and Controlling Risks

86 NC ITS’s Risk Management ProgramRisk Management Program  Consists of two components: Pre-Risk Assessment, and Risk Assessment (three phases), explained in a Risk Management Guide Phase I – Identify Risks Phase II – Analyze Risks Phase III – Manage RisksRisk Management Guide  Heavily uses the NIST rating scale: Low – Limited adverse effect on agency Moderate – Serious adverse effect High – Severe or catastrophic adverse effect

87 NC ITS’s RM – Pre-Risk Assessment  Review lines of business service that have automated systems that support the business service  Determine if critical infrastructures are involved, or if there are critical infrastructure dependencies  Complete the Pre-Risk Assessment formPre-Risk Assessment form

88 NC ITS’s RM – Phase I  A Facilitator leads a team of people responsible for delivery of a particular line of business through completing the Phase I Questions of the ITS Risk Assessment QuestionnaireITS Risk Assessment Questionnaire  If the final score is “Low”, the risk assessment process ends  If the final score is “Moderate” or “High”, proceed to Phase II for additional analysis

89 NC ITS’s RM – Phase II  A Facilitator leads a team of people knowledgeable in the particular line of business through the Phase II Questions of the ITS Risk Assessment Questionnaire ITS Risk Assessment Questionnaire  If the final score is “Low”, the risk assessment process ends  If the final score is “Moderate” or “High”, proceed to Phase III for mitigation

90 NC ITS’s RM – Phase III  A Facilitator leads appropriate managers and staff through an analysis that focuses on mitigation  The team identifies options to mitigate the risk, analyzes the cost implications, determines the benefits, and balances the cost of implementing each option against the benefits derived from it  The result is completion of the Risk Analysis Results & Mitigation Plans form found in the ITS Risk Assessment Questionnaire ITS Risk Assessment Questionnaire

91 NC ITS’s Risk Management Training  On March 31, 2004, ITS and its vendor partner, Strohl Systems, presented a two hour agency training session (introduced by Ann Garrett) which covered both Business Impact Analysis and Risk Management  Let’s fast forward and view the Risk Management part of the PowerPoint slide show presented therePowerPoint slide show  Let’s try working through an example

92 Pre-Risk Assessment Form  Line of Business – Pharmacy  Business Process Owner – Pharmacy Director  Automated System Supporting – MCPlus  Critical Infrastructure – Linux Server  Critical Dependencies – Vendor

93 Risk Assessment Questionnaire  20 Phase I Questions (Q1 – Q19)  If one or more questions is answered as “Moderate” or “High”, then proceed to Phase II questions  65 Phase II Questions (Q1 – Q25)  If one or more questions (except for Q3) is answered as “Moderate” or “High”, then proceed to Phase III  Let’s try to fill out the Mitigation Plan now

94 Who Wants to Help You?

95 (Based on June 15, 2005 DHHS Risk Management Policy) What DHHS Says You Should DoJune 15, 2005 DHHS Risk Management Policy  Assign responsibility for managing risk to senior management  Provide a mechanism for tracking and reporting risks  Identify system threats in the environment  Identify system vulnerabilities the threats could attack  Identify current security controls  Identify current security gaps

96 DHHS Risk Management Policy, June 15, 2005 More Things DHHS Says to Do DHHS Risk Management Policy, June 15, 2005  Ensure that every risk has at least one owner  Develop the responses or controls necessary to mitigate identified and reported risks  Assess the probability of risks occurring and their potential impact  Identify the risks associated with critical processes in the workflow  Identify security controls currently implemented  Provide an analysis of risks

97 DHHS Risk Management Policy, June 15, 2005 Even More Things DHHS Says to Do DHHS Risk Management Policy, June 15, 2005  Ensure that Risk Management is an intrinsic part of operations  Keep Risk Management policies and procedures current  Perform an analysis to evaluate risk mitigation actions taken, and to determine further steps  Respond to changes in risks, and take corrective action as needed

98 DHHS Information Security Management Policy, June 15, 2005 Even More Things DHHS Says to Do  Implement a systematic, analytical and continuous risk management program for information systems  Ensure that risk identification, analysis and mitigation activities are performed  Ensure that risk assessments are performed periodically to evaluate effectiveness of existing controls  Define strategies and mitigate risks to acceptable levels

99 DHHS Says to Address Risks by:  Risk Reduction – Implement measures to alter the risk position of an asset  Risk Transference – Assign or transfer the potential cost of the loss to another party  Risk Acceptance – Accept the level of loss that will occur and be prepared to absorb the loss

100 Confused Yet? ISO HIPAA NIST DHHS Microsoft What you thought you knew C OBI T

101 Who Provides Us with the Most Help?

102 NIST Says Risk Management has Three Parts  Risk Assessment - Determining where risks lie, and how big they are  Risk Mitigation - Prioritizing, evaluating, and implementing appropriate risk-reducing controls  Evaluation and Assessment – Since Risk Management is continuous and evolving, the past year’s Risk Management efforts should be assessed and evaluated prior to beginning the cycle again

103 Risk Management Process Risk Assessment Risk Mitigation RM Evaluation

104 National Institute of Standards and Technology SP The Ten Steps of Risk Assessment 1) System Characterization 2) Threat Identification 3) Vulnerability Identification 4) Control Analysis 5) Identify Threat-source/Vulnerability Pairs 6) Likelihood Determination 7) Impact Analysis 8) Risk Determination 9) Control Recommendations 10) Results Documentation

105 1) System Characterization  Define the boundaries of the IT system you are addressing, along with the resources and the information that constitute the system, setting the scope of the assessment effort  Methods of gathering system characterization information include the use of questionnaires, interviews, and automatic scanning tools  Output #1: A system characterization paragraph

106 2) Threat Identification  A threat is the potential for a particular threat-source to successfully exercise a particular vulnerability  A threat-source is any circumstance or event with the potential to cause harm to an IT system  A vulnerability is a weakness that can be accidentally triggered or intentionally exploited

107 Two Types of Threat-Sources 1) Intent and method targeted at the intentional exploitation of a vulnerability 2) A situation and method that may accidentally trigger a vulnerability

108 Common Threat-Sources  Natural Threats – Floods, earthquakes, tornadoes, electrical storms, landslides, avalanches, etc.  Human Threats – Events either enabled or caused by human beings, including both unintentional acts (inadvertent data entry) and deliberate actions (unauthorized access)  Environmental Threats – Long-term power failure, pollution, chemicals, liquid leakage

109 Threat-Source Identification  Humans are the most dangerous threat-source  For each type of human threat-source, estimate the motivation, resources, and capabilities that may be required to carry out a successful attack (to be used during the Likelihood Determination phase)  Output #2: A list of threats  Output #3: A chart showing motivation and necessary threat actions for human threats

110 3) Vulnerability Identification  A vulnerability is a flaw or weakness in system security procedures, design, implementation, or controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of an information security policy  Output #4: A list of vulnerabilities that could be exploited by the potential threat-sources

111 Where Vulnerabilities are Found 1) Hardware Configuration – Servers, Workstations, Routers, Switches, Firewalls 2) Software Applications – How installed, Where installed, Rights granted 3) IS Policies and Procedures – How complete, How up-to-date, How well known 4) Humans – Procedures not being followed, Staff not being trained

112 How We Find Vulnerabilities 1) Hardware Configuration – Complete a System Risk Analysis form for each network component, arrange for penetration testing 2) Software Applications – Complete an Application Criticality and Risk Analysis form for each application 3) IS Policies and Procedures – Complete a review of the quality of your Information Security Policies and Procedures every year 4) Humans – Review log files, training records, and incident reports

113 4) Control Analysis  The goal of this step is to analyze the controls that have been implemented to minimize the likelihood of a threat exercising a vulnerability  Output #5: A list of controls currently in use by network hardware components  Output #6: A list of controls currently in use by applications

114 5) Threat-Source/Vulnerability Pairs  Considering the controls in place, what are the Threat-source/Vulnerability pairs which are of most concern?  A vulnerability with no threat-source is not a risk  A threat-source with no vulnerability is not a risk  Output #7: A list of Threat-source and Vulnerability pairs of concern

115 6) Likelihood Determination  A determination of the probability that a potential vulnerability will be exercised  When determining likelihood, consider: 1) Threat-source motivation and capability 2) The nature of the vulnerability 3) The existence and effectiveness of current controls

116 Likelihood Determination Results  Output #8: For each identified vulnerability, a determination of likelihood (H, M, or L) H igh – The threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective M edium – The threat-source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability L ow – The threat-source lacks motivation or capability, or controls are in place to prevent or significantly impede exercising the vulnerability

117 7) Impact Analysis  Determine the adverse impact resulting from a successful threat exercise of each threat- source/vulnerability pair of concern

118 Adverse Impact Comes From:  Loss of Integrity - I mproper modification  Loss of Availability - S ystem cannot be accessed or data cannot be located  Loss of Confidentiality - Information classified as sensitive is disclosed without authorization

119 Impact Analysis Needs  For an Impact Analysis we must know: 1) The organization’s mission 2) The criticality of the data 3) The sensitivity of the data Sensitivity is the sum of the potential injury from a breakdown in confidentiality Criticality is the sum of the potential injury from a breakdown in integrity and/or availability

120 Impacts are High, Medium, or Low  Output #9: For each identified vulnerability, an estimation of the magnitude of probable impact H igh – Exercise of the vulnerability may result in a highly costly loss or may significantly impede an organization’s mission or reputation M edium – Exercise of the vulnerability may result in a costly loss or may harm an organization’s mission or reputation L ow – Exercise of the vulnerability may result in the loss of some assets, or may noticeably affect an organization’s mission or reputation

121 8) Risk Determination  NIST says risk is the net mission impact considering both the likelihood that a particular threat-source will exercise (accidentally trigger or intentionally exploit) a particular information system vulnerability, and the resulting impact on the organization if this should occur  Likelihood x Impact = Risk

122 Use a Risk-Level Matrix Threat Likelihood Impact Low (10) Medium (50) High (100) High (1.0)Low 10 x 1.0 = 10 Medium 50 x 1.0 = 50 High 100 x 1.0 = 100 Medium (0.5)Low 10 x 0.5 = 5 Medium 50 X 0.5 = 25 Medium 100 x 0.5 = 50 Low (0.1)Low 10 x 0.1 = 1 Low 50 x 0.1 = 5 Low 100 x 0.1 = 10 Risk Scale: High (>50 to 100); Medium (>10 to 50); Low (1 to 10)

123 Risk Scale and Necessary Actions Risk LevelRisk Description and Necessary Actions High There is a strong need for corrective measures, the system may continue to operate, but a corrective action plan should be put in place as soon as possible Medium Corrective actions are needed, and a plan incorporating these actions should be developed in a reasonable period of time Low Additional controls may be implemented, or management may decide to accept this risk

124 Assessing the Risk Level  Final determination of mission risk is derived by multiplying the threat likelihood and the threat impact scores  Output #10: A numeric risk score for each identified vulnerability/threat-source pair  The Vulnerability Analysis form can be used to capture this information

125 9) Control Recommendations  Finish your risk assessment by thinking of controls which could help minimize the risk of the vulnerability/threat-source combinations you are most concerned about  To determine which controls are appropriate to add, perform a cost-benefit analysis  Output #11: Recommendation of additional controls based on risk assessment

126 10) Results Documentation  The Risk Assessment report should be of sufficient detail to allow the organization’s management to make informed decision on appropriate actions in response to the risks identified  Unlike an audit or investigative report that looks for “wrong-doing”, the Risk Assessment report should be not be presented in an accusatory manner

127 Risk Assessment Report  Your Risk Assessment report should have: A) An Introduction B) A description of your Risk Assessment approach C) A system characterization summary D) A list of Threat-Sources E) Vulnerability/Threat-Source analysis results F) A summary of risk levels and recommendations  Output #12: Risk Assessment Report that measures risk and provides recommendations

128 Report - Introduction  Purpose  Scope  Describe * System Controls * Elements * Users * Site Locations * Other Details as necessary

129 Report – Risk Assessment Approach  Describe Approach Used Risk Assessment Team members Techniques used to gather information (use of tools, questionnaires, etc.) Development and description of risk scale (3x3, 4x4, or 5x5 risk level matrix)

130 Report – System Characterization  Describe the system - Hardware (server, router, switch) - Software (application, operating system) - System Interfaces (communication link) - Data - Users  Provide connectivity diagram or system input and output flowchart

131 Report - Threat Statement  Compile potential threat sources  List associated threat actions  Review Human Motivations

132 Report – Risk Assessment Results  List observations (vulnerability/threat pairs)  Observations contain - Observation number and brief description - Discussion of threat-source and vulnerability - Identification of existing security controls - Likelihood discussion and evaluation - Risk rating - Recommended controls or alternative options

133 Report - Summary  Total number of threat-source/vulnerabilities pairs identified (“observations”)  Summarize - Observations - Associated risk levels - Recommendations - Any comments  Organize into a table to facilitate implementation

134 The Ten Steps of Risk Assessment 1) System Characterization 2) Threat Identification 3) Vulnerability Identification 4) Control Analysis 5) Identify Threat-source/Vulnerability Pairs 6) Likelihood Determination 7) Impact Analysis 8) Risk Determination 9) Control Recommendations 10) Results Documentation

135 Reviewing NIST’s RA Output 1) System Characterization 2) List of Threats 3) Human Motivation Review 4) List of Vulnerabilities 5) Review Network Hardware Controls 6) Review Application Controls 7) List Threat-Source and Vulnerability pairs 8) Likelihood determination for each pair of concern 9) Estimation of probable impact 10) Identify risk scores 11) Recommendations, if any, for additional controls 12) Risk Assessment Report

136 Risk Management Process Risk Assessment Risk Mitigation

137  Risk Mitigation is the process of identifying areas of risk that are unacceptable; and estimating countermeasures, costs and resources to be implemented as a measure to reduce the level of risk  Determining “appropriate risk-reducing controls” is a job for your Risk Management Committee

138 What is “Acceptable” Risk?  Setting your agency’s “risk appetite” is up to your Director and Senior Management  Because elimination of all risk is impossible, we must use the least-cost approach and implement the most appropriate controls to decrease mission risk to an acceptable level, with minimal adverse impact on the organization’s resources and mission

139 Risk Mitigation Options  Assume the Risk – Accept the risk and continue operating (how big is your appetite?)  Avoid the Risk – Stop running the program or sharing the data  Transfer the Risk – Use options to compensate for the loss, such as insurance  Lessen the Risk – Implement controls that lessen the impact or lower the likelihood

140 Risk Mitigation Methodology 1) Prioritize based on risk levels presented 2) Evaluate recommended control options 3) Conduct a cost-benefit analysis 4) Select additional controls, as necessary 5) Assign responsibility 6) Develop an action plan, if necessary 7) Implement the selected controls

141 Possible Technical Controls  User Identification  Security Administration  Authentication  Authorization  Nonrepudiation  Transaction Privacy  Restore Secure State  Virus Detection and Eradication

142 Possible Management Controls  Assign Security Responsibility  Conduct Security Awareness Training  Conduct end-user training for system users  Implement personnel clearance procedures  Perform periodic system audits  Conduct ongoing risk management activities  Establish incident response capability

143 Possible Operational Controls  Control physical access  Secure hub and cable wiring closets  Establish off-site storage procedures  Provide an uninterruptible power supply  Control temperature and humidity  Provide motion sensors or CCTV monitoring  Ensure environmental security

144 Cost-Benefit Analysis  If control reduces risk more than needed, see if a less expensive alternative exists  If control would cost more than the risk reduction provided, then find something else  If control does not reduce risk sufficiently, look for more controls or a different control  If control provides enough risk reduction and is cost-effective, then use it

145 When Should Management Take Action?

146 Residual Risk  The risk remaining after the implementation of new or enhanced controls is the residual risk  If the residual risk has not been reduced to an acceptable level, the risk management cycle must be repeated to identify a way of lowering the residual risk to an acceptable level  Understand that no IT system can be risk-free

147 Risk Management Process Risk Assessment Risk Mitigation RM Evaluation

148 Evaluation and Assessment  People, systems, and networks change, so risk management must be ongoing  Federal agencies must conduct risk management at least every three years  Stay flexible to allow changes when warranted

149 NIST Says Good Risk Management Depends Upon 1) Senior management’s commitment 2) Support of the IT Team 3) Competence of the Risk Management Committee 4) The cooperation of the users 5) Ongoing assessment of IT-related mission risks

150 Risk Management Examples Scenario #1 - The Grounds of My Home

151 #1) The Grounds of My Home 1) System Characterization - the land my home sits on (risk owned by my wife) 2) Threat Identification – Environmental? From people? From Nature? 3) Vulnerability Identification – Looking for weaknesses which could be exercised by a threat-source; use eyes and knowledge 4) Control Analysis – City Services, fire hydrant, Home Owner’s insurance, car insurance

152 The Grounds of My Home – Continued 5) Identify Threat-Source/Vulnerability Pairs – Dead limb or whole tree could fall on my car 6) Likelihood Determination – Has happened before; lots of storms; high likelihood 7) Impact Analysis – Dents, broken glass, car not drivable, repair cost – medium impact 8) Risk Determination – High (1.0) Likelihood x Medium (50) Impact = Medium (50) Risk

153 9) Control Recommendation Options: o Have wife pull the limb down o Hire a tree surgeon to take off the limb o Take the tree down o Don’t park there o Park my wife’s company car there o Buy a bicycle o Lower amount of deductible The Grounds of My Home – Continued

154 Completing Mitigation..  Assign Responsibility Taking down the limb - My wife (stronger) Parking differently - Me (get home first)  Develop an Action Plan (if necessary) This weekend o Lessen the likelihood by removing the limb o Transfer some risk to my wife’s company o Accept the residual risk

155

156 Risk Management Examples Scenario #2 - The Agency File Servers

157 #2) The File Servers 1) System Characterization - the File Servers in our Server Closet 2) Threat Identification – Environmental? From people? From Nature? 3) Vulnerability Identification – Looking for weaknesses which could be exercised by a threat-source; use eyes and knowledge 4) Control Analysis – Firewall, Locks, Daily Observation, Separate Circuit, UPSs

158 The File Servers – Continued 5) Identify Threat-Source/Vulnerability Pairs – Big Oak could fall on flat roof, break it 6) Likelihood Determination – Tree appears strong, but lots of storms; low likelihood 7) Impact Analysis – Damage from impact, water damage, repair cost – high impact 8) Risk Determination – Low (0.1) Likelihood x High (100) Impact = Low (10) Risk

159 9) Control Recommendation Options: o Have the tree removed o Weaken the tree on the other side to affect fall o Relocate the File Servers o Reinforce the roof o Buy a tarp and rig it over the servers o Buy a tarp and keep it handy The File Servers – Continued

160 Completing Mitigation..  Assign Responsibility LAN Manager - Buying a tarp at Wal-Mart for $9  Develop an Action Plan (if necessary) Do it tomorrow o Lessen the impact by preparing for the event (even though it is unlikely) o Accept the residual risk

161

162 Risk Management Examples Scenario #3 - An Agency Application

163 #3) An Agency Application 1) System Characterization - Local Access- based system with PHI sent over the internet 2) Threat Identification – From people? From telecommunication? 3) Vulnerability Identification – Availability and Integrity risks are low, but Confidentiality risk is high; also, data is sent elsewhere 4) Control Analysis – Logical and Physical Access controls, Security Awareness Program, Staff Sensitivity Designations

164 An Application – Continued 5) Identify Threat-Source/Vulnerability Pairs – We are sharing PHI with no Business Associate agreement in place 6) Likelihood Determination – Sent to another CE, but no BA in place; low likelihood 7) Impact Analysis – PHI becoming exposed could hurt image badly – high impact 8) Risk Determination – Low (0.1) Likelihood x High (100) Impact = Low (10) Risk

165 Control Recommendation Options:  Make sure the receiver of the PHI understands their BA responsibilities  Offer training to the Business Associate  Request written documentation for the program  Establish a written Memorandum of Understanding between the agencies An Application – Continued

166 Completing Mitigation..  Assign Responsibility Security Official will contact other Security Official Security Official will develop and offer training show Data Owner will request software documentation  Develop an Action Plan (if necessary) o Lessen the likelihood establishing a HIPAA compliant Business Associate relationship o Accept the residual risk

167

168 So Let’s Go!  All Set? - We know where we want to go, and we have a map, so we’re ready, right?  Hold On – How long is this trip, and how old are we now?  Let’s estimate our organization’s risk management maturity, and our readiness

169 What is your Security Risk Management Maturity Level? Based on ISO Which of these 6 levels best describes your organization?

170 Risk Management Maturity Levels LevelStateDefinition 0 Non- Existent Policy is not documented, and previously the organization was unaware of the business risk associated with this risk management; therefore there has been no communication on the issue. 1 Ad-HocSome members of the organization have concluded that risk management has value, however, risk management efforts are performed in an ad-hoc manner. There are no documented processes or policies, and the process is not fully repeatable.

171 Risk Management Maturity Levels LevelStateDefinition 2 RepeatableThere is awareness of risk management throughout the organization. The process is repeatable, but immature, and not fully documented. Implementation is left to individual employees. 3 Defined Process The organization has made a formal decision to adopt risk management wholeheartedly in order to drive its information security program. There are clearly defined goals, and some risk management training is available for all staff.

172 Risk Management Maturity Levels LevelStateDefinition 4 ManagedThere is a thorough understanding of risk management at all levels of the organization. The process is well-defined, broadly communicated, and training is available. Some initial forms of measurement are in place 5 OptimizedThe organization has committed significant resources to risk management. The process is well-understood and somewhat automated. Training across a range of levels of expertise is available to staff.

173 What is your Security Risk Management Readiness Level? Based on Microsoft’s Security Risk Management Guide – Chapter 3Microsoft’s Security Risk Management Guide – Chapter 3 The following test measures your organization’s readiness level For each of these 17 questions, score your organization on a scale of zero to five, using the previous maturity level definitions as a guide maturity level definitions

174 Risk Management Readiness Test 1) Information security policies and procedures are clear, concise, well-documented, and complete 2) All staff positions with job responsibilities involving information security have clearly articulated and well understood roles and responsibilities 3) Policies and procedures for securing third-party access to business data are well-documented. For example, remote vendors performing application development for an internal business tool have sufficient access to network resources to effectively collaborate and complete their work, but they have only the minimum amount of access that they need From Microsoft’s Security Risk Management Guide, Chapter 3Microsoft’s Security Risk Management Guide, Chapter 3

175 Risk Management Readiness Test 4) An inventory of Information Technology (IT) assets such as hardware, software, and data repositories is accurate and up-to-date 5) Suitable controls are in place to protect business data from unauthorized access by both outsiders and insiders 6) Effective user awareness programs such as training and newsletters regarding information security policies and practices are in place 7) Physical access to the computer network and other information technology assets is restricted through the use of effective controls From Microsoft’s Security Risk Management Guide, Chapter 3Microsoft’s Security Risk Management Guide, Chapter 3

176 Risk Management Readiness Test 8) New computer systems are provisioned following organizational security standards in a standardized manner using automated tools such as disk imaging or build scripts 9) An effective patch management system is able to automatically deliver software updates from most vendors to the vast majority of the computer systems in the organization 10) Effective user awareness programs such as training and newsletters regarding information security policies and practices are in place From Microsoft’s Security Risk Management Guide, Chapter 3Microsoft’s Security Risk Management Guide, Chapter 3

177 11) The organization has a comprehensive anti-virus program including multiple layers of defense, user awareness training, and effective processes for responding to virus outbreaks 12) User provisioning processes are well documented and at least partially automated so that new employees, vendors, and partners can be granted an appropriate level of access to the organization's information systems in a timely manner. These processes should also support the timely disabling and deletion of user accounts that are no longer needed Risk Management Readiness Test From Microsoft’s Security Risk Management Guide, Chapter 3Microsoft’s Security Risk Management Guide, Chapter 3

178 Risk Management Readiness Test 13) Computer and network access is controlled through user authentication and authorization, restrictive access control lists on data, and proactive monitoring for policy violations 14) Application developers are provided with education and possess a clear awareness of security standards for software creation and quality assurance testing of code 15) Business continuity and business continuity programs are clearly defined, well documented, and periodically tested through simulations and drills From Microsoft’s Security Risk Management Guide, Chapter 3Microsoft’s Security Risk Management Guide, Chapter 3

179 Risk Management Readiness Test 16) Programs have commenced and are effective for ensuring that all staff perform their work tasks in a manner compliant with legal requirements 17) Third-party review and audits are used regularly to verify compliance with standard practices for security business assets From Microsoft’s Security Risk Management Guide, Chapter 3Microsoft’s Security Risk Management Guide, Chapter 3

180 Add all 17 scores together < 34Consider starting slowly by creating a Risk Management team and applying the process to a single business unit of your organization 34 to 50 Your organization has taken many significant steps, and is ready to move forward and expose the entire organization to the process > 50Your organization is well-prepared to begin to use security risk management to its fullest extent

181 Are You Ahead or Behind? According to the Gartner Group, using a population of G2000 type companies

182 So Let’s Go!  All Set? - We know where we want to go, and we have a map  We know how mature we are, and have an idea about the readiness of our organization to begin risk management Can we kill any other birds with the same stones?

183 Related DHHS Policies  “System owners are responsible for determining the sensitivity of data and ensuring that adequate controls are implemented to protect the data.” DHHS Information Systems Review and Auditing Policy  “Tests that shall be included in overall security testing strategy for each Division/Offices shall include Vulnerability Scanning and Penetration Testing.” DHHS Security Testing Policy

184 Related DHHS Policies  “The BC/DR planning team shall do the following: Identify the types of disasters most likely to occur and the resultant impacts on the agency’s ability to perform its mission.” DHHS Business Continuity and Disaster Recovery Policy  “The BC/DR planning team shall do the following: Propose protective measures to be implemented in anticipation of a natural or man-made disaster.” DHHS Business Continuity and Disaster Recovery Policy

185 Related DHHS Policies  “Plans shall include: A risk assessment to determine risk priorities and probability of identified risk.” DHHS Business Continuity and Disaster Recovery Policy  “Plans shall include: Development of recovery/restoration procedures for time critical systems and applications.” DHHS Business Continuity and Disaster Recovery Policy

186 Related DHHS Policies  For each application, classify the risk from loss of confidentiality as “low”, “medium”, or “high  For each application, classify the risk from loss of integrity as “low”, “medium” or “high”  For each application, classify the availability need level as 1 (2 to 4 days), 2 (5 to 9 days), 3 (10 to 19 days) or 4 DHHS Data Classification, Labeling and Access Control Policy

187 Related DHHS Policies  “System Administrators have the responsibility of periodically reviewing user access privileges and notifying management of any access concerns.”  “The system owner of each information system shall ensure that all user accounts are reviewed and access rights evaluated at least once per quarter.” DHHS User Authorization, Identification and Authentication Policy

188 More Related DHHS Policies  “DHHS Divisions/Offices shall protect data on all sensitive and critical applications/systems by implementing controls that are commensurate with the security level required to protect the data”  “If sensitive electronic data resides in a DHHS Division/Office, administrative, physical and technical security controls must be implemented to limit unauthorized access to the data” DHHS Data Protection Policy

189 More Related DHHS Policies  “All technology shall be evaluated to ensure that it can provide the level of security required.”  “Security risk in the operations environment shall be kept to a level that is considered “acceptable risk” DHHS IT Operations Security Policy

190 Related HIPAA Requirements  Application and Data Criticality Analysis – Assess the relative criticality of specific applications and data in support of other contingency plan components HIPAA Section (a)(7)(ii)(E)  Emergency Mode Operation Plan – Establish procedures to enable continuation of critical business processes for protection of the security of electronic PHI while operating in emergency mode HIPAA Section (a)(7)(ii)(C)

191  Risk Analysis – A covered entity “must conduct an actual and thorough assessment of the potential risks and vulnerabilities of the confidentiality, integrity, and availability of electronic PHI held by the covered entity” Standard (a)(1)(2)(A)  Risk Management – A covered entity “must implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level” Standard (a)(1)(ii)(D) HIPAA Security Specifications Final Rule, “Administrative Safeguards” – 45 CFR Part

192

193 12 Steps Towards YOUR Program 1) Educate Management 2) Locate all assets 3) Assign all risk 4) Complete Network Risk Analysis forms 5) Complete Application Risk Analysis forms 6) Penetration and Vulnerability Testing 7) Update Threats list 8) Review IS P&P 9) Complete Vulnerability Analysis forms 10) RM Committee meets and decides on additional controls 11) Report sent to Director 12) RM mid-year meeting

194 1) Educate Management  Risk Management is one of a half dozen Information Security projects which Management must be educated about  Consider an Information Security Training for Management presentationInformation Security Training for Management  Risk Management MUST be driven by management if it is to be successful  Don’t neglect training for “middle” managers, including application owners and supervisorsapplication owners supervisors

195 2) Locate All Assets  Hardware and Data - Start listing what you know about, then find the rest  Do searches on the network for file types  Find out who has been storing data on local hard drives (and stop it)  List applications, including which have PHI  Determine where Word, Excel, and Access files with PHI are kept

196 3) Assign all Risk  All applications have Data Owners  If you created a file (not part of an application program), then you own it  If you own a file, you are responsible for protecting it  All network components – wiring, router, switches, servers, concentrators – have a person assigned to them who owns the risk

197 4) Network Risk Analysis FormsNetwork Risk Analysis  Complete one form for each type of component 1) Windows XP Workstations 2) Windows 2000 workstations 3) Windows 98 workstations 4) File Servers 5) Firewall 6) Router 7) Core Switch 8) Workgroup Switches 9) Wireless Segment, etc. For Network Risk Analysis form instructions, click HEREHERE

198 5) Application Risk Analysis FormsApplication Risk Analysis  Complete one form for each application 1) HEARTS 2) MCPlus Pharmacy 3) NC Accounting 4) Personal Planning System 5) NCSnap 6) Restraint Tracking 7) Staff Development Records 8) Staff Vacancies, etc. For Application Risk Analysis form instructions, click HEREHERE

199 6) Penetration and Vulnerability Tests  DIRM may be willing to provide penetration and vulnerability testing  You may have to hire a firm to provide these services  Testing should be done from both inside your firewall, and from outside your firewall  If necessary, hire a teenager

200 7) Update Threats ListThreats List  Consider Natural Threats, Human Threats, and Environmental Threats  For Human Threats, consider sources of motivationsources of motivation  Your Threats List will not be identical to others, since local factors must be considered  Provide this updated list to your Risk Management Committee each year

201 8) Review IS Policies and Procedures  Many risks are inherent in the absence of information security policies and procedures  Procedures must evolve as new policies develop and old policies change  Your IS Policy and Procedure review should be done by someone other than the agency’s Information Security Official  The results of this review are presented at the Risk Management Team meeting

202 9) Vulnerability Analysis FormsVulnerability Analysis  Complete one form for each vulnerability/ threat-pair combination 1) HEARTS PHI being disclosed to or by the Client Data Warehouse 2) Workgroup switch located in unlocked wiring closet 3) Loss of application availability due to file server running out of disk space For Vulnerability Analysis form instructions, click HEREHERE

203 10) Risk Management Team Meets  RM Committee should be made up of senior managers, such as the Assistant Director and Business Manager, and at least one information system owner  Team reviews all input, and makes decisions as to what additional cost-effective controls should be implemented  Educating this team is an important part of improving your risk management process  It is the Team’s experience that sets priorities

204 11) Send RM Report to the Director  The Risk Management Report should clearly list the vulnerability/threat-source pairings of concern, and any additional controls which are recommended  The report should ideally include a cover letter to the Director, signed by each member of the Committee

205 12) The Committee’s Mid-Year Meeting  The Risk Management Committee should meet at least twice each year  The mid-year meeting should be concerned about evaluating the results of the recommendations which emerged from the year’s first meeting, where mitigation measures were discussed and decided upon  Minutes of your Risk Management Committee meetings should be saved for 6 years

206 12 Steps Towards YOUR Program 1) Educate Management 2) Locate all assets 3) Assign all risk 4) Complete Network Risk Analysis forms 5) Complete Application Risk Analysis forms 6) Penetration and Vulnerability Testing 7) Update Threats list 8) Review IS P&P 9) Complete Vulnerability Analysis forms 10) RM Committee meets and decides on additional controls 11) Report sent to Director 12) RM mid-year meeting

207 Risk Management Process Timeline Implement Additional Controls Risk Mitigation Meeting Risk Management Mid-Year Meeting Report Sent to Director Penetration Testing Network Risk Forms Application Risk Forms Update Threat List Vulnerability Forms

208 What We Covered Today..  What Risk Management means  What NIST says you should do  What ISO says you should do  What C OBI T says you should do  What Microsoft says you should do  What HIPAA says you should do  What NC ITS says you should do  What DHHS says you should do  Developing YOUR program in 12 steps

209 Links Found in this Slide Show NIST NIST SP NIST SP NIST SP NIST SP ISO Microsoft’s Security Risk Management Guide COBIT DHHS’s Risk Management ITS’s November 2005 Risk Management Policy Maturity Level Definitions HIPAA Security Rule ITS Risk Management Site ITS Risk Management Guide ITS Pre-Risk Assessment Form ITS RA Questionnaire Threats List Human Motivations List Network Risk Analysis Form Instructions for above form Application Criticality and Risk Analysis Form Instructions for above form Vulnerability Analysis Form Instructions for above form Training for Management Show Training for Supervisors Show Training for Application Owners Training for Users Show

210 Any Questions?

211 Developing an Information Technology Risk Management Program

212


Download ppt "Developing an Information Technology Risk Management Program Training for DHHS Information Security Officials and Backup Security Officials."

Similar presentations


Ads by Google