Implementing security as a set of services

This is the third in a series of blog posts about IT Infrastructure Library (ITIL) processes and security. Read Part One here and Part Two here.

In this post, I will focus on the implementation of the security services in terms of an ITIL-type framework. This is a blog post that took a long time to write — but some of the considerations here are essential if you are in the process of implementing security as a service, and especially if you are looking at ITIL as a service delivery methodology.

I have already outlined how security operations, once we come to think of them as services, integrate well with the rest of the IT environment and how thinking about them as services can remove some of the mystique usually associated with security. Once we define security services in terms of an ITIL framework, it becomes possible to define the maturity of security services, and (albeit with some difficulty) assign service-level agreements (SLAs).

This all helps to understand, measure and scale security services across the entirety of the IT landscape and make security engineering a normal part of the IT factory.

This post will focus on the implementation details of services in general, and point out some specific details that are relevant to security services. There will be a lot of little bullet points that are probably each worth a (brief!) post of their own. Yet despite that, this overall post should give you an idea of how the six security services may be implemented and what the end result looks like. As an attachment to this post, I provide some worksheets that will assist you to ‘work the model’ and to explore further.

In this blog post, it is my aim to develop the service context of security operations, which will allow you to structure security operations as part of the normal set of IT services. It is only once we can come to think of security as a service that we can remove the ‘black box’ aspect of security. As part of that process, I will define the process characteristics of the security services in terms of the ITIL framework. That makes it possible to think about security services in the context of the normal services that each IT department provides.

Setting up security as a service

For each of the six security services, four aspects have to be considered in the service design. They are:

• Definition: what is the service?
• Service processes: which processes make up the service and how are they managed? ITIL uses a specific process design template for how to design a service, and this is discussed briefly in the Appendix in the context of security services.
• Integration: what interfaces do the services have with other services — or — what service do they consume or provide?
• Practices: what practices make up the service? This will also allow you to establish the maturity of your security team.

The definitions (or at least a high-level idea) of the six essential security services were discussed in the previous blog post, but the ones to worry about are: strategy, policies, architecture, testing, monitoring and incident response. In the linked documents below I have outlined how you can develop a high-level overview of your security service framework.

For the process design, we will largely (but not slavishly) follow the ITIL service design methodology, which is outlined in the Appendix, specifically tailored to security services. This is not the only design methodology, but it is the most common one. Most of the ITIL components ‘make sense’ in some way, so it is possible to use other frameworks too, and translate the ITIL components into the components of the respective framework that you have chosen to use.

Implementing the six security services

Service	Name of the service
Definition	What the service does
Process	How the service is managed and executed. In the attachment SixSecurityPractices_HH  (docx, 15kb), I discuss all the 11 ITIL steps in service processes; here, it is necessary to worry about only four of them: 1.     Service level management 2.     Capacity management 3.     Availability management 4.     Supplier management
Integration	The other services that the service integrates with. These can be both from security or other areas of the business.
Practices	The practices that currently make up the service, and the practices that you will look at implementing in the near future. This helps with maturity assessment and resource planning.

I have provided a sample ServiceWorksheet_HH (docx, 13kb) that outlines some of the possibilities for the six essential services. You can use this as a guide to coming up with your own version of their implementation.

Service level management

Service levels are about the speed and efficiency with which service is provided. For security services, the service levels differ greatly per service. For incident response and assistance in cyber security incidents, for instance, we’d generally expect fast turnaround and a high level of service. For other services, such as security penetration testing, service levels can be both more generous, and more flexible — much depends on the complexity of the application being tested, the security problems that are found, and how they are resolved.

The security service most in need in service level management from the perspective of the business is incident response. This is all about how quickly you pick incidents up and deal with them. It may seem really hard to develop reliable service level agreements for incident response, but there are some facts that help.

The first one of these is that many incidents are Pareto optimisable: 20% of the incident types make up 80% of the incidents. Getting to grips with that 20% takes us a long way towards having defined service levels for incidents. And this is not as hard as it sounds — once an incident type is understood, standard procedures can be developed for its detection, and SLAs for the entire incident response service will improve markedly.

In ITIL parlance, many security teams do not have SLAs but operational-level agreements (OLAs) for services provided to other parts of the organisation. For the purposes of designing security services, the difference matters little, and we can refer in more generic terms to service-level requirements.

Having specified the six security services as different services, it becomes possible to specify specific SLAs and OLAs for each individual service. The result of this exercise helps to scope the workload on the security team.

Capacity management

Capacity management is all about determining the demand for a service and ensuring that demand can be met within the agreed service-level requirements. At heart, capacity management is all about ensuring that you can provide the service as needed, where needed.

One element of capacity management that deserves discussion here is staffing and the ‘skill shortage’. One of the (significant!) advantages of looking at the security function as one that supplies a set of services to the business is that it allows you to forgo hiring ‘cybersecurity expertise’, which is expensive if it is even available. Instead, why not hire against one or two of the defined services and then grow the cybersecurity expertise on top of that?

Availability management

Availability instead is all about how you deploy the resources that you have available. Again, compartmentalising security in a set of  defined services assists with defining the availability requirements. In most businesses, you probably want only the incident response function highly available, and then only up to the point where the incident is contained, to be dealt with later.

On the other hand, services such as security testing, strategy, and architecture can probably just be limited to work hours. This approach helps you to optimise staff time and resources.

Practices and maturity

Finally, it is useful to enumerate some of the practices that make up the set of security services. Practices are the components that are delivered as part of a service, and can be classified in terms of ‘basic’ or ‘advanced’ practices.

For instance, looking at the monitoring and alerting service, log monitoring is pretty basic. This is about making sure that you have enough information to troubleshoot any (i.e. not just security) issues that occur. Many organisations build out their log monitoring solution into a security incident and event monitoring (or SIEM) solution.

This is something that can, in an ‘advanced’ set of practices, be built out to include things such as threat hunting, threat intelligence feeds and such like.

The advantage of thinking about maturity in this way is that it allows you to determine what sort of solutions you are in the market for at any point in time. As an example, if your log management practice is not up to much, then it is a waste of time to be talking to threat intelligence vendors or implement a SIEM system.

Wrapping up

Thinking of ‘security’ as a set of services is useful. It demystifies security, and allows for better decision making in hiring, operating, and optimising the security function. In the end, this is beneficial to the business: they spend less money to get better service.

However, more important is that looking at security as a set of services also brings in the first aspects of business transformation. The security field will change significantly over the next few years. Our main challenge as security professionals will be how to articulate our value to the business in terms that enable innovation. We need to move our profession beyond peddling the ‘story of fear’ and being the ‘department of no’.

In my opinion, the future of security is as an enabler of trust in a rapidly changing technological and social landscape. To do that well, we need to engage with new technologies, new business models, and new ways of working effectively together.

Thinking about security in terms of services is a first, necessary and useful step in that process.

Hinne Hettema is the operational security team leader for the Unitec Institute of Technology at The University of Auckland.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.