Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Should You Secure Your LAN Like Your WAN?

Everyone knows organizations should never send sensitive data such as credit card or social security numbers across the Internet unencrypted, but many organizations think traffic inside their firewalls doesn't require as much protection as traffic that goes outside the perimeter. That's not the case. Attacks can be perpetrated by an employee or by an attacker who finds a foothold on the network. Being attacked by a stranger is a problem, but company employees can do just as much--or even more--damage than a non-employee. Twenty percent of breaches were performed by internal staff, according to a data breach investigation report from Verizon. The median number of records compromised by internal attackers was more than twice as large as records stolen by external attackers (100, 000 to 37,847).

If data has value, protect that data no matter where it travels. A SSN traveling between two applications internally is still valuable to a criminal and thus still at risk, so encrypt the transported payload or the transit. IPsec connections across site-to-site links can be costly and hinder performance, but those costs may be worth the equipment upgrade when compared to the price tag of a breach.

We aren't advocating for full encryption of all the traffic within your enterprise. Selective encryption can strike the right balance between security and usability. A good place to start is with applications that transfer or process any type of personally identifiable information, cardholder data, or proprietary information such as source code. If the applications can't support encrypted traffic, investigate options such as Stunnel, an open-source program that can encrypt connections between systems that don't support SSL/TLS. This can provide the protection required without burdening the infrastructure. Secure transport also provides other benefits, such as thwarting man-in-the-middle attacks and protecting session data to prevent session hijacks or replay attacks. These benefits should be accounted for in your evaluation.

If you think the risk of compromise is low enough that you don't need to bother with secure transport internally, then you can probably get rid of the access controls you have in place around your databases, too. Right? Wrong. If the data is sensitive enough that you're locking people out when it's at rest, shouldn't it also be protected in transit? Even if that transit is for milliseconds, there is a risk to evaluate.

IT professionals have a responsibility to protect data, our customers, and systems. If my personal information was compromised because an admin did not use SSL, IPsec, or another protection that was available, I would wonder why company didn't value my privacy and security. Wouldn't you?