Elucubrations: Service catalog – structuring the big picture for a security operations service

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.

 

 

One thought on “Elucubrations: Service catalog – structuring the big picture for a security operations service

  1. Paul D. Reigrotzki says:

    Liebe Petra

    Wie immer: ich lese deinen Blog mit Eifer und Interesse und fühle mich – wie immer – zu Kommentaren herausgefordert. Du wirst es verkraften, dass ich zu „Elucubrations: Service catalog – structuring the big picture for a security operations service“ kritisch Stellung nehme.

    Zur Eröffnung ein Rückblick: Als im April 1986 des KKW Tschernobyl in die Luft flog, war keineswegs eine Attacke die Ursache: die Bedienungsmannschaft hat in unglaublicher Dummheit und mit unglaublicher Inkompetenz ein Desaster herbeigeführt. Und als die Kernschmelze in Fukushima einsetzte, war ebenfalls keine Attacke die Ursache, sondern eine Naturkatastrophe und mangelhafte Schutzmassnahmen.

    Was will ich damit sagen? Wenn bei der AKW/KKW-Sicherheit nicht allein die Abwehr von Attacken im Fokus der Sicherheitsdispositive stehen kann, dann wohl auch nicht bei der IT-Sicherheit. Lass uns für das “Big Picture” eine Etage höher gehen: Die Mission von IT Security ist es, Schaden, die aus dem Einsatz von IT entstehen, vom Unternehmen abzuwenden oder deren Auswirkungen zu minimieren.

    Schaden entsteht aus a) Fehler und Inkompetenz des Bedienungspersonals – also IT Operations, b) Unfällen, Naturkatastrophen und Versagen von Komponenten und c) als Folge von Attacken.

    Jetzt können wir diskutieren, wo man was tun kann. Bei a) gehören Ausbildung und klare Prozeduren zum Massnahmenportfolio, bei b) gibt es eine interessante Überlappung von Qualitätssicherung, nicht zuletzt bei der Anwendungsentwicklung (der Systemtest lässt grüssen!) und IT Sicherheit, aber hier sind Redundanz PLUS Backup/Restore mit ausgebufften Recoveryprozeduren das zentrale Mittel der Wahl – und das liegt bei IT Security Operations!!!. Und für c) hast du die Massnahmen prächtig ausgebreitet. Mich hat allerdings irritiert, dass du für IT Security Operations die unverzichtbaren Vorkehrungen für Recovery/Business Continuity nicht mal erwähnt hast.

    Im Übrigen kann ich mit ganzem Herzen deinen Ansatz der Prozessorientierung unterstützen. Du solltest das Ganze aber breiter anlegen: Schadensvermeidung und Schadensminimierung als Mission, nicht nur „We detect, defend, and prevent attacks.“

    Wenn du Lust hast, können wir mal einen Zirkel alter (und ein paar junger) Security-Hasen in die Diskussion involvieren. Ich denke da an Mike Lewis, Harald von Fellenberg, Jürg Ganz, Markus Bitterli und noch eine Handvoll mehr, die ich bei Bedarf gerne aufliste. Zu den jungen Häsinnen gehört Kerstin Wagner, die IT-Security Spezialistin bei Swisscom.

    Unser Alltag ist zur Zeit ein wenig aus den Fugen, da die Trennung unseres Sohnes und unserer Schwiegertochter läuft und wir uns bei der Schadensbegrenzung (sic!) für unsere Enkel engagieren. Mal sehen, wie es weiter geht.

    Ganz herzliche Grüsse und mehr „Elucubrations“! wünscht dein Paul – und Barbara schickt auch herzliche Grüsse

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s