Data Management

Data encryption is not a security panacea


Data encryption is getting a lot of press these days.  It seems like a host of businesses are running to encryption vendors to see how fast they can scramble their sensitive information in the face of well-publicized data breaches.  Much of this excitement (or hysteria) is fueled by journalists and bloggers who frequently portray data encryption as some kind of security panacea.  Security and IT managers need to step back and take a more objective look at how encryption fits into an overall set of data security solutions that provide practical, immediate and efficient protection. TJX appears to have skipped that step.

According to a recent article at Physorg.com, there are two primary reasons why data encryption didn’t work for the giant retailer--even though data at rest was encrypted (“Why Encryption Didn’t Save TJX”).  First, credit card approval information was exchanged unencrypted with card approval processors.  Second, the attacker had obtained the tools and information necessary to retrieve data that was encrypted.  In other words, it appears that interfaces over which sensitive data flowed were not protected and encryption key management was lax.

Encrypting all data at rest or in transit might sound like a good idea, but it will require a major infrastructure overhaul for many organizations.  Implementation of encryption can mandate taking costly steps to keep performance at reasonable levels.  Further, there is the issue of key management.  Key management is a huge risk if an organization hasn’t sufficiently focused on security fundamentals, including,

  • Segment the network to provide restricted access to sensitive systems
  • Encrypt ALL data passing out of restricted data segments
  • Ensure database server security best practices are implemented: replace default passwords with strong passwords, continuously monitor direct database access activities, and use a single account to provide application access to the database; never configure a database to allow all application users (except database administrators) to have direct read or write access outside of the application
  • Enforce least-privilege when designing user and system access controls
  • Continuously monitor the movement of sensitive data within the confines of the internal network, including passing to and from mobile storage devices

This list is just a start.  There are many more steps that can be taken to protect data before an organization aggressively pursues an enterprise encryption solution. I’m not saying that encryption isn’t useful.  I am saying that it’s just one control out of a host of others that must be working effectively to truly secure information assets.

 

 

About

Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be publish...

5 comments
Tig2
Tig2

It is speculated that an employee of TJX is the likely hacker. Which leads us to consider another control. You need your employees to have access to your sensitive data. I'm good with that. But validating the risk potential of the prospective employee is the first step. While I am not sure that one's credit report is the best possible way to validate an employee, it can be a useful tool along with robust background checking and drug testing. As it is impossible to measure character, there have to be other ways to insure that you aren't giving the keys to your precious data to a prospective thief.

dspeacock
dspeacock

I'm in the process of writing a bunch of final risk assessments of companies. One of the recommendations for ALL of them is to run, personal history / employment / education and reference checks, NATIONAL criminal background checks, full drug screening and so forth for anyone who has even the potential to come into contact with PHI or PII. If they don't like it, their risk rating goes up.

grephead
grephead

According to some posts from former staff in newsgroups and articles elsewhere TJX has a big AS400 based backend. I encourage you to gather your own conclusions on how effective typical AS400 staff are at encryption and security. Incredibly the hackers were on the systems OVER A YEAR and no one noticed. Jaw dropping.

georgeou
georgeou

1. Saying encryption isn?t a panacea is a straw man's argument. No one ever claimed encryption was a panacea since nothing is ever a panacea. Encryption is a very small (yet critical) component in security; it isn't a cure all by itself. 2. TJX ran a Wireless LAN with the kind of weak security measures you seem to think were ok. They ran insufficient authentication and encryption on their wireless LAN. It seems to me you need to reassess your position on wireless LANs. http://blogs.techrepublic.com.com/security/?p=174 To which I responded. http://blogs.techrepublic.com.com/Ou/?p=454 3. TJX failed in basic access control by allowing hackers to access their network via wireless. 4. TJX failed in basic host hardening by allowing hackers to own their POS and transaction stations. Don't blame encryption. If anything they didn't implement enough encryption and authentication on their Wireless LAN in addition to all the aspects of security they botched.

Flash00
Flash00

Encryption, passwords, you name it, what we mean by security is really access control. Keeping that clearer concept firmly in mind when setting up policies helps to avoid most security failures.