Data is the Target: Our Roundabout Path to Material Security

The security industry has often times been tasked with a variety of protection goals. In its earliest incarnations, internal and proprietary networks were a focus, and the intention of security was to both harden them and to protect their traffic from view in the event that eavesdroppers could connect themselves to the networks. This resulted in the first encrypted networks, used mainly in defense and government operations. This was long before pervasive internetworking (Arpanet/UUNet/Internet) really existed or were broadly available. In these early days, the industry could have found its language and its voice in protection of data (which encryption clearly provided), but the discussion, and the vocabulary, turned to protecting networks. Encryption was thought to protect the confidentiality of the network, and the data was therefore similarly protected. The language had been chosen, and the language of security followed, to the harm of both our understanding and investment as we attempted to secure ourselves and our customers.


In the 1990's, internetworking swung wide doors, and introduced the reality of incursion by untrusted parties. The rapidity of adoption, and the mixed experience of the population connecting conspired to define a simple solution to the problem, "Put barriers (firewalls) on the networks", and the semantic momentum moved fully behind a much more physical metaphor. The goal was established as keeping people out of networks, or detecting them once they entered. The idea that the data itself should be rendered unreadable was shelved, as organizations invested in technologies that they hoped would ensure a sanitized network environment housing only a highly trusted population. It did not take long for this ideal to be undone.

The network protection model was overcome by the complexity of network connectivity and the insecurity of so network components (applications, connection points, user behaviors like passwords). The detection model did not stand up for long, either, quickly overcome by the sheer volume and heterogeneity of traffic in an era of gigabit networks with anonymous and global subscribers. While still offering value as a blunt instrument protecting against Denial of Service attacks and monitoring network traffic, it was clear that network protection/detection was necessary, but by no means sufficient.


Enter the next phase of network hardening; the use of encryption and strong authentication to create virtual private networks. Ranging from the proprietary to the widely distributed (like WEP and SSL), network authentication and encryption technologies created a means through which data could be secured when traveling over the wire or in the air. Used in infrastructure to create broad, multi-protocol pipes, and in applications to create function-specific hardened channels, the network had become opaque, but the endpoints, the sources and sinks of critical information, remained unchecked. Ironically, when traveling between an organization's office buildings on a public network, these encrypted networks provided more protection than was had when the data actually arrived at its destination on an unencrypted internal network or host disk drive.


Which brings us to the more-or-less present. In spite of the implementation and investment in all of these preceding technologies, and in the presence of a far more skilled and experienced base of technologists, organizations continue to leak data in massive amounts. The losses can be from credit cards, personal histories, or industry proprietary data. This is because security's momentum has still not really found it's ultimate best direction, which is perhaps its most primitive, the protection of the value in this food chain, the data. It isn't that products and processes don't exist to provide protection, and it is not that people aren't familiar with the risks, it is that individuals and organizations oftentimes either underestimate the exposure of a network or application, or overestimate the universal understanding that data elements must be secured.


Great examples of this disconnection are everywhere, whether we look for it in current events (breach descriptions), or current best practices (lacking). One such example is the PCI DSS standard. Developed to help organizations to better understand and to better enforce security around payment card data, it is quite clear on what data must be protected. As a specific pointer, In requirement 3.2.2, the standard says:

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-notpresent transactions.

But later, in the section on technologies (Requirement 6), there is no language about testing to ensure that data is not stored, or is stored safely, and the language which does exist about protection is sadly vague on the appropriateness of the varying technologies:

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected
against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools - or methods, at least annually and after any changes
• Installing a web-application firewall in front of public-facing web applications

This disconnection between recommended security technologies, and the actual requirements for data security are a glaring weakness in PCI specifically, and a general weakness of this type of requirement documentation. There needs to be a clearer assessment of the appropriate validation of protection of data, and a new effort to direct that protection to be as close to the data elements as possible. When one looks at the number of times that credit card numbers are stolen from organizations that view themselves as compliant with this standard, you quickly realize that there is a substantial disconnect between the goal (don't store this) and the accepted or recommended means of verifying (test the application for security) that that goal has been reached.

To protect data is to protect the asset that is of most value to both the owner organization and external attackers. Protecting access to the network and watching for unusual behaviors are good secondary behaviors, but the very first step that an organization must take is to identify all of these data targets, and to ensure that they are adequately secured in their own right, if organizations are to take the first meaningful step to improving their security.