Risk Management: A Holistic Organizational Approach


Published on

A presentation I gave at the 2008 MSIA Residency Week at Norwich University School of Graduate Studies.

Published in: Business

Risk Management: A Holistic Organizational Approach

  1. 1. Risk Management A Holistic Organizational Approach Norwich University – School of Graduate Studies MSIA Residency June 9, 2008 – Morning Session
  2. 2. Agenda <ul><li>Risk Assessment </li></ul><ul><ul><li>System Categorization </li></ul></ul><ul><ul><li>Threat Identification </li></ul></ul><ul><ul><li>Vulnerability Identification </li></ul></ul><ul><ul><li>Controls Analysis </li></ul></ul><ul><ul><li>Impact Assessment </li></ul></ul><ul><ul><li>Risk Determination </li></ul></ul><ul><ul><li>Controls Recommendation </li></ul></ul>
  3. 3. Agenda <ul><li>Risk Mitigation </li></ul><ul><li>Control Implementation </li></ul><ul><li>Residual Risk </li></ul><ul><li>Security and the SDLC </li></ul>
  4. 4. What is Risk Management? <ul><li>A structured approach to managing uncertainty related to a threat accomplished through a sequence of activities. </li></ul><ul><li>Risk Management identifies, measures, and minimizes the effect of uncertain events on systems and system resources. </li></ul>
  5. 5. The Need <ul><li>Risk is an inherent part of every business decision. </li></ul><ul><li>Senior management must realize that the highly complex and interconnected world we live in is facilitated by information systems. </li></ul><ul><li>These systems have now become a foundational element in how business manages risk. </li></ul>
  6. 6. The Need Today’s organizations face many challenges: Death by Committee Undefined Compliance Criteria Reporting Issues Lack of Resources This challenge continues to grow especially when you add in additional lines of business and geographically diverse locations.
  7. 7. The Need <ul><li>Historically Information Security has been viewed as a technical matter that was independent of how the organization as a whole managed risk. </li></ul><ul><li>This view is outdated and may pose a significant threat in and of itself to the success of a business. </li></ul><ul><li>However this message has been slow to sink in… </li></ul>
  8. 8. Source: Privacy Rights Clearinghouse
  9. 9. The Benefits <ul><li>Encourage senior management to recognize the importance of the risk posed by the operation and use of information systems. </li></ul><ul><li>Foster a climate where risks from the use of information systems is automatically considered within the context of business. </li></ul>
  10. 10. The Benefits <ul><li>Assist IT and Systems Development staff with understanding how the risk associated with their systems translates into organizational security concerns. </li></ul>
  11. 11. The Message <ul><li>Our Message must be that </li></ul><ul><ul><li>Information Security is an enabler of business functionality; </li></ul></ul><ul><ul><li>Information Security is a strategic capability that can be used to facilitate and support other business functionality. </li></ul></ul>
  12. 12. Objectives <ul><li>Risk Management should enable business by: </li></ul><ul><ul><li>Better securing the systems that store, process, or transmit information; </li></ul></ul><ul><ul><li>Providing information which supports risk-based decision making. </li></ul></ul>The essence of business is risk – the application of informed belief to contingencies whose outcomes can sometimes be predicted, but never known. ~ Judge William Chandler III
  13. 13. Risk Management <ul><li>Risk Management Activities: </li></ul><ul><li>Risk Assessment </li></ul><ul><li>Risk Mitigation </li></ul><ul><li>Ongoing Evaluation and Assessment </li></ul><ul><li>Risk Management should be performed at all stages of the SDLC. </li></ul>
  14. 14. Risk Assessment Process <ul><li>System Characterization </li></ul><ul><li>Threat Identification </li></ul><ul><li>Vulnerability Identification </li></ul><ul><li>Control Analysis </li></ul><ul><li>Likelihood Determination </li></ul><ul><li>Impact Analysis </li></ul><ul><li>Risk Determination </li></ul><ul><li>Control Recommendations </li></ul><ul><li>Results Documentation </li></ul>
  15. 15. System Categorization <ul><li>Inputs: </li></ul><ul><li>Hardware </li></ul><ul><li>Software </li></ul><ul><li>System Interfaces </li></ul><ul><li>Data and Information </li></ul><ul><li>People </li></ul><ul><li>System Mission </li></ul><ul><li>Outputs: </li></ul><ul><li>System Boundary </li></ul><ul><li>System Functions </li></ul><ul><li>System and Data Criticality </li></ul><ul><li>System and Data Sensitivity </li></ul>How can you protect what you don’t know you have?
  16. 16. A Word about Categorization <ul><li>The two most important aspects of the categorization process is defining your boundaries and identifying critical information. </li></ul><ul><li>The first step is to think about your environment as a collection of processes, communications, storage, and any related resources. </li></ul>
  17. 17. Boundary Elements <ul><li>Each Aspect should: </li></ul><ul><ul><li>Fall under the same direct management control; </li></ul></ul><ul><ul><li>Fulfill the same function or mission objective; </li></ul></ul><ul><ul><li>Reside in the same general operating environment; and </li></ul></ul><ul><ul><li>Have the same security needs </li></ul></ul>
  18. 18. Boundary Elements <ul><li>Direct Management Control? </li></ul><ul><ul><li>Who has the authority to allocate both funds and resources for the system? </li></ul></ul><ul><li>Same Function or Mission Objective? </li></ul><ul><ul><li>Does the system directly map to fulfilling a specifically defined purpose? </li></ul></ul><ul><li>Same Operating Characteristics? </li></ul><ul><ul><li>Is there anything within the system that seems out of place in the way it operates with regard to the rest of the system? </li></ul></ul>
  19. 19. Boundary Elements <ul><li>Same general operating environment? </li></ul><ul><ul><li>This does not mean that the various elements of the system be co-located in the same physical location. </li></ul></ul><ul><ul><li>The elements may be separated geographically as long as their interconnection and dependencies meet the other stated requirements. </li></ul></ul>
  20. 20. Boundary Elements <ul><li>While all of these requirements are important; they are not listed in any particular order or preference. They are all equally important and required. All must be addressed in the definition of your system. </li></ul>
  21. 21. Determining the Boundary <ul><li>Gather System Information </li></ul><ul><ul><li>System-Related Information </li></ul></ul><ul><ul><ul><li>We need to develop an understanding of the operating environment. </li></ul></ul></ul><ul><ul><ul><li>Locate and identify system-related information with regard to the following: </li></ul></ul></ul><ul><ul><ul><ul><li>Hardware </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Software </li></ul></ul></ul></ul><ul><ul><ul><ul><li>System interfaces </li></ul></ul></ul></ul>
  22. 22. Determining the Boundary <ul><li>Data and information </li></ul><ul><li>Persons who support and use the IT system </li></ul><ul><li>System mission (e.g., the processes performed by the IT system) </li></ul><ul><li>System security architecture </li></ul><ul><li>Current network topology (e.g., network diagram) </li></ul>
  23. 23. Determining the Boundary <ul><li>Once we have a handle on the above information we need to ascertain the following: </li></ul><ul><ul><li>The functional requirements of the IT system </li></ul></ul><ul><ul><li>Users of the system </li></ul></ul><ul><ul><li>System security policies governing the IT system (organizational policies, federal requirements, laws, industry practices) </li></ul></ul><ul><ul><li>Flow of information pertaining to the IT system (e.g., system interfaces, system input and output flowchart) </li></ul></ul>
  24. 24. Determining the Boundary <ul><li>Physical security environment of the IT system (e.g., facility security, data center policies) </li></ul><ul><li>Environmental security implemented for the IT system processing environment (e.g., controls for humidity, water, power, pollution, temperature, and chemicals) </li></ul>
  25. 25. Determining the Boundary <ul><li>Locating this Information </li></ul><ul><ul><li>System Development Life Cycle (SDLC) Documents </li></ul></ul><ul><ul><ul><li>Design Documentation </li></ul></ul></ul><ul><ul><ul><li>Requirement Documentation </li></ul></ul></ul><ul><ul><li>Configuration Management Documentation </li></ul></ul><ul><ul><li>Change Control Board Documentation </li></ul></ul><ul><ul><li>Policy and Procedures </li></ul></ul><ul><ul><li>Questionnaires </li></ul></ul><ul><ul><li>Interviews </li></ul></ul>
  26. 26. Boundary Summary <ul><li>The expected output from these activities is to obtain a good picture of the IT system environment, and a delineation of boundaries. </li></ul>
  27. 27. Identifying Critical Information <ul><li>Now that we have established our boundaries, we need to examine the information that </li></ul><ul><ul><li>Flows into the system; </li></ul></ul><ul><ul><li>Flows through the system; </li></ul></ul><ul><ul><li>Is processed by the system; </li></ul></ul><ul><ul><li>Is stored within the system; and </li></ul></ul><ul><ul><li>Flows out of the system. </li></ul></ul>
  28. 28. Identifying Critical Information <ul><li>We need to determine how critical this information is to the business objectives being supported. </li></ul><ul><li>Information Identification can be done at two levels of detail: </li></ul><ul><ul><li>A System Wide View or </li></ul></ul><ul><ul><li>Focusing on the Information one piece at a time </li></ul></ul>
  29. 29. Identifying Critical Information <ul><li>The Benefit of taking a system wide view is that it is normally a quick process however you should probably protect the entire system with controls appropriate for the most critical information within the system. </li></ul><ul><ul><li>This may not be cost effective depending upon the size of the system. </li></ul></ul>
  30. 30. Identifying Critical Information <ul><li>The Benefit of focusing on the information one piece at a time is that it allow you to place controls only where needed within the environment </li></ul><ul><ul><li>This is more cost effective however it can be a long process. </li></ul></ul><ul><li>It is recommended that you first take a system wide view and then focus on systems containing critical information. </li></ul>
  31. 31. System Wide Security Categorization <ul><li>When you are talking about Information Security, you are really trying to achieve three Security Objectives: </li></ul><ul><ul><li>Confidentiality or making sure that only the people who need to see the information can see the information and no others; </li></ul></ul><ul><ul><li>Integrity or making sure the information is not altered by people who are not authorized to alter it; and </li></ul></ul><ul><ul><li>Availability or making sure that you can access the information when you need to access it. </li></ul></ul>
  32. 32. System Wide Security Categorization <ul><li>These three Security Objectives need to be examined independently with regard to the impact a loss of any one would have on the overall mission being supported by the system. </li></ul><ul><li>At this stage you should focus on the worst case potential impact at this stage. You can factor in the probability of a loss when you determine the appropriate controls. </li></ul>
  33. 33. Impact Levels <ul><li>It is recommended that you use a simple measure of the potential impact such as: </li></ul><ul><ul><li>Low </li></ul></ul><ul><ul><li>Moderate </li></ul></ul><ul><ul><li>High </li></ul></ul>
  34. 34. Low Impact* <ul><li>Low </li></ul><ul><ul><li>Limited adverse effect </li></ul></ul><ul><ul><ul><li>Degradation in mission capability to an extent or duration that primary mission effectiveness is noticeably reduced; or </li></ul></ul></ul><ul><ul><ul><li>Minor damage to organizational assets; or </li></ul></ul></ul><ul><ul><ul><li>Minor financial loss; or </li></ul></ul></ul><ul><ul><ul><li>Minor harm to individuals </li></ul></ul></ul><ul><li>All of these elements need not apply; they are used to illustrate the concept. </li></ul>* These definitions come from the FIPS 199
  35. 35. Moderate Impact <ul><li>Moderate </li></ul><ul><ul><li>Serious adverse effect </li></ul></ul><ul><ul><ul><li>Significant degradation in mission capability to the extent or duration that organization is not able to perform one or more of primary functions; or </li></ul></ul></ul><ul><ul><ul><li>Significant damage to organizational assets; or </li></ul></ul></ul><ul><ul><ul><li>Significant financial loss; or </li></ul></ul></ul><ul><ul><ul><li>Significant harm to individuals that does not involve loss of life or serious life threatening injuries. </li></ul></ul></ul><ul><li>All of these elements need not apply; they are used to illustrate the concept. </li></ul>
  36. 36. High Impact <ul><li>High </li></ul><ul><ul><li>Severe or Catastrophic adverse effect </li></ul></ul><ul><ul><ul><li>Severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; or </li></ul></ul></ul><ul><ul><ul><li>Major damage to organizational assets; or </li></ul></ul></ul><ul><ul><ul><li>Major financial loss; or </li></ul></ul></ul><ul><ul><ul><li>Severe or Catastrophic harm to individuals involving loss of life or serious life threatening injuries. </li></ul></ul></ul><ul><li>All of these elements need not apply; they are used to illustrate the concept. </li></ul>
  37. 37. Impact Determination <ul><li>Begin by sitting down with the system owners, system users, and system designers to get a handle on the information flows </li></ul><ul><ul><li>You can examine existing documentation (both created and vender) to assist in this process. </li></ul></ul>
  38. 38. Impact Determination <ul><li>The questions you want to ask are: </li></ul><ul><ul><li>What impact would the mission feel if someone were to get unauthorized access to the information in this system? ( Confidentiality ) </li></ul></ul><ul><ul><li>What impact would the mission feel if someone were to alter the information in this system without authorization? ( Integrity ) </li></ul></ul><ul><ul><li>What impact would the mission feel if someone were not able to access the information in this system when they needed to? ( Availability ) </li></ul></ul>
  39. 39. Aspects to Consider <ul><li>In some cases, the security categorization for an individual system may be higher than the impact level for any information types being processed by the system. </li></ul><ul><li>The primary factors that raise the security categorization are: </li></ul><ul><ul><li>Aggregation </li></ul></ul><ul><ul><li>Connectivity </li></ul></ul><ul><ul><li>Critical System Functionality </li></ul></ul>
  40. 40. Aggregation <ul><li>Some information may have little or no sensitivity in isolation but may be highly sensitive in aggregate </li></ul><ul><li>In general, the sensitivity of a given data element is likely to be greater in context than in isolation </li></ul>
  41. 41. Aggregation <ul><li>If review reveals increased sensitivity or criticality associated with information aggregates, then the system categorization may need to be adjusted to a higher level than would be indicated by the impact associated with any individual information type. </li></ul>
  42. 42. Connectivity <ul><li>Aggregation of data can also occur across system interfaces. </li></ul><ul><li>Connecting systems should be examined to determine if information types contained on the various systems dictates a higher security categorization. </li></ul>
  43. 43. Critical System Functionality <ul><li>Access Control information for a system that processes only low impact information might initially be thought to have low impact attributes however if access to this system results in access to other systems then the sensitivity and criticality attributes of all systems needs to be considered. </li></ul>
  44. 44. Risk Assessment <ul><li>After establishing the scope of the assessment and the criticality of the information being protected you need to assess the threats. </li></ul>
  45. 45. Threat Identification <ul><li>Inputs: </li></ul><ul><li>History of System Attack </li></ul><ul><li>Intelligence Agencies </li></ul><ul><li>Mass Media (News) </li></ul><ul><li>Outputs: </li></ul><ul><li>Threat Matrix </li></ul>The goal is to identify the potential for a threat source to use a specific vulnerability.
  46. 46. Vulnerability Identification <ul><li>Inputs: </li></ul><ul><li>Prior Risk Assessments </li></ul><ul><li>Audit Results </li></ul><ul><li>Security Requirements </li></ul><ul><li>Security Test Results </li></ul><ul><li>Product Research </li></ul><ul><li>Outputs: </li></ul><ul><li>List of Potential Vulnerabilities </li></ul>Vulnerability: A flaw or weakness in system security procedures, design, implementation, or internal controls that could be used to create a security breach or a violation of the system’s security policy.
  47. 47. Control Analysis <ul><li>Inputs: </li></ul><ul><li>Required Controls </li></ul><ul><li>Current Controls </li></ul><ul><li>Planned Controls </li></ul><ul><li>List of Potential Vulnerabilities </li></ul><ul><li>Outputs: </li></ul><ul><li>List of Current and Planned Controls </li></ul><ul><li>Findings Report </li></ul>The goal of this step is to review the security controls to determine if there are any that do not adequately minimize the likelihood or impact of an incident.
  48. 48. Likelihood Determination <ul><li>Inputs: </li></ul><ul><li>Attack Statistics </li></ul><ul><li>Threat-Source Motivation </li></ul><ul><li>Threat Capacity </li></ul><ul><li>Nature of Vulnerability </li></ul><ul><li>Current Controls </li></ul><ul><li>Outputs: </li></ul><ul><li>Likelihood Rating </li></ul>The goal of this activity is to determine the probability of a particular vulnerability being exercised.
  49. 49. Impact Assessment <ul><li>Inputs: </li></ul><ul><li>Mission Impact Analysis </li></ul><ul><li>Asset Criticality Assessment </li></ul><ul><li>Data Criticality </li></ul><ul><li>Data Sensitivity </li></ul><ul><li>Outputs: </li></ul><ul><li>Impact Rating </li></ul>The goal for this activity is to determine the impact to the system and the organization’s mission.
  50. 50. Risk Determination <ul><li>Inputs: </li></ul><ul><li>Likelihood of Threat Exploitation </li></ul><ul><li>Magnitude of Impact </li></ul><ul><li>Adequacy of Planned or Current Controls </li></ul><ul><li>Outputs: </li></ul><ul><li>Risks and Associated Risk Levels </li></ul>The goal of this step is to determine the overall level of risk to the system based on all the activities that we have performed so far.
  51. 51. Recommended Controls <ul><li>Inputs: </li></ul><ul><li>Risk Determination </li></ul><ul><li>List of Current and Planned Controls </li></ul><ul><li>Findings Report </li></ul><ul><li>Outputs: </li></ul><ul><li>Recommended Controls </li></ul>Recommended controls address the risks that are not deemed acceptable. The System Owner determines which controls to implement on a cost-benefit basis.
  52. 52. Now What? <ul><li>Mitigation starts as soon as the findings are announced </li></ul><ul><li>Some risks may need to be accepted (fully document this decision) </li></ul><ul><li>Any unaccepted and unmitigated risks should become POA&M items </li></ul>
  53. 53. Control Implementation <ul><li>Prioritize Actions </li></ul><ul><li>Evaluate Recommended Control Options </li></ul><ul><li>Conduct Cost-Benefit Analysis </li></ul><ul><li>Select Control </li></ul><ul><li>Assign Responsibility </li></ul><ul><li>Develop a Plan of Action and Milestones (POA&M) </li></ul><ul><li>Implement Selected Controls </li></ul><ul><li>Assess Residual Risk </li></ul>
  54. 54. Residual Risk <ul><li>Residual Risk is the risk remaining after the controls are implemented. </li></ul><ul><li>If the level of Residual Risk is not acceptable, then additional controls need to be implemented </li></ul>
  55. 55. Where the rubber meets the road <ul><li>RM activities need to extend from the board room down to the server room. </li></ul><ul><li>RM and Information Security need to be fully incorporated into the system development life cycle in order to be truly effective. </li></ul>
  56. 56. Security and the SDLC – WHY? <ul><li>Including Information Security as a requirement early in the acquisition process will usually result in less expensive and more cost effective security. </li></ul><ul><li>Adding security to an operational system is prone to interoperability issues as well as being more expensive. </li></ul><ul><li>The most effective security controls are those that are integrated into the system from its inception. </li></ul>
  57. 57. Incorporating Security into the SDLC <ul><li>Many SDLC methodologies exist and can be used to effectively develop an Information System. </li></ul><ul><ul><li>Linear sequential model </li></ul></ul><ul><ul><li>Prototyping model </li></ul></ul><ul><ul><li>Iterative development models </li></ul></ul><ul><ul><li>Spiral model </li></ul></ul><ul><ul><li>Component Assembly model </li></ul></ul><ul><ul><li>Concurrent development model </li></ul></ul><ul><li>We’ll use the linear sequential model as an example because of its simplicity however the concepts are applicable to any SDLC Model. </li></ul>
  58. 58. Expressing Security Properties <ul><li>The first step to integrating security into the SDLC is being able to properly articulate the security requirements for the system. </li></ul><ul><li>This is typically a cyclical refinement process beginning at a high level and drilling down to what will eventually end up being security specifications. </li></ul>
  59. 59. Expressing Security Properties <ul><li>Because the security characteristics of a system will evolve over time, the system/security requirements should be placed under configuration management as part of the total set of system documentation. </li></ul>
  60. 60. IT Security in the SDLC
  61. 61. Initiation <ul><li>Needs Determination is an analytical activity that evaluates the capacity of an organization’s assets to satisfy existing or emerging demands. </li></ul><ul><ul><li>Establishing a basic system idea, defining preliminary requirements, feasibility and technology assessments. </li></ul></ul>
  62. 62. Initiation <ul><li>The security aspect will revolve around a high-level description of the security controls and the assurance requirements. This should also include security considerations of: </li></ul><ul><ul><li>Alternative architectures and technologies </li></ul></ul><ul><ul><li>Threat Analysis </li></ul></ul><ul><ul><li>Identifying Critical Information </li></ul></ul>
  63. 63. Acquisition and Development <ul><li>The A/D stage of the SDLC involves the following activities: </li></ul><ul><ul><li>Establishing a Fundamental Statement of Need </li></ul></ul><ul><ul><li>Conducting Market Research, a Feasibility Study, a Requirements Analysis, and an Alternate Technologies Analysis to determine if solution is the best technological solution for the need. </li></ul></ul>
  64. 64. Acquisition and Development <ul><li>The A/D stage of the SDLC (continued): </li></ul><ul><ul><li>Conducting a Cost Benefits Analysis to determine if the solution is the most cost effective way of meeting the need. </li></ul></ul><ul><ul><li>Studying any Software Conversion issues that may arise </li></ul></ul><ul><ul><li>Performing an overall Cost Analysis of the system and it’s overall SDLC </li></ul></ul><ul><ul><li>Developing a targeted Risk Management Plan </li></ul></ul>
  65. 65. A/D and Security <ul><li>Identify the protection requirements through a formal risk assessment process. </li></ul><ul><li>Address the security implications to other neighboring systems and/or the network environment resulting from the deployment of the identified solution </li></ul><ul><ul><li>The new system should </li></ul></ul><ul><ul><ul><li>not create any new vulnerabilities; </li></ul></ul></ul><ul><ul><ul><li>Not decrease the availability of the other systems; </li></ul></ul></ul><ul><ul><ul><li>Not decrease the overall security posture of the environment; </li></ul></ul></ul><ul><ul><ul><li>Have security specifications that are appropriate for the deployment environment; </li></ul></ul></ul>
  66. 66. A/D Tips <ul><li>External connections not under your control should be considered hostile and must be analyzed and guarded against accordingly. </li></ul><ul><li>The security specifications should be clearly stated so that the developers can adequately integrate them into their development activities. </li></ul><ul><li>The legal, functional, and other IT security requirements should be stated in specific terms within the functional requirements. </li></ul>
  67. 67. Implementation <ul><li>The Implementation stage of the SDLC involves the following activities: </li></ul><ul><ul><li>Installation of the system; </li></ul></ul><ul><ul><li>Inspecting the system to ensure that it was properly installed and performing as expected; </li></ul></ul><ul><ul><li>Acceptance Testing; </li></ul></ul><ul><ul><li>Initial User Training; </li></ul></ul><ul><ul><li>Documentation. </li></ul></ul>
  68. 68. Implementation <ul><li>Inspection and acceptance involves activities which inspect the system to determine you have received what you requested and if you should pay for it. </li></ul><ul><ul><li>Independent validation and verification testing may be conducted and should include the security requirements of the system. </li></ul></ul>
  69. 69. Operations and Maintenance <ul><li>The O/M stage of the SDLC involves the following activities: </li></ul><ul><ul><li>Performance Measurement </li></ul></ul><ul><ul><li>Contract Modification </li></ul></ul><ul><ul><li>Operations </li></ul></ul><ul><ul><li>Maintenance </li></ul></ul>
  70. 70. Operations and Maintenance <ul><li>Security Considerations </li></ul><ul><ul><li>Configuration Management and Control </li></ul></ul><ul><ul><ul><li>Live systems are continuously changing and evolving. Each change should be evaluated for security as well as functionality </li></ul></ul></ul><ul><ul><li>Continuous Monitoring </li></ul></ul><ul><ul><ul><li>Security Controls need to be constantly monitored to ensure they continue to be implemented correctly and providing the desired results. </li></ul></ul></ul>
  71. 71. Disposition <ul><li>The Disposition stage of the SDLC involves the following activities: </li></ul><ul><ul><li>Determining the appropriateness of system disposal; </li></ul></ul><ul><ul><li>Exchange and/or sale of the system hardware; </li></ul></ul><ul><ul><li>Internal Organization screening; </li></ul></ul><ul><ul><li>Transfer and/or Donation of the system; </li></ul></ul><ul><ul><li>Contract Closeout. </li></ul></ul>
  72. 72. Disposition – Security Considerations <ul><li>Security Considerations </li></ul><ul><ul><li>Disposition activities ensure the orderly termination of the system and preserves the vital information about that system so that some or all of the information may be reactivated in the future if necessary </li></ul></ul><ul><ul><ul><li>Information Preservation </li></ul></ul></ul><ul><ul><ul><li>Media Sanitization </li></ul></ul></ul><ul><ul><ul><li>Hardware/Software Disposal </li></ul></ul></ul>
  73. 73. Keys to Risk Management Success <ul><li>Support from senior management </li></ul><ul><li>Determination of the level of acceptable risk v/s risk avoidance </li></ul><ul><li>Competence of the risk assessment team </li></ul><ul><li>Awareness and cooperation of the user community </li></ul><ul><li>Ongoing evaluation and assessment of risk </li></ul><ul><li>Cost-Benefit analysis </li></ul><ul><li>System Owner who is not decision-adverse </li></ul>
  74. 74. Contact Information <ul><li>Graydon McKee </li></ul><ul><li>[email_address] </li></ul><ul><li>678.382.2626 </li></ul><ul><li>www.ascensionriskmanagement.com </li></ul>
  75. 75. Contributors <ul><li>Abe Chen – MSIA ’07 </li></ul><ul><li>Kevin Moker – MSIA ’07 </li></ul><ul><li>Michael Mango – MSIA ‘07 </li></ul><ul><li>Julius Fashae – MSIA ’07 </li></ul><ul><li>John Kampfhenkel – MSIA ’07 </li></ul><ul><li>Ian Charters – Deloitte </li></ul><ul><li>Jon Damratoski – Asurion Insurance </li></ul><ul><li>Miguel Adams – MSIA ’07 </li></ul><ul><li>Adam Dodge – MSIA ’07 </li></ul><ul><li>David Block – MSIA ’07 </li></ul><ul><li>Martinus Bruce – MSIA ’07 </li></ul><ul><li>Melvin Abraham – MSIA ‘07 </li></ul><ul><li>Michael J. Smith – Deloitte </li></ul><ul><li>Joe Faraone - GCI </li></ul>
  76. 76. Questions
  77. 77. Generic Blocks, Circles and Arrows - Copy/Paste the Objects Below or Use the Paint Brush on the Formatting Toolbar to Copy Colors onto Other Objects 1 1 Ascension Blue RGB Code: 42 - 57 -144 Standard RGB Code: 222 - 211 - 182 Ascension Green RGB Code: 152 - 202 - 60 Preferred Colors 1
  78. 78. Ascension refers Ascension Risk Management, a Limited Liability Company located in Gwinnett County, Georgia. Ascension is a woman owned company providing information risk management services to small and medium sized organizations within the public and private sectors. Ascension is dedicated to helping our clients “Create Opportunity from Risk”™. For more information please visit our website: www.ascensionriskmanagement.com