When triaging a host during incident response, it is critical to be able to quickly focus on the suspicious data. Whitelisting gives you the ability to ignore known safe files, for example, so that you can focus on truly suspicious items.
However, you can’t know what’s suspicious if you don’t know what’s “normal” — which can change from organization to organization. For example, some organizations enable software to allow their IT staff to access systems remotely.
For these organizations, the software is normal. However, threat actors can use the same software to gain remote entry into the system. If your organization uses remote access software, then whitelisting it will eliminate alerts about it on every host, reducing the amount of noise for you.
When responding to an incident, you’ll collect data that is common to:
- All hosts using that operating system
- The enterprise and how its hosts are configured
- That specific host
These details are not only unique to the organization; they tend to change as new software is rolled out, obsolete software is retired, rules change, and fixes are applied. Rather than be expected to keep track of all these changes, or for IT staff to communicate vast institutional knowledge during the heat of an incident, responders need a simple way to pre-configure what the organization considers normal.
The Cyber Triage whitelisting approach
Cyber Triage comes preinstalled with whitelist entries to hide operating system data that is common to all hosts. It also allows you to add whitelist rules to hide data that is common to your or your client’s enterprise.
This approach to whitelisting gives you control over where the whitelist rules are applied. You can configure global rules and apply them to all hosts; or apply local rules only to the specific host you’re working on. (You always have the option to disable whitelisting if you want to see alerts on whitelisted items alongside other items.) This control allows you to focus on the data that is unique to that host, which could be benign or malicious.
Although Cyber Triage has always allowed for file whitelisting based on MD5 hashes and file paths, the ability to filter out standard network ports is new with Cyber Triage 1.2, released this week. By displaying only non-standard ports which are, for example, being used by remote access applications, you can reduce the amount of time you spend assessing activity, and focus on that which is truly suspicious for an individual network.
Another time-saving feature of Cyber Triage 1.2 is a speedier first phase collection. We’ve enhanced our non-persistent agent so as to reduce the amount of time it takes to obtain volatile data, as well as data referenced in the registry and event log, by four times. In some systems, for instance, the collection went from 8 minutes to 2 minutes.
Additional whitelisting functionality, together with customization and prioritization features, are planned for the next Cyber Triage release. You’ll be able to flag items as well as group hosts to correlate, which will also help to save time.
For consultants, being able to create whitelists for a given incident as you learn more about a specific customer can make a difference in how fast you respond and the methods you use to respond. Try Cyber Triage 1.2 — schedule a demo with us today!
