A scene from a medium-sized company: an external Security Information and Event Management (SIEM) and Security Operations Center (SOC) were the management’s preferred solution for more IT security. When in doubt, let the professionals take over – that should provide peace of mind. Then the alarm sounds: the SIEM reports an event, and the SOC team has to involve other players in the company or at the customer’s site. And now…? No one in the chain of command knows exactly what to do in the event of an incident. This is because there is no structured incident response process in place.
This scenario shows that without the assignment of responsibilities in the case of an alarm and without pre-structured processes for various types of threats and incidents, companies are at risk of falling into a state of “headless chicken” mode. However, a disorganized response is highly counterproductive, especially when it comes to IT security, since the real threat is constantly becoming more serious: organized gangs are using increasingly creative methods to obtain money or information from companies, banks and institutions. Cybercrime cost businesses billions in direct costs or lost revenue every year.
Organizing the interaction between the SOC, ISB and departments
Organizing operational procedures is at least as important as implementing basic technical structures such as a SIEM solution. In general, a company must form a team from SOC employees and specialist departments. In many cases – and this role is often overlooked – an information security officer (ISO) or chief information security officer (CISO) should also be involved.
We show how the interaction can look for different types of security-related IT incidents. Three basic cases can be distinguished, which need to be handled differently:
Graphic: An appropriate security incident response process (respond) is one of the five core requirements of the NIST Cybersecurity Framework.
(1.) Non-case-closing processing by the SOC, need for action by the department or the ISB
If the SOC analyst concludes that the ticket requires organizational intervention, a report is sent to the respective department and, in special cases, directly to the ISB. In urgent and/or time-critical cases, the SOC analyst sometimes calls the department.
Examples:
A currently active ransomware – this is malicious software that prevents access to data by encrypting it and, so to speak, takes the computer hostage. This is often associated with a high ransom demand for the device to be released again. A possible malicious act by an employee that is currently in progress (e.g., the removal of large amounts of data).
Regardless of the further course of action, it makes sense to keep a log of the further steps and to store a note in the ticket about the outcome of the incident after it is closed.
(2.) Final processing by the SOC, need for action identified by the ISB
In some cases, the ticket that was initially forwarded for information purposes only may lead to the case-closing classification by the SOC analyst being assessed differently within the organization. The internal assessment may require follow-up work.
Note the following case:
An employee inserts an unauthorized removable storage device into a PC. The SOC notifies the department. There is no need for the SOC to take further action – it closes the case.
However, the organization may find it necessary to carry out follow-up work in the form of an awareness-raising measure or an investigation of the incident (by questioning the employee).
(3.) Case-closing processing by the SOC, information to the ISB
The third case is that the ticket is only of an informative nature on both sides. The incident is dealt with and does not require any further follow-up work in the organization.
The example of conspicuous user behavior can be used here as well, with the difference that both the SOC and the organization classify the event as case-closing.
When classified by both the SOC and the organization, the ticket can be filed without further action.
Which events always require an internal response
So much for the theory. What does it mean in practice? There are two types of reports that require special attention because they almost always require internal action:
(1.) Possible responses to suspicious user behavior: escalation model
If suspicious user behavior is reported, the event handling can result in disciplinary consequences within the organization. A corresponding practical example of this is an employee repeatedly attempting to log into a system for which they have no authorization. Or it may be a case of a spontaneous change that was not properly documented and for which there is therefore no recognizable legitimate reason. A step-by-step escalation model is recommended for such cases:
Step 1: Interviewing the employee or their superior
First of all, the user concerned or their superior must be interviewed about the case. The aim is to clarify the process, with these questions serving as an aid:
Can the procedure be plausibly explained? Can the procedure be justified by a change or incident? Is there a corresponding ticket number?
If not, why was no ticket number created? Was the supervisor informed about the process in advance?
Can the event be explained as harmless?
If it turns out that the case could be resolved by answering these questions, the employee can be released again if they were blocked as a precaution.
Stage 2: Blocking the user concerned
If the employee’s behavior cannot be plausibly explained with the help of the initial interview, the employee concerned should be blocked. The reason: in most cases, this is a security-related event that requires further processing.
Stage 3: Secure evidence
Since it may be necessary to secure evidence in the course of handling the security event, it makes sense to back up log files and protocols in advance. In this case, it has proven practical to back up all log files on the affected client and/or server. If necessary, it is recommended to disconnect the affected devices from the computer network or to secure them.
To ensure the usability of evidence in forensic investigations or even legal proceedings, the information must be protected from unauthorized access, deletion or accidental overwriting. To meet the requirements, it is advantageous to store the relevant information on an external medium or a client / server explicitly intended for this purpose.
Step 4: Initiate forensics
If, during the handling of incidents, employee violations of internal regulations or legal violations are detected, or if such are suspected, forensic investigations must be initiated.
A forensic investigation is carried out with the aim of investigating, understanding and documenting a process in a computer system. This includes identifying, securing and analyzing traces that can be used as evidence in the further course of the investigation.
Stage 5: Initiate criminal investigation
If the security event involves a criminal offense, a legal investigation must be initiated.
(2.) Options for responding to virus reports: Activating emergency management
If the ticket contains a virus report and it could not be automatically eliminated, action by the organization is imperative.
The first steps in this case, in the event of a major incident such as a ransomware attack, are to disconnect the affected devices from the computer network as quickly as possible and to determine the extent of the damage. After that, the emergency management system must be activated, since it can be assumed that this report is an incident with a high risk of damage. Smaller incidents can normally be automatically quarantined.
To prevent further incidents of this kind, the employee responsible should be identified, trained and supported accordingly.
Conclusion: Clearly defining responsibilities protects the core business
As can now be seen, it is entirely possible for management to concentrate on the core business with a clear conscience if responsibilities and measures are clearly defined. A company is not free of all responsibility, but it can routinely cover possible scenarios by consciously defining responsibilities.
