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
Chris Tuite
Clinton Temple
David Cottingham
David Jansen
Glen Wareing
Grant Holliday
James Kavanagh
Jason Waddell
Joseph Marino
Joy Hines
Marc Dudok
Martin Morrison
Neil Ladbrook
Nick Eichner
Regina Jagiello
Ronel Vosloo
Russell Stevens
Scott Deacon
Yen Chiu Chin
Ziggy Nemeth
Senior Premier Field Engineer, Microsoft
Support Practice Manager, Microsoft
Principal Service Delivery Manager, Microsoft
Security Consultant, Foresight Consulting
Senior Premier Field Engineer, Microsoft
Senior Enterprise Architect, Microsoft
Senior Service Engineer, Microsoft
National Security Officer, Microsoft
Senior Technical Account Manager, Microsoft
Service Management Consultant, Microsoft
Service Management Consultant, Microsoft
Senior Premier Field Engineer, Microsoft
CSS Manager, Microsoft
Senior Service Delivery Manager, Microsoft
Senior Consultant, Microsoft
Associate Delivery Project Manager, Microsoft
Senior Service Management Consultant, Microsoft
Senior Premier Mission Critical Engineer, Microsoft
Security Architect, WW Public Sector, Microsoft
Premier Field Engineer, Microsoft
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
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.
1
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.
•
Audience
The target audience for this document
includes, but are not limited to:
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.
• 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.
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
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.
Manual is the most current publication
released by the Australian Signals Directorate.
1
2
© Microsoft Corporation. All rights reserved.
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.
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.
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 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.
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
3
© Microsoft Corporation. All rights reserved.
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.
Figure 1: Industry wide vulnerability disclosure, 1H112H13
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
4
© Microsoft Corporation. All rights reserved.
Security Patching and the ISM
ISM Patching Controls
vulnerability information and software
updates are known and that these channels of
communication are reliable.
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.
‘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).
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
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 2days of release or an appropriate mitigation
be put in place to address the risk.
Determining which patches pose an extreme
5
© Microsoft Corporation. All rights reserved.
level of risk to the business of the agency is
critical to the security of the service.
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.
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 zeroday vulnerabilities suggests that the
timeliness of software update deployment is a
critical factor in its effectiveness to improve
security.
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.
Figure 2: Microsoft remote code execution CVEs, 20062013, 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
6
© Microsoft Corporation. All rights reserved.
ISM Compliance and Reporting
those duties (Australian National Audit Office,
n.d.).
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 AttorneyGeneral’s Department and the AuditorGeneral of ANAO, accompanied by rationale
for non-compliance.
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.
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).
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 noncompliance 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 noncompliance (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.
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
ASD mandates a requirement for agencies to
provide reports of non-compliance to ASD
7
© Microsoft Corporation. All rights reserved.
(ISM Control 0713). The purpose of notifying
authorities to grant non-compliance is:
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 noncompliance 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).
• 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.
8
© Microsoft Corporation. All rights reserved.
Enterprise Patch Management Approach
Where are we now?
Microsoft has developed an approach to
implement a security patch management
capability within both the private and
government sectors.
Step 1.
The approach is delivered with the following
3 phases:
Where are
we now?
1. Develop a
baseline of
current patch
capability
Where do
we want to
be?
2. Develop a
security patch
management
policy & process
How do we
get there?
3. Implement
and review a
patch
management
improvement
program
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.
Step 3.
Figure 3: Approach Phases
Develop security patch
management policy
Develop security patch
management process
How do we get there?
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.
Step 4.
Step 5.
Step 6.
Step 7.
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.
Develop a Capability
Implementation Plan
Configure the toolsets to support
the process
Implement new process and
measure performance
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.
9
© Microsoft Corporation. All rights reserved.
10
© Microsoft Corporation. All rights reserved.
1
Step 1: Baseline current
capability
 Are agency management supportive of
security initiatives?
 Are patching requirements understood
during the ‘requirements gathering’ phase
of a system being designed?
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.
 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?
People
Process
Agencies should consider the following
people elements of the extant approach:
 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?
 Who owns the security patch
management policy within the agency?
Where is it documented and how is it
accessed?
How do the following Service Management
functions work to enable and effective patch
management approach:
 Who owns the security patch
management process within the agency?
Where is it documented and how is it
accessed?
 Change Management - Including
provision for Standard Changes
relating to security patching
 Which personnel are performing security
patching activities within the agency? Has
process training and policy awareness
been provided?
 Release & Deployment Management With relation to regular deployment
windows available for patching
 What are the people’s impressions about
how effective the process is?
 Asset & Configuration Management Cataloguing all software and hardware
assets that may require patching and
the patch state of each
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.
 Incident Management - How well are
security patch related incidents
handled?
11
© Microsoft Corporation. All rights reserved.
 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?
 What can be automated? How much of
the current practices have already been
automated?
 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-ofband 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?
12
© Microsoft Corporation. All rights reserved.
2
Step 2: Develop a Security
Patch Management Policy
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.
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.
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.
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.
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.
 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?
 Identify any security patch management
related policy statements in the agency’s
security manual (clarify if required).
 Risk Based Decision Making – How a risk
based decision making regime be
implemented? What Risk matrices are
available within the agency?
 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.
 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?
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.
 Reporting – What reporting is required to
measure the success of the policy
implementation? How will the data be
obtained and processed?
13
© Microsoft Corporation. All rights reserved.
3
Step 3: Develop a Security
Patch Management Process
comprehensive security patch management
process is essential in mitigating these issues.
There are a number essential elements in 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.
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.
Research shows that 80% of all issues in IT
operational environments are related to
people and process (Scott, n.d.). Having a
Figure 4: Example Security Patch Management Process
14
© Microsoft Corporation. All rights reserved.
Assess
Identify
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.
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.
A system has been brought under the
security patch management process, or onboarded once the following have been
completed:
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.
 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
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.
 Test, implementation, and back-out
procedures have been articulated
 The above information and other systemspecific 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).
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.
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.
15
© Microsoft Corporation. All rights reserved.
Evaluate & Plan
Effectively evaluating the patches released
will assist with the planning activities:
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:
• 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.
• 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).
Building the patch release plan should take
into account the:
 Scripts, tools and procedures followed by
the system administrators to build the
release package
Using the outcome from the above criteria
and the risk management framework within
the agency, a risk rating for the patch should
be created.
 What level of testing is suitable for the
system?
Deploy
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.
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.
16
© Microsoft Corporation. All rights reserved.
4
Step 4: Develop a Capability
Implementation Plan
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:
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.
 Develop a strong business case
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:
 Define a clear end-state
 Define the work packages, schedule, and
deliverables out of the plan/project
 Stakeholder management plan
 Communications plan
• 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).
 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?
Most agencies have a combination of
Microsoft and other vendor technologies in
their environments. While patching a
complete environment can be a daunting
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.
17
© Microsoft Corporation. All rights reserved.
5
Step 5: Configure the
Technology
• 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.
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.
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?
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.
 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?
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.
18
© Microsoft Corporation. All rights reserved.
6
7
Step 6: Implement Process and
Measure Process Performance
Step 7: Conduct PostImplementation Review
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.
After each cycle of improvements
made to the people, process or
technology components of the
solution, it is valuable to conduct a PostImplementation 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.
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:
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.
 How well is the new process performing
compared to the previous one?
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.
 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.
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?
19
© Microsoft Corporation. All rights reserved.
Developing a Security Culture
Embedding 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).
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.
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.
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:
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.
 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.
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
 Communicate the need for the security
patch management process and the
20
© Microsoft Corporation. All rights reserved.
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.
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.
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.
 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.
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.
 As required, continue to provide technical,
process and other required support to the
operations teams.
 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).
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.
What is required to change?
 Send direct feedback from senior
executives as well as the project sponsor
to all staff acknowledging achievements.
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.
 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.
 Regularly check to make sure that process
and technology training has had the
21
© Microsoft Corporation. All rights reserved.
Security Patch Management Detailed StepGuidance
This 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
22
© Microsoft Corporation. All rights reserved.
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
For each new service, identify:
Performed by – System Manager
 Technical Service Owner accountable for
the service delivery.
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.
 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:
23
 System Name (and service name if the
system is inherently a part of a Technical
Service)
© Microsoft Corporation. All rights reserved.
 System Owner – The branch head2 that is
accountable for day-to-day operations of
the system.
 Configuration Items (CIs) included within
the scope of the system. Update the
agency’s asset and configuration
management database as the information
is collected.
 System Manager – The Director2 or an
appropriate delegate responsible for
operations of the system
Each systems within the agency should have a
risk profile created. This would include
attributes such as:
 System Administration Team2 – The team
responsible for day-to-day operational
activities for the system
 Business teams using the system and the
business impact of the system not being
available
 System Build Team2 (if appropriate) the
team that will be responsible for building
the deployment package if the patches are
being deployed manually.
 The operating systems and applications
that underpin the system – including their
risk profiles
 System Test Team2 will develop the test
plan/strategy and will execute the test
cases.
 The frequency of security patch releases
for the system and how to consume the
security notifications
 System Business Verification Team2 is
responsible for validating the production
readiness of the system and dependent
business services post patch installation
 Distribution and deployment timeframes
required for the security patches relating
to the system using the designated patch
deployment method.
 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
These are recommended performing roles
(functions) only and may not be actual separate
2
24
teams/roles. Smaller agencies may have a single
team/roles performing multiple set of activities.
© Microsoft Corporation. All rights reserved.
1.1.3 Define Impact Matrix
potential risks that may cause the agency to
not deploy patches in a timely manner to all
the required agency assets.
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.
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.
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.
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.
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.6 Compile Security Patch Management
Plan
1.1.4 Identify Risks to Patching
Performed by – System Manager
Performed by – System Manager
The system patch management plan captures
all the information collected during the onboarding 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.
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
25
© Microsoft Corporation. All rights reserved.
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.
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:
Always make sure that there are multiple
people monitoring the vendor alerts in case
the primary person is not available.
• 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 preapproved release schedule with their IT
and Business areas. Having pre-approved
windows enable agencies in using a
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
26
© Microsoft Corporation. All rights reserved.
Centralised vs Distributed Model for Patch
Selection
‘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 preassigned 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.
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.
Pros



Cons




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.
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.
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.







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.
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
27
© Microsoft Corporation. All rights reserved.
2.2 Validate priority
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.
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.
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.
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
28
© Microsoft Corporation. All rights reserved.
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
Standard Change as the mechanism typically
used for activities like patching. Use of
Standard Changes may assist with:
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
 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.
29
Standard Changes typically do not require
submission to the Change Advisory Board
© Microsoft Corporation. All rights reserved.
(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 preapproved, with no additional approval
required.
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.
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.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.1.2 Assign Deployment Window(s)
Performed by – System Manager
Assign deployment window(s) for the
deployment of the patches based on a preagreed 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
30
© Microsoft Corporation. All rights reserved.
3.2 Build Patch Release Package
Figure 9: 3.2 Build Patch Package Activity Flow Diagram
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.
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.
Performed by – System Build Team
Performed by – System Build Team
3.2.1 Acquire Patches
Performed by – System Build Team
3.2.3 Install to Dev Environment
3.2.2 Build Release Package
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.
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
31
© Microsoft Corporation. All rights reserved.
3.3 Test Patch Package
Figure 10: 3.3 Test Patch Package Activity Flow Diagram
organisations assets at serious risk of
compromise.
3.3.1 Install Patches in Test Environment
Performed by – System Test Team
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.
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).
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.3 Assess Residual Risk to Production
Performed by – System Manager
3.3.4 Issue Testing Endorsement
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
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.
32
© Microsoft Corporation. All rights reserved.
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
4.1.2 Install Patches
Performed by –Deployment Team
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.
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.
33
© Microsoft Corporation. All rights reserved.
4.2 Escalate Issues
Figure 12: 4.2 Escalate Issues Activity Flow Diagram
4.2.2 Notify Intent to Continue
4.2.1 Seek IT Security Input
Performed by – System Manager
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.
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.
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.
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.
34
© Microsoft Corporation. All rights reserved.
4.3 Monitor Patch Distribution
Figure 13: 4.3 Monitor Deployment Activity Flow Diagram
 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.
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.
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).
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:
35
© Microsoft Corporation. All rights reserved.
A.1 Report
Figure 14: A.1 Report Activity Flow Diagram
IT Security Related Reports
A.1 Produce 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:
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:
 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
 Operational reports
 IT security related reports
 Executive and compliance.
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:
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:
 Indicators of compliance to ISM Controls
related to security patch management
 Deployment tool capability
 Indicators of level of undocumented,
uncontrolled non-compliance
 Availability, capacity and performance of
their patching infrastructure
 Security patch related achievements as
well as major risks to the agency’s security
patching environment.
 Deployment compliance
36
© Microsoft Corporation. All rights reserved.
A.2 Process Compliance Assessment
Figure 15: A.2 Process Compliance Assessment Activity Flow Diagram
 Hold Process Compliance Assessment kickoff meeting.
A.2.1 Identify System to Assess
Performed by – System Assessor
A.2.3 Conduct Compliance Assessment
The compliance assessment is a mechanism to
drive adherence to the process as specified in
the security patch management policy and
process.
Performed by – System Assessor
Conduct the assessment activities by
following the created checklist:
Identify systems to assess based on the
following suggestions:
 Check adherence to the agency’s security
patch management process and
procedures.
• High-value, high-risk systems
• Systems for which patch related Security
Incidents are being logged regularly.
• Systems where compliance state is
unknown or poor.
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:
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.
• Assessment and system overviews
• Assessment observations and finding
• Recommendations.
A.2.2 Plan Compliance Assessment
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.
Performed by – System Assessor
Plan for the patching process compliance
assessment:
 Document patching activities (meetings
and checklist)
 Create assessment schedule
37
© Microsoft Corporation. All rights reserved.
Common Implementation Challenges
Supportive IT Security Policies
Covering Security Patching
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.
Challenge: There is no buy-in from
management for the implementation of the
ISM controls within the agency.
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:
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.
• 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?
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
Figure 16: Encounter rates for different types of exploit
attempts in 2013
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
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.
38
© Microsoft Corporation. All rights reserved.
A Risk-Based Approach to
Security Patching
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.
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?
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.
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.
Deployment Timeframes for
Patches
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.
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”.
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).
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.
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
Even though these are two very important
aspects of the overall process, it is beneficial
that they be performed in the context of the
39
© Microsoft Corporation. All rights reserved.
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.
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.
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 preapproved, significant time can be saved in
eliminating the Change Advisory Board
(CAB) lead timeframes, dependency on
40
© Microsoft Corporation. All rights reserved.
Streamline the Patching Process
A RACI matrix can be used to clearly
specify for each activity, who is:
Challenge: We already have a patch process,
but it doesn’t seem to be giving us optimised
results.
o R – Responsible
o A – Accountable
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.
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)
Here are a few techniques that can be helpful
when streamlining the process:
o Information Security Management
(OGC, 2011)
 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.
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.
 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.
o Release and Deployment Management,
o Asset and Configuration Management,
Validation and Testing Management,
Information Security Management,
Incident Management, and Problem
Management processes.
41
© Microsoft Corporation. All rights reserved.
Minimising Impact Downtime
for Business-Critical
Applications
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.
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
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.
42
© Microsoft Corporation. All rights reserved.
References
Australian National Audit Office, n.d. About
Us. [Online]
Available at: http://www.anao.gov.au/AboutUs
Microsoft, 2010. Microsoft Solution
Accelerators - Service Mapping (Microsoft
Operational Framework). [Online]
Available at:
http://download.microsoft.com/download/6/
5/8/658BC1E9-E262-45CA-BB6EE87C058BBD37/MOF%20Service%20Mapping.
docx
[Accessed 2015].
Australian Signals Directorate, 2013. Assessing
Security Vulnerabilities and Patches. [Online]
Available at:
http://www.asd.gov.au/publications/csocprot
ect/assessing_security_vulnerabilities_and_pa
tches.htm
Microsoft, 2014. Security TechCentre Microsoft Exploitability Index. [Online]
Available at:
http://technet.microsoft.com/enus/security/cc998259.aspx
[Accessed 2015].
Australian Signals Directorate, 2014. ISM Information Security Manual. [Online]
Available at:
http://www.asd.gov.au/publications/Informat
ion_Security_Manual_2014_Controls.pdf
Microsoft, 2015. Security Intellegence Report.
[Online]
Available at: http://www.microsoft.com/sir
Batchelder, D. et al., 2013. Microsoft Security
Intelligence Report - Volume 16, s.l.:
Microsoft.
Microsoft, n.d. Definition of a Security
Vulnerability. [Online]
Available at:
http://technet.microsoft.com/enus/library/cc751383.aspx
[Accessed 2015].
Commonwealth Consolidated Acts, 1983.
Archives Act 1983. [Online]
Available at:
http://www.austlii.edu.au/au/legis/cth/conso
l_act/aa198398/
[Accessed 2015].
OGC, 2011. ITIL Service Design. 2011 ed.
Norwich: The Stationary Office.
Ferris, K., 2011. Balanced Diversity - A
Portfolio Approach to Organisational Change.
London: The Stationery Office.
OGC, 2011. ITIL Service Operations. 2011 ed.
Norwich: The Stationery Office.
International Standards Organisation, 2009.
International Stanard ISO31000. Geneva: ISO
copyright office.
OGC, 2011. ITIL Service Transition. 2011 ed.
Norwich: The Stationary Office (TSO).
Microsoft Operations Framework, 2008.
Microsoft Operations Framework (MOF) 4.0.
[Online]
Available at: http://www.microsoft.com/enus/download/details.aspx?id=17647
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
43
© Microsoft Corporation. All rights reserved.
ance/security-riskmanagement/Pages/Businessimpactlevelsguid
elines.aspx
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/enus/security/gg524265.aspx
[Accessed 2015].
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.
The International Organisation for
Standadization, 2011. ISO/IEC 27005:2011.
[Online]
Available at:
http://www.iso.org/iso/home/store/catalogu
e_ics/catalogue_detail_ics.htm?csnumber=56
742
Protective Security Policy Section, 2011.
Protective Security Policy Framework. [Online]
Available at:
http://www.protectivesecurity.gov.au/inform
ationsecurity/Documents/Information%20sec
urity%20management%20protocol%20%20INFOSEC%204%20amendment%20%20April%202013.doc
U.S. Department of Defense, 2009. Software
Protection Initiative. [Online]
Available at:
http://www.spi.dod.mil/tenets.htm
Scott, D., n.d. Operations Zero Time, s.l.:
Gartner Security Conference.
44
© Microsoft Corporation. All rights reserved.
Appendix
Glossary
Asset
Emergency Change
Normal Change
Patch
Service Level
Requirements
Standard Change
System Owner
Technical Service
Owner
Threat
Vulnerability
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
45
© Microsoft Corporation. All rights reserved.
Appendix
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.
46
© Microsoft Corporation. All rights reserved.
Appendix
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
2 (Unlikely)
Credible intelligence indicates that threat sources currently have little
capability or intent to target the agency. Action is assessed as unlikely.
1 (Rare)
3 (Possible)
5 (Likely)
6 (Almost Certain)
There is no indication of any threat to the agency. Action is assessed as very
unlikely.
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.
Credible intelligence indicates a current intention and capability to conduct
action against the agency. Action is assessed as likely.
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.
47
© Microsoft Corporation. All rights reserved.
Appendix
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.
Likelihood
1
2
1
Low
Low
3
Low
Medium
Medium
High
2
4
5
Low
Medium
Impact
3
4
5
Low
Medium
Medium
Medium
High
High
Low
Medium
Medium
High
High
Medium
High
Extreme
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).
48
© Microsoft Corporation. All rights reserved.
Appendix
Appendix II – Security Patch Management
Process Document Outline
Purpose
toolset-specific deployment procedures. See
Appendix V – Security Patch Management
Plan Document Outline.
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.
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.
Document Composition
Typically, a security patch management
process will include the following:
Process Objective
Key Success Indicators
This section would describe the purpose and
objective of the security patch management
process.
This section will contain the indicators which
measure the effectiveness of the process.
Some common measures for security patch
management may include:
Security Patch Management Process Flow
and Procedures
• 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
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 StepGuidance 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
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.
49
© Microsoft Corporation. All rights reserved.
Appendix
Appendix III – Capability Implementation
Plan Document Outline
Purpose
• 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.
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 highrisk components of the agency’s environment.
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??
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).
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).
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.
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.
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:
50
© Microsoft Corporation. All rights reserved.
Appendix
Appendix IV – Security Patch Management
Deferral Notice Document Outline
Purpose
Impact Definition
This section will capture the risk associated
with the non-compliance:
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.
•
•
•
•
•
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.
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.
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:
Document Composition
• IT Security’s assessment of the residual risk
• Recommendations on the Deferral Notice
including restrictions and special
conditions.
The security patch management deferral will
include the following sections:
Deferral Details
Recording Approval
The section records information about the
request being made. The following
information should be captured within this
section:
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.
• Identifiers of affected systems
• System Manager
• System Owner
51
© Microsoft Corporation. All rights reserved.
Appendix
Appendix V – Security Patch Management
Plan Document Outline
Purpose
Service Information
This section is a brief description of the
service including:
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.
• 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.
The security patch management plan
document put forward in this approach
captures all service-specific and systemspecific 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.
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:
Document Composition
The security patch management plan includes
the following sections:
• 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
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.
“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
the system managers should be at such a level”
(Australian Signals Directorate, 2014).
3
52
© Microsoft Corporation. All rights reserved.
Appendix
Vendor Information
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.
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)
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:
Patch Prioritisation
• 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).
Refer to Appendix I – Assessing System Risk
for information on how to create content for
this section.
• Maximum Business Impact (MBI)
• Exploit Likelihood (EL).
Resource Management
Patch Implementation Procedures
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.
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.
53
© Microsoft Corporation. All rights reserved.
Appendix
54
© Microsoft Corporation. All rights reserved.