Any cybersecurity analyst will tell you that there is a huge need to reduce the amount of false positive alerts they receive every day. In the first part of this blog series we described an Incident Response (IR) team that, instead of focusing on true threats, was all-to-often running down “suspect ping” alerts caused by harmless software updates.We discussed using ontologies to model alert data in graph form. By putting the original alert data into graph form, and using a description logic reasoner, Dark Light™ is able to apply expert knowledge to make inferences. In the case of the “suspect ping” problem, we use knowledge about related processes to reason if the alerts should be ignored, or classified as truly “suspect”.
The nature of Process X's parent-process implies that it is a SuspectPing.
Events viewed in Dark Light can save the analyst the need to return to the original event logs by putting their results in context. This PRO includes the parent-process with the discovered SuspectPing. Like a good little scientist, the PRO is saying:
"Don't take my word for it! See for yourself: Here are all the facts I used to reach my conclusion."
The completed PRO publishes A SuspectPing together with its parent-process.
We can use this enrichment technique to include other time-saving facts to assist the human investigator. In addition to reasoning over and including other log events, Dark Light has a store of contextual knowledge that PROs can access during their analysis. Contextual data is enterprise specific information that a cybersecurity analyst would have knowledge of, but is usually absent from event logs and security appliance alerts. As part of Dark Light’s initial configuration, this data is modeled in an ontology then transformed into graphs and stored in contextual memory.
Graph structure of the enterprise contextual data
The PROs came to the conclusion that this particular SuspectPing was a true positive, enriched it with this important contextual information and the results are displayed in tabular, detail and graphical formats as shown below. Now, it's ready for the analyst to resolve.
A SuspectPing with parent-process, device owner, department and manager.
In this series we've discussed how Dark Light PROs can be used to ask (and answer) the same questions a cybersecurity analyst would tackle as they investigate an abnormal event. The first PRO identifies the SuspectPing events by allowing the analyst to automate their decision making process. An additional PRO enhances these true positives with contextual details that would usually be gathered manually from disparate sources. Together, these PROs automate the beginning of each investigation, giving the cybersecurity analyst a significant head start.
For a more detailed walk-through, see our in depth tutorial: Eliminating False Positives for a Suspect Ping Alert.