Transcript Compliance and Change Management

Enforcing Compliance:
A Patch Management
Strategy That Works
1
Copyright Notices




ITIL® is a registered trademark of the UK
Office of Government Commerce.
Visible Ops is the trademark of the IT Process
Institute (http://www.itpi.org)
All other trademarks and company names are
the property of their respective owners.
This webinar is the property of Spafford Global
Consulting, Inc.
2
Overview






Patching Challenges
Policies and Procedures
Change Management
Release Management
Metrics
Questions and Answers
3
Question

Do you have a Change Management process?
1. Yes
 2. We are in the process of developing one
 3. No

4
Question

How familiar are you with the Information
Technology Infrastructure Library (ITIL) as it
pertains to Service Support?
1.
 2.
 3.
 4.
 5.

Not familiar
Have heard of it
Somewhat familiar
Familiar
Very familiar, refer to it routinely.
5
Patching Challenges







Patches are time consuming to assess and apply.
Patches are released constantly.
They fail during installation.
They cause services to fail.
One patch can undo another patch.
They can introduce errors.
Developing policies and procedures that work.
6
Policies and Procedures






We want to use standards to reduce variation
Standardization can help improve security and
compliance postures while managing costs
Policies and procedures need to be realistic and add
value
Shelfware achieves nothing – the policies and
procedures must be feasible and make a positive
difference (WIIFM)
Getting started is the hardest part. Use your best and
brightest people to develop policies and procedures.
So … where do we start?
7
Don’t rush to apply
patches immediately!
Uncontrolled change can
do more harm than good!
Many high-performing IT organizations do not
rush their patches and, in fact, patch less
frequently.
Moreover, they do not patch production systems
directly! They do so in pre-production.
8
Defense in Depth





Think of the rings of walls in a castle.
More walls equate to an overall better
defensive posture.
Processes, systems and people always
have variation – go for layers.
The idea is to layer controls in a cost
effective fashion.
If the first control fails, then there is a
second, etc.
Compensating Controls






Control 3
Control 2
Control 1
Firewall – perimeter and segments
Network Segmentation
Intrusion Detection Systems
Log Monitoring / Alerting / Security
Event Management (SEM)
Antivirus/Anti-malware on clients, hosts,
gateways
Integrity Management Systems
9
What are we really
talking about?
Change and Release Management
with support from Configuration
Management
10
ITIL Definitions



Change Management
Is the set of standardized processes and tools used to
handle change requests in order to support the business
while managing risks.
Release Management
Uses formal controls and processes to safeguard the
production environment.
Configuration Management
Focuses on tracking and documenting configurations
and then providing this information to other areas
including Change and Release Management.
11
Human Error is Huge!

May 17, 2005 – Third annual CompTIA study
shows human error still counts for the majority
of security incidents – 79.3%. That number is
virtually the same as 2004.
-- Comp TIA, 2005
http://www.comptia.org/about/pressroom/get_pr.aspx?prid=611

Human error accounts for 80% of network
availability issues. -- Stephen Elliott, Senior Analyst, Network and
Service Management, IDC 2004
12
Change Management is
the organization’s last
firewall against human
error and malicious
activity before
production.
13
Phase I: Ungoverned Change
Unplanned work
(Unplanned work >
100%)
Failed changes and/or
Number of
unauthorized changes
Change rate
time
Source: IT Process Institute, 2005
http://www.itpi.org
14
Phase I: Stabilized Patient
Unplanned work
Failed changes or
Num of unauth chgs
Change rate
time
Source: IT Process Institute, 2005
http://www.itpi.org
15
What does this mean?




If we can reduce the errors going into production, then
unplanned work can be reduced.
If unplanned work is reduced, then projects can get
done.
If projects can get done, then, hopefully, IT is enabling
the functional areas to move towards their objectives
and the organization towards its goal.
By patching, or introducing change, IT should be
adding value by enabling the business or assisting in the
mitigation of risks. With uncontrolled change, IT adds
risks.
16
Process References

For a definitive reference, see ITIL’s Service
Support Volume
http://www.ogc.gov.uk/index.asp?id=2261

Microsoft’s Operations Framework

British Educational Communications and
Technology Agency (BECTA)
http://www.microsoft.com/technet/itsolutions/cits/mo/smf
http://www.becta.org.uk/tsas

IT Process Institute’s Visible Ops Methodology
http://www.itpi.org
17
A Basic Change Management
Process




Identify a potential change
Create Request For Change (RFC)
Seek Approval to Proceed
Plan the Change







Plan & Prepare
Test
Develop Rollback Plan
Peer Review
Seek Approval to Implement
Deploy
Review
18
What is Release Management?
Development
Environment
Test
Environment
Production
Environment
Release Management


“The focus of Release Management is the protection of
the live environment and its services through the use of
formal procedures and checks.” – ITIL Service Support
Release management is often squeezed between the
development environment and production.
19
Release Management Processes



To plan and oversee rollouts
Acceptance Testing
Design and implement procedures for the distribution and
installation of changes.





Automation can reduce variation and speed deployment in known
environments.
This means that change, release and configuration management must
work together.
To ensure only authorized and tested “releases” are deployed.
Ensures that all master copies of software is stored in the
Definitive Software Library (DSL)
Ensures that the Configuration Management Database (CMDB)
appropriately reflects new Releases.
20
A Sample Process








Development/Engineering/Security identifies
potential patches.
Change Management reviews the RFCs for the
patches and, if approved, do the planning, testing,
etc.
Approved patches/changes are reviewed and
consolidated into a given release.
Integration testing is performed and requires
effective Configuration Management.
Once tested and accepted, approved releases are
stored in the Definitive Software Library (DSL).
Releases and schedules are communicated.
Operations then reviews the Release, formally
accepts and deploys the Release from the DSL.
The more automated the deployment, the better as
it reduces the possibility of human error but
necessitates solid Change and Configuration
Management.
Patch 1
Patch 2
Patch 3
Change
Management
Release
Planning
Integration
Testing
Authorized
Release
21
Metrics to consider







Total Number of Changes
Total Number of Emergency Changes
Total Number of Service Affecting Outages
% of Successful Changes (Meaning they
installed according to plan)
Mean Time To Repair
Availability
Unplanned work
22
In Summary


Patches are changes and must follow the
organization’s Change and Release Management
processes.
The goal is to manage risks and add value – not
just to patch for the sake of patching.
23
Thank you!
George Spafford
[email protected]
http://www.spaffordconsulting.com
Daily News Archive
http://www.spaffordconsulting.com/dailynews.html
24