Skip to main content

Unlocking the Power of Organizational Context: The Devil is in the Details

By Dan Ramaswami, VP of Field Engineering

From a security standpoint, we’ve done a really good job of building large data repositories that accept massive volumes of disparate pieces of information. But the problem is that we rely on those repositories only after the signal itself has been created. So, before we can determine whether an alert is of interest or not, relevant data within those repositories has to be applied to the signal for context. 

To gain context, we “swivel chair” between context tools and signaling technologies such as our firewall log, intrusion prevention system (IPS), endpoint detection and response (EDR) system, and context sources such as Active Directory, and the configuration management database (CMDB) to piece together the who, what, and where of an alert. Or we wait until the data gets into the SIEM so we can send a query that might take hours to process. The alert volume is so high, and the task of figuring out what matters is so onerous and time-consuming that teams become desensitized to alerts and now 70% of SOC teams report they are emotionally overwhelmed by their work managing threat alerts. The challenge only compounds as organizations rely on an increasingly diverse set of tools to secure their Atomized Networks.

At Netography, we believe that when the devil is in the details—literally—organizational context should be part of the signal stream, so alerts are really alerts, and not just information. Instead of waiting until post-signal to apply context, we enrich cloud and on-prem network flows and metadata with organizational context at the time of ingestion. We use three main categories of organizational context: 

  1. User information which may include the username, what department they are in, who they report to, whether they’re an employee or contractor, a phone number, and home office data.
  2. Host information which includes hardware, operating system, applications and services installed, patch levels, BIOS levels, etc.
  3. Location information which, in addition to a physical address can include aspects such as where within a specific campus—the data center, the finance department, or a conference room, etc.—and what, if any, security controls are in place between these physical locations and the destination of any traffic.

We work with customers to look at all facets of each category and define those important context data points to connect detailed information about users, hosts, and location. We winnow the wheat from the chaff using powerful context labels that we apply to traffic, and include relevant data points as part of the signal stream as the occurrence is happening. There’s no need to go from point to point to point gathering pieces of data or do additional look ups and wait for queries to run. 

Having organizational context from the start, customers are able to make business-relevant detection and response decisions with greater efficacy, ease, and speed. Instead of an alert just being this IP address talked to that IP address, we break it down further. For example:

  • A printer is talking to a country of significant concern, such as “The People’s Republic of well, it’s Not Kentucky”. That’s a problem. 
  • Or an IP phone is talking to a specific container within the cloud that computes sales tax, which is probably not good. That’s indicative that the phone might be serving as a jump-off point and is now being used in lateral movement.
  • Or drilling down further, if there is a laptop in the finance department that is doing something it shouldn’t, that’s important. But, if that laptop in the finance department also has access to the SWIFT network and to banking apps, then that alert becomes so much more important to the business. 

Customers receive true, high fidelity, actionable alerts worthy of an outcome, whether that’s changing a firewall rule to block communication between a database server in your cloud backend and an IP address in “Not-here-istan” or quarantining a laptop immediately in case of a “nuclear-level” security event.

These scenarios are wild by design to really show that when alerts are based on an understanding of the operating environment—leveraging the organizational-specific context, we instantly know something potentially bad is happening and can move more quickly to detect and remediate. And that’s the point. Instead of alerts that require more work to know whether to worry about them, Netography unlocks the power of organizational context to deliver alerts that matter.