Why you need to segment your network for security

Pen tester Mark Wolfgang argues segmenting for security is a key piece of an overall defense-in-depth strategy. Here he explains why and how to accomplish it in your organization (registration required)

My job over the last thirteen years as a penetration tester has given me a unique understanding of security from an attacker's point of view. I have conducted hundreds of penetration tests on organizations ranging from Federal government nuclear weapons labs, to banks, city governments, and practically everything in between. I know what makes an attacker's job easy, and what makes it difficult or practically impossible. I am oftentimes surprised that in 2014, I can gain access to one server or workstation, and use it to traverse the entire network, unhindered at the network layer.

[Security tactic might have helped battle foreign ministry hacks]

I'm shocked that close-circuit television (CCTV) systems, alarm systems, building access control systems, and manufacturing process control systems are just "hanging out" on the corporate network for all to see. I recently conducted an assessment on a very large city. They had a flat and permissive internal network, meaning there were virtually no barriers between their different systems.

I ended up compromising literally everything. I could disable the proximity card reader on any door in the city, including the police narcotics vault, gun vault, holding cell, and many others, all because the workstation that managed the access control system was identifiable and accessible to all internal network users.

What is network segmentation for security?

Simply put, it is classifying and categorizing IT assets, data, and personnel into specific groups, and then restricting access to these groups using ingress and egress filtering. We all understand this at some level. We know that we need to put our Internet-accessible servers into a DMZ, and that those DMZ assets should have little or no access to the internal network. This way, if a DMZ server is compromised, the attacker can't leverage the access and "touch" internal systems. We know that SCADA/EMS/DCS and other process control systems should be isolated from the corporate network. Why is it that we don't do it throughout our entire enterprise?

In my experience, organizations don't segment for security properly because they 1) don't understand their organization's business drivers and 2) they don't understand how an attacker operates.

[Experts question security used in Target breach]

Segmenting for security is a key piece of an overall defense-in-depth strategy. It provides the foundation for a secure network. It limits the movements of an attacker, and therefore limits the overall impact of a security breach. It may even be more important that applying updates and patches to your systems. If the CEO of your organization refuses to give up Administrator rights, refuses to be part of the domain, refuses to apply updates, and won't put a strong password on his laptop, that's just fine. Put him or her in their own VLAN and protect yourself from his toxic security hygiene. The point is, that proper segmentation for security limits the impact of vulnerable systems.

How to segment your network for security

Before you can properly segment your organization's network for security, you need to understand your organization's mission. You need to fully understand the business drivers. Why does your organization exist? Who are the key personnel in your organization? What are the key IT assets? What types of data do you hold? Where are these personnel, assets, and data located? You must know the answers to these questions before you can begin to group and isolate.

If your organization is a for-profit entity, you should have a good idea of where and how revenue enters the business stream. You should know how the business makes its money and from which products and services. For a non-profit or a government entity, you should seek to understand the same things, with the exception of how to make money. More often than not, success of the mission itself is the most important factor in the overall success of your organization. Only when you understand your organization and how it operates can you sufficiently protect it from the variety of threats it faces.

Understanding the threats and how attackers operate is another key step to being able to segment your network for security. Attackers from within your internal network operate a number of ways:

  • They attack your servers directly
  • They attack the network infrastructure
  • They attack the people that control and access the servers

Once they compromise one system/server, they branch out and seek to compromise other assets. They have a goal, and they will not stop until they have achieved that goal.

[SDN: The security pros and cons of using it in your organization]

I've been on many penetration tests where the servers themselves were up to date with Operating System (OS) and application patches and were sufficiently hardened. I could identify no vulnerabilities or ways to compromise the servers directly. In this case, I conducted an indirect attack by targeting the system administrators that controlled and accessed the servers.

First, I identified who they were. Then I identified where their workstations or laptops were located on the network. Then I attacked their workstations directly. Once I compromised their laptops, then I could continue my attack against the server through different methods. For example, I could install a keystroke logger or other malware to capture credentials, or perhaps I could install remote control software and wait till they left their workstation unattended. I'd then take control of their workstation as them, and do things that they could do, like add a domain user account, or click and activate the SSH session to the Unix server they're logged into.

Once you have a solid understanding of your organization and a basic understanding of how attackers operate, you can begin to build your segmentation strategy.

You might begin by laying out some basic logical groups for IT assets:

  • Windows servers
  • Unix servers
  • Network Infrastructure
  • Security devices
  • Development servers
  • Financial servers or workstations
  • HR servers

Then you'll want to group certain personnel by function:

  • Windows system administrators
  • Unix system administrators
  • Network administrators
  • Security administrators
  • Developers
  • Accountants
  • Human Resources
  • Executives
  • General users

Gather an inventory for each of the above IT asset groups and determine if there needs to be further categorization of assets. I.E. Do all Windows servers need to be protected in the same manner, or does the Windows server on the shop floor running Windows 2000 controlling machinery need to be protected differently? Let me answer that question for you: yes, it does! This is all part of the process of figuring out what you have, what it does, and how to protect it.

Similarly, collect an inventory of personnel and their associated IT assets (workstations, laptops, mobile devices) and determine "who holds the keys to the kingdom." Should product development engineer workstations be protected differently than receptionist's workstation?

This takes time and requires a lot of interaction with other parts and personnel in your organization. Once you're finished with this process, you'll have a much better understanding of your organization and how it operates. It'd be a great idea to document this knowledge.

[Ransom, implant attack highlight need for healthcare security]

Once your groups of assets and personnel have been defined, it's time to begin the process of shifting those assets into separate network segments. VLANs make this process much easier than it used to be, and I recommend starting out with a small, less noisy group to begin with. You may find that you can group accountants, HR, and legal personnel into one VLAN called, "admin-users." You have taken the time to learn which servers these personnel interact with, and have grouped the servers into another VLAN named, "admin-servers." Now it is time to setup a default allow access control list (ACL) to permit all traffic. Logging all traffic in and out of the "admin-servers" VLAN segment will give you a very good idea of who accesses the servers via what protocols. Perhaps you'll see mostly Oracle database traffic, Remote Desktop (RDP), and web traffic to this segment. Once you think you have a good feel for what level of access the "admin-users" need, then you can begin the task of restricting their access.

The goal for each VLAN will be a default deny ingress rule. Nothing comes into the segment unless you specifically allow it. Different users will have different needs. For example, the "admin-users" require TCP ports 80 and 443 for web applications, 1521 for Oracle, and 3389 for Remote Desktop. They do NOT require access to any other ports. They have no business touching the NetBIOS ports (135,139,445), nor do they ever need to be able to interact with the FTP port. On the other hand, Windows system administrators have a need to interact with all ports on the segment. General network users, say, the receptionist, has no business at all talking to any ports on servers located in the admin-servers segment.

Once you've implemented access restrictions into the segment, you will further refine your ACLs (rules) as the need arises. You'll learn a variety of things. For example once a month, a certain Vice President logs on to the web interface of the financials application to access a report. Be prepared to respond quickly, and apologize profusely when the VP can't access the server. Hopefully you'll proactively figure out things like this to avoid disruptions, but it is not always possible. For this reason, you may want to monitor traffic for longer than a week before implementing restrictions. You may want to allow and monitor traffic for a month or two, depending on the climate of your organization.

[Virtual Network Segmentation for PCI?]

Make a plan and prioritize the implementation of network segmentation over time. For a large, global organization, a properly segmented network may contain hundreds of VLANs with very granular access controls. They may be broken down into VLANs such as, "email-admins", "www-admins", "dns-admins" and "file-server-admins" to administer the respective groups of computer systems. For a small organization, an adequately segmented network may mean only a few VLANs. Perhaps a "management" VLAN for system and network administrators of all types of computers, an "admin" VLAN for HR, finance, accounting, and a "server" VLAN for all types of servers. A "user" VLAN for general network users that require no access to the management ports on the routers, switches, firewalls, and servers.

The time it takes to implement network segmentation for security will vary. It may take only a month or two at small organizations, and may take a year or more to implement on a large scale. It should be viewed as a long-term project. It may be a project that requires new equipment and additional technical expertise, although most routers can implement ACLs, and all network administrators should be capable of doing this.

Network segmentation for security is a key strategy in building a secure network. Done properly, it limits the impact of a security breach. It prevents an attacker from moving throughout your network. In order to properly segment your organization's network, a good deal of knowledge about your organization is required. A plan must be formulated and an implementation strategy must be developed.

Mark Wolfgang is the President of Shorebreak Security, LLC, a company that specializes in real-world security testing. He is an expert penetration tester, published author, speaker, and information security veteran.

Copyright © 2014 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)