Cyclone

One of the goals of a Security Operations Center (SOC) is often incident response at the speed of business. When an incident occurs, various different stakeholders will have tough questions requiring timely, accurate answers. Network forensics provides the means through which timely, accurate answers are uncovered in the enterprise data. The "Cyclone" workflow enables network forensics by allowing the human analyst to focus on incident response, rather than serving as a "Human API". Cyclone eliminates the need for the human analyst -- the most precious resource -- to force various technologies to fit operational needs and demands that they were not designed to fit. Cyclone consists of three components:

• Capture
• Inspect
• Expose

Elaborating a bit more, these components of Cyclone ensure:

• That the network traffic was captured
• That the meta-data from the network traffic was inspected
• That the meta-data is exposed for analysis, network forensics, and complex event processing

It is not surprising that in order to perform network forensics, an organization requires that the network traffic data was captured. The answers to the tough questions posed by stakeholders are found in the data, and if a record of the data does not exist, those questions cannot be answered.

Once the data has been captured, it must be inspected. The inspection process allows for extraction of valuable meta-data, assembly into sessions, enrichment, and indexing for high speed search. Large enterprises see an overwhelming volume of traffic that necessitates high speed search in order to properly perform network forensics. The data can only be exploited for network forensics if searches return results at high speed.

Once the meta-data has been inspected, that meta-data needs to be exposed for analysis, network forensics, and complex event processing. In other words, answering the important questions requires crafting specific, incisive queries that extract the precise data necessary to answer those questions. This can only occur when the meta-data is exposed and can be exploited analytically.

When an incident hits, organizations need to respond quickly. Cyclone ensures that the proper workflow components are in place ahead of time and ready for when an incident occurs. With Cyclone in place, organizations can focus on carrying out a timely, effective incident response, without wasting precious time serving as the "Human API".

Visualization

The human eye can often pictorially identify patterns, connections, and outliers in the data that would otherwise be very difficult to identify through other means.  Visualization, in that it allows the human eye to pictorially scan the underlying data, can be a powerful tool when leveraged appropriately.

I have seen many different types of network traffic data visualizations, but I have seen very few that add value to security operations.   To understand why, it helps to take a step back and look at what visualization is attempting to do from a higher level.

The purpose of visualization is most often to elicit patterns, connections, and outliers in the data using the human eye as the parsing and analysis mechanism.  In order to properly elicit meaning from large enterprise data, one must first reduce the data to improve the signal to noise ratio.  In other words, given the volume and variety of data in the modern enterprise, the level of noise is simply too high to allow for meaningful visualizations without first performing one or more data reductions.

How does one perform data reduction to produce a meaningful visualization that will be useful to security operations?  Thinking about what specific question the data should be used to answer is a good first step.  Let me try and illustrate this through an example.  For our example, let's assume that we are trying to use visualization to understand to which countries we are sending Office documents.  Before we can think about how to visualize the data, we need to reduce the data by asking it to return only the results that meet these criteria:

• That the data is leaving the network (as opposed to entering the network).
• That the data contains only sessions where the file type is one of the Office file types (e.g., Word, Excel, PowerPoint, etc.).
• That we have a mechanism in place to map the destination to a country (be it by domain, IP address, or ASN).

Once the data has been reduced, and the signal to noise ratio has been increased substantially, we can begin to consider which type of visualization fits best.  Different questions asked of the data will necessitate different types of visualizations to elicit the patterns, connections, and outliers we are looking to delineate.  In our example, a world map with some coloring or shading to indicate volume (be it number of sessions, number of bytes, or otherwise) probably fits best.  When completed, our visualization will provide us with a graphic that we can scan with our eye.  The data reduction we performed allows us to assess quickly, with a specific context in mind, whether or not we can identify something requiring further investigation.

In my experience, unfocused attempts at visualization produce visualizations that are not particularly useful for security operations.  Visualization does have tremendous potential to bring value to security operations when leveraged properly.  Performing data reduction by posing specific, incisive queries into the data provides a good starting point for producing visualizations of high value to security operations.

Moving up the Stack

Over the past decade, attackers have moved deeper into the packet. As network defenses, controls, and detection techniques have improved, attackers have had to "move up the stack" to avoid detection and maintain persistence. A decade ago, attackers would often use dedicated resources on known malicious networks to communicate with their malicious code. Back then, malicious IP blacklists were common, and they were used widely to detect malicious activity. Back then, it was often possible to detect malicious activity using only data available at layer 4 of the OSI model.

Over the years, attackers were forced to move away from dedicated resources to more dynamic resources. This was due in part to dynamic resources becoming easier and cheaper to use, as well as efforts by law enforcement, telecoms, and others to shut down dedicated resources. Because of this transition, attackers were forced to change the way they operate and communicate with their malicious code. Domain names and URL patterns, both of which are only found in the data available at layer 7 of the OSI model, became the preferred means for malicious communication. Moving up the stack allows attackers to change where their malicious code communicates easily and at a moment's notice. This new paradigm requires layer 7 data to detect intrusions -- layer 4 data is no longer sufficient.

Attackers have already made the move up the stack. On the enterprise side, we need to make sure we have the tools to move up the stack with them. Layer 7 enriched meta-data provides us a solid foundation upon which to perform the network forensics we need to perform in order to detect and respond to intrusions in a timely manner.

Shrinking the Rack

It will come as no surprise that most enterprise security organizations are perpetually understaffed and resource constrained. This is especially true with regard to the resources required to deploy, maintain, and use enterprise security technology. Because of this, choosing which security technologies to deploy is an important decision that has many ramifications and consequences. This blog posting explores the concept of collecting fewer data sources of higher value, rather than a larger number of data sources of lower value. In effect, "shrinking the rack" of network instrumentation equipment without adversely affecting visibility, monitoring, and operations.

Most enterprises instrument their network to collect highly specialized forms of data. For example, an organization may have a netflow collector, a DNS tap, and a variety of other technologies to collect highly specialized forms of data. This creates a stream of various different data types and formats that complicates and clouds the operational workflow. I note this as an observation and do not mean it to be critical. Having worked on the operational side for over a decade, I understand quite well that for historical and other reasons, enterprises have had to make difficult choices to meet operational needs under less than ideal conditions. What I am suggesting is that as equipment comes to end of life, as priorities change, and as the threat landscape evolves, enterprises take a second look at what goes into their network instrumentation and monitoring rack.

In addition to the variety and complexity of specialized forms of data, the volume of data confronting enterprises these days is also overwhelming. So, this adds huge quantities of data to the already complicated operational security workflow. This perfect storm of circumstances creates a very real big data challenge.

Let's consider a unified, consolidated approach provided by PCAP data and its associated meta-data. Full packet capture (PCAP) records all traffic transiting the network. The meta-data that can be parsed out of both layer 4 (network layer) and layer 7 (application layer) provides an incredibly rich data source for the big data challenge. This rich meta-data also includes the specialized data forms often collected within enterprises. For example, if we look at the data obtained from the DNS tap example, we see that it is functionally the same as the DNS protocol meta-data parsed out of PCAP data. The potential this provides for simplification, streamlining, and optimization of workflow and operations is incredible.

We live in a world that seems to get increasingly more complex. Those of us that work in the security operations field feel this on a daily basis. Shrinking the rack allows us to simplify, optimize, and reduce complexity within our environments without sacrificing visibility and functionality. As you think about replacing, upgrading, or modifying your network instrumentation equipment, it may be helpful to consider shrinking the rack. Sometimes, less is more.

Breaches Happen

Recently, a number of high profile data breaches have been in the news quite a bit. The general public is quickly becoming aware of something that security professionals have known for quite some time -- that compromises and breaches are going to happen. What separates good organizations from great organizations is really their preparedness and response during these types of high profile incidents.

Typically, immediately after an enterprise becomes aware of a data breach, several important, focused, and pointed questions will be asked of the security organization by the company's leadership, as well as the members of the company's legal and privacy organizations:

• How did this happen? 
• When did this begin?
• Is this activity still occurring?
• How many systems/brands/products have been affected?
• What sensitive, proprietary, and/or confidential/private data has been taken?
• What can be done to stop this activity/prevent it from happening again?

These questions are appropriately and pointedly aimed at assessing the damage, understanding the legal, privacy, and business ramifications of what has occurred, and formulating a plan to respond as required. The answers to these questions require hard facts that can only be found in the enterprises's network traffic data.

Given this, it is perhaps a bit surprising that when many organizations attempt to answer the above questions, they will find that they do not have the appropriate data in place to do so. There can be many reasons why this is the case, but chief among them are:

• Incomplete/partial instrumentation of the network (i.e., the required data is not being collected at all required points of presence to provide the appropriate answers)
• Inadequate data retention (i.e., the required data is not being retained sufficiently long enough to provide the appropriate answers)
• Inability to leverage the data for analysis (i.e., the required data may or may not be collected, but is retained in a system or systems that do not allow for it to be exploited analytically to provide the appropriate answers) 

People, process, and technology are said to be the elements upon which great organizations are built. When data breach response time comes, having the right people and the right processes in place is undoubtedly critical. Equally critical though is having the right platform in place that allows for both collection AND analysis, so that a great organization's people and process can shine and perform incident response properly.