Partner Perspectives  Connecting marketers to our tech communities.
5/21/2018
09:00 AM
Jack Hamm
Jack Hamm
Partner Perspectives
Connect Directly
LinkedIn
RSS
50%
50%

Get Smart About Network Segmentation & Traffic Routing

Through a combination of intelligent segmentation and traffic routing to tools, you can gain much better visibility into your network. Here's how.

The first step to solving the security tool selection problem is asking the right questions:

•   Do you handle credit cards? Are you subject to Payment Card Industry (PCI) regulations?
•   Do you handle Personal Identifiable Information (PII) in Europe that is in scope with the General Data Protection Regulation (GDPR)?
•   Do you build computer things? Do your engineers do stuff that could “look suspicious”?
•   Do you have a small number of things you really need to secure, but the rest can burn?

Step two is taking inventory of exactly what your company does. For example, in my world, I know that:

•   We build network security tools.
•   Our engineers do a lot of DevTest work that “looks suspicious.”
•   We run traffic generators that create fake network behavior.
•   We run a lot of testing side by side with production traffic.
•   We have multiple clouds.

While our jobs entail much more, these tasks play directly into our tool selection process. Fortunately for me, I’ve been given carte blanche at Gigamon to test whatever tools I want on my live network. In fact, seeing how tools have failed in my network is what led me down the bespoke train of thought. To give some concrete examples:

•   User Behavior Analysis (UBA) tools firing dozens of alerts per day.
•   Network Intrusion Detection System (NIDS) tools failing to detect files fast enough due to excessive, irrelevant, traffic.
•   Metadata alarms triggering at all hours.
•   Security Information and Event Management (SIEM) systems failing on unusual Transmission Control Protocol (TCP) parameters.

As a research and development shop that builds security tools, we do a lot of stuff that other security tools would consider bad. For example, if I were to deploy a UBA and one of its criteria is “Secure Shell (SSH) is suspicious,” I’m going to get several alerts or need to do a ton of whitelisting that may even increase my risk, or a combination of both. Likewise, if you happen to be downloading malware samples that pass through your NIDS … well, as they say, “Hang on tight.”

By contrast, if you’re a retail organization, where SSH on your network would be suspicious since it’s probably something only a few of your administrators are doing, perhaps, for you, a UBA might drop in right out of the box and be an effective tool in your security posture.

Or what if your business is somewhere in between – for example, you are developing tools in a cloud environment, but also have normal business operations like financial planning and accounting (FP&A) or human resources (HR)? In that case, tool selection gets more complicated. Each of your supported groups will likely have different threat models that need to be monitored differently – call it bespoke monitoring to go with our bespoke network. How do you secure those FP&A and HR people while not burning through Security Operations Center (SOC) analysts because of the pile of false positives coming out of your development team? How do you secure that team?

The answer: network segmentation and tool routing.

More Nuanced Network Segmentation

Yes, I hear you, “I’ve got a DMZ and a management zone, I’m segmented already.” I challenge that you can do better and grow your security posture with even more nuanced segmentation.  Segmentation is generally viewed as a method to contain lateral movement, but I claim that we can expand this definition to encompass a strategy to contain lateral movement and provide situationally targeted security monitoring. 

By recognizing the different behavioral scopes previously discussed, you can start segmenting based on security requirements. This isn’t a new concept. In James Rome’s paper “Enclaves and Collaborative Domains,” he notes that segmentation “is required when the confidentiality, integrity or availability of a set of resources differs from those of the general computational environment.” Does that sound familiar? You can solve this problem when you move into a micro-segmented environment – part one of the solution.

Part two is getting the data from each segment to the correct tools.

Figure 1: Micro-segments with tool-specific routing.
Figure 1: Micro-segments with tool-specific routing.

Figure 1 shows how micro-segmentation looks at Gigamon – well, a bit. I’ve purposefully not added much detail so you don’t attack me. But the graphic does show that we’re considering tools based on how to properly monitor each group. For example, with my HR and FP&A teams, a UBA could be very effective at finding unusual behavior such as SSH on the segment or unusual client-client interactions. On the lab network, however, the UBA would likely gurgle blood while a NIDS looking for file hashes could be useful since, even in testing, I don’t expect engineers to be shipping malware around. Additionally, for tools that are of uniform use, like my SIEM, I can route all traffic to it. In my real use case, I don’t do this because I find that targeted metadata is easier to work with and so instead, I generate that off of all my traffic, and route the details that interest me into my SIEM for intel bumping and alerting.

Through a combination of smart segmentation and selective traffic routing to tools, you can gain much better visibility into your network and, at the same time, create high-fidelity data to work with. This approach helps you better pair tools with workloads, which in the long run, can lower your tool expenditure since you may need less boxes to cover the various targeted segments. What’s more, with intelligent tool routing, you can also skip sending traffic you have whitelisted – for example, Netflix – from even hitting the tools, thus lowering the overall tool spend as your network scales up.

 

Jack is principal information security engineer at Gigamon, responsible for managing the company's internal security team – conducting security operations, security architecture and incident response. A hands-on, seasoned operations manager with a focus on quality and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
BEC Scammer Pleads Guilty
Dark Reading Staff 3/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-20031
PUBLISHED: 2019-03-21
A Denial of Service vulnerability related to preemptive item deletion in lmgrd and vendor daemon components of FlexNet Publisher version 11.16.1.0 and earlier allows a remote attacker to send a combination of messages to lmgrd or the vendor daemon, causing the heartbeat between lmgrd and the vendor ...
CVE-2018-20032
PUBLISHED: 2019-03-21
A Denial of Service vulnerability related to message decoding in lmgrd and vendor daemon components of FlexNet Publisher version 11.16.1.0 and earlier allows a remote attacker to send a combination of messages to lmgrd or the vendor daemon, causing the heartbeat between lmgrd and the vendor daemon t...
CVE-2018-20034
PUBLISHED: 2019-03-21
A Denial of Service vulnerability related to adding an item to a list in lmgrd and vendor daemon components of FlexNet Publisher version 11.16.1.0 and earlier allows a remote attacker to send a combination of messages to lmgrd or the vendor daemon, causing the heartbeat between lmgrd and the vendor ...
CVE-2019-3855
PUBLISHED: 2019-03-21
An integer overflow flaw which could lead to an out of bounds write was discovered in libssh2 before 1.8.1 in the way packets are read from the server. A remote attacker who compromises a SSH server may be able to execute code on the client system when a user connects to the server.
CVE-2019-3858
PUBLISHED: 2019-03-21
An out of bounds read flaw was discovered in libssh2 before 1.8.1 when a specially crafted SFTP packet is received from the server. A remote attacker who compromises a SSH server may be able to cause a Denial of Service or read data in the client memory.