Move Over, Network Security
As business moves to the Web, security must move to protocols and data, and away from the network. by Paul Simmonds
Network security is dead; long live network QoS.
Let's look at why. Imagine a C-level executive came to you and wanted to know whether he or she could transmit a highly confidential raw text file using TFTP. Every security officer I know, however junior, would explain to them why this is a bad idea.
There are two solutions to the schoolboy problem: harden your border so it's leakproof, and upgrade your infrastructure with NAC, NAP, network sensors, IDS and IPS; or use SFTP or put it in a PGP wrapper.
While I know of a few three-letter agencies that may choose the first solution, in the real world there is no ROI case for it. And the reality is that when you are encrypting the data, or using secure protocols, all those expensive network monitoring solutions on your network have just been bypassed as they can no longer inspect traffic. This simple illustration demonstrates why traditional network security measures are no longer viable in today's extended enterprise.
When you have to manage a large multinational corporate network, you are unable to physically constrain the boxes and wires. Nor is there a practical way to control thousands of devices that need to connect daily--most being automatically allocated an IP address (using DHCP). Then add the fact that you are letting through port 80, for both the Web and applications, and your border has a slew of gaping holes for applications, connections to third parties, joint ventures, business partners and others.
So what can we do at the network layer? Well, the network is good at being resilient, and there are many additions to ensure traffic is protected against flood DoS attacks, not to mention traffic shaping. But all this is just ensuring that the network has the appropriate level of quality of service. Ultimately it is doing nothing to protect the data.
As our intranets continue the slide toward looking more and more like the Internet--we continue to move ever increasing numbers of devices to Internet/ public IP addresses--the security must move to the protocols and data.
Thus, the fundamental question you should ask is: "If I can design my device to work securely on the Internet (day-in, day-out), why would I want to operate with a reduced security posture on the intranet?" To which the answer is: "I wouldn't, but the insecure design of many current applications forces me to."
So we gradually move to applications that use secure protocols and design out any reliance on the network other than for transport of the raw packets.
The goal, therefore, is to be able to design your systems to run securely on the raw Internet, and then run most of them on an intranet that provides guarantees around throughput and latency.
Obviously, anyone with "network security" in their title will probably not relish the thought of being called a "network QoS something," to which my retort would be "get over it." Networks are about ensuring that data is smoothly delivered from one point to the other, so a network QoS specialist should be a very honorable profession. But don't confuse it with security.
Paul Simmonds is a board member of the Jericho Forum, and CISO of U.K. chemical company ICI. Send comments on this column to firstname.lastname@example.org.