Transcript Developing and Implementing a Rollout Plan

The Role of Security in IT Service
Management
October 31, 2007
2:00pm EDT, 11:00am PDT
George Spafford,
Principal Consultant
Pepperweed Consulting, LLC
“Optimizing The Business Value of IT”
www.pepperweed.com
© 2007 Jupitermedia Corporation
Housekeeping
• Submitting questions to speaker
– Submit question at any time by using the “Ask a question”
section located on lower left-hand side of your console.
– Questions about presentation content will be answered during 10
minute Q&A session at end of webcast.
• Technical difficulties?
– Click on “Help” button
– Use “Ask a question” interface
© 2007 Jupitermedia Corporation
Main Presentation
© 2007 Jupitermedia Corporation
Agenda
• How to view security in the world of ITSM
• Risk Management and Controls
– Getting Started
– Enterprise Risk Management
• Why security plays an important role in Service Delivery
and Service Support
• Where there are resources to learn more
© 2007 Jupitermedia Corporation
What ITIL Represents
•
•
•
•
•
•
ITIL is the de facto standard approach towards IT Service Management
(ITSM)
It is about IT delivering quality services that meet the needs of the
organization
IT services enable business processes that, in turn, enable the business to
meet goals
The management of risk to attain goals is essential
Security is a key stakeholder in requirements definition
Security requirements are business requirements!
– Security in support of X service
– Security in support of the enterprise
© 2007 Jupitermedia Corporation
Security in ITIL v3
• In the Service Design book
• “The goal of the ISM [Information Security Management] process is
to align IT security with business security and ensure that
information security is effectively managed in all service and Service
Management activities.”
• Confidentiality, Integrity, Availability
• Information Security Policy
• ISO 27001 for the Information Security Management System
• Control – Organize, establish management framework, roles &
responsibilities
• Plan – SLAs, UCs, OLAs, Policies
• Implement – Awareness, classification, personnel security, physical
security, logical security, incident handling
• Evaluate – Audits, assessments, incident review
• Maintain – Continuous improvement
© 2007 Jupitermedia Corporation
The Goal
Accounting
Manufacturing
Organizational Goal
Human Resources
© 2007 Jupitermedia Corporation
Sales
Customer Service
Each Functional Area Has Objectives that
Support the Goal
Accounting
Manufacturing
A1. Financial Reporting
Organizational Goal
A2. Employee Tracking
A3. Customer Tracking
Human Resources
Sales
Customer Service
Examples:
A1 – “Provide accurate and timely financial reporting data for the public and internal decision
making.”
A2 – “HR will track timely and accurate vital information about employees including key dates,
training, performance, skills, and benefits. ”
A3 – “Customer service will ensure that all customer master profiles are current and accurate.”
© 2007 Jupitermedia Corporation
IT Provisions Services That Add Value
and/or Mitigate Risks
Accounting
Corporate ERP
Manufacturing
Spreadsheets
A1. Financial Reporting
Organizational Goal
Corporate ERP
CRM System
A2. Employee Tracking
A3. Customer Tracking
HR System
Human Resources
Sales
IT in support of X business service …
© 2007 Jupitermedia Corporation
Customer Service
Why is risk management so
important?
Limited Resources and Seemingly
Unlimited Risks!
US companies are adopting a risk based approach and going after what
matters most in order to be sustainable. It makes sense to spend $1,000
to safeguard $1Billion but not to safeguard $100. Understand and
prioritize risks to focus compliance efforts.
© 2007 Jupitermedia Corporation
If a risk doesn’t map to objectives and goals,
then does it matter?
Accounting
Manufacturing
NO
Organizational
Goal
Human Resources
Sales
© 2007 Jupitermedia Corporation
Customer Service
Getting Started with Risk Management
• Formal ERM can take a lot of time to ramp up
• Need a method to start & fast ramp up
• Interview senior management, audit, and finance to understand what
matters to the business
• Identify material systems
– Review the Institute of Internal Auditor’s Guide to the Assessment of IT
General Controls Scope (GAIT)
• Identify gaps in key IT General Controls not all vulnerabilities
• Identify mitigation options
• Gain senior management approval
– Mitigate
– Accept the risk
• More to come in Visible Ops Security due later this year
© 2007 Jupitermedia Corporation
Enterprise Risk Management
• Ideally, risk management needs to be implemented,
ideally at the enterprise level, to ensure that
organizational risks are identified and properly managed.
– IT needs risk management to prioritize mitigation efforts and to
help facilitate discussions with senior management
– Senior management can use risk management to understand
risks to objectives, the current risk levels and prioritize
investments intended to mitigate risks
© 2007 Jupitermedia Corporation
One challenge is how to prioritize
hundreds, if not thousands, of risks.
We still need to focus on what matters using
a top down approach
© 2007 Jupitermedia Corporation
Quantifying Risk
• Simple approach is to use Likert (1-5) scales to develop ordinal
ranking
• Inherent Risk Score = Probability x Impact
• Residual Risk Score = IRS x (100% - % Mitigated)
• If nothing has been mitigated, RRS = IRS
• Management defines what level of RRS is acceptable
• How do you factor risks to objectives with varying importance? One
method is multivariate risk models.
– Weighted Average IRS = Probability x (Risk 1 weight x impact) x (Risk 2
weight x impact) x ….
• Note – Risk Management is an exercise in objective subjectivity
hence the need to get buy-in on the model and scores/values used
© 2007 Jupitermedia Corporation
A Spreadsheet-based ERM Model
Risk Workbook
Updated: MM/DD/YYYY
0.25
ID
Description
Affected CI
1
2
3
4
5
This is a sample risk
Data center fire
Virus on fileserver X
Firewall breach Due to open port
Default passwords on AS400a1
00-000-1234
10-001-0001
20-010-0123
20-020-0022
20-020-0001
Category Found by
IT
IT
IT
IT
IT
Bob
Tom
Sara
Bob
Greg
Date
Found
11/02/04
01/10/05
01/10/05
01/10/05
02/15/05
Weights for each objective area
0.25
0.25
0.25
Probability Strategic Operations Reporting Compliance
3
2
4
4
3
2
3
2
2
2
5
5
4
4
3
5
5
3
4
4
5
5
3
4
4
Inherent
Impact
Inherent
%
Risk
Mitigated
Score
4.25
4.50
3.00
3.50
3.25
12.75
9.00
12.00
14.00
9.75
Probability
Use 1-5 scale but be sure to define it
1 Could happen in the next year but very unlikely
2 Could happen in the next year and has 25% odds
3 Could happen in the next year and has 50% odds
4 Could happen in the next year and has 75% odds
5 This will happen in the next year
You will need to define the scales for each of the four impact areas. The provided
scales are for reference only.
1
2
3
4
5
Impact to Strategy
Use 1-5 scale but be sure to define it
Will cause minor disruption to a supporting objective.
Will cause a major disruption to a supporting objective
A key objective will be minorly disrupted, but within the risk tolerance.
A key objective will be majorly disrupted and move outside the risk tolerance.
A key objective will not be remotely obtained.
Impact to Reporting
Use 1-5 scale but be sure to define it
1
Will cause minor disruption to reports
2
Will cause a disruption to reports but can be recovered.
3
Will cause a major disruption to reports
4
Will disrupt reporting and take significant effort to recover.
5
Will halt reporting and trigger an investigation.
1
2
3
4
5
Impact to Operations
Use 1-5 scale but be sure to define it
Will cause minor disruption to a department and/or cost less than $10,000
Will disrupt a department for up to 8 hours and/or cost up to $50,000
Will disrupt a facility for up to 8 hours and/or cost up to $75,000
Will disrupt a facility for an unknown period of time and/or cost up to $100,000
Will disrupt business and/or cost at least $150,000
Impact to Compliance
Use 1-5 scale but be sure to define it
1
Will cause a minor compliance issue but not a deficiency.
2
Will cause a deficiency.
3
May cause a deficiency and trigger disclosure
4
May cause a significant deficiency and trigger disclosure
5
Will cause a material weakness and trigger disclosure
Note, this spreadsheet model is at http://www.spaffordconsulting.com/Risk_v5.xls
© 2007 Jupitermedia Corporation
20%
40%
50%
0%
50%
Residual Residual
Impact
Risk
Score
3.40
10.20
2.70
5.40
1.50
6.00
3.50
14.00
1.63
4.88
In response to risks we implement
controls
© 2007 Jupitermedia Corporation
What Are Controls?
•
•
•
•
•
Controls safeguard objectives / value
All processes contain an inherent level of variation that can not be eliminated.
Only put in enough controls to lower the residual risk to a level that is acceptable
to management.
Controls can be
– Manual – Meaning they take a person to perform without automation.
– Automated – Meaning that technology is used to enable the process
partially or entirely.
– Important Note – In accounting terminology, an automated control is a
control that is embedded in a system such as bounds checking, audit trails,
workflow, etc.
Three broad types
– Preventive Controls – Intended to stop a future transgression. Examples
– policies and procedures
– Detective Controls – Attempt to find out about an event that has already
happened. Example – Log review
– Corrective Controls – Aimed at restoring the last known good state.
Example – Restore from tape
© 2007 Jupitermedia Corporation
Cost of Control
100%
Level of Assurance
You can spend a fortune and
you will never truly hit a
100% level of assurance.
The objective is to lower risk
to an acceptable level,
not eliminate it because
you can’t!
Level of Investment
© 2007 Jupitermedia Corporation
Defense in Depth
•
•
•
•
•
•
Think of the rings of walls in a castle.
More walls equate to an overall better
defensive posture.
The idea is to layer controls in a cost
effective fashion.
If the first control fails, then there is a
second, etc.
The objective is to create an
acceptable level of residual risk and
stop!
Don’t spend more on controls than what
you are protecting is worth.
Don’t forget processes, systems and
people always have variation – go for
layers.
© 2007 Jupitermedia Corporation
Control 3
Control 2
Control 1
Control Objectives for Information and related
Technologies (COBIT)
•
•
•
•
•
•
•
Maintained by the IT Governance Institute (ITGI), which is part of the Information
Systems Audit and Control Association (http://www.isaca.org)
ISACA started in 1967, has over 50,000 members in over 140 countries.
Essentially, COBIT is the de facto reference for IT Controls. Nothing else quite like it
exists.
Four domains
– Plan and Organize – Strategy, Tactics, Vision
– Acquire and Implement – Identification, Development, Purchase,
Implementation
– Deliver and Support – Security, Continuity, Management of Data, Operations
– Monitor and Evaluate – Assessments and Audit
34 High-Level Control Objectives
Over 250 Detailed Control Objectives
Example:
– Domain: Deliver and Support
• High Level Control Objective – “DS5 Ensure Systems Security”
– Detailed Control Objective – “DS5.1 Management of IT Security”
– Detailed Control Objective – “DS5.2 IT Security Plan”
– Detailed Control Objective – “DS5.6 Security Event Definition”
– …and so on
© 2007 Jupitermedia Corporation
Security is a Risk Mitigation Process
We implement security controls
commensurate with risk to safeguard
objectives and goals
© 2007 Jupitermedia Corporation
Appropriate PPT Blending
•
•
•
•
•
A process is a course of action with an intended
result
Technology has been the mainstay of Information
Technology
– Technology can’t fix all of our problems!
The need to find and retain qualified people is
known, but not always stressed enough
– They need adequate training
– Segregation of Duties
– Cross-training/backups
What hasn’t received as much attention are the
processes
– Leveraging best practices
– A focus on quality management
– Continuous Improvement Processes
Any technology can be rendered ineffectual by poor
personnel and process choices
– Very true for security as well as other processes
© 2007 Jupitermedia Corporation
Outcomes
People
You can have processes without
adequate controls, but you can not have
an effective and efficient control
environment without good processes.
© 2007 Jupitermedia Corporation
ITIL v2
Service Level
Management
Incident
Management
Problem
Management
Service Desk
Function
Control
Processes
Release
Management
Change
Management
Configuration
Management
Capacity
Management
Availability
Management
IT Financial
Management
IT Service
Continuity
Management
IT Security
Management
© 2007 Jupitermedia Corporation
Change Management
• IDC – 80% of network availability issues caused by human error
• CompTIA – 60% of breaches are caused by human error
• Change management is a risk management function that assesses the
potential impacts of a change to the organization
• Security must be able to understand “What Changed?” as quickly as
possible
– Has a vested interest in detecting all changes to infrastructure
• Security should:
– Sit on the Change Advisory Board (CAB)
– Review change requests
– Review changes that are rolled back
– Review unauthorized changes for security events
• Security must work through Change Management and not around it
– Ideally through operations and not direct
– Quis custodiet ipsos custodes – Who will guard the guards?
– Never forget about human error!
© 2007 Jupitermedia Corporation
Configuration Management
•
•
•
•
Focuses on tracking and documenting configurations and then providing this
information to other areas
Configuration tracks relationships to understand who is affected and assesses
impact.
Enables the control of configuration items by monitoring, maintaining and verifying
– Resources
– Status
– Relationships
Security is a consumer of Configuration Management
– Infrastructure details
• Relationships
• IT and Business Owner Contact information
– User profiles
– Incident records (alerts + manually logged)
– License information (if tasked with tracking down unlicensed information)
– Reviewing security configurations
– Security logs / records
– Review of CMDB access levels
© 2007 Jupitermedia Corporation
CMDB Design Tip
•
•
A control is a CI type
Potential attributes include
–
–
–
–
–
•
Control ID
Control Objective
Standard Control Activity
Applicable Regulations (1 to many relationship)
Date last reviewed
You can then relate the to other CIs
– Systems (HW CI + SW CI)
– Processes
– Services
•
•
•
•
Is governed then by Change Management
Document / Version Control
Can immediately understand relationships and where used
Can relate control activity per CI / per control
– What is actually being done for the CI
– Audit findings
– Mitigation activities
© 2007 Jupitermedia Corporation
Service Level Management
• “The goal for SLM is to maintain and improve IT Service
quality, through a constant cycle of agreeing, monitoring and
reporting upon IT Service achievements and instigation of
actions to eradicate poor service – in line with business or
cost justification.” – ITIL Service Support
• Concerned with understanding the customer/organization’s
security requirements for each service
• SLM negotiates service security levels based on input from
the security function
• SLAs define security requirements
© 2007 Jupitermedia Corporation
Incident Management / Service Desk
• Concerned with restoring service as quickly as possible
• Alerts should route into Incident Management, not
pagers
– Key is to manage alerts, not fire and forget
– Need consistent handling
• Security needs to help IM with
– The development of incident call scripts and workflow
– The identification and proper coding of security incidents
– Processing of security related Incidents
© 2007 Jupitermedia Corporation
Problem Management
• Determination of root cause of actual and potential
incidents and, where it makes business sense, eliminate
it.
• Security involved with problem teams to establish solid
solutions
– Working on security related problem ticket
– Ensuring that proposed solution doesn’t compromise security
• Security opens problem tickets for Problems
© 2007 Jupitermedia Corporation
Release Management
• Ensures the quality of releases into production via formal
checks. Spans from development through testing to
operations
• Security will define what the security requirements of
releases will be
– Controls in a service
– Testing of controls
– Documentation of controls
• Security will check on the contents and security of the
Definitive Software Library (DSL)
© 2007 Jupitermedia Corporation
Capacity Management
• Tasked with translating business capacity requirements
into IT service and then Configuration Item (CI) resource
requirements
• Ensure that security is factored into capacity
requirements
• Ensure that capacity constraints don’t cause
vulnerabilities
– Out of disk space errors causing untrapped script failures, etc.
© 2007 Jupitermedia Corporation
Availability Management
• To understand the Availability needs of the business and
to continuously strive to improve
• Availability is a key element of Customer satisfaction
• You can not have sustainable high-availability
without fundamentally sound security
• Availability Management contributes to the Security
Policy
• Availability Management advises SLM on all
Confidentiality, Integrity, and Availability (CIA) issues
© 2007 Jupitermedia Corporation
IT Financial Management
• Budgeting, Costing, Charge backs and Value for IT
services
• Need to ensure security requirements are understood
and budgeted for
– Want to avoid cutting security features due to budget constraints
– Information Security and the organization will pay in the longterm for short cuts in development / procurement
• Security measures need proper budgeting, costing, etc.
– ROI is often ex post facto – in the value is often only “provable”
after an event
– Security of the ITFM services
© 2007 Jupitermedia Corporation
IT Service Continuity Management
• Defines how IT will support the Business Continuity
Plans (BCP) of the organization
• A disaster may create/exacerbate vulnerabilities
• Security needs to understand and approve the security
implications of the ITSCM plans
© 2007 Jupitermedia Corporation
Are compliance, security and operations
mutually exclusive?
Of Course Not!
Operations
Security
© 2007 Jupitermedia Corporation
Compliance
Continuous Improvement Is Key
• Like any process, you must
pick a place to start and begin
• As you gain more experience,
evolve the various aspects of
security as the organization
matures
• Be sure to tie security activities
to functional area objectives
and organizational goals
© 2007 Jupitermedia Corporation
Where do we want to be?
Vision and Objectives
Where are we now?
Audits / Assessments
How do we get to where
we want to be?
Process Improvement
(Leverage Best Practices)
How do we monitor
Progress?
Metrics and Critical
Success Factors
* Adapted from ITIL Service Support Graphic
Additional Resources
© 2007 Jupitermedia Corporation
IT Infrastructure Library (ITIL)
• Office of Government Commerce
http://www.ogc.gov.uk/guidance_itil.asp
• British Educational Communications and Technology Agency
(BECTA)
http://www.becta.org.uk/tsas
• Microsoft’s Operations Framework (MOF)
http://www.microsoft.com/technet/itsolutions/cits/mo/smf
• IT Service Management Forum
http://www.itsmf.org
© 2007 Jupitermedia Corporation
The IT Process Institute
•
•
Maintained by the Information Technology Process Institute (http://www.itpi.org)
Visible Ops leverages ITIL and is prescriptive
–
–
Change Management is key, as is reduction in variation and integration of process areas
It is split into three project phases to start
•
•
•
•
•
ITPI Controls Benchmark Study
–
–
Scientific study of what controls really matter
From 200+ to 53 to 3 + 9 foundation controls with August 2007 release
•
•
•
•
–
•
Phase 1 – Stabilize the Patient
Phase 2 – Catch & Release and Find Fragile Artifacts
Phase 3 – Create a Repeatable Build Library
Phase 4 – Continual Improvement – is the start of a process.
Can you detect unauthorized change?
Do you have defined consequences for intentional unauthorized change?
Do you have a formal process for managing known errors?
The 9 are largely communication and coordination controls
Highly recommended!!
Visible Ops Security
–
–
Four discrete catalytic phases
The phases at this point are:
•
•
•
•
–
Phase 1: Stabilize the Patient and Get Plugged In
Phase 2: Find Business Risks, Identify Controls and Fix Fragile Artifacts
Phase 3: Implement Development and Release Controls
Phase 4: Enable Continuous Improvement
Coming late Fall 2007
© 2007 Jupitermedia Corporation
Other Best Practice Sources
•
•
•
•
•
•
•
•
•
•
Australia Standard 4360 Risk Management http://www.riskmanagement.com.au/
British Standards Institute (BSI) - http://www.bsonline.bsi-global.com/
Carnegie Mellon’s Software Engineering Institute (SEI) http://www.sei.cmu.edu/
Computer Emergency Response Team (CERT) - http://www.cert.org/
COSO ERM - http://www.coso.org
Federal Financial Institutions Examination Council (FFIEC) –
http://www.ffiec.gov
IIA’s GAIT Page - http://www.theiia.org/guidance/technology/gait/
International Organization for Standardization (ISO) 27000 –http://www.iso.ch
ISACA – COBIT- http://www.isaca.org
OECD Guidelines on Information Security http://www.oecd.org/document/42/0,2340,en_2649_34255_15582250_1_1_1_1,00.ht
ml
•
•
•
The Systems Security Engineering Capability Maturity Model –
(SSE-CMM) - http://www.sse-cmm.org/index.html
US General Accounting Office (GAO) – http://www.gao.gov
US National Institute of Standards (NIST) - http://www.csrc.nist.gov/
© 2007 Jupitermedia Corporation
Thank you for the privilege of facilitating this
webcast
George Spafford
[email protected]
http://www.pepperweed.com
Daily News Archive and Subscription Instructions
http://www.spaffordconsulting.com/dailynews.html
© 2007 Jupitermedia Corporation
Questions?
© 2007 Jupitermedia Corporation
Thank you again for attending
If you have any further questions, e-mail
[email protected]
For future ITSM Watch Webcasts, visit
www.jupiterwebcasts.com/itsm
© 2007 Jupitermedia Corporation