How to triage Elastic Security alerts

Where Elastic Security alerts show up

To triage an Elastic Security alert, open it from the Alerts page, read the rule that raised it, identify the host and user, look at the events around it on that host, and make a clear call: real attack, suspicious, harmless or not enough evidence. The rest of this guide turns those steps into a routine you can repeat on a busy day.

In Elastic Security, detection rules run on a schedule against the data in your indices. When a rule matches, it writes an alert, and alerts are listed on the Alerts page inside the Security app in Kibana. Each row shows the rule name, the time, the severity, the risk score and the main entities involved, such as the host name and the user name. Opening a row shows the alert’s details: the fields of the event that matched, the rule’s description and links into deeper views.

Alerts also carry a status, usually open, acknowledged or closed. Use the status on purpose. Acknowledged should mean someone is working on it, and closed should mean someone reached a verdict and wrote it down. A queue where alerts are closed in bulk without notes tells you nothing later, when an incident review asks what was seen and when.

How to read the rule name, severity and risk score

Start with the rule name, then open the rule itself. The name is a summary written by whoever built the rule, and a name such as “Suspicious process execution” can cover very different behaviour. The rule’s query and description tell you what was actually matched: a command line, a parent and child process pair, a sign-in, a network connection or a threshold being crossed.

Severity and risk score are set on the rule, not worked out from your environment. Severity is a label (low, medium, high, critical). Risk score is a number the rule author picked to rank alerts against each other. Both are useful for sorting the queue, and neither knows that the host in question runs your payroll or is a test machine due to be rebuilt. Treat them as the rule author’s first guess, then adjust with what you know about the machine and the account.

Note the rule type too. A query rule matched a single event. A threshold rule counted events and crossed a limit. A machine learning rule saw something unusual for that host or user compared with its own history. An indicator match rule found a value from a threat intelligence list. Each type deserves a slightly different first question: what was the event, what was counted, what is the usual pattern, or where did the indicator come from.

• What exactly did the rule match, according to its query?
• Which event fields triggered it, and at what time?
• How often has this rule fired in the past few weeks, and on which hosts?
• Does the severity fit what this host and account do for the business?

How to check the alert’s host and user

Most of the triage decision rests on two entities: the host where it happened and the user or account involved. Elastic records these in standard fields, such as host.name and host.os for the machine and user.name for the account. Click through to the host and user details to see their other recent activity and any other alerts raised on them.

For the host, find out what it is for and who owns it. A domain controller, a build server, a developer laptop and a shop till each have a different normal. For the user, find out whether it is a person or a service account, which team it belongs to and what it usually does. A service account that runs backups at two in the morning is ordinary. The same account opening an interactive shell is not.

Look for other alerts on the same host or user over the past few days. One odd event on a machine can be noise. Several alerts from different rules on the same machine, close in time, are much harder to explain away and are often the first sign of a real attack moving through its stages.

How to use the timeline and process view

Elastic Security gives you two ways to see what happened around an alert. The timeline is a workspace where you collect events: you can send an alert to it and then add queries for the same host and user, a few minutes either side of the trigger. Read it like a log of the scene. Which processes started? Which files were written? Which network connections were made? Did anyone log on?

The process view, which Elastic calls the analyser, draws the alerted process with its parents and children as a tree. This is often the fastest way to understand intent. A command shell whose parent is a web server process, a script interpreter launched by an office document, or a binary started from a temporary folder all suggest something arrived from outside. A tool started by your configuration management agent, under its usual account, usually did not.

Use both views to answer one question at a time rather than scrolling. Write the question down, run the search that answers it and note the result. That record becomes the evidence behind your verdict, and it lets someone else check your reasoning without repeating your work.

Which fields and data sources to check

Triage depends on the data behind the alert. If endpoint process events are not arriving from a host, you cannot build a process tree for it, and an alert from that host will be harder to judge. Before you rely on a view, check that the data it needs is present for the time and machine you are looking at.

The fields below are named in the Elastic Common Schema, which Elastic integrations use. Your data may carry extra fields, but these are the ones worth checking first on most alerts.

• Process: process.name, process.executable, process.command_line and process.args, to see exactly what ran
• Parent: process.parent.name and process.parent.command_line, to see what launched it
• Account: user.name and the user’s domain, to see who ran it and whether that is normal
• Network: source.ip, destination.ip, destination.port and dns.question.name, to see where the host talked
• Authentication: event.category of authentication, with event.outcome, to see sign-ins and failures
• Files: file.path and file.hash values, for writes to unusual places and hashes to look up
• Data sources: Elastic Defend or other endpoint data for processes, the system integration and auditd data on Linux, Windows security event logs, and firewall, proxy or DNS logs for the network side

How to treat noisy rules

Some rules will fire often on ordinary activity in your environment. Common examples are rules for discovery commands that administrators also run, rules for script interpreters used by automation, rules for new scheduled tasks or services created by software installers, and machine learning rules on hosts whose behaviour changes often. None of these is a bad rule. Each needs tuning to your environment.

The safest tuning is narrow. Elastic rules support exceptions, and an exception that names a specific process, a specific account and a specific set of hosts removes one known source of noise. An exception that excludes a whole folder, a whole family of accounts or every process with a common name can open a gap an attacker can use. Record why each exception was added and review the list from time to time.

Before closing a noisy alert as harmless, check that it really matches the known pattern. Attackers favour the same tools administrators use, precisely because they blend in. A discovery burst from your usual admin account on its usual jump host is one thing. The same commands from a web server’s account are another.

How to build a repeatable triage routine

A routine keeps triage consistent between people and between shifts. Write it down, keep it short, and use it on each alert you open. The aim is not to make triage mechanical. It is to make sure the same questions are asked each time, so that a missed step shows up as a gap rather than a guess.

Escalate when the evidence points to a real attack, when the host or account matters to the business and the activity cannot be explained, or when the data you need is missing and the stakes are high. Say why in one or two sentences, attach the searches you ran, and name the person or team you handed it to. A clean escalation saves the next person from starting over.

• Read the rule and its query, not only its name
• Identify the host, its owner and what it does
• Identify the account, and whether it is a person or a service
• Look at the process tree and the events a few minutes either side
• Check other alerts on the same host or user in recent days
• Look up any outside addresses, domains or file hashes
• Make a call, say how sure you are, and record the evidence
• Escalate, close with a reason, or tune the rule through change control

How armor360 approaches it

armor360 is an AI SOC analyst that works with Elastic Security first. It collects new alerts automatically, puts likely real attacks first in the queue and investigates each one by asking questions and answering them from your data: events in Elastic, other alerts on the host, process and parent chains, user activity and threat intelligence lookups. Each record it uses is kept and cited.

Each alert gets a verdict (real attack, suspicious, harmless, authorised activity or unsure) with a confidence and a reason. A person reviews it, agrees or changes it, and decides what to do. armor360 recommends; it takes no action on your systems.