Presentation is loading. Please wait.

Presentation is loading. Please wait.

Developing an Information Technology Risk Management Program

Similar presentations


Presentation on theme: "Developing an Information Technology Risk Management Program"— Presentation transcript:

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

2 What this training covers . .
What Risk Management means What NIST says you should do What ISO says you should do What COBIT 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

3 Risk “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

4 the protection of data against unauthorized access or modification
Information Security is the protection of data against unauthorized access or modification

5 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)

6 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

7 Risk Management is the Keystone of Information Security

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

9 Why are we doing this? A car has brakes so it can go fast
Why do we do risk management? Why does a car have brakes? A car has brakes so it can go fast We do risk management so we can take risks An organization that can take advantage of opportunities (and the inherent risks) will outlast an organization which cannot

10 Reactive Risk Management
Protect human life and people’s safety Contain the damage Assess the damage Determine the cause of the damage Repair the damage Review response, and update policies

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

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

13 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

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

15 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

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

17 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

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

19 Vulnerabilities Protected by What Security Controls?
Physical Technical Administrative 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

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

21 Two Approaches to Risk Assessment
1) Quantitative 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

22 Two Approaches to Risk Assessment
2) Qualitative 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

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

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

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

26 Know what to do now?

27 Who Wants to Help You?

28 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

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

30 NIST Says It’s a Management Function
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

31 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

32 Risk Management Process
What is my risk? What will I do about it? How did I do? Risk Assessment Risk Mitigation RM Evaluation

33 System Characterization Threat Identification
National Institute of Standards and Technology SP The Ten Steps of Risk Assessment System Characterization Threat Identification Vulnerability Identification Control Analysis Identify Threat-source/Vulnerability Pairs Likelihood Determination Impact Analysis Risk Determination Control Recommendations Results Documentation

34 Risk Management Process
What is my risk? What will I do about it? Risk Assessment Risk Mitigation

35 Risk Mitigation 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

36 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

37 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

38 Risk Mitigation Methodology
Prioritize based on risk levels presented Evaluate recommended control options Conduct a cost-benefit analysis Select additional controls, as necessary Assign responsibility Develop an action plan, if necessary Implement the selected controls

39 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

40 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

41 Risk Management Process
What is my risk? What will I do about it? How did I do? Risk Assessment Risk Mitigation RM Evaluation

42 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

43 NIST Says Good Risk Management Depends Upon
Senior management’s commitment Support of the IT Team Competence of the Risk Management Committee Cooperation and education of the users Ongoing assessment of IT-related mission risks

44 Who Wants to Help You?

45 ISO - 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

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

47 ISO 17799 – 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

48 ISO 17799 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

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

50 ISO Deliverables

51 ISO 17799’s Information Security Management Process
Obtain Upper Management Support Define Security Perimeter Create Information Security Policy Create Info Security Management System Perform Risk Assessment Select and Implement Controls Document in Statement of Accountability Audit

52 ISO 17799 Risk Assessment Steps
Identify assets within the security perimeter Identify threats to the assets Identify vulnerabilities to the assets Determine realistic probability

53 ISO’s Probability of Event Scale
Frequency Rating Negligible Unlikely to Occur Very Low 2 to 3 times every 5 years 1 Low Less than or equal to once per year 2 Medium Once every 6 months or less 3 High Once every month or less 4 Very High More than once every month 5 Extreme Once per day or more 6

54 ISO 17799 Risk Assessment Steps
Identify assets within the security perimeter Identify threats to the assets Identify vulnerabilities to the assets Determine realistic probability Calculate harm

55 ISO’s Harm of Event Scale
Degree of Harm Rating Insignificant Minimal to no impact Minor No extra effort required to repair 1 Significant Tangible harm, extra effort required to repair 2 Damaging Significant expenditure of resources required; Damage to reputation and confidence 3 Serious Extended outage and/or loss of connectivity; Compromise of large amounts of data or services 4 Grave Permanent Shutdown; Complete compromise 5

56 ISO 17799 Risk Assessment Steps
Identify assets within the security perimeter Identify threats to the assets Identify vulnerabilities to the assets Determine realistic probability Calculate harm Calculate risk (probability x harm)

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

58 ISO 17799’s Information Security Management Process
Obtain Upper Management Support Define Security Perimeter Create Information Security Policy Create Info Security Management System Perform Risk Assessment Select and Implement Controls Document in Statement of Accountability Audit

59 Who Wants to Help You?

60 COBIT – 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

61 What COBIT Says You Should Do
COBIT looks at information that is needed to support business requirements and the associated IT resources and processes COBIT 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

62 High Level Objectives COBIT – Planning and Organization
Define a Strategic IT Plan P02 Define the Information Architecture P03 Determine Technological Direction P04 Define the IT Organization and Relationships P05 Manage the IT Investment P06 Communicate Management Aims and Direction P07 Manage Human Resources P08 Ensure Compliance with External Requirements P09 Assess Risks P10 Manage Projects P11 Manage Quality

63 High Level Objectives COBIT – Acquisition & Implementation
AI1 Identify Automated Solutions AI2 Acquire and Maintain Application Software AI3 Acquire and Maintain Technology Infrastructure AI4 Develop and Maintain Procedures AI5 Install and Accredit Systems AI6 Manage Changes

64 High Level Objectives COBIT – Delivery and Support
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

65 High Level Objectives COBIT – Monitor
Monitor the Processes M2 Assess Internal Control Adequacy M3 Obtain Independent Assurances M4 Provide for Independent Audit

66 Who Wants to Help You?

67 Microsoft 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

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

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

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

71 Microsoft Says . . Conducting Decision Support Phase
Determine functional requirements Identify combinations of controls (Organizational, Operational, Technological) Compare proposed controls to functional requirements Calculate the probable overall risk reduction to the organization Estimate the cost of teach proposed control Select which controls to implement

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

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

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

75 Who Wants to Help You?

76 The Health Insurance Portability and Accountability Act of 1996
Dance with HIPAA or Get Smushed!

77 HIPAA Says Covered Entities Must
Final Rule, “Administrative Safeguards” – 45 CFR Part 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

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

79 HIPAA Security Specifications
Final Rule, “Administrative Safeguards” – 45 CFR Part HIPAA Security Specifications 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) Security Incidence Procedures – “Mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity” Standard: (a)(6)(2)

80 HIPAA Security Specifications
Final Rule, “Administrative Safeguards” – 45 CFR Part HIPAA Security Specifications 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)

81 . . And Why 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)

82 Because it’s the Law!

83 Who Wants to Help You?

84 What NC ITS Says You Should Do*
They say you should focus on four things: Identification of Risks Analysis of Risks Mitigation Planning Tracking and Controlling Risks * Based on November 2004 Risk Management policy issued by the State Chief Information Officer

85 NC ITS’s Risk 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 Risks Heavily uses the NIST rating scale: Low – Limited adverse effect on agency Moderate – Serious adverse effect High – Severe or catastrophic adverse effect

86 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 form

87 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 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

88 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 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

89 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

90 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 there Let’s try working through an example

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

92 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

93 Who Wants to Help You?

94 (Based on June 15, 2005 DHHS Risk Management Policy) What DHHS Says You Should Do
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

95 DHHS Risk Management Policy, June 15, 2005 More Things DHHS Says to Do
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

96 DHHS Risk Management Policy, June 15, 2005 Even More Things DHHS Says to Do
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

97 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

98 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

99 What you thought you knew
Confused Yet? ISO 17799 HIPAA DHHS NIST What you thought you knew Microsoft COBIT

100 Who Provides Us with the Most Help?

101 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

102 Risk Management Process
What is my risk? What will I do about it? How did I do? Risk Assessment Risk Mitigation RM Evaluation

103 System Characterization Threat Identification
National Institute of Standards and Technology SP The Ten Steps of Risk Assessment System Characterization Threat Identification Vulnerability Identification Control Analysis Identify Threat-source/Vulnerability Pairs Likelihood Determination Impact Analysis Risk Determination Control Recommendations Results Documentation White Lie

104 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

105 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

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

107 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

108 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

109 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

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

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

112 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

113 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

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

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

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

117 Adverse Impact Comes From:
Loss of Integrity - Improper modification Loss of Availability - System cannot be accessed or data cannot be located Loss of Confidentiality - Information classified as sensitive is disclosed without authorization

118 Impact Analysis Needs For an Impact Analysis we must know:
The organization’s mission The criticality of the data 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

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

120 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

121 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)

122 Risk Scale and Necessary Actions
Risk Level Risk 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

123 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

124 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

125 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

126 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

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

128 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)

129 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

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

131 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

132 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

133 The Ten Steps of Risk Assessment
System Characterization Threat Identification Vulnerability Identification Control Analysis Identify Threat-source/Vulnerability Pairs Likelihood Determination Impact Analysis Risk Determination Control Recommendations Results Documentation

134 Reviewing NIST’s RA Output
System Characterization List of Threats Human Motivation Review List of Vulnerabilities Review Network Hardware Controls Review Application Controls List Threat-Source and Vulnerability pairs Likelihood determination for each pair of concern Estimation of probable impact Identify risk scores Recommendations, if any, for additional controls Risk Assessment Report

135 Risk Management Process
What is my risk? What will I do about it? Risk Assessment Risk Mitigation

136 Risk Mitigation 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

137 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

138 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

139 Risk Mitigation Methodology
Prioritize based on risk levels presented Evaluate recommended control options Conduct a cost-benefit analysis Select additional controls, as necessary Assign responsibility Develop an action plan, if necessary Implement the selected controls

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

141 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

142 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

143 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

144 When Should Management Take Action?

145 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

146 Risk Management Process
What is my risk? What will I do about it? How did I do? Risk Assessment Risk Mitigation RM Evaluation

147 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

148 NIST Says Good Risk Management Depends Upon
Senior management’s commitment Support of the IT Team Competence of the Risk Management Committee The cooperation of the users Ongoing assessment of IT-related mission risks

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

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

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

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

153 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 Lessen the likelihood by removing the limb Transfer some risk to my wife’s company Accept the residual risk

154

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

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

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

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

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

160

161 Risk Management Examples
Scenario #3 - An Agency Application

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

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

164 An Application – Continued
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

165 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) Lessen the likelihood establishing a HIPAA compliant Business Associate relationship Accept the residual risk

166

167 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

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

169 Risk Management Maturity Levels
State Definition 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-Hoc Some 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.

170 Risk Management Maturity Levels
State Definition 2 Repeatable There 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.

171 Risk Management Maturity Levels
State Definition 4 Managed There 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 Optimized The 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.

172 What is your Security Risk Management Readiness Level?
Based on Microsoft’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

173 Risk Management Readiness Test
From Microsoft’s Security Risk Management Guide, Chapter 3 Risk Management Readiness Test Information security policies and procedures are clear, concise, well-documented, and complete All staff positions with job responsibilities involving information security have clearly articulated and well understood roles and responsibilities 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

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

175 Risk Management Readiness Test
From Microsoft’s Security Risk Management Guide, Chapter 3 Risk Management Readiness Test New computer systems are provisioned following organizational security standards in a standardized manner using automated tools such as disk imaging or build scripts 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 Effective user awareness programs such as training and newsletters regarding information security policies and practices are in place

176 Risk Management Readiness Test
From Microsoft’s Security Risk Management Guide, Chapter 3 Risk Management Readiness Test The organization has a comprehensive anti-virus program including multiple layers of defense, user awareness training, and effective processes for responding to virus outbreaks 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

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

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

179 Add all 17 scores together
< 34 Consider 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 > 50 Your organization is well-prepared to begin to use security risk management to its fullest extent

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

181 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 Hold On! Can we kill any other birds with the same stones?

182 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

183 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

184 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

185 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

186 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

187 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

188 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

189 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)

190 HIPAA Security Specifications
Final Rule, “Administrative Safeguards” – 45 CFR Part HIPAA Security Specifications 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)

191 Ready? Set?

192 12 Steps Towards YOUR Program
Educate Management Locate all assets Assign all risk Complete Network Risk Analysis forms Complete Application Risk Analysis forms Penetration and Vulnerability Testing Update Threats list Review IS P&P Complete Vulnerability Analysis forms RM Committee meets and decides on additional controls Report sent to Director RM mid-year meeting

193 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 presentation Risk Management MUST be driven by management if it is to be successful Don’t neglect training for “middle” managers, including application owners and supervisors

194 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

195 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

196 4) Network Risk Analysis Forms
For Network Risk Analysis form instructions, click HERE Complete one form for each type of component Windows XP Workstations Windows 2000 workstations Windows 98 workstations File Servers Firewall Router Core Switch Workgroup Switches Wireless Segment, etc.

197 5) Application Risk Analysis Forms
For Application Risk Analysis form instructions, click HERE Complete one form for each application HEARTS MCPlus Pharmacy NC Accounting Personal Planning System NCSnap Restraint Tracking Staff Development Records Staff Vacancies, etc.

198 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

199 7) Update Threats List Consider Natural Threats, Human Threats, and Environmental Threats For Human Threats, consider sources 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

200 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

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

202 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

203 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

204 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

205 12 Steps Towards YOUR Program
Educate Management Locate all assets Assign all risk Complete Network Risk Analysis forms Complete Application Risk Analysis forms Penetration and Vulnerability Testing Update Threats list Review IS P&P Complete Vulnerability Analysis forms RM Committee meets and decides on additional controls Report sent to Director RM mid-year meeting

206 Risk Management Process Timeline
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Risk Mitigation Meeting Report Sent to Director Implement Additional Controls Risk Management Mid-Year Meeting Penetration Testing Network Risk Forms Application Risk Forms Update Threat List Vulnerability Forms

207 What We Covered Today . . What Risk Management means
What NIST says you should do What ISO says you should do What COBIT 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

208 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 Vulnerability Analysis Form Training for Management Show Training for Supervisors Show Training for Application Owners Training for Users Show

209 Any Questions?

210 Developing an Information Technology Risk Management Program

211 Developing an Information Technology Risk Management Program


Download ppt "Developing an Information Technology Risk Management Program"

Similar presentations


Ads by Google