Risk Assessment Guide

Transcription

1 Government of Newfoundland and Labrador Office of the Chief Information Officer Information Management Branch Risk Assessment Guide Overview of Information Protection Risk Assessments May 2010 Information Management Branch Information Protection Division

2 Table of Contents Introduction...3 Roles and Responsibilities...3 Branch IP Leads...3 Information Management Branch...4 Project Manager / Project Team...5 Team Lead / Support Team...5 Client (Government Departments)...5 Client Services...5 Project Management Office...6 Overview: Preliminary Threat Risk Assessment...7 Initiate Pre-TRA Process...8 Conduct Pre-TRA...9 Close Out Pre-TRA Process...9 Budget and Scheduling...9 Overview: Threat Risk Assessment...10 Initiate TRA Process...10 Complete Statement of Sensitivity...11 Conduct TRA...11 Close Out TRA Process...12 Budget and Scheduling...12 Overview: Vulnerability Assessment...13 Initiate VA Process...13 Conduct VA...14 Close Out VA Process...15 Budget and Scheduling...15 Overview: Risk-Based Decision Document...16 Initiate Risk-Based Decision Document Process...16 Complete Risk-Based Decision Document...16 Close Out Risk Based Decision Document Process...17 Budget and Scheduling...17 Appendix A: Lead Model...18 Appendix B: TRA Process...19 Appendix C: VA Process...20 Appendix D: VA Timeline...21 Appendix E: Risk-Based Decision Process...22 Appendix F: Functional Architecture (FA2)...23 Page 2 of 23

3 Risk Assessment Guide An Overview of Information Protection Risk Assessments Introduction This document provides an overview of Information Protection risk assessments initiated across the Office of the Chief Information Officer (OCIO) by the Information Management (IM) Branch. This formalized, request-based approach to assessing risk will help all OCIO branches assess threats and vulnerabilities, document existing security measures and make recommendations to either implement additional safeguards or accept the risk. Current Information Protection risk assessments being used across OCIO include: 1. Pre-TRA Assessment ( Pre-TRA Checklist & Information Security Classification ) 2. Threat Risk Assessment 3. Vulnerability Assessment 4. Risk-based Decision Document The implementation of the Lead Model (see Appendix A) and Branch IP Leads will be used to communicate and coordinate risk processes across the branches. This guide will help OCIO staff and contractors understand these risk assessments and related deliverables. Further questions related to this guide or its contents should be directed to the IM Branch (IP Division) at IM@gov.nl.ca. Roles and Responsibilities Branch IP Leads The OCIO has adopted a Lead Model to communicate and facilitate Information Protection processes, initiatives and issues across all branches. As part of this model, each branch has designated a Branch IP Lead that will be the single point of contact to communicate and coordinate IP matters across the branches. A close working relationship between the IM Branch and the Branch IP Leads will help clarify branch responsibilities as they relate to Information Protection and encourage a culture of managing risk across the OCIO. The roles and responsibilities of the Branch IP Leads are as follows: Receive requests for risk assessments from within their branch and submit to the IM Branch Participate in weekly Branch IP Lead meetings, as required Be aware of any Information Protection-related initiatives ongoing within their branch Sign off, on behalf of their branch, on Deviations (i.e. unmitigated items) resulting from Threat Risk Assessments (TRA) and Vulnerability Assessments (VA) Distribute Information Protection communications within their branch, as required Branch IP Lead Jey Kumar Calvin Butt (Backup: Vickie O Neill) Andre Besso OCIO Branch Solutions Delivery Application Services Operations Page 3 of 23

4 Information Management Branch Information Protection Division Information Protection (IP) is an area of practice focused on the protection of information from inappropriate access or use, using a variety of means as required, including, but not limited to policies, directives and guidelines; physical and electronic security measures; and compliance monitoring and reporting. IP represents the point at which management of information converges with security policy and practices. Within the Government of Newfoundland and Labrador, public bodies are required to protect information as part of their accountability under Section 6 of the Management of Information Act SNL2005 c.m Information Protection and Security Program The IP Division is responsible for the definition, administration and oversight of the Information Protection and Security (IP&S) Program on behalf of OCIO. While managed by the IM Branch, the IP&S Program is an OCIO program that holds responsibilities for all branches. The IP&S Program: Enables OCIO to establish appropriate information security controls that safeguard government s information assets and resources; Manages risk by providing the appropriate parts of the organization with the information they need, when they need it and by creating and maintaining risk assessment tools and process; Promotes consistency and reduces overall risk by providing clear accountability and responsibility for information security risk decisions; and Encompasses the following processes as they relate to Information Protection and Security: Governance, Policy and Standards; Planning and Strategy; Education and Awareness; Information Risk Management; Monitoring and Compliance; and Executive Incident Response. Risk Assessment Responsibilities In support of its IP mandate related to risk assessments, the IM Branch is responsible for: Development of IP policies, directives, standards and guidelines, in accordance with the IP&S Policy Mosaic and Framework; Development, coordination, oversight and process definition of the Preliminary Threat Risk Assessment (Pre-TRA), Information Security Classification and Risk-based Decision processes and tools; Oversight and process definition of independent 3 rd party risk assessments (i.e. TRA and VA); Sign off of Deviations resulting from a TRA or VA; Tracking of risk assessments and Deviations; Coordination and facilitation of Branch IP Lead meetings; Advice and guidance to other branches on risk assessment activities; and Communication and education of all risk assessment processes across OCIO Page 4 of 23

5 Project Manager / Project Team For risk assessments conducted on projects coming through the System Development Lifecycle (SDLC), it is the responsibility of Project Managers to contact their Branch IP Lead and request the Pre-TRA. Once contacted, the Branch IP Lead will submit a formal Request for Service to the IM Branch. When the Pre-TRA determines a TRA and/or VA are required, it is the responsibility of Project Manager to contact the Project Management Office (PMO) to initiate the risk assessments. While not tasked with the hands-on completion of risk assessments, Project Managers and project teams are expected to attend assessment meetings as well as provide project knowledge, subject matter expertise and relevant documentation to the IM Branch throughout the risk assessment process. Project team members that are familiar with the business requirements and system design will participate in the assessment meetings, where required. With respect to a TRA and/or VA, Project Managers are responsible for ensuring all vulnerabilities identified in the independent assessor s VA/TRA Report are mitigated to a standard deemed acceptable by the Project Management Office (PMO). In the event that items cannot be mitigated before Go Live, Project Managers are responsible for identifying and documenting unmitigated items and clearly justifying the reason for not mitigating all vulnerabilities. Team Lead / Support Team For risk assessments conducted on existing systems/environments, it is the responsibility of Team Leads (AS / Ops) to contact their Branch IP Lead and request a risk assessment, where required. Once contacted, the Branch IP Lead will submit a formal Request for Service to the IM Branch. While not tasked with the hands-on completion of risk assessments, Team Leads and Support Teams are expected to attend assessment meetings as well as provide project knowledge, subject matter expertise and relevant documentation to the IM Branch throughout the risk assessment process. Support team members that are familiar with the business requirements and system design will participate in the assessment meetings, where required. With respect to a TRA and/or VA, Team Leads are responsible for ensuring all vulnerabilities identified in the independent assessor s VA/TRA Report are mitigated to a standard deemed acceptable by the Project Management Office (PMO). In the event that items cannot be mitigated before Go Live, Team Leads are responsible for identifying and documenting unmitigated items and clearly justifying the reason for not mitigating all vulnerabilities. Client (Government Departments) As the sponsor, the client provides an overview and understanding of their business needs throughout a risk assessment process. They are invaluable to understanding sensitivity and criticality of their information assets. All engagements with the client should be facilitated through the appropriate Client Services representative within the Client Services and Corporate Operations Branch. The client, where possible, should attend Pre-TRA meetings because this process will complete the Information Security Classification and the client will provide guidance and background about information assets and key business requirements. In the event that a TRA is required, the client will again play a critical advisory role in understanding the sensitivity and criticality of information assets during the Statement of Sensitivity process. The VA process may require engagement of the client in terms of user acceptance testing and communication of appropriate outage windows, but active participation in VA activities is not required. Client Services Client Services representatives are responsible for communicating the importance of risk assessments to their clients, as well as facilitating discussions with the client to discuss specific risks that are identified, where required. Page 5 of 23

6 Project Management Office The PMO is responsible for the day to day operational tasks of TRA and VA activity, including: Scheduling of VA and TRA; Preparing the Statement of Work; Facilitating completion of the Statement of Sensitivity for the TRA; Arranging setup and close-out of the test environment for the VA; Managing external resources conducting the TRA or VA; receiving / distributing draft and final reports; and Sanctioning and monitoring proposed TRA and VA mitigation activities and confirming completion of those activities; Forwarding unmitigated TRA and VA items to the IM Branch (i.e. Deviations ) Important: The IM branch will continue to own the TRA and VA processes, sign off on the TRA and VA process completion and maintain responsibility for oversight and definition of these processes. In addition, the IM Branch will continue to recommend when an independent (i.e. external) TRA or VA is required via the existing Pre-TRA process. Page 6 of 23

7 Overview: Preliminary Threat Risk Assessment The Pre-TRA is comprised of two deliverables in the form of a Risk Assessment Workbook : 1. Information Security Classification (& Functional Control Recommendations) 2. Pre-TRA Checklist Information Security Classification An Information Security Classification ranks the sensitivity and criticality of government information and guides the process to place appropriate levels of security and protection around information assets. Classification supports the Risk Assessment model in its selection of suitable safeguards. While the Information Security Classification is not a risk assessment per say, it drives a risk assessment process by identifying and ranking asset(s) that must be protected from threats, vulnerabilities and risk. The sensitivity and criticality of government information will receive a ranking of High, Medium, Low or Unclassified, based on the following criteria: Confidentiality (C) upholding required restrictions against unauthorized access or disclosure of information (e.g., personal information, cabinet confidences, trade secrets) Integrity (I) maintaining the authenticity and preventing unauthorized modification or destruction of information (e.g., food or water testing, health care, law enforcement) Availability (A) ensuring timely and reliable access to and use of information (e.g., emergency communications or health services, financial systems, benefits systems) For every Information Security Classification, a ranking of High, Medium and Low (as well as Unclassified, for Confidentiality only) is provided for each of the CIA criteria. Based on these rankings, Functional Control Recommendations are provided, stating the minimum level of information protection and security functions to be implemented to adequately protect the information asset. Functional Control Requirements As part of the IP&S Framework, OCIO s Security Architecture is grouped into three layers Conceptual, Functional and Physical. The Conceptual and Functional layers are owned by the IM Branch; the Physical Architecture layer is owned by the EAG, SD Branch. The Functional Architecture (FA2) identifies the functions (i.e. functional controls) that must be in place to adequately protect the information asset. Functional control requirements will increase as the sensitivity of the information asset increases the extent to which an information asset is protected, from a functional perspective, is relative to the sensitivity of that asset (i.e. the underlying Information Security Classification). For an overview of the Functional Architecture (FA2), see Appendix F. The IM Branch (via the Information Security Classification) is only responsible for identifying what functions must be in place to protect information the EAG, as owners of the Physical Architecture, are responsible for identifying how those functions should be implemented. For example, the Classification states that the functional control 2 nd Factor Authentication is mandatory to access High Sensitivity information from outside the Government network. Identification of specific technologies, tools, architectures or designs considered acceptable to perform the function of 2 nd Factor Authentication would be the responsibility of the EAG. The IM Branch and the Classification only state the required functional controls. Page 7 of 23

8 Pre-TRA Checklist The Pre-TRA Checklist determines the need for a TRA and/or VA. The Checklist makes this recommendation based on the underlying Information Security Classification and exposure of the system, as defined below: Internal the system is exposed only to the internal network users without access to the GNL network cannot access this system. Trusted Source (3 rd Party) the system is exposed to the network via a third party that is known to GNL and shares a level of trust with our network users can access some or all of the system from this trusted source. Internet the system has some or full exposure outside of the GNL network users can access some or all of the system from the Internet. The exposure of a system will influence the degree of risk posed to the information. For example, 3 rd Party or Internet-facing systems may demand a higher level of security than an internal application with the same Information Security Classification. The degree of risk increases as the system moves away from the internal network. Recommendations for a TRA and/or VA provided via the Pre-TRA Checklist are mandatory and apply to independent third party risk assessments they do not refer to any internal Quality Assurance reviews or requirements that may be mandated by the PMO. Initiate Pre-TRA Process When to Engage Engaging the Pre-TRA is mandatory for all projects coming through the SDLC. It will be initiated during the Analysis phase, after client sign off of the Business Requirements. If the project team is disbanding after the Business Requirement deliverable, the Pre-TRA process will be engaged after the client signs off the first draft of the requirements. If the project does not have a Business Requirement deliverable, the Pre-TRA will be initiated midway through the Analysis phase. At this time, engaging the Pre-TRA process is not mandatory for the Application Services and Operations Branches, but may be requested on a voluntary basis, as deemed necessary. The IM Branch continues to work with the Branch IP Leads in those areas to develop a fixed integration process for these deliverables. How to Engage A request to engage the Pre-TRA must be made to the respective Branch IP Lead, who will submit a formal Request for Service (DOC10365/2009) to the IM Branch. Only the Branch IP Leads can submit requests for risk assessments to the IM Branch. How to Prepare Upon receipt of the request, the IM Branch will set up a meeting to conduct the Pre-TRA. Informal discussions may take place prior to the meeting in preparation for the actual assessment. Key stakeholders and subject matter experts should be identified to the IM Branch prior to the meeting to ensure their participation in the assessment process. Key participants would typically include the Project Manager or Support Team Manager/Lead, technical leads, Client, Branch IP Lead and where appropriate, the Client Services representative for the client department. The following deliverables must be provided to the IM Branch before the Pre-TRA meeting: Business Requirements IM Assessment Report PPIA Checklist & Privacy Impact Assessment (PIA) Recommendation Letter Page 8 of 23

9 Conduct Pre-TRA Hold Pre-TRA Meeting The Pre-TRA meeting will be scheduled for a maximum of two hours. During the meeting, the IM Branch will facilitate a discussion to ascertain the sensitivity and criticality of the information assets and determine the need for a TRA and VA. Complete Information Security Classification and Pre-TRA Checklist Completing the Information Security Classification and Pre-TRA Checklist is the responsibility of the IM Branch. Follow up and informal discussion may be required with relevant stakeholders during completion of the Classification to ensure all necessary background and criteria are captured and documented appropriately. DELIVERABLE: Risk Assessment Workbook - Information Security Classification - Pre-TRA Checklist - Functional Control Recommendations Owner: Close Out Pre-TRA Process Close out of the Pre-TRA will occur when the Risk Assessment Workbook is finalized and stored in TRIM. Budget and Scheduling As the Pre-TRA is an internal process, there is no additional cost to engage associated with its completion. However, projects may have to adjust resource costs to ensure participation in required assessment activities and discussions. In most cases, projects can expect to schedule 2-3 weeks from the time a request is initiated until the Risk Assessment Workbook is completed. Larger, more complex projects may have to allow for additional time. Page 9 of 23

10 Overview: Threat Risk Assessment A TRA is a detailed, structured process designed to provide an understanding of the risks and issues associated with the implementation of a new application or infrastructure. The intention of a TRA is to determine: What needs to be protected; Who/What are the threats and vulnerabilities; Likelihood of threat occurrence; Impact to the organization; What are the implications if they were damaged or lost; What is the value to the organization; What can be done to minimize exposure to the loss or damage; and The residual risk. The outcome or objective of a TRA is to provide recommendations to maximize the protection of information confidentiality, integrity and availability while still providing functionality and usability for business owners. The TRA will be performed by an independent security vendor, upon recommendation from the IM Branch during the Pre-TRA process. For an overview of the TRA process, see Appendix B. Initiate TRA Process When to Engage If the Pre-TRA Checklist indicates that a TRA is required, the TRA process should be initiated upon receipt of the Risk Assessment Workbook from the IM Branch. How to Engage While the IM Branch makes the initial recommendation to complete a TRA via the Pre-TRA Checklist, engagement to proceed with actual TRA activities must be made to the PMO, as they are the entity responsible for day to day operational tasks within the TRA and VA processes. To initiate the TRA, please contact OCIO-PMO@gov.nl.ca. How to Prepare The PMO will arrange on-site visitation and stakeholder interviews on behalf of the vendor, as required. The vendor will require several items before assessing the threats and risks, including (but not limited to): Detailed Architecture Design (DAD); Information Security Classification; Network Diagram (Visio); Preliminary Privacy Impact Assessment (PPIA) Incident Response Protocols; and Other relevant documentation, as necessary (e.g., such as user manuals, technical guides, document handling procedures, policies, processes and procedures, etc ) Page 10 of 23

11 Complete Statement of Sensitivity The first step in the TRA process is the completion of a Statement of Sensitivity (SoS). The SoS identifies the relative importance of assets based on the degree of injury that could result from their unauthorized disclosure, destruction, removal, modification, interruption or use. The Information Security Classification completed during the Pre-TRA Assessment will feed into the SoS. The SOS identifies all valuable and essential assets and determines their financial or business value to the client, based on their confidentiality, integrity and availability ranking. Completion of the SOS will serve to scope the requirements for the Threat Risk Assessment. While not a formal deliverable, the SoS should be reviewed by the client, IM Branch and PMO for accuracy and acceptance before proceeding with the remainder of the TRA. The PMO will complete the Statement of Work for the TRA (including the Statement of Sensitivity) and make any necessary arrangements to engage the independent security vendor performing the assessment (i.e. travel, meetings, interviews, etc ). Important: The client plays a crucial role in explaining their business needs - they are invaluable to understanding the assets and their importance to the line of business. Client Services should be engaged to facilitate client involvement in completing the SoS. Conduct TRA Completion of the TRA is the responsibility of the independent security vendor hired to do the assessment. However, participation and consultation is expected of the client and project/support staff through interviews, document reviews and on-site visits to the business operating location(s), including the OCIO. After completion of the hands on portion of the assessment (i.e. that period of time where the vendor is on-site and meeting with key stakeholders), the vendor will assess and document identified vulnerabilities, potential threats, as well as existing safeguards and their effectiveness in the business and technical environment. Some follow up with the client and/or stakeholders may be required. The initial results of the vendor s findings will be documented in a draft Threat Risk Assessment Report. DELIVERABLE: TRA Report (DRAFT) Owner: Independent Security Vendor (not OCIO) The vendor will provide the draft TRA Report to the PMO and the IM Branch for review. Upon review, feedback, updates and/or changes will be incorporated into the document by the vendor and a final TRA Report will be delivered for sign off by the IM Branch. The Branch IP Lead for the branch that required the TRA will sign off to indicate acceptance of the final TRA Report and the Director of Information Protection, IM Branch, will sign off on the final TRA Report. DELIVERABLE: TRA Report (FINAL) Owner: Independent Security Vendor (not OCIO) Mitigation The PMO and IM Branch will review the TRA Report and the IM Branch will forward recommendations to stakeholders for mitigation via a TRA Recommendations Summary. DELIVERABLE: TRA Recommendations Summary Owner: Page 11 of 23

12 Recommendations may apply to the client or other key stakeholders outside of OCIO (e.g., Transportation and Works, for issues related to physical security). For recommendations that fall under the responsibility of entities outside of OCIO, the PMO and IM Branch will engage Client Services to communicate the TRA findings and results, but OCIO will not be responsible for the mitigation efforts of stakeholders outside of OCIO. The PMO will oversee all mitigation efforts but completion of mitigation activities is the responsibility of the Project team, who must document all mitigation efforts in a Threat Risk Assessment (TRA) Report Response. If follow-up with other branches is required to ensure completion of mitigation efforts, the Project Manager is responsible for facilitating those discussions and following through on completion of those activities. DELIVERABLE: TRA Report Response Owner: Project Manager Deviations Any TRA recommendation under OCIO control that is not mitigated at the time of Go Live will be documented as a Deviation by the IM Branch. All branches, via their Branch IP Lead will be required to sign off on the Deviations prior to Go Live to indicate approval to proceed, even though these items will not be fully mitigated at that time. The Director of Information Protection, IM Branch, will have final sign off of the Deviations after branch approval is obtained in writing (i.e. Deviations Summary and Sign-Off Report). It is important to note that the Director has the authority to refuse sign off of the Deviations even after branch approval is received, if the Director determines the risk to OCIO is unacceptable. Important: Items that are scheduled for a change window but not yet implemented at the time the Deviations are signed must still be documented as Deviations. Important: There will be only one Deviation Summary and Sign-Off Report per project, which may include Deviations resulting from the TRA and/or VA. DELIVERABLE: Deviation Summary and Sign-Off Report Owner: Close Out TRA Process Close out of the TRA process, as determined by the IM Branch, will occur when the assessment moves from an active phase to a tracking phase. Close out of the formal process takes place when the Director of Information Protection signs off on the final TRA Report. The IM Branch will continue to track the status of TRA mitigation after formal close-out of the process. Budget and Scheduling The time required to complete the TRA process will depend on the scope of the system(s) being assessed in the TRA. A minimum of 45 days should be scheduled from the time the hands-on assessment begins (i.e. on-site vendor visit and interviews with stakeholders) until the draft TRA Report is received by the PMO and IM Branch. Mitigation of items identified in the draft TRA Report that fall under the responsibility of the OCIO would occur parallel to regularly scheduled project activities in the Design and Build phases of the SDLC. Costs associated with a TRA for projects coming through the SDLC are a project responsibility. Costs associated with a TRA completed outside of the SDLC are the responsibility of the branch requesting the TRA. Page 12 of 23

13 Overview: Vulnerability Assessment A VA is a series of processes and procedures used to assess and prioritize security vulnerabilities in a system (i.e. application and/or infrastructure). Conducting a VA assists an organization in determining the state of the environment and the level of exposure to threats. A VA will identify vulnerabilities by evaluating if the system has the proper controls in place as they were designed and meant to be implemented. For an overview diagram of the VA process, see Appendix C. Initiate VA Process When to Engage If the Pre-TRA Checklist indicates that a VA is required, the VA process should be initiated upon receipt of the Risk Assessment Workbook from the IM Branch. How to Engage While the IM Branch makes the initial recommendation to complete a VA via the Pre-TRA Checklist, engagement to proceed with actual VA activities must be made to the PMO, as they are the entity responsible for day to day operational tasks within the TRA and VA processes. To initiate the VA, please contact OCIO-PMO@gov.nl.ca. How to Prepare There are several tasks that must be completed before hands-on VA testing can begin. The PMO is responsible for overseeing these tasks and determining when a system is ready to start the VA. Failure to complete these tasks will delay project timelines moving forward. These tasks include: Task Responsible Accountable Infrastructure Readiness Technical Architect (EAG) *Project Manager Application Readiness *Project Team *Project Manager Freeze on Changes ( Blackout ) *Project Team *Project Manager Statement of Work PMO PMO Purchase Order PMO PMO Vendor on-site access PMO PMO * For systems not coming through the SDLC, the Team Lead /Support Team would be responsible. Important: There will be a freeze on changes (i.e. Blackout ) to the system beginning 5 days prior to the start of the VA. The following documentation must be provided to the vendor prior to starting the VA: Detailed Architecture Design (DAD); Network diagram (Visio); Firewall rules (PMO will provide); User manuals and other system documentation (e.g., technical guides, document handling procedures, policies, processes and procedures, etc ) When the PMO has determined that the system is ready to proceed, the vendor will begin hands-on VA testing. The definition of ready is that the system is ready to go live and no other changes are required. If, for example, features need to be added or items still require configuring, then the system is not ready and the VA cannot begin. For an overview diagram of the VA timeline, see Appendix D. Page 13 of 23

14 Conduct VA Completion of the VA is the responsibility of the independent security vendor hired to do the assessment and contains the following components: 1. Hands-on VA Testing 2. Analysis 3. Draft VA Report 4. Re-test (where applicable) 5. Final VA Report After completion of the hands on portion of the assessment (i.e. that period of time where the vendor is using automated and manual processes to identify vulnerabilities in the system), the vendor will assess, document and prioritize identified vulnerabilities and remediation in the draft VA Report. While the draft VA Report may not be available until three weeks after the start of the VA, the Project team will be advised of all major issues upon completion of testing and can begin remediation once the blackout (freeze on changes) period has been lifted. If the VA is conducted against an existing system, any mitigation would have to take place before the system goes back online or via established Change Management processes at a later time. DELIVERABLE: Vulnerability Assessment Report (DRAFT) Owner: Independent Security Vendor (not OCIO) Mitigation The PMO will review the Draft VA Report and forward the recommendations to the Project team for mitigation. The PMO will oversee all mitigation efforts but completion of mitigation activities is the responsibility of the Project team, who must document all mitigation efforts in the Vulnerability Assessment (VA) Report Response (DOC10406/2008). If follow-up with other branches is required to ensure completion of mitigation efforts, the Project Manager is responsible for facilitating those discussions and following through on completion of those activities. A focused re-test of the specific items identified in the draft VA Report may be required, at the discretion of the PMO. Important: Only changes specific to VA mitigation are allowed after the Blackout has been lifted. Changes not related to the remediation of identified VA items are not allowed. DELIVERABLE: Vulnerability Assessment (VA) Report Response Owner: Project Manager Deviations The IM Branch will review the Vulnerability Assessment (VA) Report Response and document any item that is not mitigated at the time of Go Live as a Deviation in the Deviations Summary and Sign- Off Report. All branches, via their Branch IP Lead will be required to sign off on the Deviations prior to Go Live to indicate approval to proceed. The Director of Information Protection, IM Branch, will have final sign off of the Deviations after approval from the branches and has the authority to refuse sign off of the Deviations even after branch approval is received, if the Director determines the risk is unacceptable to OCIO. Important: Items that are scheduled for a change window, but not yet implemented, at the time the Deviations are signed must still be documented as Deviations. DELIVERABLE: Deviation Summary and Sign-Off Report Owner: Page 14 of 23

15 Close Out VA Process Close out of the VA process, as determined by the IM Branch, will occur when the Director of Information Protection signs off on the final VA Report. The Branch IP Lead for the branch that required the VA will sign off to indicate acceptance of the final VA Report and the Director of Information Protection, IM Branch, will sign off on the final VA Report to indicate completion of the VA process (DOC17943/2009). Once the final VA Report has been signed off by the Director of Information Protection, the VA will go from an active phase to a tracking phase. The IM Branch will track all VA Deviations and their status via the weekly Branch IP Leads meetings. Budget and Scheduling In most cases, projects can estimate the VA testing start date as 4-6 weeks before the anticipated Go Live date. Project Managers should initiate VA discussions with the PMO upon receipt of the Risk Assessment Workbook from the IM Branch, recommending a VA. The time required to complete the VA process will depend on the scope of the system being assessed in the VA. The PMO identifies three types of projects in terms of scheduling: New System Project Enhancement Project Pilot Project Costs associated with a VA completed within projects coming through the SDLC are a project responsibility. Costs associated with a VA completed outside of the SDLC are the responsibility of the branch requesting the VA Page 15 of 23

16 Overview: Risk-Based Decision Document A Risk-Based Decision Document provides a structured approach and decision making process to address information security risks within the OCIO. This process can be used to assess risk when more detailed assessments, such a TRA and VA, are not feasible due to time constraints or other factors. The Risk-Based Decision Document process is the responsibility of the IM Branch. Completion of a Risk-Based Decision Document will allow OCIO to document and justify the rationale for making a decision that may result in an increased level of risk to OCIO. This process, at a high level, documents the following as it relates to the risk: 1. Initial Threat Identification 2. Information Asset Sensitivity (i.e. Information Security Classification) 3. Risk Determination (i.e. Likelihood of Occurrence & Severity of Impact) 4. Recommendations & Controls For an overview of the Risk-Based Decision process, see Appendix E. Initiate Risk-Based Decision Document Process When to Engage A Risk-Based Decision Document may be requested from the IM Branch at any time, if a decision has been made which may result in an increased risk to OCIO. Requests for the Risk-Based Decision Document should be limited to situations where Executive within the Branch determines it necessary to formalize the decision-making process by documenting and justifying their rationale for making that decision. How to Engage A Risk-based Decision Document can be requested by any branch via the Branch IP Leads. Leads should formally submit requests (via ) to the. Only requests from the Leads will be accepted by the IM Branch. How to Prepare The Branch submitting the request will be required to identify a Prime Contact that will liaise with the IM Branch to facilitate completion of the Risk-Based Decision Document. The Prime will be expected to provide background, context and documentation about the risk being assessed and documented. Complete Risk-Based Decision Document Completion of the Risk-Based Decision Document deliverable is the responsibility of the IM Branch. However, most content within the document will be provided by the Prime Contact. Other subject matter experts may have to be consulted, as required (i.e., Enterprise Architecture Group, vendor, client, etc ). Important: This process will not be used to make a decision for a Branch it will only be completed to document the justification and rationale of a decision that has already been made by the requesting branch. Acceptance of Recommendations and Risk required by: Director (requesting branch) Director (any branch impacted by the recommendations and/or risk) Director of Information Protection Page 16 of 23

17 Approval of Risk-Based Decision Document required by: Executive Director (requesting branch) Executive Director (any branch impacted by the recommendations and/or risk) Executive Director (IM Branch) DELIVERABLE: Risk-Based Decision Document Owner: Information Management Branch (IP Division) Close Out Risk Based Decision Document Process Close out will occur when Executive Director approvals and signatures have been obtained and the document is filed in TRIM. Recommendations will be tracked by the IM Branch via the Branch IP Leads meetings. Budget and Scheduling As completion of a Risk-Based Decision Document is an internal process, there is no immediate cost associated with its completion. However, branches may have to adjust resource costs to ensure participation in required in assessment activities and discussions. In most cases, projects can expect to schedule 2 weeks from the time a request is initiated until the Risk-Based Decision Document is completed. Larger, more complex risk scenarios may have to allow for additional time. Risk Scenarios requiring immediate attention may be escalated, where required. Page 17 of 23

18 Appendix A: Lead Model Page 18 of 23

19 Appendix B: TRA Process Page 19 of 23

20 Appendix C: VA Process Page 20 of 23

21 Appendix D: VA Timeline Page 21 of 23

22 Appendix E: Risk-Based Decision Process Page 22 of 23

23 Appendix F: Functional Architecture (FA2) Page 23 of 23