Gareth,
I think deriving the SLA form ITIL will be a tough approach.
ITIL is somewhat more like supporting processes for IT-Management. While the
idea to integrate Security Management into all relevant IT processes is a
good approach it will not assist you in developing SLA.
My experiences with SLA in that context are, that you must integrate a
paragraph for patch management (alligned to your normal change management),
incident management (procedures and escalations), auditing & reporting
(especially if you have outsourced the IT) and CERT tasks.
Patch Management:
You should insert a section into the change management process that will
handle security patches. In general it is a good idea to derive the SLA
times from the change management, but you need to take care that emergency
patches can be implemented in an appropriate time.
Incident Management:
Same as CM, you should insert a section for handling security incidents
along the ITIL Incident/Problem Management. You should think about what is
necessary for you to be inserted. At least you should integrate a section
what has to be done in case of an serious incident.
Auditing, reporting:
This is quite an important issue, especially if you have outsourced the IT.
Regular audits are really important to prove the current status of security.
At least once a year you should perform a regular audit, but you need a
paragraph that allows you to perform an audit at any time a security breach
(or a suspiction of a breach) has occured.
Regular reporting about firewall logs, error logs, incidents and so on will
be important as well. Otherwise you have some kind of a black box and you
will have no idea what's going on.
CERT tasks:
If you have an IT-Outsourcer you should think about who will be responsible
for CERT activities. That means who will monitor CERT and decide whether or
not a bug is affecting you.
Be smart, let them monitor CERT (don't forget reporting than) and you will
decide to implement a patch or not.
Within ITIL you already have the methods to be involved into all relevant
service support processes, but you need to establish this involement that it
will work for you. Regular change- and incident management board will be
helpful to inform you about the current status of the IT. Additionally, you
should be involved in the day to day incident and change management process.
On the one hand side to be informed and on the other hand to veto and stop
activities which will affect security.
I hope that helps..
I have added a document of mine (patch management process, derived from
ITIL) which is available at:
http://www.giac.org/practical/GSEC/Maik_Medzich_GSEC.pdf
Cheers,
Maik
GSEC
-----Original Message-----
From: Gareth Bromley [mailto:gbromley@intstar.com]
Sent: Dienstag, 9. November 2004 13:34
To: security-management@securityfocus.com
Subject: ITIL for Security Management
As subject:
Hi,
I'm been 'tasked' with looking at ITIL for Security
Management, and generally feel it isn't too bad a frmaework
(being mainly based on 7799). However, I'm having some
trouble working out what should go into the SLAs for Security
Management etc..
Has anyone been through this using ITIL for Security
Management and would be happy to help, provide SLAs, KPIs etc..?
Cheers
Gareth
