29
Apr
Why SecOPs?
As a consultant, sometimes you have to face some questions from clients, that you don’t really have an answer to.
This happened to me, when a client asked me: “What do you think about SecOps? Would it be useful to me?”
As I didn’t have much experience with SecOPs, I started a research (luckily I have some very experienced colleagues that are always there to provide support), to provide a good answer to the client and also enrich myself with some knowledge about SecOps.
ServiceNow Security Operations Management is composed of three different scoped applications, which are: Security Incident Response, Vulnerability Response and Threat Intelligence.
In this article, I’m going to talk about the one I consider most important from ServiceNow SecOPs: Security Incident Response.
What’s ServiceNow SecOps?
As you probably already know, SecOps, that stands for Security + Operations, is a trend whose purpose is to simplify the alignment of people, processes and technology involved in responding to and mitigating security breaches. Everything focused on reducing the risk and enhancing business agility.
Servicenow SecOps integrates information/incidents from existing security tools into a structured response engine.
It uses intelligent workflows and automation to prioritize threats, connecting existing security tools with a security orchestration and response engine to speed up the resolution of security incidents.
With this brief overview, it’s probably difficult to make an idea of what ServiceNow SecOps really provides. So, let’s have a look into the Security Incident Response Management application.
Security Incident Response Management
ITIL doesn’t differentiate a normal “Incident” from an “Security Incident”, so, ServiceNow considers a Security Incident, an Incident created to handle an issue related with security (a threat, a vulnerability…) which usually comes from a SIEM (Security Information and Event Management) external system.
This application brings in a new Security Incident layer, separated from normal incidents in a different table. This new “type of Incidents” have their own dedicated processes (forms, states, fields, SLAs) and are driven by workflows to help the orchestration.
Here’s an example of how different the forms are:
An interesting feature is the Security Incident calculators. They are used to modify values from the Security Incident when certain conditions are met.
There are predefined calculators that update the Risk, Impact, Priority and Severity of a Security Incident. They are validated one by one in an order defined for each calculator. If the Security Incident matches the conditions of the calculator, the corresponding field is modified according to the rules of the calculator.
An example of a calculator:
Another important thing to consider is, where do Security Incidents come from?
Most of the time, they are created automatically, but there’s also the option of creating them manually through the Security catalog. This catalog allows the end users to report security threats or breaches, guiding them to provide the information required to tackle the potential security issue.
Another feature that’s quite interesting is the Post Incident Report. It is essentially a PDF file, generated after closing a security incident. This report contains the actions performed over the whole lifecycle of the incident, from its creation to its closure, detailing what, when and who performed the action.
On the right there is a piece of how a Post Incident Report can look.
One feature that impressed me the most, is the new UI for managing security incidents:
You could say it is sort of the same layout as we could find in any instance, but to me it has a more intuitive look and easiness for filtering, and working. As an example, the tabs it provides, help you keeping your work in the same tab of your browser without waiting for loading:
In addition, there’s one important tool that can be seen on the right of the form, the Playbooks.
A Playbook is a step by step guide to solve certain types of Security Incidents.
In the Security Incident Response, there are different playbooks that you can use. These playbooks can be created or configured easily without coding too much.
- The playbooks included in a base instance are meant to quicken the investigation process of the Security Incidents automating different tasks.
- Each type of task guides you through different steps to tackle the threat.
- While working on each task, you can add work notes to help with future attacks.
- There are also knowledge articles linked in each task, with information on how to perform the task. Or explaining the reasons behind the tasks to perform.
- Also you can create your own articles and link them to a playbook task
- You can also assign a different playbook to the security incident.
And at last, there are also specific dashboards: CSO reporting overview which helps the Security Administrator to check the impact of the Security Incidents in the business from different views .
As a conclusion, I can say that the Security Incident Response application improves the business security stance. This is because it helps start working on critical security threats first, increasing the efficiency and reducing the response time on them therefore reducing the impact on the business.