Assume this task: Write a service catalog for IT Security Operations
Assume that IT Security Operations has to write down their services for a large company. I like this task. I believe that writing down the services helps clarify the mission and targets, focus on deliverables asked for and ease collaboration with the related IT and business areas.
In this blog I describe my thoughts about structuring the big picture of the service catalog for IT Security Operations. My thoughts may be useful for similar endeavors.
Four questions that help structure the big picture of our service catalog
- What is the most logical structure for IT security operations services?
- Who is the main client and what is his mandate? Who are additional clients and stakeholders?
- What does the service list look like?
- What layout/details shall describe the services on the list?
To answer these questions requires talking to the subject matter experts within the IT Security Operations team and around it.
What is the most logical structure for IT security operations services?
The mission of Security Operations is: “We detect, defend and prevent attacks.” They are a “watch dog” for the enterprise IT infrastructure.
- They detect attacks based on the knowledge about threats and vulnerabilities and based on analyzing logs as well as user/client reports of attacks perceived.
- They defend attacks that have penetrated into the IT infrastructure. They stop incidents immediately and for major attacks they collaborate with other teams and with management.
- They prevent attacks in future by feeding back their hands-on experience to security -, risk – or engineering teams and their management.
I like the mission “detect, defend, prevent” to give structure to the services. This is a process oriented view.
An alternative is the attack classification (e.g. by objectives such as privilege gain, denial of service (DDOS) or malware). I rejected to use attack classification, because it is ambiguous (research has provided multiple classifications) and rather reflects a client or market view (e.g. selling malware defense services and tools) which is less relevant for an internal service. I prefer the process view.
Conclusion: For our service catalog, structuring the services along the lines “detect, defend and prevent” or along the process is the best option.
Who is the main client and what is his mandate? Who are additional clients and stakeholders?
In the organization that I had in mind, IT security has been assigned to a cross-functional department (owning enterprise IT security). This IT Security Department has “outsourced” IT security operations to the IT department that owns incident and problem management. Hence the IT Security Department is the main client of IT Security Operations. I believe this is an efficient organizational set up for IT Security Operations, as they will follow the one incident/problem management process (IPM) that holds for all IT services often following the best practice library ITIL.
In addition to the IT Security Department, IT Security Operations has more clients/stakeholders such as Legal&Compliance, Business Risk Functions and Officers, Fraud Detection, Enduser or Server Operations, Application Development or Enterprise Architecture. The major stakeholders collaborate in a Security Committee.
Indirectly all employees and business clients as well as all departments benefit from IT Security Operations, as they can rely on the “watch dog” detecting, defending and preventing attacks. IT Security Operations is a link in the value chain delivering to the entities that are in more direct contact with the end clients.
Conclusion: The IT Security Department (owning IT security services) is the main client of IT Security Operations (responsible for security incident/problem management)… in the setup that I was confronted with.
What does the service list look like?
Even if a service list already exists, I propose to change it, in case it does not fit the logical structure “detect, defend and prevent”. A logical structure eases communication. Also service names have to be as short and concise as possible. To convince the stakeholders of the catalog, I always make a cross tabulation to show where the differences are (while working the existing list into my proposal). This is a description of the process:
- “Detect” encompasses (1) operating the security tools (needed for attack detection), (2) security event monitoring (normalizing a variety of logs), (3) running a security and advisory desk, and (4) security incident detection (analyzing the logs, taking into consideration attacks reported to the service desk by internal users and external clients, being aware of vulnerabilities found in vulnerability scans and benefiting from knowledge bases available from sources such as governmental or research authorities).
- “Defend” is (1) incident response (taking immediate action to stop incidents) and (2) security problem management (initiating/participating in solving major problems).
- “Prevent” is providing (1) a vulnerability scan service, (2) reporting security incidents (successful and unsuccessful attacks) and (3) consulting about security operations (based on hands-on experience with attacks, e.g. in Security Committees, to project and system managers or to security architects).
Conclusion: The big picture is clear – mission (detect, defend, prevent attacks; responsibility for security incident and problem handling), main client (IT Security Department or owner of security), and the service list (to be illustrated as a pie chart along the lines “detect, defend, prevent”) . This will be the heart of the service overview chapter.
What layout shall describe the services on the list?
Based on the ITIL best practice and with some minor modifications, I chose this layout to describe the service items on the lists:
- Service name: Describing the service as shortly and as clearly as possible. Example: “Security incident response” or “Security event monitoring”.
- Service lifecycle status: Mostly operational.
- Client/audience: Business or IT facing. Examples: IT Security or Legal&Compliance.
- Service owner/manager: Responsible person from within IT Security Operations.
- Service description: Short outline of the service and reason. Example: IT Security relies on measures being taken to stop incidents detected. Or: Legal&Compliance relies on logs available for compliance coverage.
- Service deliverables: Breaking down the service into individual results. Example: Incident classes in scope such as DDOS, malware, phishing etc. Or: Logs available for compliance.
- Limitation of the service: What is included. Example: Only handling security relevant incidents.
- Service dependencies: Prerequisites for the service. Example: IPM process is operational. Or: Raw event logs are available for normalization and further analysis.
- Cost recovering: Lump sum recovery or cost charging based on prices. Example: IT Security provides the budget, but projects pay for security operations consultancy.
- Service changing/canceling: How can the service be modified or canceled. Example: IT Security Committee agrees about new incident classes to be included.
- Service support: Contact points. Example: Dispatching group defined for ticketing process or one mailbox for clients to report observed/suspected attacks.
- Hours of operation: Example: 7×24 or week days with on call availability.
- Performance metrics: What are the handles to measure the quality of the deliverable. Example: Resolution time for incidents or false positives. Note that research (e.g. from Forrester or Gartner) is available that supports defining performance metrics for security.
- Target service level: What service level is to be delivered (ITIL calls this “service level agreement”). Example: 99% of malware attacks stopped within 24 hours hours or no more than 10% false positives
Conclusion: Deliverables matter
I strongly believe that it is indispensable to focus the service catalog on deliverables. The clients/stakeholders want to know, what is in it for them: What matters for them are the results, not the tasks performed that describe “how” results are achieved. Focusing on deliverables leaves room for optimizing or innovating the process at the point where the process knowledge is – in IT Security Operations.