Event Data Sources, Haystacks and Needles

What are your uses cases, the chicken or the egg?

I have been asked on a recurring theme what my use cases are for the security related products I am deploying.  The more I have put concerted thought to this question the more I realize that it is very much a chicken and egg proposition.  In security we are effectively trying to protect the confidentiality, integrity and availability of our clients business transactions.  We are asked to accomplish this by being as non-invasive and invisible as possible, while providing the utmost of details when something unexpected occurs. In this vein of thinking I suggest that a haystack of event data sources is desirable and therefore I want to capture the modicum of data points available in the client environment.  The needle I am searching for is very likely present in the most inconspicuous place.

Don’t you want to filter out the noise first?

Simple answer is no, not first.  First I want to compare any and all documentation about the protected environment against the events actually occurring in that environment.  I want to identify the modicum of events compared to those specific events that make up known transactions.  What does the transaction set look like when my patch management systems scans the environment for missing patches for example? What does the transaction set look like when business process X is initiated, communicates with supporting processes and successfully completes?  What pieces of the haystack are missing and are thereby preventing me from documenting the expected transactions in my protected environment? I want to compare the documented systems data flows against the actual event throughput. I want to compare the documented actors in the system against the actual sources and destinations captured. I need to understand when a business process receives or provides output to external sources and targets.

What’s second?

Understanding the threat sources compared to the vulnerabilities present in the protection environment.  This is accomplished by documenting the known vulnerabilities in the protected environment against the national vulnerability database, CVE, virus and malware databases as well as others.  Correlation rules can then be created that take into account the transaction patterns identified in these malicious or commonly exploitable transactions. Those rule fires can be compared known expected transactions, the intersection and outliers of which can be investigated as our “needles”.

So you found a needle, now what?

Categorization, that’s what.  Many of the needles found will end up being false positives, but that does not mean the information generated from the investigation is not useful.  That information can be used to correct configuration issues and to classify events to better describe known transactions. The more we can characterize the expected the easier it becomes to key in on the unexpected.

What is my use case?

The actor will observe system event data sources with respect to given event periods, enhanced by the sequence of common initiators as compared to known expected situations identifying undesirable occurrences to which the actor will apply remedies protecting the confidentiality, integrity and availability of appropriate business processes.