Netflow in the Era of EDR and Cloud: Helicopter Parenting for Your Network
PUBLISHED IN
Situational AwarenessAs network data collection opportunities increase and usage patterns evolve, our “network parenting” methods must follow suit. Despite well-defined security policies, technical safeguards, and extensive user education, people still make mistakes and adversaries still succeed. A similar situation, despite society’s best efforts, exists in raising children. As detailed in this blog post, using the perspective of a security operations center (SOC) treating their network as their children they’re responsible for, we can use aspects of parenting to determine uses of monitored data to build more complete situational awareness. This blog post assumes the reader has kids…or used to be one.
Netflow Data: Listening to Your Network
The age-old method of learning about your children is to listen to them. Everything from big announcements to subtle changes in tone can help parents maintain a sense of the child’s well-being. They detect alterations in opinions and feelings and notice when an issue or situation is no longer discussed, such as when the child is losing interest in a particular subject or activity at school. They also may hear words or phrases that they deem to require intervention, such as social media influencer. Most importantly, they can observe and investigate any indications of health problems. Extensive collection and analysis of netflow is how an SOC listens to its network.
Netflow collection has been an established practice for decades. For much of its existence, it was the primary source of information describing activity on networks. Since its inception, we have witnessed the growth of big data storage and analysis platforms that have enabled the expansion of traditional flow records to include deep packet inspection metadata, such as domain names and SSL certificates. Changes in network architectures, such as cloud adoption and zero trust, have reduced the value of netflow because not all traffic can easily be captured at the network edge. Netflow is not irrelevant, however, and cannot be fully replaced by other data sources. It remains an essential source of information to establish and maintain situational awareness. Adversaries are still required to reach network internal assets from the outside. Even when gaining remote access with stolen credentials, that traffic is visible to network monitoring. Netflow may no longer be the only game in town—and may now even be considered a secondary data source—but rumors of its demise have been greatly exaggerated.
The Role of EDR Data
Endpoint Detection and Response (EDR) data is information generated locally about the inner workings of a host or machine at the system level. With EDR data collection now feasible at scale, it is an excellent complement to netflow, or maybe even the other way around. However, this data is fundamentally different from netflow in terms of structure, variability, complexity, and granularity. Consequently, analytic techniques, processing approaches, and forensics must be adjusted accordingly. A user-level action performed on an endpoint by a member of the organization, or an adversary, creates a multitude of system-level records. These details are essential in the long run, but in a sea of standard and expected system calls, SOC anaysts have a difficult time precisely identifying a specific record that indicates malicious behavior. While EDR may not paint a clear and complete picture of how a host interacts with the surrounding network, there is no better source of actively monitored and collected data about the internal operations of a given host or machine. This situation is similar to the way that medical tests and examinations provide irreplaceable data about our bodies but cannot determine how we think or feel.
As we watch our children go about their days, we are doing cursory-level analysis of their summary EDR data. We can see if they are sluggish, have no appetite, develop a rash, gain or lose weight unhealthily, or have wide emotional swings. After observing these issues, we then choose the appropriate path forward. These next steps are like pivoting between data sources, triggering targeted analyses, or changing your analytic focus altogether. Asking your child to tell you about any issue is like identifying associated netflow records to gain additional information. A doctor uses medical history and information about the whole patient to determine which tests to run. This analysis is akin to a forensics audit of a system’s EDR data in response to an observed anomaly. While the results of those tests are detailed and essential, they still cannot tell us exactly what the child has said and done.
Tailoring Analytics to the Cloud
Paying attention to and interpreting everything a child says and does perpetually can be hard without situational context facilitating comparisons against history and baseline expectations. This situation is why parent-teacher conferences can be so valuable. We have clear expectations about how students should act in the classroom and how their development should be progressing. Feedback received at these conferences is useful due to the level of specificity and because it is offered by a trusted source: a trained expert in the field. In most instances, the desired feedback is, Everything is going great, nothing out of the ordinary. While this feedback may not be exciting, it is an affirmation that there is nothing to worry about from a trusted source that you are confident has been closely monitoring for deviations from the norm. The same style of context-specific intelligence can be attained by proper monitoring of cloud environments.
Transitioning to public cloud services is typically done for specific business purposes. As a result, expected behavior of assets in the cloud is more easily defined, at least compared to the network usage of the on-premises assets. There is less human-generated traffic emanating from cloud infrastructure. Access patterns are more regular, as are the application-layer protocols used. Detection of deviations is much simpler in these constrained environments.
There are two primary types of data that can be collected in the cloud to provide situational awareness: traffic monitoring and service logs. Traffic monitoring can be achieved through third-party flow logs or via traffic mirroring into established netflow sensors such as Yet Another Flowmeter (YAF) or Zeek. Service logs are records of all activity occurring within a particular service. Each data source can be used to detect behavioral anomalies and misconfigurations in an easier way than on-premises network architectures.
Avoiding the Locked Vault Door and Open Window Scenario with Zero Trust
Zero trust concepts, coupled with remote work postures, have enabled significant user activity to occur outside traditional network boundaries. Building zero trust architectures requires organizations to identify critical assets and the associated permissions and access lists for those resources. After those permissions and accesses are deployed and confirmed, monitoring of those connections must commence to ensure full policy compliance. This examination must be done for both the users and the critical assets. It is not enough to have confidence that all expected accesses maintain zero trust protections.
We want to avoid a situation analogous to a locked vault door (zero trust connections) attached to a wall with a big hole in it. Netflow can be used to monitor whether all connections to and from critical assets are properly secured according to policy, not just those connections built into the policies. Zero trust application logs can be correlated to netflow records to confirm secure connections and interrogate repeated failed connections.
The initial deployment of zero trust architectures is akin to a parent meeting their child’s friends. The key is that after the initial introductions, a parent needs to ensure that those are the main friends their child is interacting with. This process happens naturally as parents listen to their children discuss activities and pay attention for new names. As children expand their social circles, parents must continually update their friend lists to maintain situational awareness and ensure they are paying attention to the proper aspects of their children’s lives. This analogy extends to the other benefit of zero trust architectures: mobility. Smart phones increase the freedom of children while maintaining a connection to their parents. For this to be effective, parents must ensure their child is reachable. The same logic applies to monitoring connections to critical assets, as organizations must ensure their users are securely accessing these assets no matter their location or hardware type.
The Importance of Real-Time Streaming Data Analysis
Something we take for granted with parenting is that analysis happens in real time. We do not use mechanisms to record our children’s activities for future analysis, while ignoring the present. We do not wait for something unfortunate to happen to kids then go back and look up what they said, how they behaved, the actions at school, and who they interacted with. However, that is the route we take much of the time with security data collection, when we should be looking to gain insights as events happen and data is collected.
There are many of types of detections that are ripe for streaming analytics that do not require maintaining state and avoid complex calculations:
- network misconfigurations
- policy violations
- cyber intelligence feed indicator hits
- rarely used outbound protocols
- rarely used applications
- changes in static values, such as V(irtual)P(rivate)C(loud) ID
- account or certificate information
- zero trust connection termination points
Understanding the specific purpose of different data sources and appropriate linkages for enrichments and transitions is essential for SOC operators to avoid drowning in the data. Utilizing streaming analysis to build context and for faster detections can avoid repeated large queries and repository joins. SOC operators considering themselves to be parents of the assets on their network can change the perspective and provide better understanding.
Happy parenting.
Additional Resources
The Network Situational Awareness (NetSA) group at the CERT Division of the SEI has developed and maintains a suite of open-source tools for monitoring large-scale networks using flow data:
- SiLK - https://tools.netsa.cert.org/silk/
- YAF - https://tools.netsa.cert.org/yaf/index.html
- Mothra - https://tools.netsa.cert.org/mothra/index.html
- Super Mediator - https://tools.netsa.cert.org/super_mediator/index.html
- Analysis Pipeline - https://tools.netsa.cert.org/analysis-pipeline5/index.html
- NetSA NiFi - https://tools.netsa.cert.org/netsa-nifi/index.html
- fixbuf - https://tools.netsa.cert.org/fixbuf/index.html
More By The Author
More In Situational Awareness
PUBLISHED IN
Situational AwarenessGet updates on our latest work.
Sign up to have the latest post sent to your inbox weekly.
Subscribe Get our RSS feedMore In Situational Awareness
Get updates on our latest work.
Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.
Subscribe Get our RSS feed