NETWORKING

  • 06/16/2014
    7:00 AM
    Reuven Harrison
  • Reuven Harrison
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

Network Segmentation Key To Good Network Hygiene

Recent security breaches underscore the importance of maintaining proper network segmentation.

In light of recent security breaches, where third-party credentials have been used to access entire networks, IT organizations are turning their attention to the risks that can result from basic network segmentation errors. This serves as a good reminder to us all that practicing good network segmentation is as much a hygienic best-practice as brushing your teeth -- no one loves to do it, but regular care is essential to prevent long-term harm.

In many organizations, network segmentation has been a "set it and forget it" effort, which once done is almost immediately out of date. But network segmentation needs to be managed, and policies continuously enforced to maintain the desired network segmentation.  

Security is not the only issue addressed by proper network segmentation. The ability to contain network problems, improve performance, and reduce congestion are all key benefits that come from a well-segmented, well-maintained network.

Make no mistake: Network segmentation is very hard. Complex networks house hundreds of devices, and enterprises typically have complicated policies with hundreds of rules. At Tufin, we see customers with hundreds of firewalls, routers, and switches across their network, each on average having hundreds of rules per device. A typical enterprise therefore has to consider tens of thousands of rules when segmenting its network in order to maintain a security and compliance.

In addition, most organizations are dealing with dozens of changes a week to support new business applications, and users are demanding technologies like virtualization and cloud, each of which is a force-multiplier to this complexity and can impact the integrity of network segments.

It’s helpful to think of your network in zones, so you can visualize and manage your network segmentation, either manually or in an automated fashion. Consider the business drivers as you map out your zones, including compliance (e.g., the PCI Data Security Standard), industry or company-specific risks, third-party contractual requirements, and company-specific business processes. Once you have mapped this out, you can instantly see detailed insights on your network segmentation, such as what services are allowed between different network zones and zone sensitivity.

Enterprises have hundreds of applications serving multiple lines of business, which adds to the order of magnitude and complexity of any change, and must be factored in to any segmenting exercise.

For example, when an organization rolls out a new application that requires interaction with several other resources in the network, a visual map of how this application interacts with other resources can help ensure that only the business required communications are allowed, while other types of communication are blocked.

One company we work with has segmented its network into 40 zones, split based on risk assessments, business, and compliance requirements. Some of the key segmentations include separation of the development network from the Internet, and even the general enterprise network, so as to minimize any leakage of intellectual property.

In addition, organizations need to consider how they can be alerted on policy violations, so that changes made "out of band" can be immediately remediated, and administrators made aware of gaps between desired and actual segmentation. Organizations should consider obtaining the ability to visually validate that the desired segmentation is the same as the actual (or enforced) segmentation.

Recent breaches should have served as a wake-up call to those not closely watching their network segmenting policies, but they’re not the only reason to practice good network segmentation hygiene. Organizations should consider adopting a matrix approach to network segmentation in order to enable a clear baseline and set of rules for all ongoing changes.

Once this is established, they can consider enabling automation of these rules and policies as much as possible, in order to reduce the risk of policy violations going unnoticed for days, weeks, or months.


Comments

Target breach

Our sister site, Dark Reading, provided some discussion of the Target breach, network segmentation, and PCI compliance. Seems a little strange that the PCI DSS doesn't require network segmentation, but then again, there's a lot about PCI that's strange.

Re: Target breach

Hi Marcia,

The reason PCI doesn't require segmentation per se, is that all of its rules apply to the entire "cardholder data environment". Many organizations DO employ segmentation for PCI purposes, because it can decrease the amount of your envionment that PCI applies to. "But", you might say, "shouldn't I have good security like PCI demands on all of my network?" Yes, you should, and some places just make their entire network PCI compliant, but that can be because of difficulties in achieving segmentation. Also, segmenting your PCI network reduces the amount of assets that you have to subject to a PCI assessment (think: audit), which will save you money on the assessment.

pitfalls?

Reuven, can you comment on what types of mistakes organizations tend to make with network segmentation, other than failing to continously update it?

Re: pitfalls?

Marcia,

 

Let me give an example. Although when you segment your network , and even segment your configuration , although overall network might be a more complex from the management complexity point of view due to more configuration and protocols usage.


But on the other hand, you simplify individual tenant configuration. For example you can configure VRF ( Virtual routing and forwarding instance ) for each applicaiton/network/tenant and put them into VRF. Now managin the individual policy is much easier. This is modularity and also we call it vertical layering. Can problem still occur?.Yes it can. For this I want to point out my early NC article.

http://www.networkcomputing.com/tech-talk-week-1-service-provider-networ...?

Re: pitfalls?

The principle is simple.  Keep the network clean and it will have fewer problems.  When problems do occur, they will be easier to spot and simpler to fix because there will be fewer negative interactions between network subsystems.  If you don't keep things clean, interactions between otherwise minor problems can create a larger problem.  http://www.fiberstore.com/

Re: pitfalls?

VRF sounds good option here, but can VRF Lite introduction to subnetwork/ intranetwork add more security.

Re: pitfalls?

aditshar1,

Quick answer is yes. Vrf gives you a segmentation and security.

Let me explain it a bit more in detail. VRF stands for virtual routing and forwarding, and you can think it as router in router. We use it for layer 3 virtualization.

Consider vlans. Vlan actually gives you an abstractian , you virtualize your physical infrastucture. But this is within the layer 2 flooding domain.

So if you will route the packets you use VRF since it is layer3.

Use cases might be within ISP,to separate their customer networks. Within enterprise separate application or tenant so on.

Even small enterprise for example , you can put your all data traffic into one VRF and guest wireless access into a different VRF and they will not by default reach to each other.


But since you segment the VRF within the same device , they use common resources. So for the service provider example, within the same router , if there is noisy neighbor , you will be affected.


But there is also device level virtualization mechanisms such as VDC Virtual device context. You allocate CPU and memory to each context and assign tenants/application so on to context so you will not have this problem.

 

You asked VRF-Lite particularly and I explained VRF briefly , they are the same  but for the VRF-lite you should keep in mind that , it is not scalable. In order to separate and virtualize networks end to end , you need to touch to many routers, switches so on. More scalable way of doing this is MPLS L3 VPN which use VRF as overlaying virtualization tools and create Multi Protocol BGP session between edge PEs over VRF.

 

HTH.

Re: pitfalls?

Thanks for this insight Orhan. I read that VRF-Lite is used more in enterprise networks, while VRF is used in service provider MPLS networks. Is that accurate?

Re: pitfalls?

Marcia,

 

Quick answer is maybe :). Let me explain in this way. If you need segmentation at the layer 3 for very small scale , VRF-Lite might be an option. But Service Providers commonly enable MPLS in their backbone.( Even up to aggregation - access with Seamless MPLS ). And over MPLS they give layer 2 and layer 3 VPN services.

 

If you are using VRF without MPLS , without Multi Protocol BGP , then it is called Vrf-Lite. You don't need them. But even enterprises might have MPLS in their backbone , and even historically it invented for the perfomance , nowadays performance is not a main concern , companies use MPLS mostly for VPN , also some cases for traffic engineering.

Re: pitfalls?

adithsar1,

 

I am glad to hear that my comments, posts are useful. You can always ask your questions here in NC, I try to give my answer as quickly as possible.

 

 

Re: pitfalls?

Thanks Orhan for explaining those nuances. The article I read made it sound more clear-cut, which is rarely the case!

Re: pitfalls?

Thank You @Orhan for such explainatory answer, I have been assigned with new project in my company wherein entire network is running on static route defination, no OSPF no ISIS and now i have to plan in order to move them in dynamic routing, i will come back with some queries and also not to miss everytime i read your response/ comment i save that for my future referance.

Re: pitfalls?

Failure to update is the biggest one we see by far. Another common mistake is "over segmentation". This makes maintenance very hard, and leads to segmentation becoming something which disrupts the business, rather than being a business enabler. 

Re: pitfalls?

Sounds like it's something of a delicate balance getting the right amount of segmentation then.

Re: pitfalls?

Yes it is truth that network security is a full time job. Regular check up is also necessary in order to protect data from any threat.