Security Efforts for Data In Motion Should Be Put to Rest

(29/09/2003)

Everybody knows that it is easier to hit a stationary target than a fast-moving target. Yet, an enormous amount of financial and development resources are being used to encrypt data in motion. Any smart hacker, can tell you that data at rest is that much easier to decode and transmit to a second location, whether the perpetrator has physical access to the data being accessed or is utilising remote network-based access tools.

While nearly everybody has come to the rightful conclusion that the Internet has massively enabled hacking with regards to corporate data, the actual risks are still largely unknown and efforts to secure data seem to be targeted in the wrong places - often with complex and costly encryption schemes that serve little purpose.

For example, only a few months ago, I was watching a popular technology show on cable television that explained how Ethernet traffic broadcasts all communications between two computers to all of the nearby computers on the adjoining network, thus allowing a clever hacker with a sniffer (a piece of software that captures network traffic) to see other users' data.

While this may have been true in the old shared loop days, prior to 1994, in most small, medium and large enterprises today, data is almost always transferred on switched networks, with Ethernet switches retailing for less than $100, and is transferred from point to point - with no visibility of that data by other network-attached devices. This fact alone prevents almost all sniffer-based hacking attempts from outside the corporate data centre, and let's face the truth - if the hacker is actually physically in the data centre itself, you have a very serious and very different problem. The only way to circumvent this point to point data transmission would be for the hacker to load their sniffer program onto the actual target server itself, but even in this scenario, there would be much simpler ways to access the data directly.

Given this fact, and the continued increasing adoption of Ethernet in all levels of business, the enormous amount of resources put into encrypting data in flight, travelling over the network, seems disproportionate. For example, the emerging iSCSI protocol incorporates IPSec security, which can encrypt data as it is transferred between two devices, preventing a hacker with a sniffer from seeing the contents of that data. Never mind that the hacker would first be lucky to get access to the data being routed from point to point, but they also would have to know ahead of time which packets to capture and decrypt from the thousands of packets per second travelling over a particular network segment.

For a long time, this perceived risk of data interception was considered to be of such high concern that IPSec very nearly became a mandatory requirement for iSCSI traffic, this condition being removed just prior to the standard's ratification, when the extreme overhead cost to implement any reasonable data rate was fully realised. Encryption is becoming more and more standard and other new protocols such as NFS v4 are making on-wire encryption the norm.

By discounting the intense efforts to encrypt data in motion, I do not intend to minimise the importance of data security, but to instead lay increased emphasis on areas that are more at risk due to their ease of access and primarily concerning internal data access within the enterprise itself. Rather than trying to decode thousands of network packets from many different sources, it is a much easier course for a hacker to get to the data where it is resting in an easy to read format on an edge device, such as a server, as hacking a standard server is much simpler to do in comparison. Locating the data from a single stationary source and uploading it to a secondary location is much less difficult than trying to decode network traffic packet by packet. With this clear vulnerability and comparatively trouble-free intrusion, the lack of focus on encrypting data while at rest is surprising.

One standard approach employed by a hacker is the insertion of a program called a Trojan, named after the famous Greek horse used in the invasion of Troy. Just as the soldiers inside the horse were able to infiltrate the walls of Troy without detection, a Trojan program is delivered to a user's computer or server inside the corporate security systems by various covert means, often unwittingly activated when a user reads an e-mail containing the Trojan or visits a Web site that uploads the Trojan. In many cases this program, then safely inside the corporate firewall, can transmit data to the hacker in the outside world beyond the firewall's reach, without barrier, as most companies still do not stop outbound data transfer, choosing to direct firewalls and other security measures on inbound traffic, erroneously assuming that hackers will be trying to get in, rather than out.

In using this simplified approach, the hacker is not required to know any passwords, as the Trojan will, at worst, have the same rights to the corporate data as the user who first activated it. This is of course one reason why it is very important not to grant administrative privileges to any standard user account, instead keeping such privileged capabilities to only be available when administrative work needs to be carried out by trusted administrators and then logged off immediately following completion of the required tasks. This will vastly decrease the capability for damages caused by accidental or malicious misuse of administrative privileges and accounts. Once inside the network, a Trojan program can do a number of malicious things such as sending data it finds out by e-mail, monitoring network traffic for key phrases (this is where on the wire encryption can help), and causing malicious damage.

Given the current API’s that exist today in almost all development languages (these are especially rich in rapid application development environments such as Visual Basic and Java), it is quite possible for applications to encrypt the data stored locally in such a way that regular file system access, such as that achieved by a hacker with a Trojan program he had inserted onto the target server, would be unable to make sense of the data. In these examples only the application itself would be able to read the encrypted data. Applications, especially those custom-designed by the end-users themselves, are trickier in general for hackers to penetrate, as less is know about them in comparison to general-purpose operating systems and popular programs or utilities with well-known vulnerabilities.

In fact, the state of California has recently passed legislation to require companies to encrypt certain types of personally identifiable data, such as credit card numbers, Social Security Numbers, etc. However, even encryption on disk is only going to prevent the data from being read if somebody were to steal the hard disk itself, an unlikely event. A clever hacker with a hijacked user account or implanted Trojan can still log onto the server and read the data directly, as the file system will decrypt the data as it is read from disk and transfer it in its decoded state unless the aforementioned encryption tools are explicitly used in the application storing and retrieving the data.

Another key consideration in the defence of the network servers against these kinds of attacks is that of defending servers inside the enterprise from one another. Most enterprises today have firewall servers that provide defences from external attacks. However, once inside the enterprise, these defences are typically weak or even non-existent, as it is assumed that clients and servers inside the firewalled perimeter are truste

Related topics:  Security industry 

Print version | Email to a friend | Related articles

Data breaches: Trends, costs and best practices gives you all the latest information on securing personal and corporate data, key recommendations for immediate action to improve data security, and how to respond to data breaches.

Other Security news and resources