May 2013 Issue No: 0.2. Good Practice Guide No. 1 Managing Security Risks In Government IT Projects

Transcription

1 May 2013 Issue No: 0.2 Good Practice Guide No. 1 Managing Security Risks In Government IT Projects

2 Document History Version Date Author Description May 2013 Peter Kahiigi CISM, CISSP Initial Draft June 2013 Peter Kahiigi CISM, CISSP Scope & Coverage Please send queries to: Directorate for Information Security, National Information Technology Authority, Uganda (NITA-U), Palm Courts, Plot 7A Rotary Avenue, P.O Box 33151, Kampala, Uganda Tel: Fax:

3 1 Executive Summary 1.1 Overview This guide identifies the main steps that parties involved in the delivery of Government of Uganda IT projects must take to develop information systems that could obtain and maintain accreditation in accordance with the National Information Security Framework (NISF). The document complements the National IT Project Management Methodology because Accreditation for Information Assurance (AIA) continues throughout the lifecycle of an information system. The guide is not prescriptive due to the recognition that IT usage, threats, vulnerabilities and risk appetite vary across and within organisations. 1.2 Coverage The Internet Engineering Task Force (IETF) defines accreditation as an administrative action by which a designated authority declares that an information system has approval to operate in a particular security configuration with a prescribed set of safeguards. This guide explains the steps taken to enable the accreditation of an information system in accordance with the NISF. At the very least, risk management in IT projects shall comply with the mandatory security requirements in the four NISF policy areas i.e. governance, information, personnel and physical security. However, depending on local business needs, risks, environment and risk appetite, the MDA may have to apply more stringent security controls. The accounting officer has a duty to cause the creation of a record explaining the choice of security countermeasures and their adequacy in enabling the effective, safe and secure delivery of the public services under their control. Since the NISF draws upon the ISO/IEC Series of international security standards, the evidence gathered to show compliance would support ISO/IEC compliance. In addition, ISO/IEC compliance itself supports ISO/IEC certification. 1.3 Target Audience This Good Practice Guide would benefit all parties that must comply with the National IT Project Management Methodology. However, it is of particular relevance to Accounting Officers. The Public Finance and Accountability Act 2003 requires the accounting officer to ensure that effective systems of internal control and internal audit are in place in respect of all transactions and resources under their control. Internal control means a set of systems to ensure that financial and other records are reliable and complete. AIA is an internal control activity because it helps provide reasonable assurance that information systems would work reliably under the control of legitimate users. Therefore, this guide aims to assist the accounting officer in identifying the main steps they have to take to improve AIA. This document also applies to parties with delegated responsibility for risk management and accreditation at all levels. The parties include project managers, security managers, accreditors, auditors, IT consultants, third party service providers and delivery partners. Lastly, this guide applies to the wider public sector including local government as well as operators and owners of critical national infrastructure systems.

4 Table of Contents 1 Executive Summary Overview Coverage Target Audience Accreditation for Information Assurance (AIA) Overview Enterprise Level IA System Accreditation AIA: Business Process AIA and IT Project Management Methodology Project Initiation Accreditation Scope Initial Risk Assessment Accreditation Plan Project Security Team Accreditation Panel Security Working Groups Planning IA in Tendering Process Execution Risk Management Documents Accreditation Decision Accreditation Decision Types Monitoring and Controlling Operational Security Re-Accreditation Closure Decommissioning Secure Sanitisation... 12

5 2 Accreditation for Information Assurance (AIA) 2.1 Overview As noted earlier, the IETF defines accreditation as an administrative action by which a designated authority declares that an information system has approval to operate in a particular security configuration with a prescribed set of safeguards. Similarly, the United States Committee on National Security Systems (CNSS) defines accreditation as a formal declaration by a designated authority granting an information system approval to operate at acceptable level of risk. The authority bases this decision on evidence of the implementation of an approved set of technical, managerial and procedural safeguards. 2.2 Enterprise Level IA The Security Governance Policy under the NISF outlines the Accounting Officer s duty to Parliament to protect all resources received, held or disposed of, by or on account of their respective Ministry, department, fund, agency, local government or other entity. The resources include people, information, infrastructure, facilities and services. Accreditation helps the accounting officer in meeting this obligation. However, accreditation is not an end unto itself. Instead, accreditation is a means for providing information assurance. On top of the mandatory structures, the NISF requires the accounting officer to determine the most appropriate IA structures to enable the organisation to meet its security goals. 2.3 System Accreditation This guide focuses on system-level accreditation. ISO/IEC states that system acceptance often involves a formal certification and accreditation process to verify that the IT project has met security requirements. IA is confidence gained from accreditation. Therefore, accreditation is the process for achieving the IA objective. The NISF requires that all IT systems processing classified GoU information must pass the AIA process before gaining Approval to Operate. In addition to determining, creating and funding the enterprise-level IA structures, the accounting official should finance AIA adequately AIA: Business Process AIA must necessarily be a business process. This means that it is up to the accounting officer to satisfy himself or herself that the security countermeasures and the mitigations are robust enough to manage the risks without unnecessarily encumbering business. It is for this reason that the accreditation process gathers comprehensive evidence to help the accounting officer and their representatives to make informed decisions on whether the AIA process has succeeded in reducing technical risks to acceptable levels. May 2013 Issue No: 0.1

6 3 AIA and IT Project Management Methodology Accounting officers shall require the management officials with delegated responsibility for risk management to provide evidence that they have addressed AIA issues in all phases of the National IT Project Management Methodology. AIA should have its own milestones running in sync with the normal project plan. Failure to identify and address AIA requirements sufficiently early in the lifecycle could have devastating impacts on milestones, scope and cost. Accounting officers have an obvious motivation to avoid IT project cost overruns and failure to deliver value for money because they have personal accountability for the propriety of the expenditure of money under their control. Next, the guide proffers good practices for handling AIA activities across the Project Methodology. 4 Project Initiation This phase involves the formal initiation, justification and authorisation of the project or programme according to the National IT Project Management Methodology. It is a good practice to issue an accreditation strategy to outline the approach for handling AIA issues across in accordance with the NISF. The strategy helps ensure the project consider AIA issues from the outset. The key success factors at this stage include: Effective collaboration between the MDA, service provider, Accreditor, risk managers and other relevant stakeholders to ensure that accreditation decisions occur on time in support of project milestones; A senior official owning the AIA schedule to ensure accreditation milestones are met; AIA teams working with IT technical designers to ensure the timely escalation and consideration of changes that affect accreditation milestones and requirements; AIA teams participation in technical design reviews to enable timely identification, escalation and resolution of potential security issues; Accreditor sign-off of requirements; and Consistent collection of accreditation evidence to reduce bottlenecks in latter phases 4.1 Accreditation Scope The activity involves the definition of the areas that the formal assessment will cover. Setting an accreditation scope distinguishes information resources that have to undergo a formal assessment from related or interconnected assets. Thereafter, an accreditation plan presents the scope in terms of activities and products required to gain and maintain accreditation throughout the lifecycle of the information system. The scope covers the IT systems, data, people and other resources within a given domain. The resources include all system environments that would enable the development, installation and operation of the information system throughout its lifecycle. Additionally, the scope should identify the locations and systems that delivery partners use to support the main system or domain. The accreditation scope also identifies applications and services. The scope also names external domains i.e. systems, people and data outside the accreditation scope. May 2013 Issue No: 0.1

7 4.2 Initial Risk Assessment The Security Governance Policy defines an enterprise-level approach to risk. This guide recommends that senior risk managers ensure that IT projects follow the enterprise-level approach to risk. The Risk management process involves: Identification of risks that assets are facing or is likely to face; The selection of controls to mitigate the risks identified in the risk assessment view; Formalisation of the risks identified during the risk assessment view; Management s acceptance of the controls identified; The acceptance of residual risk; and The preparation of a Risk Treatment Plan The NISF policies and standards describe risk management approaches in more detail. 4.3 Accreditation Plan This guide recommends that IT projects draft an Accreditation Plan as soon as possible. The Plan aims to provide the project sponsor and other relevant parties information on how the service provider will manage accreditation activities throughout the lifecycle of the information system. An Accreditation Plan provides the designated authority details of the activities that will occur at different accreditation milestones. Since accreditation is fact-based, the Plan defines the evidence produced at various milestones to enable the Accreditor to judge whether the measures mitigate identified security risks sufficiently. 4.4 Project Security Team The Security Governance Policy NISF defines the mandatory roles required to manage security effectively. This guide set out to avoid the temptation to prescribe security roles, responsibilities and structures, because IT projects differ by objective, size, processes and structure. Therefore, MDAs should structure security teams according to their needs. In general, large or complex IT projects require a dedicated security team throughout the life of the project. The team helps implement and interpret the decision of the Accreditor or Accreditation Panel. The project security team works with the teams responsible for produce technical, policy and procedural documents. Moreover, the team helps review and/or supervise other stakeholders testing specific security technologies and standards. MDAs should ensure that only suitably qualified staff serve on such a team. 4.5 Accreditation Panel In many cases, a single organisation owns the information system, the data it processes and its entire infrastructure. The information owner is right to appoint a single Accreditor under such circumstances. However, the number of systems crossing inter-departmental boundaries is on the rise. Indeed, an increasing number of information systems exist primarily to process information and interconnect services of two or more MDAs. Interdepartmental systems habitually depend on an Accreditation Panel rather than a single Accreditor due to their many information owners. It is the job of stakeholder Accreditors to represent the views of their information owners. MDAs should recognise that whilst the

8 Panels are good idea in theory, they might suffer dysfunction without strong leadership. Therefore, the Accreditor of the sponsoring department should ideally become the Lead Accreditor of the Panel to help maintain focus on achieving the business benefits of the system. The sponsoring department s senior business representative may also join the Panel to expedite the resolution of conflicts between business benefits, cost and risk. 4.6 Security Working Groups IT projects should constitute any number of groups or committees to support the AIA process. Again, this document does not prescribe the number or format that such groups or committees might take. Factors such as the number of participants, size, complexity, resources and preference would influence the choices organisations make in this area. However, security working groups typically: Bring together all security representatives on an IT project; Serve as fora for directing, managing and accreditation process matters; Have clear and jointly agreed Terms of Reference; Identify and agree AIA requirements; Ensure that all stakeholders adhere to the agreed AIA requirements; Meet at regular intervals, for example monthly; Must be able to convene on an ad-hoc basis to resolve urgent issues; May constitute sub-groups to address specific issues whenever required; Highlight inadequate controls to business and programme leadership; and Serve as a bridge between the Accreditor/Accreditation Panel and delivery teams on information security matters NITA-U will produce guidelines on groups and share them on a Need-to-Know basis. 5 Planning The project team develops a detailed project management plan at this stage under the National IT Project Management Methodology. This phase should address AIA because the failure to address AIA issues during planning could lead to delays and threaten the delivery of the project. The following are important AIA considerations under this phase: 5.1 IA in Tendering Process Information assurance often becomes a critical path issue in government IT contracting because sponsoring organisations often sign-up suppliers before they bottom out all AIA issues and thus be in a position to let the contract. This guide believes considering the issues below could help an IT project start from a firm IA foundation. Security specialists such as Accreditor should define the IA requirements in planning documents such as Expressions of Interest (EOI) and Invitation to Tender (ITT); Make IA a vital criteria in judging supplier responses to EOIs and related documents;

9 The IA team should be essential reviewers of supplier responses to documents such as EOI or ITT to ensure that the answers comply with NISF requirements; The contract should contain an independent IA focused schedule; and Contract should identify the through-life costs for maintaining accreditation. 6 Execution This phase is about implementing the plans defined in the project management plan according to the National IT Project Management Methodology. From an IA perspective, this phase deals with gathering evidence to help build confidence that the system meets IA requirements and could gain accreditation. Some of the crucial issues to note include: 6.1 Risk Management Documents At this stage, the IA team should have compiled a comprehensive and cohesive set of documents to help the Accreditor and information owners gain confidence around the adequacy of the risk management processes. Whilst the documents and the information therein may differ according to requirements, this guide recommends that the set: Should list all the procedures, processes, instructions and plans generated to help maintain the security of the information system throughout its life; Identifies the enterprise-level IA policies that the system has to comply with; Describes the security governance regime with roles and their relationships; Outlines the IA requirements that the information system has to meet; Provides evidence of compliance with the identified IA requirements; Describes the impact of compromising different information assets within the system; Presents a detailed list threats and risks to the system; Contains a risk treatment plan and options for mitigating identified risks The NISF offers more information about the risk management process and documents. 6.2 Accreditation Decision The designated Accreditor awards ATO only after gaining reasonable assurance that the chosen security controls adequately mitigate the risks and comply with relevant NISF policies and standards. As the NISF explains, the Accreditor will form their view following the review of documented evidence such as: Draft risk management documents e.g. policies, procedures, processes; Final copies of risk management documents; Advice of technical experts on the adequacy of the security designs; Scope of IT Health Check (ITHC) or Penetration Testing exercises; ITHC results, rework or retest as appropriate

10 The Accreditor may also conduct or cause the performance of inspections of facilities such as data centres to validate the implementation of the security countermeasures Accreditation Decision Types Based on the review of evidence and inspections, the Accreditor may make one of the following decisions: Grant Full Accreditation A system gains full accreditation if the Accreditor is satisfied that the security controls and relevant mitigations operate as described in the risk management documents; Grant Partial Accreditation This decision arises when the Accreditor is largely happy with the implementation but unsure about the effectiveness of given controls; Interim Accreditation Especially for new information systems, the Accreditor may grant Accreditor for a specified period, say six months, to confirm whether the control operate as described. For example, the Accreditor may want to see how backup arrangements and processes work in practice. The interim accreditation allows the service provider to remedy the issues whilst the system delivers business benefits; Denial of Accreditation The Accreditor may decide to deny the system Authority to Operate. However, denial of accreditation is a very rare occurrence because there is always a way to accredit a system if the information owners have the will to do so. Withdraw of Accreditation This occurs when the security operations of a previously accredited system substantially diverge from the approved risk management documents. For example, this could after a major cyber attack. The Accreditor may re-accredit the system on evidence of the mitigation of the substantial divergence from described processes. The Accreditor does not have the final word. Thus, on many occasions, accreditation occurs with exceptions in consultation with the risk owners, where the business benefits outweigh the impact of the materialisation of risk and the cost of eliminating the risk fully.

11 7 Monitoring and Controlling This phase involves the tracking, reviewing, monitoring and measuring to validate whether the IT project meets the performance objectives of the project management plan according to the National IT Project Management Methodology. From an IA perspective, this phase is about ensuring that the security operations and the management of a live system comply with agreed security requirements. The following are important activities. 7.1 Operational Security Operational security involves activities to protect information whilst it is resident on electronic media and in transit on communication links. Operational security seeks to enable the main IA goal that is ensuring that the systems protect the information that they handle and operate reliably when required under control of legitimate users. A major activity under operational security is the definition of Security Operating Procedures (SyOPs). The process involves tying security responsibilities to individual roles and thus enables the implementation of effective controls. Incident response is another major activity under operational security, which deals with how to prevent, detect and respond to security incidents. The NISF discuss operational security in more detail. 7.2 Re-Accreditation Accreditation only applies for a given period say a year or six months. Therefore, the IA team has to re-submit at the end of this period for the Accreditor s consideration. In addition, it is good practice for the information owners to seek to re-accredit the system if the following, non-exhaustive, list of conditions apply A major change to the IT architecture e.g. major operating system upgrade; A major security incident; The use of the information system beyond its accredited scope; A large number of users than anticipated by countermeasures; and A large volume and/or different type of data than originally anticipated It is the job of the information owners to determine when to request re-accreditation and name the applicable conditions. Changes in conditions may also lead the information owner and Accreditor to institute a more regular accreditation cycle.

12 8 Closure This phase involves the activities to end the project according to the national IT Project Management Methodology. From an IA viewpoint, the closure phase coincides with the decommissioning, disposal and/or transfer of information system assets. 8.1 Decommissioning MDAs should define the processes and standards for the secure decommissioning of information system assets in line with the NISF. The processes should aim to help the MDA and its delivery partners manage the security risks associated with the disposal and re-use of computer storage media holding classified or sensitive GoU information. 8.2 Secure Sanitisation Sanitisation is the general process of removing data from storage media securely. The process aims to offer reasonable assurance that unauthorised parties would not retrieve or reconstruct the erased data using keyboard or laboratory attacks. Sanitisation covers disposal, clearing, purging and destroying. This guide recommends that MDAs draw on the NISF to define comprehensive departmental procedures to help ensure that asset decommissioning proceeds in a timely and cost effective manner. The assets include: Networking Devices; Magnetic Disks and Tapes; Office Equipment; Solid State Devices (SSDs); and Optical Disks The MDAs should also review the mandatory sanitisation levels with the NISF. The levels define the degree of wiping required to provide reasonable assurance against the retrieval or reconstruction of data from a decommissioned asset. The sanitisation level relates to the classification of the asset and/or information therein.