Social Network For Security Executives: Help Make Right Cyber Security Decisions
What Is It? Think of network segmentation as dividing up your network and resources either physically or logically to mitigate an attacker’s capability to freely propagate from systems to system and from network to network. By putting controls in place, you can effectively compartmentalise the differing areas to limit the extent of damage, intentional or accidental. To some degree, you likely already use network segmentation without fully realising it.
At the most basic level, a firewall provides network segmentation between your private LAN and the public WAN. Even in your home office, that handy-dandy whizbang Wi-Fi Modem-Router provides network segmentation. Do you have a DMZ for your public facing services? That’s more network segmentation, especially where those servers likely act as the front-end for some critical databases. VLANs, used to separate management, workstation, server, IP Telephony, wireless, and guest networks from each other are network segmentation. Anywhere there is a physical or logical “break” in the traffic flow can be considered segmentation.
Take this a step further and your delegation of authority, limitation of administrator accounts, Active Directory groups and Organisational Units, and even file shares and their permissions are essentially network segmentation. The biggest problem in all of this is that while we may be doing all of this, few of us do it well and those lines get very blurry for one reason or another. Fundamentally we’re trying to limit traffic to a least-privilege, need-to-know basis for users and computers. No one resource should “talk” to any other resource unless absolutely required.
Where Do I Start? Figuring out your current state of network segmentation can be simple or difficult, but it needs to be done. How current is your network and systems documentation? (Oh yeah, that….) How current are your network diagrams and architecture / design documents (Uh, yeah, those…?) When was the last time you undertook a full end-to-end network and systems assessment? (Well, we’ve been meaning to…) Relax. We can help. You can do this!
There are a variety of tools available that can help you map out your networks at a physical and logical level, and even tools to help you sort out your virtual environments, Active Directory architecture, application flows, file shares and permissions, and even user rights and privileges. If your documentation (if you even have any because, believe me, the number that don’t shock even me) is out of date, it’s time to start digging up the details and mapping everything out. Need help? Ask! You are extremely good at whatever your chosen career path is, so please allow those of us that specialise in this area to step in and assist. Ask the right questions, get the right people with the right tools involved, and you’ll be fine.
From experience, I would also recommend a full change freeze before beginning this exercise. Even the most skilled marksman struggles to hit a moving target. Unless it’s an emergency, consider a DFWI policy (feel free to message me directly to find out what that is). If you have good change control in place, the point may be moot.
Gather as much detail as you can about what makes your environment tick, and everything should be on the table. Once you have a clear vision of how things are segmented or not, we can begin to implement network segmentation to help you achieve your security objectives.
How do I make It Work? Like building a home, start with a solid foundation, and start at the perimeter, working your way in from the least secure to the most secure layers of your defence in depth. Begin with the physical and logical network elements. Always ask A) does x talk to y? B) Why does x talk to y? C) Does X absolutely must talk to y? D) How can we secure the X to Y connection?
This can involve VLANs, switches, routers, firewalls, servers, workstations, and so on. Look at your routing tables. Look at your ACLs. Look at your firewall rules. Who talks to what, and why? Unless explicitly defined, the default answer should be “No”. Granted, this can mean a lot of headaches for administrators and believe me, the last thing I am advocating is manual, static routes and static IP addressing. Where possible, use groups and shared objects, but please try to avoid something akin to “any”. Separate trusted traffic from untrusted traffic. For example, if you have corporate Wi-Fi and Public Wi-Fi that runs on the same equipment, these should be separated from unique SSIDs through to VLANs and explicit routes and firewall rules.
One of the things that scares me the most are large, flat networks. I have seen large environments using a 10.0.0.0/16 network and yes, even networks that use 10.0.0.8 which can’t be easy to manage. If you don’t need a full subnet range, for example a /24, then don’t use it. That said, always allow room for growth.
Odds are your network isn’t like that, and you already use VLANs, routers, firewalls, active directory groups and OUs, and are mindful of file shares and permissions. Therefore, I advocate an evaluation first; a full redesign is rare. Just a little housekeeping is in order, especially if there have been a lot of changes, notably among administrators.
Whatever changes you make should be justified with logic, match your policy, and accounted for through change management. And by the way, keep your documentation up to date – you’ll probably go through this all over again in the future, even if just for a tidy-up.
Pitfalls? The network segmentation as it relates to the physical and logical parts of the network such as routers, switches, VLANs, and firewalls is straightforward. Sorting out the groups, permissions, and applications can take a bit more doing, so before you make the changes, make sure you’re not breaking anything you shouldn’t be. It may seem like overkill, but a lack of logging and alerting coupled with ignoring those very same logs and alerts may lead you to overlook communications that happen, but shouldn’t. Many times, we think of logging the “denied” connections, but how many of us look for the “allowed” connections with specific conditions. I don’t worry so much about the connections that fail as the connections that succeed.
Ghosts in the Machine? People can be quite inventive at finding work-arounds. Like a good lawyer that discovers and leverages loopholes, your users can quickly subvert your best security plan unless it provides the necessary functionality. We all show up every day to do our jobs, right? The last thing any of us want is for that job to become more difficult. Watch out for shadow IT. Also, be wary of who has access to the comms rooms or else you may find cables connected between devices that shouldn’t be. Spanning tree won’t save you from a data breach.
Anything Missing? Proper planning and testing of your segmentation is a must before you make any changes. Also, when it comes to matters of permissions and access to systems, data, and applications, be sure to have an underpinning policy with management support and endorsement that can be enforced. We’re not thinking of network segmentation for the sake of it, but rather with the overall security posture of the organisation in mind.
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such. Appropriate legal advice should be obtained in actual situations. All images, unless otherwise credited, are licensed through ShutterStock