Internal networks are notoriously insecure so why wouldn’t you encrypt PCI data end to end? What makes an Internal Network somehow so inherently secure that encryption is not needed? I would contend that even the idea of an Internal Network is inconsistent with today’s network architectures. Companies have moved to ubiquitous access, perimeter-less networks, rendering the concept of an Internal Network inappropriate. Much debate has been had over internal Network encryption, especially as it pertains to the PCI standard. The PCI standard doesn’t mandate that you encrypt internal network traffic, only that you encrypt cardholder data at rest and over public networks. That seems a bit odd doesn’t it? From this you can extrapolate that internal networks are considered more secure than internal servers or storage. I take issue with that hypothesis, as should you.
Internal network security in the vast majority of companies, both large and small, is virtually nonexistent. We take great pains to harden our perimeters but almost nothing is done to harden internal networks. Given that today is the age of perimeter-less networks, how can we be confident that we have secured each and every perimeter to begin with. How do you know if someone puts a rouge DSL line into some branch office across the world. How about rogue wireless AP’s connecting to your network.
Every legitimate business takes great pains to make sure they are updating their operating systems and programs with the latest security patches. Since they present the most likely attack vector for intruders updating is done in a controlled, judicious and diligent manner. Can you say the same about the updating of your network infrastructure (switches, routers, firewalls, wireless, etc.)? Sure these devices don’t present as sexy of a target as operating systems but a savvy attacker can exploit network weaknesses to their advantage and profit. Network infrastructure security updates should be treated with the same due diligence that you apply to OS and application updates.
Perhaps even more uncontrolled is the wired LAN. Think about your internal wired LAN security. Do you have any security controls in place? Could I walk into your office and easily find a network jack to steal for a few minutes? Is there anything preventing me from connecting (like NAC or 802.1x)? How about if I hack one of your desktops, is their anything stopping me from capturing and recording your PCI sensitive network traffic? Wired LAN man-in-the-middle attack techniques have been known for years and years yet almost nobody protects themselves from them. Think about your access switch security, are you preventing ARP spoofing, IP source spoofing, rogue DHCP servers, or CAM table floods? If you said no to just one of those then you are wide open for anyone to capture your data via a Man-in-the-middle attack. Keep in mind I just listed the commonly known methods for LAN attacks; there are several other methods.
So, the point I’m building up to here is that chances are high that your internal networks are not very secure and so should be encrypted just like any public network. Ideally this encryption would be end-to-end, as in from card swipe machine all the way to final processing. Several card swipe vendors are beginning to offer SSL encryption in their terminals. Hopefully encrypting at the terminal will become the de-facto standard in the not too distant future.
Until you can replace all of your terminals with new ones implement encryption using existing or new gear wherever you can. In addition, you should implement the layer 2 security features you more than likely already have on your access switches. If you would like some best practice guidance for Cisco switch security check out http://www.cisco.com/go/safe .
Bottom line is everyone with confidential data to protect should enable encryption on all internal networks with access to that data. In addition, layer 2 security features should be enabled on the access switches carrying said data. Be sure to unencrypt your data streams before sending them to IPS, DLP, and other deep packet inspection devices. This is easy to say but in many cases harder to implement in practice. If you run into any issues feel free to post them here.
I realize this is a controversial topic for security geeks (like myself) but given recent PCI breaches that took advantage of the above weaknesses, I have to error on the side of security. Sure more security doesn’t always mean better security, but smarter security always equals better security, which I believe is the case here.
Before quoting Bruce Schneier’s position at me, I’m already familiar with it. But if you do have other ideas about why encrypting Internally is either a good idea or bad idea please post it.
The opinions and information presented here are my PERSONAL views and not those of my employer. I am in no way an official spokesperson for my employer.
More from Jamey Heary:
* Credit Card Skimming: How thieves can steal your card info without you knowing it
* Cisco enters the crowded AV and DLP client market
*Cisco's new ASA code allows you to securely take your Cisco IP Phone with you anywhere
* Cisco targets Symantec, McAfee with its new antivirus client
* Google's Chrome raises security concerns and tastes like chicken feet a>Go to Jamey’s Blog for more articles on security.
Jamey Heary, CCIE No. 7680, is the author of the Cisco NAC Appliance: Enforcing Host Security with Clean Access book by Cisco Press. Jamey is a seasoned security technologist with over 15 years in the IT field with 10 years focused on IT security. His areas of expertise include network and host security design and implementation, security regulatory compliance, and routing and switching. His other certifications include CISSP, CCSP, and Microsoft MCSE. He is also a Certified HIPAA Security Professional. Jamey is currently a Security Consulting Systems Engineer with Cisco, though the opinions expressed here are his own. Jamey is a member of Network World's Cisco Subnet blog community.
The Leader in Network Knowledge
E2E Encryption Prescription Is Bad Medicine
"Encrypted traffic cannot be analyzed by a firewall unless either decrypted permissively or decrypted forcibly. The same traffic cannot be cleansed of viruses, or worm signatures, or attack characteristics (IIS URL length overflow) until the traffic is decrypted on the host. Clearly, traffic should never hit a multi-purpose operating system until after all of this happens. End-to-end encryption is what we want, but not at the price we'd have to pay. Protection of data during creation, transmission, processing and storage or End-to-End-Defense-in-Depth is what we really want, as it ensures the defense in depth best practices are not lost."
http://information-security-resources.com/2009/03/24/e2e-encryption-prescription-is-bad-medicine/
already covered that
I mentioned this already in the article.
"Be sure to unencrypt your data streams before sending them to IPS, DLP, and other deep packet inspection devices. This is easy to say but in many cases harder to implement in practice. If you run into any issues feel free to post them here."
And example would be Cisco's new trustsec can be used for link by link encryption.
-Jamey
who NIPS wil work ?
i hate to see crypto traffic in my campus network.if all traffic being encrypted with ssl/ipsec , how the poor NIPS will detect malicious traffic.how much money should i pay for HIPS to be installed on my desktops OS ? do you know the license fee of Cisco CSA for 1000 desktop? i prefer to using my Cisco Catalyst layer 2 security features that i am sure can stop a wide range of L2 attack , specially to mitigate sniffing , man-in-middle-attach , CAM overflow , VLAN hopping , ... . as you recommend before , it is highly recommend that INFOSEC professional read the newly published Cisco SAFE while it will really works in all type for networks.you will love it.
Layer 2 controls, don't forget nac
Your spot on Ali, using layer 2 security controls effective can mitigate many of the attacks I've outlined in the blog. You would also have to add either NAC or dot1x to really get'er done though.
-Jamey
End to End Encryption
While this sounds great in principle, it is not necessarily great in practice.
If you are truly transmitting PCI data, why on earth would you have this on the same physical/logical medium as internal client data? Encrypting data renders analysis difficult (if not impossible) after a breach has occurred. Take time in designing your layer two infrastructure properly instead of taking the perceived easy way out by encrypting everything.
agreed
Absolutely you will need separation of security domains with PCI. However, what makes the PCI domain inherently secure just because you have carved it out in a bunch of VLANs and ports. Can I still walk up to a POS and plug my laptop in? Can I still get on the POS network via free physical switch ports in an unprotected closet or under a counter somewhere? Encrypting PCI data end-to-end is necessary to protect against this until we have companies deploying NAC or dot1x type solutions everywhere. Unfortunately that is not happening quickly.
-Jamey
Encryption End-End
I think we are probably close to being on the same page. I just don't want inexperienced Network Security folks to read this and then run out and encrypt everything without understanding the consequences in doing so.
Security 101 teaches us that designing is like the graph with one extreme end of that graph being completely secure and the other end being completely usable. You need to find the happy medium for your organization because you can't have both.
Now, if you are transmitting sensitive data such as credit card information, then there better be concessions in place but it doesn't end with the network. Ensure any node in the path (servers, etc) has the proper protection...your design is only as secure as the weakest link.
I'll also re-iterate that you should not use the same physical medium to transmit this data that is being used to transport client traffic. Doing so is a recipe for disaster...
clarification
I'm not advocating encrypting everything on your network, only PCI or confidential data. For example, There is no need to encrypt email and web traffic if they are not part of the PCI data streams. It should be a very rare occurrence that card swipe terminal would be spreading a virus or worm. Encrypt from the card swipe to the card processor, and if you want to inspect it somewhere along the way, decrypt it, inspect it, and encrypt it again. this is typically done at a server but can also be done in the network if you have the right gear.
-Jamey
There should not be ANY PCI
There should not be ANY PCI information or access on you LAN. Have you never heard of segmentation and separation of duties.
If you are worried about sniffing and MITM, then maybe you should be more worried about the physical security of your location. If I can just walk in and find a jack, I could just TAKE the damn computer or backup tape or anything else.
what?
Surely you know that PCI data flows on a LAN and WAN right? You also know that segmentation is a mandatory practice for PCI, so I consider it table stakes. But segmentation doesn't help with the above issues I detail. One more example, I walk up to a POS machine, unplug it, plug in my laptop and get free an unrestricted access unless you have the above controls I mention. So many other attack vectors exist I could write a paper on them. Hmmm...maybe I should.
One thing you need to understand is that segmentation by itself does not equal good security, that is the same mistake folks make with internal and external networks. Just because they are separate doesn't make them magically secure.
-Jamey
Post new comment