6 Core Principles of Incident Escalation

Introduction

What happens when an incident occurs, incident in the sense when SIEM (security information and event management) triggers any activity as an offense? Either the malicious IP is blocked by the firewall if it is configured to do so or if one of the firewalls can’t prevent it and allows passing it. If any incident occurs, the team that is monitoring the logs tries to handle it, and if they can handle it, then it is OK, but if they can’t handle it then they need to escalate to their upper authority to handle that. For example, level 1 escalates to level 2; level 2 escalates to level 3, and then level 3 goes to the incident response team (IR) team, then they further drive the investigation.

Rules for Incident Escalation

1) Understanding Intensity of Attacks

In SOC (Security Operation Centre), if there is an incident escalation, then there must be two cases, First is SOC analysts have don’t much knowledge; this happens very rarely because, in this field, there are only professionals who have real knowledge about this field. Secondly, the offense is critical, and that isn’t very good. If SIEM considers any event as false positive (false positive is when the reports say there is offense, but it’s just a false alarm) and the escalation happens, then it is considered as terrible practice and can lead to a couple of crippling issues. Firstly, the SOC ends up with the reputation of “crying wolf” (call for help when it is not needed). Secondly, SOC analysts waste their time in the offense that is not dangerous. As I said before, the lower level escalates to upper-level authority if the lower level fails to resolve it.

There are two types of activities, either the business is successful or either the operation is blocked. Always give priority to the fruitful service and investigate it because another one is already blocked.

A precious rule is that SOC analyst has to analyze the activity, whether it is successful or not.

After studying, check whether the event is malicious or not, or we are just wasting our time. Some steps can be taken from the upper context that is-

• Expand the time frame of your investigation of the SIEM dashboard so that you can get more information regarding the offenses.
• Check if; there is traffic returning from sources using firewalls.
• Check application logs and web servers to see if the webserver responded with an HTTP.

2) Incident Completeness

If you escalate any incident, then there must be a proper explanation of the event that you have analyzed. It is essential to ensure all the information that you have captured during the analysis phase. Making a full defined picture of the data when, where and how it has happened, it makes it easy for the upper authority to understand and speed up the work, and it should be stated that why it is escalated. Necessary information that is needed for the upper power should be adequately covered. There are stringent compliance policies for it, so victims are very likely to pay the ransom.

List of points that much be essential for escalating:

• System criticality and role
• The types of behavior alerted on.
• Source, destination hostnames, and IP addresses
• Source and destination ports
• Operating systems involved
• Listening services
• If relevant vulnerabilities exist on the system
• If the attack occurs, then all the information collected during or after the attack must be logged, and this information acts as crucial evidence. When you back up an incident escalation with hard evidence, the incident will receive the attention and urgency.
• All the items or any information discovered during the investigation must be written in proper notes—for example, information regarding the source or destination IPs, etc.

3) Prioritizing the areas

Another essential parameter to be taken care of while incident escalation is the business context. Assuming a system being the target of the attack in an organization, understanding the business context is critically important for the incident escalation.

It becomes more important to protect when after the investigation, if the system attacked is a revenue-generating component of the organization.

This will create urgency on the research and becomes a priority to assign further for the escalation. It can be wiser for the analyst or the team to check the organization’s Incident Response Plan to proceed when dealing with business-critical systems.

4) Scope

Determining the scope of the incident is difficult for SOC analysts as within the SOC, they are not equipped with the adequate tools that are required to scope an event. So, it is said to perform the best to find a similar affected system within the environment by using the tools available. The information which is gathered by the investigation so far is used to pivot through the additional sources of data.

After that looked into the other system in the environment that displays the same or similar behavior as the identified system. This can include:

• Network connections to IP addresses or domain names
• Unusual processes or processes running from abnormal directories
• The presence of a remote management tool with a unique version number
• The hash of a particular file
• Use of specific user accounts across multiple systems

When connections are found between a formerly infected system and another system in the environment, be sure to:

• Document that connection
• Provide a sample of the data that connects the two systems

Include the new system in your incident escalation.

5) Writing the Notes

Writing a summary for an incident escalation is something that came up with time and practice. Usually, SOC analysts face problems while writing a review. Writing a paragraph contains detailed information about that incident so that when the person is escalating it to the higher authority, he can form a hypothesis that what caused that event to occur and what its effects are. The timeline will guide you, describing the sequence of events in the incident summary. Mentioning events according to the timetable will help you write many useful reviews.

• All logs generated should be stored as a record for further analysis.
• All the data stored must be in a standardized format to ensure effective and efficient processing.

6) Escalate With Urgency

Now that a brief understanding of the events analyzed, the number of systems involved and their weakness, magnitude of the game has been reached, you should also get an idea about how harmful the attacker is and thus try to use the right level of urgency.

Moreover, organizations can use the Incident Response Plan (IRP) as a guide for the level of need on incident escalation. If the information is collected and analyzed correctly and if it requires a higher level of need, then take the initiative to escalate it as soon as possible.