Security Patching in Complex Environments v1 · 2016. 8. 23. · 6hfxulw\ 3dwfklqj lq &rpsoh[ (qylurqphqwv $ 3udfwlfdo *xlgh wr 3rolf\ dqg 3urfhvv 'hvljq iru 3dwfklqj $ssolfdwlrqv

$Page 1: Security Patching in Complex Environments v1 · 2016. 8. 23. · 6hfxulw\ 3dwfklqj lq &rpsoh[ (qylurqphqwv $ 3udfwlfdo *xlgh wr 3rolf\ dqg 3urfhvv 'hvljq iru 3dwfklqj $ssolfdwlrqv$
Security Patching in Complex Environments A Practical Guide to Policy and Process Design for Patching Applications and Operating Systems in the Context of Australian Signals Directorate Top 4 Guidance

Rishi Nicolai Senior Service Management Consultant, Microsoft Australia Jimmy Fitzsimmons Senior Premier Field Engineer, Microsoft Australia

Contributors and Reviewers Brian Farnhill Senior Premier Field Engineer, Microsoft Chris Tuite Support Practice Manager, Microsoft Clinton Temple Principal Service Delivery Manager, Microsoft David Cottingham Security Consultant, Foresight Consulting David Jansen Senior Premier Field Engineer, Microsoft Glen Wareing Senior Enterprise Architect, Microsoft Grant Holliday Senior Service Engineer, Microsoft James Kavanagh National Security Officer, Microsoft Jason Waddell Senior Technical Account Manager, Microsoft Joseph Marino Service Management Consultant, Microsoft Joy Hines Service Management Consultant, Microsoft Marc Dudok Senior Premier Field Engineer, Microsoft Martin Morrison CSS Manager, Microsoft Neil Ladbrook Senior Service Delivery Manager, Microsoft Nick Eichner Senior Consultant, Microsoft Regina Jagiello Associate Delivery Project Manager, Microsoft Ronel Vosloo Senior Service Management Consultant, Microsoft Russell Stevens Senior Premier Mission Critical Engineer, Microsoft Scott Deacon Security Architect, WW Public Sector, Microsoft Yen Chiu Chin Premier Field Engineer, Microsoft Ziggy Nemeth Senior Consultant, Microsoft Disclaimer: This document has been prepared by Microsoft to provide an overarching framework to assist the implementation of security patch management capability within complex environments. This document is provided on an “as is” basis and to the maximum extent permitted by law Microsoft disclaims all conditions, warranties and guarantees, express or implied, including but not limited to any warranty or guarantee that the use of the framework set out in this document will not infringe any rights or any warranty or guarantee of merchantability or fitness for a particular purpose. The document is intended to be used as a guide to create a security patching approach for your organisation. The process flow and document outlines specified in the document should be used as an example only. Before using components set out in this document, you should evaluate its suitability for your organisation. In particular, if you choose to act upon the recommendations of the approach, then you do so at your own risk. Apart from any use permitted under the Copyright Act 1968, and the rights explicitly granted above, all rights are reserved.

Contents Executive Summary ................................................................................................................................. 1 Introduction ............................................................................................................................................ 2

Purpose of the Guide .......................................................................................................................... 2 Audience ............................................................................................................................................. 2 Patching and the Australian Information Security Manual ................................................................ 3 Security Vulnerability .......................................................................................................................... 3

Security Patching and the ISM ................................................................................................................ 5 ISM Patching Controls ......................................................................................................................... 5 ISM Compliance and Reporting .......................................................................................................... 7

Enterprise Patch Management Approach .............................................................................................. 9 Step 1: Baseline current capability ................................................................................................... 11 Step 2: Develop a Security Patch Management Policy ..................................................................... 13 Step 3: Develop a Security Patch Management Process .................................................................. 14 Step 4: Develop a Capability Implementation Plan .......................................................................... 17 Step 5: Configure the Technology ..................................................................................................... 18 Step 6: Implement Process and Measure Process Performance ...................................................... 19 Step 7: Conduct Post-Implementation Review ................................................................................. 19

Developing a Security Culture ............................................................................................................... 20 Embedding the Security Patch Management Capability .................................................................. 20

Security Patch Management Detailed Step-Guidance .......................................................................... 22 1. Assess ............................................................................................................................................ 22 2. Identify .......................................................................................................................................... 26 3. Evaluate & Plan ............................................................................................................................. 29 4. Deploy ........................................................................................................................................... 33 A.1 Report ......................................................................................................................................... 36 A.2 Process Compliance Assessment ................................................................................................ 37

Common Implementation Challenges .................................................................................................. 38 Supportive IT Security Policies Covering Security Patching .............................................................. 38 Security Patch Management Capability Implementation Plan ......................................................... 38 A Risk-Based Approach to Security Patching .................................................................................... 39 Deployment Timeframes for Patches ............................................................................................... 39 Streamline the Patching Process ...................................................................................................... 41

Minimising Impact Downtime for Business-Critical Applications ..................................................... 42 References ............................................................................................................................................ 43 Glossary ................................................................................................................................................. 45 Appendix I – Assessing System Risk ...................................................................................................... 46

Step 1 - Calculating Maximum Business Impact (MBI) ..................................................................... 47 Step 2 - Calculate Exploit Likelihood (EL) .......................................................................................... 47 Step 3 - Calculate Risk ....................................................................................................................... 48 Step 4 – Consider mitigating factors ................................................................................................. 48

Appendix II – Security Patch Management Process Document Outline ............................................... 49 Appendix III – Capability Implementation Plan Document Outline ...................................................... 50 Appendix IV – Security Patch Management Deferral Notice Document Outline ................................. 51 Appendix V – Security Patch Management Plan Document Outline .................................................... 52

1

Executive Summary Patching of security vulnerabilities is the single most important activity any organisation can undertake to secure their information systems. It is essential to providing a foundation on which other security controls can be overlaid. This is reflected by Australian Signals Directorate guidance that specifically calls out patching of operating systems and applications as two of the Top 4 mitigations against cyber intrusion. Yet patching of systems within enterprise environments is often perceived as a complex challenge fraught with cultural, procedural and technical issues. Many organisations find it difficult to effectively prioritise and plan for deployment of patches within a consistent risk management framework. Others face significant challenges in consistently complying with policies for the deployment of patches within specified timeframes. During 2014, Microsoft worked with some of the largest organisations in Australian government and enterprises to navigate these challenges and develop a pragmatic, realistic approach to improving patch management practices in complex environments. By mapping and optimising processes, identifying the root causes of issues, trialling different strategies and establishing performance metric-driven approaches, these organisations have made remarkable progress. As an illustration, one large organisation with more than 10,000 staff, now achieve deployment of priority patches to 90% of workstations within 48 hours – an improvement in timing of more than 3 months. These improvements have a very real impact on the security posture of organisations that are increasingly under threat from online risks. Here are some essential stages to the strategy:

Baseline definition of the current environment to understand the current state of policy, process and technology relating to the patching of vulnerabilities

Developing a patching policy and process that reflects the needs and complexities of the organisation using an optimisation approach to remove delays and streamline decision making

Developing and executing an improvement plan that leverages tools, technologies and process changes to drive improvement followed by monitoring progress on improving the patching process, optimising and extending the implementation across all parts of the organisation

The approach outlined in this paper has now been proven and refined in a number of organisations who are gaining significant benefits in terms of reduced risk exposure and improved compliance. Perhaps of even more value, by significantly streamlining processes and resources, those organisations have been able to prioritise their efforts on high value activities and greater innovation.

James Kavanagh National Security Officer, Australia.

2 © Microsoft Corporation. All rights reserved.

Introduction Purpose of the Guide The purpose of this document is to share an approach that Microsoft has developed to address patch management in complex government environments. The approach, which can also be considered a high-level strategy, is described within the context of the Australian Government information security requirements, but parts may be leveraged by any enterprise or government organisation. Effective patch management is a fundamental element of a sound information security management strategy. However, it is also recognised as being complex and fraught with organisational and technical challenges. This guide aims to navigate these challenges, tackling the realities of patch management in a complex, and technologically heterogeneous environment. It was developed directly as a result of experiences with large Australian government organisations who faced the complexity of patch management and have successfully achieved significant improvements. The principal goals of the guide are to: • Outline the core objectives for effective

patch management, particularly in the context of the Information Security Manual (ISM)1.

• Describe an approach for both determining a baseline for current practice, and also establishing a policy and

1 At the time of writing this document, the 2014 publication of the Information Security

plan for addressing security patch management.

• Provide guidance on building an optimised patch management process that reflects the real complexity of enterprise environments.

• Provide templates, guidance and resources that can assist with such areas as risk assessment and exception handling.

Audience The target audience for this document includes, but are not limited to: • Information Technology Security Advisors

(ITSA) and Agency Security Advisors (ASA) • Chief Information Security Officer (CISO) • Information Technology Security Manager

(ITSM) • Various business and technical service

owners as well as other roles responsible for performing security patching related activities within Australian Government agencies.

The Australian Signals Directorate (ASD) is the Australian Governments ICT security authority, and the guidance specified in the ISM is mandated across the Australian Federal Government. This document may also be used as a guide for other government agencies as well as private enterprises to improve their security patch management capability and maturity.

Manual is the most current publication released by the Australian Signals Directorate.


The document assumes some prior knowledge of the ISM controls relating the security patch management as well practitioner level knowledge of the ITIL® framework. Sections of the document also require practitioner level knowledge of risk management with a focus on ISO 31000:2009. Patching and the Australian Information Security Manual The Australian Signals Directorate (ASD) have developed a set of policies to safeguard the Australian Federal Government’s ICT assets from the threat of cyber-attack. These policies are published in a public suite of documents known as the Information Security Manual (ISM). The ISM details the principals and policy controls necessary to assist Australian federal government agencies to secure their ICT systems. Complementing the ISM is the ASD Top 35 Strategies to Mitigate Targeted Cyber Intrusions – a set of controls considered to be the most effective against a determined adversary attempting to penetrate and persist on a government network. The ASD estimate that implementing just the Top 4 Strategies to Mitigate Targeted Cyber Intrusions of these 35 controls would mitigate at least 85% of the intrusion attempts that the Australian Cyber Security Operations Centre observe (Australian Signals Directorate, 2013). Patch applications and patch operating system vulnerabilities are number 2 and number 3 respectively on the list of mandatory Top 4 controls. The ISM describes several controls that relate to the deployment of software security updates. Many technology vendors have developed security patch deployment tools and technical guides, however without the right approach, meeting some of the ISM compliance requirements can be challenging. The predominant focus of this guide is on the

management and process considerations around patching. Security Vulnerability Vulnerability is the intersection of three distinct elements: a system susceptibility or flaw, an attacker’s access to the flaw and an attacker’s capability to exploit the flaw (U.S. Department of Defense, 2009). To exploit a vulnerability, an attacker must identify and use the appropriate tools and techniques to exploit a systems weakness, which forms its attack surface. The Microsoft Security Response Centre (MSRC) uses the term in the following context: “A vulnerability is a security exposure that results from a product weakness that the product developer did not intend to introduce and should be fixed once discovered” (Microsoft, n.d.). Software vulnerability disclosure can come from a variety of sources, including publishers of the affected software, security software vendors, independent security researches and even malware creators. (Batchelder, et al., 2013). The United States Government publishes security vulnerability disclosures in the National Vulnerability Database (NVD). The diagram below shows how many security vulnerabilities were recognised by the NVD, industry-wide, between 2011 and 2013.


Figure 1: Industry wide vulnerability disclosure, 1H11-2H13 Out of all exploited vulnerabilities, zero day vulnerabilities pose the greatest potential risk as they are exploited in the wild before the software vendor is able to release a security patch to address the vulnerability. Typically, when zero day vulnerabilities emerge, the initial focus for organisations is

on compensating mitigations in lieu of an available update to the vulnerable software. In a zero-day scenario, the asset owner does not have the ability to deploy a security update, and must apply other potentially complex mitigating controls. Once a patch is released for a zero-day vulnerability, the priority typically becomes deploying the patch as rapidly as possible to eliminate the vulnerability.


Security Patching and the ISM ISM Patching Controls A number of controls within the ISM encourage a risk-based conversation within government agency’s IT environment about the impact of security patching, instead of simply patching as a mechanical exercise. The intent behind these controls is to promote a security risk-based culture where operational staff, management and executives are all making and supporting risk-based decisions. This will assist in protecting the confidentiality, integrity and availability of business services and agency’s ability to implement the policies of the government. Typically, Commercial off the Shelf (COTS) software product vendors address security vulnerabilities identified in their products by issuing security patches. Vendors do not generally issue updates for software outside of the product support lifecycle. Ongoing use of unmaintained software poses a risk to the security of the environment. This risk needs to be managed. The Information Security Manual (ISM Control 0304) indicates that a security risk assessment is to be carried out against software or ICT equipment that is no longer supported by the vendor, so that the risk of ongoing use is understood. Where security patches are not available, ISM Control 0941 indicates that the risk must be managed (recommendations are detailed in the control). To minimise the risk of an extended window of vulnerability, ISM Control 0297 suggests that all relevant sources for patch release information should be monitored. Step guidance provided further in the document suggests some tips on how patch release information should be monitored. It is important that authoritative sources of

vulnerability information and software updates are known and that these channels of communication are reliable. ‘Extreme Risk’ Vulnerabilities ASD recommends that a number of factors be considered when conducting a risk assessment for system vulnerabilities, including the value and exposure of assets or their history of being attacked or impacted. The following are examples of an ‘Extreme Risk’: • The vulnerability allows remote code

execution. • Critical business systems/information

affected. • Exploits exist and are in use. • System is Internet connected with no

mitigating controls in place (Australian Signals Directorate, 2013).

Based on ISM Control 1144, all extreme risk patches must be deployed within 2-days. Patching Timeframes The ISM contains several controls that focus on mitigating the adverse impact caused by the exploitation of vulnerabilities. The intent of the ISM controls are to assist agencies to strengthen their security basics. Timing is essential when mitigating vulnerabilities that attackers are actively seeking to exploit. Closing the window of vulnerability is one of the most effective ways agencies can safeguard their environments against attackers. ISM control 1144 requires all “extreme risk” patches be deployed within 2-days of release or an appropriate mitigation be put in place to address the risk. Determining which patches pose an extreme


level of risk to the business of the agency is critical to the security of the service. The Microsoft Security Intelligence Report (Vol. 15) has published data on the timing of a remote code execution vulnerabilities first detected exploitation, relative to the release of a software update to address the vulnerability. This data shows a distinct downward trend in exploited remote code execution vulnerabilities over recent years. However, of particular interest is the increasing proportion of vulnerabilities that are already publicly exploited before any software update is available to address the vulnerability. This proportional rise in zero-day vulnerabilities suggests that the timeliness of software update deployment is a critical factor in its effectiveness to improve security.

Figure 2: Microsoft remote code execution CVEs, 2006-2013, by timing of first known exploit Deployment of software updates which address ‘extreme’ risk vulnerabilities is a high priority activity, providing an effective mitigation to serious security risks. Deployment of security updates which do not address extreme risk vulnerabilities is still an important activity, as there is still a risk that the exploit could have impact on the business. ISM control 0940 requires that “agencies must apply all security patches as soon as possible”. Commonly new products not only add new features, but also address a number of security flaws with the security foundations of

the product, bringing security features which cannot be implemented by issuing security updates. ISM Controls 1348 and 1349 thus require agencies to deploy new versions of products as soon as they are released, with products addressing ‘Extreme risks’ deployed with the 2-day timeframe. Devices and firmware are exposed to the same risk as computer operating systems and applications, therefore any known vulnerabilities need to be addressed to prevent their compromise. The recommended ISM Controls 1350 and 1351 focus on the patching of drivers and device firmware and suggests that agencies should mitigate ‘Extreme Risk’ vulnerabilities within 2 days.


ISM Compliance and Reporting The PSPF Mandatory Requirement GOV-7 requires agencies to “undertake an annual security assessment against the mandatory requirements detailed within the PSPF, and report their compliance with the mandatory requirements to the relevant portfolio Minister”. ASD’s Top 4 Strategies to Mitigate Targeted Cyber Intrusions, including all the security patch management controls, are required by the PSPF, under mandatory requirement INFOSEC 4. It requires agencies to capture their compliance to the Top 4, including patching applications and operating systems, reporting to the relevant portfolio Minister(s), the Secretary of the Attorney-General’s Department and the Auditor-General of ANAO, accompanied by rationale for non-compliance. Documentation Obligations Documenting key progress, decisions and interactions in an operational environment is a part of good operational practices. The ISM has also dedicated a number of controls requiring that government agencies use a security patch management approach that is planned and structured. The final step is the documentation of the method into a number of artefacts including Patch Management Strategy (ISM Control 1143) which is addressed by having a comprehensive Security Patch Management Capability Improvement Plan and Security patch management process and procedures (ISM Control 0303). Compliance Checking The Auditor-General is responsible, under the Auditor-General Act 1997, for providing auditing services to Parliament and public sector entities and is supported by the Australian National Audit Office (ANAO) in

those duties (Australian National Audit Office, n.d.). ANAO performs regular audits of government agencies against the ISM Top 4 strategies, including all the ISM controls referring to patch management. ANAO also publishes findings and provides recommendations on how the agencies can improve their security posture and achieve improved compliance with the defined controls. Documented Non-Compliance The ISM acknowledges that it is not always possible for all agencies to follow all the defined patch management related controls, given unique business situations, technology compatibility issues, or even occasional resourcing issues. There are a number of controls that provide guidance on ‘documented non-compliance’ and what the ISM requires to be recorded in such situations. ISM Control 0001 identifies the authority for controls – “For any control where the authority field is 'ASD', system owners must seek and be granted approval for non-compliance from the Director ASD in consultation with their accreditation authority”. All other controls typically require the agency’s Accreditation Authority (AA) to oversee compliance and grant non-compliance (ISM Control 1061). In certain circumstances, it is not possible to deploy patches as per the controls specified in the ISM and as a result, risks within the agency’s environment may be un-mitigated. To assist with understanding the reasons behind the situation to the various response teams within the agency, it is important to document non-compliance. ASD mandates a requirement for agencies to provide reports of non-compliance to ASD


(ISM Control 0713). The purpose of notifying authorities to grant non-compliance is: • To assist capturing an accurate picture of

the state of information security across government

• To help inform incident response • To use as feedback for the ongoing

refinement of the ISM. Documentation is submitted as required by ISM Control 0710 to the Accreditation Authority to declare non-compliance. These submissions include: • A justification for non-compliance • A security risk assessment • The alternative mitigations to be

implemented.

As the justification for non-compliance may change, the risk environment will continue to evolve over time. It is thus important that the System Owner update their approval for non-compliance at least every two years. This allows the appropriate authority to have any decision to grant non-compliance either reaffirmed or rejected if the justification or residual security risk is no longer acceptable (ISM Control 0876).


Enterprise Patch Management ApproachMicrosoft has developed an approach to implement a security patch management capability within both the private and government sectors. The approach is delivered with the following 3 phases:

Where are we now? Where do we want to be?

How do we get there? 1. Develop a baseline of current patch capability

2. Develop a security patch management policy & process

3. Implement and review a patch management improvement program

Figure 3: Approach Phases The phases focus on understand the agency’s current state and contrasting that against the desired state required to meet the agency’s security obligations. This assists with driving the creation of the required policy and process direction, which would be leveraged in remediating the agency’s approach to patch management. This practical approach is constructed in eight steps that flow from understanding current practices and context, to developing a patch management policy and process, to ultimately implementing an improvement program and reviewing the outcomes.

Where are we now? Step 1. Baseline current environment:

a. People: Identify the policy sponsor, capability owner and stakeholders

b. Process: Identify the current patching activities, responsible roles, and patch management process performance

c. Technology: Identify the deployment tools/architecture and technical mitigations

Where do we want to be? Step 2. Develop security patch

management policy Step 3. Develop security patch

management process How do we get there? Step 4. Develop a Capability

Implementation Plan Step 5. Configure the toolsets to support

the process Step 6. Implement new process and

measure performance

Step 7. Perform a Post Implementation Review for Continual Service Improvement.

The remainder of this section describes each of these steps in further detail and is accompanied by supporting information in the appendices. The sections also provide practical checklists for the implementation of the capability.



Step 1: Baseline current capability

One of the most important activities when taking on an improvement exercise is to have an opportunity to

review and document the current practices. This not only gives the agency an opportunity to assess their internal capability, but also provides a starting point for any improvement activity in the environment. The following checklist is broken into core areas and can assist with a review process. People Agencies should consider the following people elements of the extant approach: Who owns the security patch

management policy within the agency? Where is it documented and how is it accessed?

Who owns the security patch management process within the agency? Where is it documented and how is it accessed?

Which personnel are performing security patching activities within the agency? Has process training and policy awareness been provided?

What are the people’s impressions about how effective the process is?

Culture Agencies should also assess their culture and baseline patterns of behaviours and cultural norms. This will assist with diagnosing any issues that may need to be addressed for a successful security patch management capability.

Are agency management supportive of security initiatives?

Are patching requirements understood during the ‘requirements gathering’ phase of a system being designed?

Are new systems designed so they can be easily patched during operations? Is the operations team consulted during the design phase?

Is IT Security able to enforce the security initiative?

Process What are the detailed, end-to-end

activities performed currently within the environment to deploy a software update released by a vendor? Who performs them and how are they sequenced?

How do the following Service Management functions work to enable and effective patch management approach: Change Management - Including

provision for Standard Changes relating to security patching

Release & Deployment Management - With relation to regular deployment windows available for patching

Asset & Configuration Management - Cataloguing all software and hardware assets that may require patching and the patch state of each

Incident Management - How well are security patch related incidents handled?

1


How well is the current process performing? What is the current security vulnerability window, or the turn-around time from patch release to a compliant state? How reliable are the measurements?

How well is non-compliance captured and understood?

How much effort is required to follow the end-to-end process to deploy patches?

Number of actors responsible for the various activities with the process and the number of touch-points with the various teams.

Is there a process to deploy out-of-band or extreme risk patches within the organisation? Does it meet a 2-day turnaround?

Technology What are the deployment

tools/procedures currently in use? How accurate is the inventory? Which are the simple and complex

workloads for deployment? Which deployment tools apply to which

systems? Are the deployment tools and systems

suitably designed to support the timely distribution and deployment of patches?

Are the deployment tools in a healthy state?

How much effort is required to deploy software updates using the toolsets?

What can be automated? How much of the current practices have already been automated?


Step 2: Develop a Security Patch Management Policy

The purpose of the security patch management policy is to communicate the intent of security patch

management in the agency, and will define the principals that guide its implementation throughout the agency. The security patch management policy statements should focus on: Roles & Responsibilities - Clearly

articulating accountable roles and incorporating information security into the agency’s broader risk management practices.

Timeframes – What are the timeframes for implement the patching policies? How can the security patching policies be implemented across the agency: Big-bang or phased? How and why a risk based approach can be implemented to identify the security patching phases?

Risk Based Decision Making – How a risk based decision making regime be implemented? What Risk matrices are available within the agency?

Recording – What are the agency recording obligations as defined in the ISM and the Archives Act 1983 (Commonwealth Consolidated Acts, 1983)? What level of security is required around patching information and how will this be achieved?

Reporting – What reporting is required to measure the success of the policy implementation? How will the data be obtained and processed?

The security patch management policy statements are a way of communicating what & why security patching should be undertaken within the agency. It should also include information on how the activities relate to the agency’s security obligations and business objectives. All security patch management policies should be clearly articulated and widely communicated to both the employees of the agency as well as any contractors or service providers. Having an ability to enforce the IT Security Policies is just as important as having them in the first place. In order to be successful in its enforcement, having executive and senior management buy-in for these policies is critical. Ensuring that senior managers and decision makers are fully aware of security risks and the need for patching in a timely manner is critical in facilitating the availability of appropriate resource. Identify any security patch management

related policy statements in the agency’s security manual (clarify if required).

Create security patch management policy statements (either as part of an existing IT Security Policy or as a separate document). The appropriate agency Accreditation Authority (Australian Signals Directorate, 2014) must sign off the security patch management policies before circulation.

The security patch management policy statements should be reviewed and updated annually to cater for changes in the business and external circumstances, such as new Information Security Manuals and guidelines, or changes to the global security threat landscape.

2


Step 3: Develop a Security Patch Management Process

Security patch management is the process of controlling the deployment and maintenance of security patches in the organisation. The process

improves system security, while helping maintain operational efficiency and effectiveness, and stability of the technology. Research shows that 80% of all issues in IT operational environments are related to people and process (Scott, n.d.). Having a

comprehensive security patch management process is essential in mitigating these issues. There are a number essential elements in a security patch management process. The process should contain the components essential to the implementation of the capability within the individual agencies. This document includes an example four-phased security patch management process, which can be used as a basis for forming an agencies process. The section below describes the 4 phases of the process.

3

Figure 4: Example Security Patch Management Process


Assess The Assess phase focuses on bringing a system under process compliance (also referred to as ‘on-boarding’ within the document). The main purpose of this phase is to take a system through a checklist of readiness activities so the various teams responsible for its patching can prepare for ongoing patching operations in alignment with the ISM requirements. A system has been brought under the security patch management process, or on-boarded once the following have been completed: Current state of patching activities is

identified Risks associated with on-boarding and

ongoing patching activities have been identified, and mitigations have been put in place

Vendor information has been identified Test, implementation, and back-out

procedures have been articulated The above information and other system-

specific information (see section 1.1 of Appendix V – Security Patch Management Plan Document Outline) has been compiled into a document artefact (security patch management plan).

This phase is intended to be run once per system and does not need to be executed for each patch release applicable to the system.

Identify The Identify phase in the example process focuses on the identification of vulnerabilities for a system. Security vulnerability identification can be pro-active or reactive in nature. Depending on the system and the potential impact of the vulnerability, the software vendor may use: • A regular security patch release cycle, or • An irregular (out-of-band) security patch

release. Agencies must use the information collected within their inventories to identify which systems require patching, in what timeframe, and where to source relevant vulnerability and patch information. ISM control 1144 describes an overall response time between patch release and patch deployment to be two days for ‘Extreme’ risk patches, making it critical to make sure that the notification of a patch release is as immediate and credible as possible for the assessment to take place. Make sure that there is more than one person subscribed to the vendor patch notifications, in the event notifications arrive when the primary person is unavailable. Occasionally, vendors release security updates to address vulnerabilities outside of their standard release cycle. This generally occurs when a discovered vulnerability is already being exploited in the wild (zero day) or is considered critical enough to warrant the urgent release of the patch mid-cycle.


Evaluate & Plan The Evaluate & Plan phase assesses both the impact of not deploying the patches (leaving the vulnerability exposed), and the risks associated with the deployment of the patches to the production environment. Deployment may, but not certainly, necessitate an outage to a service, depending on a number of factors such as design of the service. Each patch should be assessed individually based on the systems impacted and dependencies on other related patches. Each patch should be assessed for the: • Risk profile of the system being patched

(based on historical patches) • Impact to the business, as outlined by

PSPF (Protective Security Policy Committee Attorney-General's Department, 2014).

Using the outcome from the above criteria and the risk management framework within the agency, a risk rating for the patch should be created. It is important to understand the risk of delaying deployment of patches, or indeed not deploying them at all: What would be the business impact of confidentiality, integrity or availability of the system being compromise? The propensity for compromise will only increase in the days following the release of a security update for a vulnerability. This should be a key input into the agency’s decision-making. The risk rating of the vulnerability may influence the deployment timeframe for the patch. The testing outcome and deployment timeframes will assist with the identification of the release window for the patching cycle. In situations where the testing has identified outstanding defects, there may be sufficient risk posed by the vulnerability to continue with deployment.

Effectively evaluating the patches released will assist with the planning activities: • Determining required outage • Identifying risks, issues and constraints • Building the release plan. Determining the required outage requires an understanding of the impact to the business and IT services and the agreed Service Level Agreements (SLAs). An SLA is usually specific to a system or a service. Other constraints such as network capacity, business requirements and security requirements should also be considered at this stage. Building the patch release plan should take into account the: Scripts, tools and procedures followed by

the system administrators to build the release package

What level of testing is suitable for the system?

Deploy The goal of this phase of the process is to confirm that approved security patches have been successfully deployed in the production environment while meeting all the Service Level Agreements (SLAs) negotiated with the business and the required level of compliance can be demonstrated. This phase is completed through the execution of technical deployment procedures for the applicable systems.


Step 4: Develop a Capability Implementation Plan

Implementing the agency’s security patch management Policy must be a planned activity. Agencies with large

and complex environments should consider a phased approach to make implementation more manageable. There are various criteria that can be used to identify which systems within your environment should be prioritised. This must be a risk-based decision; systems with a higher risk profile are the highest priority. Here are some of the things that may be considered while prioritising systems: • Value of the data – what data

classification will have the most adverse impact if compromised? How do we secure that first?

• Business critical services – what services are on the critical path for the agency’s operation and its ability to meet its objectives? What systems need to be kept secure so the business critical services are not compromised?

• Minimizing attack vector – What are the biggest attack vectors within the organisation? (e.g. operating systems and applications on end user desktops, IT admin desktops, server fleet, etc.)

• Industry exploitation patterns – Major security reports such as Microsoft Security Intelligence Report (Microsoft, 2015).

Most agencies have a combination of Microsoft and other vendor technologies in their environments. While patching a complete environment can be a daunting

task, success can be achieved by addressing the requirement in a phased approach. Priority should be given to systems with a high risk profile and they should be brought under process control before lower risk systems. There are a number of components essential to an effective Capability Implementation Plan: Develop a strong business case Define a clear end-state Define the work packages, schedule, and

deliverables out of the plan/project Stakeholder management plan Communications plan Organisational change management plan

(discussed further on in the document). As part of the implementation plan, also discuss: Documents and templates – What

documents and templates are required to support the implementation of the security patch management policy? Do they exist? How will they be developed?

Tools – What tools and techniques are available within the agency/partners/ service providers that can be leveraged to support the security patch management Policy?

It is important that the security patch management policy owner is also supportive of the Capability Implementation Plan and is involved in the development of it.

4


Step 5: Configure the Technology

Having a robust and streamlined security patch management process gives an agency the ability to respond

promptly to security risks presented to the organisation. Technology is the important enabler of organisational policies, and should support the outcomes the organisation is seeking to achieve. The effectiveness of the patch deployment toolset and associated automation has a direct impact on software update deployment timeframes, and consequently, on the security posture of the organisation. To improve the deployment performance of software updates, many activities can be automated, including using appropriate deployment toolsets to download, distribute, and apply security updates. It is important to make the most of available features of deployment tools to make a difference to the swiftness, and therefore effectiveness of the deployment efforts. The selection, design, and configuration of a software update management toolset and supporting network infrastructure are all critical to the ability of the organisation to maintain secure systems, and achieve prompt deployment timeframes. Factors to consider in the design and configuration of a software update management toolsets and supporting infrastructure include: • Ability to accurately determine applicable

updates. • Ability to download/import software

updates promptly. • Ability to stage software updates at

locations to optimize WAN utilization. • Ability to distribute software updates

promptly, to support the goals of the applicable policies.

• Ability to prioritize the distribution of particular software updates based on associated risk.

• Ability to support sequenced installation, or multiple deployment windows to assist with complex workloads and maintaining service availability.

Consider the following checklist when assessing the software update management tools and supporting network infrastructure: Can the download/importation of

applicable updates be optimised? Does network bandwidth and distribution

point hierarchy adequately support the security goals?

Can/should the update distribution priority align with the risk level of the software update?

Which complex and labour intensive systems with availability requirements need to have the deployment sequence automated?

5


Step 6: Implement Process and Measure Process Performance

The first step of the approach (Baseline current environment) focuses on reviewing the current

people, process and technology practices. This phase is an opportunity to measure the improvements that have been made after having implemented a streamlined process, clear roles and responsibilities, and the required technology tuning. Upon implementation of the new process, a post-implementation baseline would assist with the articulation of the project value realisation. Consider the following areas when measuring the performance of the new process: How well is the new process performing

compared to the previous one? What is reduction in the Security

Vulnerability Window? How well did all the teams work together

to achieve the desired outcomes? Are there areas where process improvement can be made or a process re-design is required?

What is the effort required to perform all the activities required to patch each system? This information will assist in identifying which are the labour intensive activities, which are prime candidates for automation.

Step 7: Conduct Post-Implementation Review

After each cycle of improvements made to the people, process or technology components of the

solution, it is valuable to conduct a Post-Implementation Review (PIR). This would enable all stakeholders to discuss the good and the bad aspects of the process. Sharing how different teams may have tackled the same challenges can be a useful exercise, leveraging cross-team collaboration. The security patch management process owner should chair the sessions. It is essential to document all the opportunities for improvement and the process owner should feed that into the security patch management’s continual improvement exercise. In some cases, if there are too many teams that are involved in the process execution, it may be more productive if the process owner meets with each of the teams individually. This will not only enable the process owner to discuss operations in a lot more detail, but would make sure that the time of the attendees is used appropriately. One-on-one meetings also provide a good opportunity to discuss challenges with inter-team communication, which is a key success criterion. The PIR sessions are best run straight after the process execution, so feedback can be freshly captured. It is important to answer questions such as: • Are the communications working

effectively? • Were there any incidents caused? • What are the potential future

improvements?

6 7


Developing a Security CultureEmbedding the Security Patch Management Capability “Most change initiatives fail because there is insufficient focus on the activities and practices that need to be carried out to embed change into the organisational culture” (Ferris, 2011). A well designed process that no one follows produces no improvement in an agency’s security posture. A well designed toolset or capability that the right people aren’t consuming does not bring the intended value and creates a missed opportunity for the investment. On the contrary, it results in a net decrease in value of the investment due a false sense of security (as management assume that the new toolset or capability has been adopted) while adoption related issues continue to emerge. It is crucial to build a bridge between the new process and technology introduced and confirm that all stakeholders are supporting and adopting the change to realise the benefit to the agency. Agencies need to assess how the newly developed security patch management capability is to be adopted into the culture of the organisation. This requires people to adopt the new practices and understand how these activities will help them and the agency achieve the required level of security and desired business outcomes. To enhance the probability of successful adoption of new work practices, behaviours and roles and responsibilities, agencies can apply a number of different Organisational Change Management models including: • PROCI ADKAR Change Management Model • Kotter’s 8-Step Change Model

• Balanced Diversity Model • The Deming Cycle (PDCA) • Kanter, Stein and Jick’s 10 commandments • Nadler’s 12 steps. The phased approach within the capability implementation plan can be scoped and prioritised based on the appetite for change of the system owners as well as the security risk profiles of their systems. Whichever change model the agency chooses to deploy, there are a number of common areas that need to be addressed. This section focuses on some of the questions that need to be resolved during implementation. Why change? It is important for all staff and managers to understand the benefits of a robust security patching capability to the agency’s security fabric as well as the agency’s obligations under the ISM and why the change in process is required. The following are a number of activities that aim at increasing awareness of new process and change to activities they would be performing: Ensure all managers and team leaders

within IT and Security are aware of the need for the new process and how their will contribute to the successful implementation of the process.

Ensure senior management publically communicate their support of the initiative to improve the security capability, as well as acknowledge compliance obligations and how they align to the agency’s business outcomes.

Communicate the need for the security patch management process and the


behavioural changes required, widely, often and in different ways. Based on each employee’s understanding of the current state, his or her buy-in into the change will be different and would benefit from tailored communications.

What does the change actually mean? For agency staff to have buy-in into the new security patch management process, their awareness must lead to a desire to participate in the implementation of the new process. Here is a list of activities that can assist: Clearly understand the changes required

for each individual. Be able to demonstrate the advantage of the new or changing activities.

Where appropriate, notify the staff of the incentives of successful embedding of the security patch management process and how they will be individually rewarded for contributing to the change (e.g. public recognition, additional training, career development opportunity, and being part of an important change).

What is required to change? Having the appropriate level of training provided to all the impacted roles is an important part of implementing the change. Prepare training packages to make sure

that all impacted staff are aware of the new process’s business value, the change in activities for their roles, as well as the operation of any new technologies introduced into the environment.

Regularly check to make sure that process and technology training has had the

intended benefits and the staff have been able to absorb the training.

Is the change being implemented successfully? It is important to get a feel from the roles involved with regards to the effectiveness of the new process and how well it is performing. Activity execution is well understood and

continual service improvement is in place Seek direct feedback from stakeholders

and make appropriate changes to the new process and procedures to facilitate smoother operations.

As required, continue to provide technical, process and other required support to the operations teams.

Recognition of success Once the process implementation is underway within the agency, and the agency is successfully able to start on-boarding critical workloads, it is crucial that there is adequate acknowledgement of the achievement as well as an ongoing emphasis of the importance of what has been achieved. Send direct feedback from senior

executives as well as the project sponsor to all staff acknowledging achievements.

Have direct managers provide public feedback thanking all team members for the effort provided.

Continue to reinforce the importance of the achievement and directly link it to the agency’s goal.


Security Patch Management Detailed Step-GuidanceThis section of the document describes some of the activities that may be conducted during the four phases of the example security patch management process which was constructed in step 4 of the security patch management approach. The intent of the section is to provide optimised and streamlined example guidance that each of the agencies can tailor to the operational requirements of their

organisations, as per their agency’s IT Security Policy. Agencies should consider how they would achieve the intent of the procedures and adapt the procedures to their agency. The section below provides examples of what the step guidance for the various process steps may look like.

Figure 5: Security Patch Management Process


1. Assess This phase focuses on bringing the system(s) under the control of the security patch management process and is essentially an “on-boarding” phase. The goal of this phase is to: • Define service and system specific information • Develop Risk Impact Matrix • Complete the security patch management plan. 1.1 Service On-boarding

Figure 6: 1.1 Service On-boarding Activity Flow Diagram 1.1.1 Define Service Attributes Performed by – System Manager When technical services are transitioning under the management of the security patch management process (either as part of transitioning into operations or bringing an existing production system under process compliance), identify and document all the systems that comprise the stack. The following steps will make sure that each system identified within the service has been “on-boarded”. To make sure that Service Level Agreements can be met, make sure that the outage requirements (if any) of all the individual systems sequenced in such a way as to minimise the impact on the availability of the service.

For each new service, identify: Technical Service Owner accountable for

the service delivery. List of systems that make up the service. Relevant service level requirements,

including availability requirements for the service.

1.1.2 Define System Attributes Performed by – System Manager On-boarded system can be either part of a service or as a stand-alone system (potentially providing a technical service in itself). For each of the systems being on-boarded, identify the following attributes: System Name (and service name if the

system is inherently a part of a Technical Service)


System Owner – The branch head2 that is accountable for day-to-day operations of the system.

System Manager – The Director2 or an appropriate delegate responsible for operations of the system

System Administration Team2 – The team responsible for day-to-day operational activities for the system

System Build Team2 (if appropriate) the team that will be responsible for building the deployment package if the patches are being deployed manually.

System Test Team2 will develop the test plan/strategy and will execute the test cases.

System Business Verification Team2 is responsible for validating the production readiness of the system and dependent business services post patch installation

System Deployment Team2 is responsible for installing/deploying the patches/package to the production environment

System Monitoring Team2 monitors the deployment and compliance of patches within the agency’s environment

System Vendor(s) – including method of communicating patches and release schedule

System Change Management Team2

2 These are recommended performing roles (functions) only and may not be actual separate

Configuration Items (CIs) included within the scope of the system. Update the agency’s asset and configuration management database as the information is collected.

Each systems within the agency should have a risk profile created. This would include attributes such as: Business teams using the system and the

business impact of the system not being available

The operating systems and applications that underpin the system – including their risk profiles

The frequency of security patch releases for the system and how to consume the security notifications

Distribution and deployment timeframes required for the security patches relating to the system using the designated patch deployment method.

teams/roles. Smaller agencies may have a single team/roles performing multiple set of activities.


1.1.3 Define Impact Matrix Performed by – System Manager This activity pre-calculates the impact of a system compromise and likelihood for patches released for this system for later use in risk assessment. Calculating the right risk rating is important for the correct prioritization of the patches. During operations, there is often insufficient time to collect all the information required to calculate the impact to the business of the agency. Pre-digesting some of this information can help expedite operational decision making and assist with meeting the ISM’s 2-day turnaround timeframe for ‘extreme risk’ patches. In order to calculate the impact of deploying a patch to a system, it is important to understand the system’s purpose and the impact on the agency’s business if the system is compromised. Refer to section Appendix I – Assessing System Risk for further information on assessing risk. 1.1.4 Identify Risks to Patching Performed by – System Manager An agency’s IT operations environment can be very challenging and there are always many things happening at the same time. The volatility of the environment often requires the operational teams to be agile and divert resources to high priority tasks as they come along. It is however important that high value activities such as security patching do not get re-prioritised and have sufficient support at all times. This step of the process requires the System Manager to run workshops to gather all of the

potential risks that may cause the agency to not deploy patches in a timely manner to all the required agency assets. Use the agency’s prescribed Risk Management framework to capture the risk. If there is no framework available, refer to ISO 31000:2009 for further information. 1.1.5 Suggest Mitigations & Actions Performed by – System Manager For each of the identified risks, it is important that there be an appropriate response to make sure that there is no unnecessary impact to the agency’s patching activities. Ensure that the treatments are identified and agreed as part of on-boarding the service/system. This will assist with making sure that there is an opportunity to plan upfront for resourcing requirements as well as getting management’s support to prioritise patching activities should there be competing demands for resources. 1.1.6 Compile Security Patch Management Plan Performed by – System Manager The system patch management plan captures all the information collected during the on-boarding of the service or system, and acts as a concise, service-specific reference document for driving the process. The plan should be published and accessible to all the roles involved in patching the system. A document outline for the security patch management Plan can be found in Appendix V – Security Patch Management Plan Document Outline.


2. Identify The Identify phase focuses on identifying which patches need to be deployed to the agency’s environment. The goal of this phase is to: • Determine relevance of patches to the agency’s environment • Categorise patch priority, influencing the timeframe required to deploy. 2.1 Identify and Prioritise

Figure 7: 2.1 Identify and Prioritise Patch Activity Flow Diagram 2.1.1 Assess Released Patches Performed by – System Manager Ensure that there is a clear communication channel between the vendor who releases the patches and the agency. Subscribe to a variety of methods including: • email subscriptions, • RSS feeds, and • Websites. Always make sure that there are multiple people monitoring the vendor alerts in case the primary person is not available. Each patch should be assessed by the system administrator for its applicability to the system. For example, the team responsible for the managing the Standard Operating Environment(SOE) should be assessing all

patches relating to the SOE operating systems and applications; the database platform team should be assessing any database patches; etc. Understanding patch dependencies and the recommended sequence of installation (usually published by vendors) will make sure that patch deployment is successful and have the desired mitigation. There are three primary release types for patches: • Scheduled patch release – A number of

vendors publish schedules for the release of their patches. These schedules are published in advance, and gives agencies an opportunity to negotiate a pre-approved release schedule with their IT and Business areas. Having pre-approved windows enable agencies in using a


‘Standard Change’ option within the Department’s Change Management process, removing a number of administrative overheads.

• Unscheduled patch release – A number of vendors do not have a standard schedule for when they release their patches and as a result, release windows cannot be pre-assigned or pre-approved for their deployment.

• Emergency/Out of Band patch release – Occasionally, patches are released which address vulnerabilities that are known to be actively exploited. These patches are considered too urgent to wait for the scheduled release.

Centralised vs Distributed Model for Patch Selection There are two options for approaching patch selection within an agency. This section discusses pros and cons of each of them. Agencies may choose to use either of the centralised or de-centralised patch selection models, including a combination where it makes sense to do it. Whatever the model used, it is important to make sure that roles and responsibilities are agreed and documented.

Distributed Patch Selection Model Each team is responsible for monitoring the releases of all the security patches relating to the products they maintain within the environment.

Centralised Patch Selection Model A single IT Security team is responsible for monitoring the releases of all the security patches relating to the products deployed within the environment.

Pros Patch deployment decisions are more likely to be technically sound as they are being made by the technology SMEs. This is a scalable solutions for agencies with larger IT environments as there is no ‘single point of failure’ for patch selection and each team can select their patches in parallel, improving the efficiency of patch selection process. Time investment is significantly less per team as the workload is distributed.

Decisions are more likely to be consistent as they are being made by the same team. Centralised understanding of all the patches released allows better impact assessment (including identifying cross system patch dependencies). One team requires training and always has the agency’s security as the primary focus. Governance, reporting and compliance checking is controlled centrally and much easier to improve.

Cons Cross-system impact assessment identification requires the various dependent stakeholder teams to communicate the impact between themselves, potentially increasing time to deploy. Application of agency’s risk management principals consistently across all technical teams involved in patch selection is more difficult and requires additional quality assurance. Every change made to the process and supporting documentation requires all teams to train. Governance, reporting and compliance checking is a significant effort investment.

As this team is not the technology SME, critical patches may not be correctly assessed for deployment. Solution not scalable for large number of technologies within the agency as one team may not know about all technologies deployed, their interdependencies and operational specifics. Significant time investment by the team.

Table 1: Distributed vs Centralised Patch Selection Model - Pros and Cons


2.2 Validate priority Performed by – System Manager It is crucial that agencies assess each patch to determine the deployment priority for the impacted systems. A typical risk-based approach for assessing likelihood and impact is the best way to identify and validate deployment priority. A thorough risk-based approach requires agencies to understand: Likelihood – The probability for the vulnerability to be exploited in the near term. Impact –The impact to the agency’s business functions if the system was compromised (financial, labour, reputational, etc.) Use the agency’s Risk Calculation table (as part of the agency’s Risk Management

Framework or as documented in the system’s security patch management plan) to assess the risk of the vulnerability to the agency’s environment. Some additional guidance has been put forward in Appendix I – Assessing System Risk. It is also important to capture the mitigations that exist within the agency’s IT environment which may either reduce the likelihood of the vulnerability being exploited or the Impact should it be exploited, thus reducing the overall risk. This would not only represent a more accurate threat assessment, but would also provide greater focus on vulnerabilities that are of ‘extreme risk’. Also refer to section Security Patching and the ISM earlier in this document.


3. Evaluate & Plan Goals of the Evaluate and Plan phase include making a decision whether or not to deploy an update, determining deployment requirements, and testing to confirm that it does not compromise the stability of business-critical systems and applications. The intent of this phase is to: • Determine the appropriate response • Obtain authorisation for deployment • Review change request(s) • Plan the release • Identify key issues and constrains; and • Build and test the release. 3.1 Authorise Change

Figure 8: 3.1 Authorise Change Activity Flow Diagram

3.1.1 Raise Standard Change Performed by – System Manager The agency’s change management processes usually identify which change record type is the best one to use in the various circumstances. A Standard Change (OGC, 2011) gives the operations teams the ability to promote the patches through the various environments and into the production requirements within minimum delay. Industry frameworks including ITIL® and Microsoft Operational Framework (MOF) identify

Standard Change as the mechanism typically used for activities like patching. Use of Standard Changes may assist with: Removing the additional submission lead

time requirement Increasing focus on critical documentation. Standard changes are optimal for proven cases, where the risk of failure is low as the change has been proven successful multiple times. Standard Changes typically do not require submission to the Change Advisory Board


(CAB) and can be approved either by the Change Manager, by the System Owner as specified by the agency’s Change Management Process or may at times be pre-approved, with no additional approval required. Use the IT Service Management product within your agency to raise the Standard Change record and submit it for approval. For further guidance on how standard change approvals work for your agency, contact the Change Management team. 3.1.2 Assign Deployment Window(s) Performed by – System Manager Assign deployment window(s) for the deployment of the patches based on a pre-agreed patch release calendar or else identify an appropriate window for the patch release. Refer to the agency’s Change Management, Release and Deployment Management processes for further guidance on assigning deployment windows. 3.1.3 Raise Change Record Performed by – System Manager Where a Standard Change option is not available, one of the follow options may be appropriate: Normal Change (OGC, 2011) may be used

for deployment of patches that are not ‘Extreme Risk’ and can fit within the change cycles of the agency.

Consider ‘Emergency Change’ (OGC, 2011) may be an option when ‘Extreme Risk’ patches need to be deployed within 48

hours and a Standard Change option is not available.

Refer to the agency’s Change Management process for further guidance on how the different change record types should be used. 3.1.4 Obtain Approval Performed by – System Manager Ensure that the appropriate level of approval is granted for the Change Record raised and the impact is well understood before continuing. Where there is end-user impact and the outage to end-user applications may be outside of pre-advertised windows, make sure they are notified in advance.


3.2 Build Patch Release Package

Figure 9: 3.2 Build Patch Package Activity Flow Diagram

3.2.1 Acquire Patches Performed by – System Build Team Wherever possible, patches should be automatically downloaded from the verified repositories to expedite the deployment activity as soon as the patch selection activity is complete. 3.2.2 Build Release Package Performed by – System Build Team If a deployment toolset is not available, this step may be redundant. Many patch management toolsets are able to automatically package patches they download. A number of deployment toolsets are able to deploy custom packages for applications and patches. A package must be

manually created for deployment as part of the guidelines provided by the deployment software vendor. A number of deployment toolsets are able to deploy custom packages for applications and patches. A package must be manually created for deployment as part of the guidelines provided by the deployment software vendor. 3.2.3 Install to Dev Environment Performed by – System Build Team Install patches to the agency’s development environment as soon as possible. This will allow developers to catch issues with patches earlier. An up-to-date development environment will make sure that developers are developing on the latest platform.


3.3 Test Patch Package

Figure 10: 3.3 Test Patch Package Activity Flow Diagram

3.3.1 Install Patches in Test Environment Performed by – System Test Team Install the downloaded patches into the test environment. 3.3.2 Perform Testing as per Test Plan Performed by – System Test Team Perform testing as per the test plan. For more information on testing processes, refer to ITIL Service Validation and Testing process (OGC, 2011) and MOF (Microsoft Operations Framework, 2008). 3.3.3 Assess Residual Risk to Production Performed by – System Manager The risk posed by delaying the deployment of security updates should be weighed up against any defects discovered in testing. A defect is an important observation that should not be ignored; at the same time, unpatched security vulnerabilities put an

organisations assets at serious risk of compromise. For each outstanding defect, also consider if there are alternative strategies that can help mitigate the risk to the production environment posed by the defect. It is also important to consider the discrepancy between the test and production environment when assessing outstanding defects. If the residual risk to the production environment is unacceptable, IT security’s input would assist with a buy in for the system owner’s decision for next steps. 3.3.4 Issue Testing Endorsement Performed by – System Test Team If the security updates have passed testing, this decision is recorded and the deployment team is notified of the decision. Proceed to the deployment phase.


4. Deploy The Deploy phase includes the rollout of approved update(s) into the production environment. Generally the success is measured against the requirements of service level agreements (SLAs). • Prepare deployment • Deploy patches to target endpoints; and • Perform post implementation activities. 4.1 Distribute and Install Patches

Figure 11: 4.1 Distribute and Install Patches Activity Flow Diagram

4.1.1 Distribute Patches Performed by – Deployment Team Patch distribution is the act of staging the patches to the necessary distribution points or to the assets where the updates are to be installed. As soon as the updates are packaged, they should be distributed. The distribution of the patches (especially to a large and decentralised environment) can take some time and should be sequenced to parallelise activities that need not be executed serially. Change approval for installation may not necessarily be required as a prerequisite for distribution. Distribution windows should be pre-approved and communicated within the organisation.

4.1.2 Install Patches Performed by –Deployment Team As soon as the distribution of the patches is complete and the approved outage window is open, install the patches using the Deployment Procedures for the system. The monitoring team should be notified of a successful deployment so they can start monitoring for expected compliance.


4.2 Escalate Issues

Figure 12: 4.2 Escalate Issues Activity Flow Diagram

4.2.1 Seek IT Security Input Performed by – System Manager An escalation may be required for a number of reasons: Technical – architectural or compatibility

conflict Risk – Testing failed, outstanding defects,

issue with piloting or patch rollout, not being able to meet the 2-day window for whatever reason.

Business – Business requires service availability and reliability during the deployment window.

The intent of this activity is for the system manager to seek consultation with IT Security and seek their support for the next steps. Seeking IT Security endorsement upfront will not only assist with managing expectations within both IT and business areas of the agency, but will provide an additional level of consultation before security based decisions are made. There are a number of alternative activities to be considered based on ISM control 0941 to assist with risk mitigation. These activities should be discussed prior to agreeing to a Deferral Notice.

4.2.2 Notify Intent to Continue Performed by – System Manager When a decision to continue with the patch deployment (either in its current scope or reduced distribution) is made, continue with the deployment of the patches under any agreed conditions. A reduced scope deployment should accompany a deferral request. 4.2.3 Submit Deferral Notice Performed by – System Manager The ISM expects all exceptions to the patch management controls to be documented (ISM Control 003). The Deferral Notice should be used to document deferral decisions as well as the mitigations implemented.


4.3 Monitor Patch Distribution

Figure 13: 4.3 Monitor Deployment Activity Flow Diagram

4.3.1 Monitor Patch Distribution Performed by – System Monitoring Team Once distribution has initiated, progress should be actively monitored to ensure no issues are preventing the propagation of security patches. Lengthy delays to distribution could pose a security risk to the agency. The monitoring team should raise a Security Incident to have the situation investigated further. 4.3.2 Raise Security Incident Performed by – System Monitoring Team There may be a number of reasons why the patch deployment rate does not meet baseline performance, for instance:

There is an issue with the deployment infrastructure (the deployment toolset, server or the hardware layer).

Software update packages are failing to install due to some unreliability.

There are issues with the reporting capability of the deployment toolset.

Security Incidents should be handled by the Incident Manager responsible for security incidents for resolution (please refer the Security Incident Management process within the agency). For further guidance on Incident Management, refer to the ITIL Service Operations publication (OGC, 2011).


A.1 Report

Figure 14: A.1 Report Activity Flow Diagram

A.1 Produce Reports Performed by – System Monitoring Team The PSPF has specific reporting requirements for agencies on their compliance with the ISM Top 4 Strategies to Mitigate Targeted Cyber Intrusions. In conjunction with published requirements, various level of decision makers in the agency require different reports to make operational decisions. Here are three different reports that administrators, security operators and executives can use to get the information they need: Operational reports IT security related reports Executive and compliance. Operational Reports The System Managers and administrators require visibility of the deployment rate of their packages as well as how it is impacted by all the technical factors in their environment: Deployment tool capability Availability, capacity and performance of

their patching infrastructure Deployment compliance

IT Security Related Reports IT Security needs to have visibility of the success or otherwise of the effort of the System Mangers to comply with the ISM controls. The IT Security reports may include: Deployment compliance over time The percentage of the system CIs

successfully patched within 2 days of patch release (compliance to ISM Control 1144)

Number of systems that have a security patch management plan in place and are being patched regularly

Executive and Compliance The agency executives need to have visibility of the agency’s activities to verify that they are strengthening the security of their environment. Here are some examples: Indicators of compliance to ISM Controls

related to security patch management Indicators of level of undocumented,

uncontrolled non-compliance Security patch related achievements as

well as major risks to the agency’s security patching environment.


A.2 Process Compliance Assessment

Figure 15: A.2 Process Compliance Assessment Activity Flow Diagram

A.2.1 Identify System to Assess Performed by – System Assessor The compliance assessment is a mechanism to drive adherence to the process as specified in the security patch management policy and process. Identify systems to assess based on the following suggestions: • High-value, high-risk systems • Systems for which patch related Security

Incidents are being logged regularly. • Systems where compliance state is

unknown or poor. Contact the System Owner and the System Manager of the intent to assess including timeframes and list of people to engage. This would provide them sufficient time to organise the required documentation to present for the assessment. A.2.2 Plan Compliance Assessment Performed by – System Assessor Plan for the patching process compliance assessment: Document patching activities (meetings

and checklist) Create assessment schedule

Hold Process Compliance Assessment kick-off meeting.

A.2.3 Conduct Compliance Assessment Performed by – System Assessor Conduct the assessment activities by following the created checklist: Check adherence to the agency’s security

patch management process and procedures.

A.2.4 Produce Compliance Assessment Report Performed by – System Assessor Document the findings of the process compliance assessment. Cover the following topics at a minimum: • Assessment and system overviews • Assessment observations and finding • Recommendations. Follow up with the System Owner and the System Manager to discuss actions for remediation, action owners and dates for completion. Present the assessment report and the agreed remediation action plan to the IT Security Advisor and if appropriate, to the agency executive. Follow up on the remediation action plan on a regular basis.


Common Implementation Challenges Supportive IT Security Policies Covering Security Patching Challenge: There is no buy-in from management for the implementation of the ISM controls within the agency. A critical success factor for achieving effective security outcomes is that all stakeholders, including senior leaders in the organisation, understand the importance of the security patch management policies and their applicability to the information security posture of the organisation. Agencies must have the appropriate level of security patching related policies and they need to be well communicated to both the IT staff as well as the business areas of the organisation. Ensuring that the senior executives, middle management as well as all IT and business staff understand the importance of the implementation of these policies is also crucial. Policy owner should make sure that the security patch management policies are adequately communicated and their purpose is clearly articulated (also see section Step 2: Develop a Security Patch Management Policy). Security Patch Management Capability Implementation Plan Challenge: How do we decide what we should on-board first? Having a comprehensive security patch management capability implementation plan can guide embedding of behaviours required to achieve the security patch management Policies. The Capability Implementation Plan outlines a rough timeline of what devices and systems will be brought under IT Security Policy compliance. This enables the System

Owners and the System Managers to plot a timeline to bring the target systems into compliance, or to implement other proactive threat mitigations, as part of the Capability Implementation Plan. When building a security patch management capability implementation plan, consider the advice in previous sections of this document (Step 4: Develop a Capability Implementation Plan). In addition to the above, also consider: • Where does the agency store trophy data? • Where is the greatest opportunity for risk

reduction? • Which operating systems or applications

are most frequently exploited in the wild? • How widely is the operating system or

application used within the agency and what is the potential business impact of the vulnerability?

Figure 16: Encounter rates for different types of exploit attempts in 2013 There are many publicly available sources of vulnerability exploit data, which can help paint a picture of the software security threat landscape. For instance, the below above from the Microsoft Security Intelligence Report (Volume 16) shows publicly observed vulnerability encounter rates by type of exploit.


A Risk-Based Approach to Security Patching Challenge: Vendors publish a rating for their patches. What does that mean for my agency and why can’t I just use that to prioritise patch deployments? Exploitation of a vulnerability within a Department’s IT environment can have an impact to the confidentiality, integrity and availability of the assets. This could lead to a negative impact to the business services and business processes that depend on the asset. The consequences for a compromised organisation can mean a measurable loss of financial assets, reputational damage or worse. As per the PSPF Protective security governance guidelines on Business Impact Levels (Protective Security Policy Committee Attorney-General's Department, 2014), agencies should consider all threat sources and potential consequences on an asset before determining the overall business impact from the asset’s compromise or loss. The Capability Implementation Plan should give priority to mitigating risk to assets which, when compromised, will have an unacceptable impact to the business of the organisation. The PSPF requires that agencies apply the risk management methodology detailed in SAI Global – AS/NZS ISO 31000:2009 Risk management – Principles and guidelines and SAI Global – HB 167:2006 Security risk management to assess their security risks (Protective Security Policy Committee, Attorney-General's Department, 2012). It is often difficult for teams in large organisations to determine how deploying, or not deploying a certain patch impacts risk to the organisation, and how to best prioritise its

deployment. Even though vendors provide advice on the urgency of patch deployment, each agency should use a risk-based decision making approach to make IT security-related risk decisions. Vendor attributes should be inputted into the decision making process as well. Taking a risk-based approach to security update management means using knowledge of a particular security vulnerability, as well as mitigating and environmental factors, to determine the level of risk posed to the organisation. Understanding the risk posed by a specific vulnerability enables informed decisions about priority, resources and deployment schedule. Deployment Timeframes for Patches Challenge: It is not possible to deploy patches to production within 2-days. Testing takes too much time and change control can add days/weeks to the timeframe. The Information Security Manual has two primary controls that cover deployment timeframes of software security updates. ISM Control 1144, describes deploying updates, which are described as ‘extreme risk’ within the 2-days. ISM Control 0940 indicates that all security updates should be installed “as soon as possible”. During an assessment of the as-is process documentation, the following areas generally stand out for time consumption: • Time required for testing of the patches • Time required for going through the

agency’s change control and release management processes.

Even though these are two very important aspects of the overall process, it is beneficial that they be performed in the context of the


overall process objective - to mitigate the risk to the production environment. Every minute that the patches are undergoing testing or going through the agency’s change management process, there is an increased risk that the vulnerability in the production environment may be exploited. It is crucial to find the right balance between the amount of testing required to mitigate the risk of patching and the risk of having the vulnerability exploited on production systems. The following activities can assist with improving the time to deploy: Assess the requirement for each activity

within the “as-is” workflow. Calculate the effort required to perform the activity and determine if that activity is essential in the achievement of the objective of the process. Removal of non-critical activities from the core process.

Identify activities that can be performed in parallel. Apply these parallel optimisations even to individual process steps. (E.g. Can test plan steps be sequenced differently to optimise without compromising quality? Apply these parallel optimisations even to individual process steps. (E.g. Can test plan steps be sequenced differently to optimise without compromising quality?)

Identify and agree on what is the appropriate amount of testing required to mitigate the risk to production. Streamlining the testing effort can significantly improve the time to deploy.

Utilise the Standard Change provision within the agency’s Change Management process. As these changes are typically pre-approved, significant time can be saved in eliminating the Change Advisory Board (CAB) lead timeframes, dependency on

CAB sitting times and required documentation.

Assume a positive path through the process flow assuming that ‘all will go as planned’. Only disrupt the positive flow if there is a show-stopping event which adds unacceptable amount of risk to the process outcome. Here are a few examples: Once the patch release windows have

been published, consider business approval to commence by default unless approached by the business area with a valid business case. Once the patch release windows have been published, consider business approval to commence by default unless approached by the business area with a valid business case. Once the patch release windows have been published, consider business approval to commence by default unless approached by the business area with a valid business case.


Streamline the Patching Process Challenge: We already have a patch process, but it doesn’t seem to be giving us optimised results. The details around patch deployment activities are typically the responsibility of the technical resources responsible for BAU maintenance of the system (Server OS, applications, SOE, etc.), thus there may be a varied set of approaches to patching within a single agency. Approaches that have grown organically offer an opportunity for consolidation. There are benefits in designing a streamlined approach for services/systems that require patching within the agency. Here are a few techniques that can be helpful when streamlining the process: Have a strong process baseline with

activities identified within a workflow. Brainstorming and white boarding are very effective techniques that can be used to capture the extant approach.

Defining the inputs and outputs of each captured activity step will assist in linking each activity to the previous one and the following activity. This can assist with the value identification of each of the activity steps. Six-Sigma SIPOC is one of the common technique used to achieve this.

Analyse the agency’s patching capability, documenting individual steps and eliminate steps that do not deliver value. Lean IT (Value-Stream Mapping) uses a diagram based approach to represent the process flow activities for analysis.

A RACI matrix can be used to clearly specify for each activity, who is: o R – Responsible o A – Accountable o C – Consulted o I – Informed

Guidance from the following processes within your agency (based on the ITIL processes) may assist the creation of the security patch management process: o Change Management, Release and

Deployment Management, Asset and Configuration Management, Validation and Testing Management (OGC, 2011)

o Information Security Management (OGC, 2011)

o Incident Management, and Problem Management processes (OGC, 2011).

Assess Compliance & Reporting Once a security patch management process has been defined for the agency, it is important to agree on measures of success for the process – Key Performance Indicators (KPIs). The resulting performance of the process is a function of the inputs, being the policy, process, procedures, and the decisions made in execution. The KPIs will assist with the measurement of the effectiveness of the process and will provide further visibility into how much improvement may be required for the processes to be able to meet the policy objectives.

o Release and Deployment Management, o Asset and Configuration Management,

Validation and Testing Management, Information Security Management, Incident Management, and Problem Management processes.


Minimising Impact Downtime for Business-Critical Applications Challenge: Deploying patches will impact our business critical applications. We cannot afford to take them offline. Ensure that patching requirements have been taken into consideration during the service development phase. System attributes like availability, capacity, performance, reliability should all be taken into account and captured upfront as non-functional requirements. Systems with such availability requirements can be designed such that components can be maintained either in sequence, or in parallel without a complete outage of the service. Where business expects a service to remain available during proactive maintenance, the design of the service should support this

requirement. An individual system’s maintenance should not equate to a service outage. Having automated deployment tools can also assist with reducing the downtime for application servers and the administrative overhead of sequencing patch deployment activities for complex workloads. Keeping each server outage to a minimum can be achieved by ensuring that there is a good understanding of the dependencies between the various components of a service/system and that the correct restart/start-up procedure is known. Having appropriate documentation can also assist with ensuring that instructions for managing activities is clear. Any lessons learnt which can assist with reducing downtime should be clearly documented within the deployment procedures.


References Australian National Audit Office, n.d. About Us. [Online] Available at: http://www.anao.gov.au/About-Us Australian Signals Directorate, 2013. Assessing Security Vulnerabilities and Patches. [Online] Available at: http://www.asd.gov.au/publications/csocprotect/assessing_security_vulnerabilities_and_patches.htm Australian Signals Directorate, 2014. ISM - Information Security Manual. [Online] Available at: http://www.asd.gov.au/publications/Information_Security_Manual_2014_Controls.pdf Batchelder, D. et al., 2013. Microsoft Security Intelligence Report - Volume 16, s.l.: Microsoft. Commonwealth Consolidated Acts, 1983. Archives Act 1983. [Online] Available at: http://www.austlii.edu.au/au/legis/cth/consol_act/aa198398/ [Accessed 2015]. Ferris, K., 2011. Balanced Diversity - A Portfolio Approach to Organisational Change. London: The Stationery Office. International Standards Organisation, 2009. International Stanard ISO31000. Geneva: ISO copyright office. Microsoft Operations Framework, 2008. Microsoft Operations Framework (MOF) 4.0. [Online] Available at: http://www.microsoft.com/en-us/download/details.aspx?id=17647

Microsoft, 2010. Microsoft Solution Accelerators - Service Mapping (Microsoft Operational Framework). [Online] Available at: http://download.microsoft.com/download/6/5/8/658BC1E9-E262-45CA-BB6E-E87C058BBD37/MOF%20Service%20Mapping.docx [Accessed 2015]. Microsoft, 2014. Security TechCentre - Microsoft Exploitability Index. [Online] Available at: http://technet.microsoft.com/en-us/security/cc998259.aspx [Accessed 2015]. Microsoft, 2015. Security Intellegence Report. [Online] Available at: http://www.microsoft.com/sir Microsoft, n.d. Definition of a Security Vulnerability. [Online] Available at: http://technet.microsoft.com/en-us/library/cc751383.aspx [Accessed 2015]. OGC, 2011. ITIL Service Design. 2011 ed. Norwich: The Stationary Office. OGC, 2011. ITIL Service Operations. 2011 ed. Norwich: The Stationery Office. OGC, 2011. ITIL Service Transition. 2011 ed. Norwich: The Stationary Office (TSO). Protective Security Policy Committee Attorney-General's Department, 2014. Protective Security Governamnce Guidelines - Business Impact Levels. [Online] Available at: http://www.protectivesecurity.gov.au/govern


ance/security-risk-management/Pages/Businessimpactlevelsguidelines.aspx Protective Security Policy Committee, Attorney-General's Department, 2012. Protective security better practice guide - Developing agency protective security policies, plan and procedures., ACT 2600: Australian Government. Protective Security Policy Section, 2011. Protective Security Policy Framework. [Online] Available at: http://www.protectivesecurity.gov.au/informationsecurity/Documents/Information%20security%20management%20protocol%20-%20INFOSEC%204%20amendment%20-%20April%202013.doc Scott, D., n.d. Operations Zero Time, s.l.: Gartner Security Conference.

Serna, F. J. & Roths, A., 2010. Security TechCenter - Using the Enhanced Mitigation Experience Toolkit to Safeguard Against Zero Days. [Online] Available at: https://technet.microsoft.com/en-us/security/gg524265.aspx [Accessed 2015]. The International Organisation for Standadization, 2011. ISO/IEC 27005:2011. [Online] Available at: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=56742 U.S. Department of Defense, 2009. Software Protection Initiative. [Online] Available at: http://www.spi.dod.mil/tenets.htm

Append

ix


Glossary Asset Any resource or capability. The assets of a service provider include anything that could contribute to the delivery of a service. Assets can be one of the following types: management, organisation, process, knowledge, people, information, applications, infrastructure or financial (OGC, 2011). Emergency Change A change that must be implemented as soon as possible – for example to resolve a major incident or implement a security patch. The change management process will normally have a specific procedure for handling emergency changes (OGC, 2011). Normal Change A change that is not an emergency change or a standard change. Normal changes follow the defined steps of the change management process (OGC, 2011). Patch A piece of software designed to fix problems with, or update, a computer program or its supporting data. This includes fixing security vulnerabilities and other program deficiencies and improving the usability or performance of the software (Australian Signals Directorate, 2014). Service Level Requirements An agreement between an IT service provide and a customer. A service level agreement describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer. A single agreement may cover multiple IT services or multiple customers (OGC, 2011). Standard Change A pre-authorised change that is low risk, relatively common and follows a procedure or work instruction – for example, a password reset or provision of standard equipment to a new employee. Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request (OGC, 2011). System Owner The System Owner is the person responsible for an information resource. While the system owner is responsible for the operation of the system, they will delegate the day–to–day management and operation of the system to a system manager or managers. While it is strongly recommended that a system owner is a member of the Senior Executive Service, or in an equivalent management position, it does not imply that the system managers should also be at such a level (Australian Signals Directorate, 2014). Technical Service Owner An IT service that is not directly used by the business, but is required by the IT service provider to deliver customer-facing services (for example, a directory service or a backup service). Supporting services may also include IT services only used by the IT service provider. All like supporting services, including those available for deployment, are recorded in the service catalogue along with information about their relationships to customer-facing services and other CIs (OGC, 2011). Threat Any circumstance or event with the potential to harm an information system through unauthorised access, destruction, disclosure, modification of data, and/or denial of service. Threats arise from human actions and natural events (Australian Signals Directorate, 2014). Vulnerability A weakness of an asset or group of assets that can be exploited by one or more threats where an asset is anything that has value to the organisation, its business operations and their continuity, including information resources that support the organization’s mission (The International Organisation for Standadization, 2011).

Append

ix


Appendix I – Assessing System Risk

Figure 17: Example Risk Calculation Logic A number of available Risk Management frameworks can be used to identify and manage the risks associated with patching and security vulnerabilities. This document takes guidance from ISO 31000:2009, which is mandated by PSPF as the Risk Management standard for Australian Government. It is recommended that each agency use the Risk Management practices adopted within their agencies to address risk associated with patch management. The sections below provide guidance, examples, and factors to consider as part of a risk-based approach to addressing patch management. Risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated likelihood, and can be calculated using a risk matrix (The International Organisation for Standadization, 2011). This section offers suggestions on how to calculate the likelihood (Exploit Likelihood) and consequence (Maximum Business Impact) to be used in the agencies risk assessment. In order to help make an informed decision about exploit likelihood, vendors often publish data that seeks to articulate the likelihood that functioning exploit code will be observed in the immediate future. This data can be consumed by organisations to help address the likelihood component of the risk assessment. As an example, Microsoft publish attributes such as the exploitability index and a severity rating. These attributes both contain elements that can influence the assessed exploit likelihood for a given vulnerability in a system. According to PSPF’s Business Impact Levels (BILs) document “The highest impact from the compromise of confidentiality, integrity or availability should be the BIL assigned to the resource or aggregation or resources” (Protective Security Policy Committee Attorney-General's Department, 2014).In this example approach, the systems Business Impact Level captures the Maximum Business Impact of a system vulnerability, and informs the consequence component of future vulnerability risk assessments.

Append

ix


The System Owner should seek guidance from the agency’s Risk Management capability area and IT Security to make sure that the risk matrix is used appropriately. Step 1 - Calculating Maximum Business Impact (MBI) The impact of the system compromise may be calculated using BILs (Protective Security Policy Committee Attorney-General's Department, 2014), which can be used as the Maximum Business Impact for a specific system of a given classification. As an example, it may be assessed that the Business Impact Level of the Exchange messaging system carrying information of a protected classification has a Business Impact Level of 4 (Extreme), based on the Business Impact Level descriptors defined for the organisation. This knowledge forms the understanding of the Maximum Business Impact (consequence) of the system, which will go on to inform the risk assessment of future vulnerabilities. Step 2 - Calculate Exploit Likelihood (EL) In Risk Management terminology, the word likelihood is used to refer to the “chance of something happening, whether defined, measured or determined objectively or subjectively, qualitatively or quantitatively and described in general terms or mathematically (such as a probability or a frequency over a given time period)” (International Standards Organisation, 2009). Here is an example of risk likelihood descriptors:

Likelihood Description 1 (Rare) There is no indication of any threat to the agency. Action is assessed as very unlikely. 2 (Unlikely) Credible intelligence indicates that threat sources currently have little capability or intent to target the agency. Action is assessed as unlikely. 3 (Possible) Credible intelligence indicates that the agency is a possible target of threat sources that have either limited intent or limited capability or both. Action is assessed as possible but is not expected. 5 (Likely) Credible intelligence indicates a current intention and capability to conduct action against the agency. Action is assessed as likely. 6 (Almost Certain) Credible specific intelligence indicates a current intention, capability and planning to conduct action against the agency. Action is certain.

Table 2: Example risk likelihood descriptors Known risk determinants from various sources, including the vendor-defined attributes describing anticipated exploitability and urgency should be consumed to form a model for attributing likelihood to future published vulnerabilities. It is important that this model for attributing exploit likelihood is compatible with the organisations established risk management practises.

Append

ix


Step 3 - Calculate Risk Risk matrices like the risk matrix shown in the example below are a standard tool used in risk management. These matrices are normally applied consistently within an organisation to maintain a consistent approach to risk-based decisions. This step (calculate risk) is performed reactively, once a vulnerability and the associated security update are released. The aim is to attribute a risk rating to the vulnerability in order to prioritise its deployment, and to be able to engage in risk-based conversations using risk descriptors that are used organisation-wide. The impact assessment should be informed by and should directly correlate with the Maximum Business Impact assessed for the system in Step 1 – Calculate Maximum Business Impact. The likelihood assessment should be informed by the model created in Step 2 – Calculate Exploit Likelihood.

Impact Likelihood 1 2 3 4 5

1 Low Low Low Medium Medium 2 Low Low Medium Medium High 3 Low Medium Medium High High 4 Medium Medium High High Extreme 5 Medium High High Extreme Extreme

Table 3: Example risk matrix Step 4 – Consider mitigating factors To achieve an accurate understanding of the residual risk, agencies may also consider existing mitigating factors already deployed within the agency’s environment. Some of examples of mitigations that may reduce the likelihood of exploitation are: • Application whitelisting is implemented within the environment • Content types are blocked by the messaging service • The environment is air-gapped from the Internet and less secure networks, and • Other mitigations (See ASDs Top 35 Mitigations for Targeted Cyber Intrusion).

Append

ix


Appendix II – Security Patch Management Process Document Outline Purpose The security patch management process describes how the agency will carry out security patch management and the roles and responsibilities of people who perform security patch management-related activities. The creation of the security patch management process is the responsibility of the process owner within the agency (as defined in the policy), who may engage various disciplines within the agency to define the process. Document Composition Typically, a security patch management process will include the following: Process Objective This section would describe the purpose and objective of the security patch management process. Security Patch Management Process Flow and Procedures This section should detail the process workflow, along with the detailed step guidance for each activity step. Inputs, outputs and the responsible party for each activity should also be clearly defined. A sample process workflow is described in the Security Patch Management Detailed Step-Guidance section of this document and can be tailored to implement the agency’s security patch management policies. A process should address the high-level patch management activities, but should not go down to the level of system-specific, or

toolset-specific deployment procedures. See Appendix V – Security Patch Management Plan Document Outline. Roles and Responsibilities This section contains the matrix for defining who within the agency is Responsible, Accountable, Consulted and Informed during each of the activities outlined in the security patch management process. Mitigation Timeframes What are the timeframes for implementing the security patch management policies for the various systems with the agency? The capability Implementation Plan will take guidance from the strategy to develop their implementation cycles. Key Success Indicators This section will contain the indicators which measure the effectiveness of the process. Some common measures for security patch management may include: • Vulnerability window for ‘Extreme Risk’

patches (ISM Control 1144 specifies 2 days) • Percentage of patches scheduled to be

released within the deployment timeframe • Incidents caused by patch installation • Number of emergency changes raised to

deploy patches • Number of deferral reports raised Agencies should design the relevant indicators to make sure they are able to measure the effectiveness of the process against the approved policy in an efficient manner.

Append

ix


Appendix III – Capability Implementation Plan Document Outline Purpose The Capability Implementation Plan (CIP) describes the detailed activities required to bring the agency’s IT systems to the required compliance levels. The document is typically owned by IT Security with the various System Owners contributing to the system specific content. The document outlines the body of work that need to occur to implement the capability, focusing on prioritising the high-risk components of the agency’s environment. Document Composition Typically, the CIP will include the following: Introduction This section of the document will list all the services/systems that have been analysed by IT Security, their ownership information and the priority for the agency to address security patch management for the service/system (high, medium, low). Inventory Clearly articulate all systems in their respective priorities (priority 1, priority 2… Priority n) to make sure that there is clear understanding of which systems need to be prioritised first. Implementation Schedule This section should discuss the timeframes for bringing the systems under the compliance of the security patch management process. The Implementation schedule should discuss the following topics:

• Major tasks that need to be executed for the implementation to be successful

• Schedule for the implementation of the above identified tasks

• Budget and resource requirements • Training and side-by-side support • Changes to tools/implementation of new

tools • Expected impact • Measuring project success. Stakeholder Management What stakeholders need to be consulted, involved in the development of the Capability Implementation Plan? What roles will they play? Are they supporters of the initiative or do they need to be brought on-board. What tools are available, and what tools need to be procured?? Communications The document should discuss the creation of a Communications Plan as well as how the change will be managed within the organised so it ‘sticks’ (see section Embedding the Security Patch Management Capability for further information). Signoff Clearly document the commitment from the senior executive, capability owner and the areas responsible for execution. Having a signed-off Implementation Plan often assists with resource, time and cost commitments from the implementation teams, especially if the implementation is run as a project.

Append

ix


Appendix IV – Security Patch Management Deferral Notice Document Outline Purpose The ISM discusses the topic of provisional, documented, and approved non-compliance to policy controls. Given the appropriate approval and remediation plan, compliance may be deferred for a limited period. The security patch management deferral notice captures the non-compliance to the agency’s security patch management process and any associated deployment timeframes mandated by the ISM controls, as defined by the agency’s security patch management policy. The deferral notice document is the formalisation of an in-principle agreement between IT Security (under the delegation of the Accreditation authority) and the System Manager to defer a patch deployment and thus compliance to ISM controls relating to deployment timeframes. It is important that IT Security track all outstanding action items against their due by dates to encourage System Owner accountability for remediation activities. Document Composition The security patch management deferral will include the following sections: Deferral Details The section records information about the request being made. The following information should be captured within this section: • Identifiers of affected systems • System Manager • System Owner

Impact Definition This section will capture the risk associated with the non-compliance: • Identifier of deferred patch • Deferral period • Mitigating controls and residual risk • Factors driving non-compliance • Business services that are exposed due to

the system remaining unpatched • Business functions at risk to the system

remaining unpatched • Business function owner who has agreed

to the deferral (Non IT Branch Head) • Remediation plan – Including activities and

planned dates. IT Security Risk Assessment The risk of the deferral must be accurately captured and understood before an informed risk-based decision can be made. It is important that the risk associated with deferred, documented non-compliance is reviewed by IT Security. This section should include: • IT Security’s assessment of the residual risk • Recommendations on the Deferral Notice

including restrictions and special conditions.

Recording Approval IT Security should take into account various compliance aspects when assessing a deferral to ensure that the documentation is sufficient, and that the level of risk is acceptable before recording their approval.

Append

ix


Appendix V – Security Patch Management Plan Document Outline Purpose A process covering security patch management would generally not detail service-specific or system-specific attributes and procedures, and would instead focus on more high-level process activities. This system-specific information should be readily available in a more lightweight reference document. The security patch management plan document put forward in this approach captures all service-specific and system-specific information, including system-specific procedures for patching the system/service. The security patch management plan should be used in conjunction with the process to bring the service-specific and system-specific information to the approach. Document Composition The security patch management plan includes the following sections: Introduction The introduction will state the purpose of the system and how it supports the agency’s business functions and objectives. It should assist with understanding the business impact of a compromise to the system’s confidentiality, integrity or availability.

3 “While it is strongly recommended that a system owner is a member of the Senior Executive Service, or in an equivalent position, it does not imply that

Service Information This section is a brief description of the service including: • Service name • Service objectives – Description of how the

service will assist with the agency’s business achieve their outcomes

• Service Owner – Agency executive accountable for operations of the service

• Service composition – The list of systems that compromise the service and the interdependencies between the systems.

Adding a Service Map (Microsoft, 2010) is a good way to capture the various components within the service and can assist with the identification of the supporting systems. System Attributes Repeat this section for each system comprising the service. This section details each system including: • System name • System objectives – Description of how the

system assists the service in achieving the service objectives

• System Owner – Band 1 executive, usually the branch head3

the system managers should be at such a level” (Australian Signals Directorate, 2014).

Append

ix


Vendor Information This section is to be repeated for each vendor represented in the system. Capture the following vendor information: • Vendor name • Vendor product update website • Primary and alternate security bulletin

information sources • Patch release schedule • Authoritative source of security patches • Patch access information (if appropriate) Patch Prioritisation Refer to Appendix I – Assessing System Risk for information on how to create content for this section. • Maximum Business Impact (MBI) • Exploit Likelihood (EL). Patch Implementation Procedures This section captures all of the information required to perform the implementation, such as: • Test strategy and test plan • Piloting requirements (targeted end points

or phased releases) • Deployment procedures • Back out plan and procedures • Business verification (if required). Deployment Tracking As part of system on-boarding, create a baseline of the expected rates of distribution and installation of patches for the system. Depending on a number of environmental factors, system compliance over time will often follow a familiar trajectory, approaching similar limits at a similar rate. Understanding this performance characteristic is important to the monitoring exercise and understanding if there are potential new issues.

For example, it may that for a given system there is an expected compliance rate of 80% after 48 hours since deployment commenced. This anecdotal information is important to the ongoing monitoring exercise. Governance & Reporting This section documents the IT Service Management requirements (Service Transition (OGC, 2011)) to be considered during the operation of the security patch management process including: • Change control reference • Release & deployment windows • Business end user notification email

template • Reporting (discussed in section A.1 Report

of Security Patch Management Detailed Step-Guidance).

Resource Management This section documents the resourcing requirements to complete the patching activities assigned to the team. This also enables the team to commit the resources in advance for all patching activities.

Append

ix
