Why securing East-West network traffic is so important – and how it can be done One of the fun things about being an Australian living in the Northern hemisphere (which was my situation for over thirty years) is having repeated conversations about which way water rotates when it goes down the drain. OK, it becomes a bit less fun over time, but I was always surprised that few people actually tried the …
I've learned a few things. Now I know what East-West network traffic is, and I understand how important it is to lock that down.
Yes, apparently end-to-end encryption is extremely important, if only to ensure that a destination that a given source is not supposed to connect to is ignored.
It is obvious that East-West traffic is going to be hard to secure. This article demonstrates that it is, nonetheless, necessary.
There is no way that Coriolis acceleration will affect flow out of a paddling pool. Remember that it's 2 x angular velocity x linear velocity. At the poles angular velocity is 2 pi radians / 24 x 60 x 60 second = 0.000072 radians second, and about half that (cos 60) in England or Australia. So for something moving at 1 m/s (bloody fast for a drain) that's a Coriolis acceleration of 0.000036 m/s^2, or 0.00037g.
For Coriolis acceleration due to the earth's rotation to matter you need either (a) very high speeds, as in gunnery or (b) very large distances, as in weather systems. A paddling pool? Not a chance.
The author of the article cites an attack at target basically against tiny embedded computers in a cooling unit and point of sale systems, then goes onto push a virtualization security approach that apparently can solve these problems. But it's not as if these embedded computers are going to be running such hypervisors or virtualization stacks so you're really not solving the problem there.
I suspect the issue at target was also much more complex than just compromising some cooling unit and there all of a sudden you have unrestricted access to the credit card terminals. PCI (I think PCI existed back then) has pretty strict rules about limiting access to "in scope" systems. But can certainly understand getting a foothold then allows you to get access to other things and maybe you can get to a system that is authorized to talk "through the firewall".
But the solution being pitched only covers certain use cases, and is not a complete solution. It's not a bad idea to have such east-west traffic being processed more securely, though I know in many cases the costs simply isn't worth it (I know for the orgs I have worked for that certainly is the case, I have zero interest in costs/complexity of deploying VMware NSX for example). Even in my small networks there are a lot of things that are not VMs, and such are not going to be impacted much by any VM-centric solution.
My own hacky solution which I started using back in 2005 is network zones with basic ACLs on the core switches to limit traffic. Nothing super sophisticated, if anything it simply prevents accidental communication (perhaps misconfiguring a device/application) between zones. Higher level zones have unrestricted access to lower level but not vise versa. There are a few zones which have no restrictions on the switch level(instead such restrictions(if any are needed) are implemented on the devices themselves in those zones. The switches use ASICs for the ACLs, so while they are not stateful, they are line rate. In a few more sensitive cases I do isolate VLANs behind the firewall with more strict rules(taking into account expected bandwidth required to those zones, in those cases it's just a trickle). It's not built to be bulletproof, but has worked well for me. Not talking a lot of ACLs either, for my main network which has at peak around 1000 VMs+other gear just a couple dozen ACLs total(across about 25 VLANs). My original implementation in 2005 was far more locked down and sophisticated. I had spreadsheets with the networks and then a perl script would build the ACLs from the spreadsheets (CSV files). The core switches I had at the time supported up to 128,000 ACLs in hardware so I was able to go nuts. In the years since I decided to make it more simple.
Some folks like to go full on firewall between all subnets, and that can work too of course there are more likely to be bottlenecks there.
Side note, with so much encryption being used in today's apps/services, having a firewall, whether it is east/west or north/south or whatever, really loses effectiveness if it can't decrypt the packets. Lots of things use port 443 for example, lots of things connect to services hosted "in the cloud" (which have obviously huge swaths of shared IP ranges). As far as I know(haven't checked recently) pretty much all of the "SDN" like firewall products are not sophisticated like say a Palo Alto firewall (I don't use their products either, just know them mainly from reputation) in being able to intercept and classify actual traffic , rather than just being basically blind in doing layer 4 stuff. Obviously other firewall products can do the same (better or most likely worse than PAN from what I gather). Then there are other products still like Darktrace who sit on the network and you mirror your traffic to them and they look for unusual activity in real time (I've seen some demos, never have been a customer, another product am not particularly interested in), but they too are blind to encrypted stuff.
Deployed my first network intrusion detection system in 2002 (Snort based Sentarus ran PHP/MySQL too on FreeBSD with bridging interfaces), so have been doing this for a little while. Ironically that IDS was more effective at picking up stuff than many of the current ones because encryption wasn't widely used back then vs now.
Can you show where the original posted states the intrusion at Target was via embedded computers? Also, a hypervisor is not necessary for SDN - while SDN might have been birthed due to widespread hypervisor use, it is by no means solely restricted to that. Even bare-metal networking kit can support SDN technologies.
>> PCI (I think PCI existed back then) has pretty strict rules about limiting access
Yes, PCI existed long before then.
I think PCI is applied unfairly overall. Huge corporations seem to get free passes at doing horrible PCI violations, while small and midsized get raked over the coals.
I believe it was shown that Target & TJ Max (another credit-card breach due to wifi based roaming cash registers) were keeping way more data than allowed by PCI, such as the CVV and other data they should not have been.
The problem was not the cooling units themselves - it was that the 3rd-party doing the remote maintenance on them got breached and while they were only supposed to access the cooling units at Target, they didn't have actual restrictions - likely because those who setup the VPN didn't want to bother with figuring out which 3rd party needed access to which part of the network.
I have a client that is trying to balance system efficiency with the complexity of the system maintenance. While it is true that advanced options like encrypted traffic analysis bring more security it seems that simple level 4 firewall management automation brings a quick and efficient enough solution to secure the network for an average organization with realistic IT budget. I wonder whether there is a practical software (virtual) solution that would grant or deny connection based on decrypted traffic? Anyone know of something?
Wikipedia, < 4 years ago.
Otherwise known as "lan side" and "wan side". Datacenters are not a new thing.
https://en.m.wikipedia.org/wiki/Special:History/East-west_traffic
I guess the terms "vertical" and "horizontal" also needed rebranding.
> ...the number of ingress points to a datacenter is small – maybe as low as one, certainly no more than a handful.
In Telephony (and much Telegraphy), that number is exactly ONE. A copper-cable telephone exchange has ALL cables, both voice and power and supervisory, come into the building in ONE hole/panel, preferably less than 4 feet across.
If, like my old house, phone came in on the east and power came in at south, nearby lightning stokes induce a surge from one portal to the other, VIA my answering machine or modem. I was replacing several every summer. (Yes, the phone line had a protector but it was incredibly old and used-up.) Finally the phone line quit altogether and we got telco to re-route it next to the power entrance with a shared earth. No more trouble. Bell had been taught this lesson a century before. (Didn't matter when it was just Bakelite phones, but answering machines and modems mix phone and power in small parts.)
Off-premises data is now mostly optical but some optic cables have copper so they can be found with metal detectors.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
