This is the second post in a series about IT Infrastructure Library (ITIL) processes and security.
Defining precise cybersecurity services in the context of an IT Infrastructure Library (ITIL) is very important. From my perspective, many organizations struggle with cybersecurity because they do not understand what these essential services are.
In the first post of this series, I discussed how ITIL misses the mark when it comes to operational security. In this post, I will discuss the six essential cybersecurity services required to run a credible security operation and how you can implement them in security operations.
1. Strategy
A cybersecurity strategy is a story; it needs to be forward looking, encompass all parts of a business and embed a number of security principles.
Most importantly it needs to enable the security leader to make decisions in the best interest of the organization, even in cases where there is no exact precedent. For this to happen it needs to be endorsed by the highest level in the company. If, as a security leader, you cannot reach that high up in the company, partner with someone who can.
As part of your strategy service, you need to outline how the organization perceives cybersecurity risk, where it fits in the organization and what the overall approach is to deal with it.
As an example, if the principle is “the confidentiality of our customer data is paramount” it may mean that security services are temporarily disabled if it is discovered that they are being abused to exfiltrate customer data. If instead, the principle is “we will provide all services to our customers all of the time” then maintaining security services remains a priority during that incident.
It pays to have this sort of distinction decided and agreed before an incident happens (because happen it will).
2. Policies
Policies help communicate strategies to stakeholders and lay out principles and some rules for what are and aren’t allowed.
The hard part of doing policies well is not developing the framework and writing the policies themselves; it’s getting them accepted by the business and then making sure they are communicated properly and understood.
3. Architecture
Is your network defensible? Do you develop threat models when you design stuff? If the answer to these questions is “no”, you probably don’t have a security architecture service.
Architecture is the first step of ensuring that “stuff” is secure by design. That means that security is baked into new deployments from conception, rather than “bolted on” afterwards, and that threats and risks are documented and understood.
4. Security testing
New solutions should be tested for security flaws before they are deployed. In principle, the sooner you do security testing in the build cycle, the better.
Security testing should be integrated with both threat modelling and monitoring. Security testing done well looks back to the architecture phase, but, more importantly, it looks forward to ensure that an application, once deployed, is defensible.
5. Monitoring and alerting
Monitoring and alerting is hard to do well. The main problem is not a lack of data, but rather too much of it – the same goes for threat intelligence. The art is to interrogate data wisely, and focus on the things that point to incidents, rather than collect data for the sake of it.
An immature way of doing this, in my view, is to upload monitoring all data into a SIEM and then wait until it pings. One problem with traditional SIEMs is that they have to understand evil in order to recognize it, and it is hard to query the data with non-specific, random guesses. Another is that SIEMs require ongoing tuning, and an over-reliance on SIEMs will lead your security team to focus on its tools rather than on the environment.
The largest problem, however, is not understanding your adversary.
For example, monitoring failed login attempts daily gives you an indicator of how many brute force attacks – random trials of passwords – happen every day. This information is somewhat useful, but also very limited. These attacks still happen (nowadays especially with admin accounts on Internet of Things devices), but for normal user accounts, not so much.
More useful is to be able to track users changing roles or identities on the network in a manner that is not related to any business processes. That may be an indicator of someone pivoting – a potentially nasty hack – that just monitoring for failed login attempts won’t pick up.
6. Incident response
The last security requirement for the IT environment is “secure in breach”. The incident response process speaks to that. The truth is that you will get hacked. When that happens, it’s how you deal with it that counts.
Incident response is a huge topic, too much to cover in a single paragraph. But what matters most in incident response is how you close the incident response loop, and how today’s incidents provide learning for tomorrow – here are some examples.
In my next post in this ITIL series, I will discuss how these six cybersecurity services can be integrated with the ITIL process.
This post has been adapted from my post on LinkedIn.
Hinne Hettema is the operational security team leader for the Unitec Institute of Technology at The University of Auckland.
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.