If your organization’s security posture is maturing beyond prevention and beginning to focus on detection, you may find yourself evaluating a host of new security technologies.

Among the most attractive for many organizations are network intrusion detection systems (NIDS) or intrusion prevention systems (IPS). These “starter” platforms are easier to roll out, because they don’t involve configuring each endpoint; they require no training, rendering them transparent to end users; and you don’t need to test them on lots of platforms.

You’ve got alerts. Now what?

When you first start out with your NIDS or IPS, the influx of alerts where there were none before can be confusing. . Without a systematic approach, you may find yourself unsure of what to do with all these alerts.

However, it’s important to find a way to examine each and every incoming alert. Even if you aren’t part of a regulated industry — where compliance and audit rules may force you to look into each alert — the inability to clearly delineate false positives from real threats is too great a risk to take.

How so? NIDS alerts about a host system’s communication to a blacklisted IP address don’t differentiate well, so an outsider’s effort to steal Facebook credentials won’t look any different from an effort to steal admin credentials.

Therefore, while you may investigate an alert one week — only to find that it’s a “tip of the ice cube,” random, small-scale adware infection that doesn’t require a lot of time and effort to contain and remediate — the alert you investigate next week could be a “tip of the iceberg,” widespread compromise of your network, which you were lucky enough to happen upon.

In short, when a NIDS flags command-and-control traffic, it isn’t giving you the whole story. How can you contextualize the parts of the story you are getting?

Put alerts in perspective with triage

A NIDS alert in itself doesn’t need to trigger a full-scale incident response. However, there are basic incident response practices you can put into play yourself to improve your context and help you make better decisions. These include:

• Review the system for malware and system configuration changes. Common locations for hidden malware include startup programs, running processes, and scheduled tasks.
• Review user activity. Logins, remote desktop activity, network shares, and programs that have recently run can all provide important indicators if the account credentials were compromised and the attackers have been using it to steal information.

These activities provide the needed visibility into the endpoint. When they are automated, they can be performed with little user interaction. This way, you need only spend time reviewing the data to make a determination. This saves time and allows you to get through alerts more quickly, keeping your alert backlog smaller and more manageable.

An automated, easy-to-use process also reduces the need for a “deep dive” incident responder or forensic expert, saving additional time and money at a time when you may not even be sure you need that expert.

Cyber Triage automates these and other triage processes so that anyone who is responsible for the initial stages of incident response can assess alerts quickly and use the information to decide what comes next. Contact us for a demo of how you can put it to work for your organization.

photo credit: malware-analysis-category1-1024×682.jpg via photopin (license)