In 2009, Heartland Payment Systems suffered what was until recently the largest data breach in recorded history, at the hands of a skilled and malevolent hacker. After the attack, the company went on the offensive, implementing numerous protocols to safeguard against a future attack. And hey, lightening doesn’t strike twice, right?

The unfortunate thing about this incident is that Heartland, ever since its 2009 breach, dedicated quite a bit of effort into making sure its name wasn’t in the news again associated with a data breach. The lesson here is, while endeavoring to detect and respond to sophisticated attacks from advanced persistent threats, don’t forget the fundamentals of security.

Data breaches happen for a variety of reasons, and not just the exciting zero-day from elusive nation-state actors. Don’t forget the unexciting, mundane reasons data breaches occur. Paperwork thrown into a dumpster instead of being shredded, someone losing a USB drive full of PII, leaving a laptop on a train or having your office broken into and desktops stolen. Your firm is much more likely to experience a data breach from one of these reasons than from a sophisticated nation-state actor.

What can we learn?

Data inventories are important

It’s one of the most routine and unglamorous jobs when running an information security program, but it is very important to have good inventories of sensitive data, in all forms. Most companies have a good idea of what data is on systems that are publicly accessible via the Internet, but as data shifts away from being centrally administered and over to users, control is commonly lost. For example, a company would typically have a good idea of the number of records on a customer database containing PII but would not know which users have the same data on their desktop PCs and the number of records.

Start with a data classification policy that defines different levels of data, such as customer data, confidential company data, and public data. The policy also should include handling instructions for each data classification type. Communicate this policy to users. Loop in upper management to create a tone-from-the-top and the company’s audit function to ensure compliance. Various technical controls can be implemented to keep track of where sensitive data is, but a level of responsibility rests with users and department managers to ensure full compliance.

If you’re not going to encrypt everything, be smart about it

The easy answer to securing data is to encrypt it everywhere, both at-rest and in-motion. It’s not a panacea and there are ways for attackers to obtain sensitive data even if it’s encrypted, but this adds a layer of security. However, barriers may exist to encryption, ranging from cost to a perception that some systems do not need encryption, due to other compensating controls.

This may be the case and there are valid business reasons for why a firm may not want to encrypt all data, but it needs to be a fully informed, risk-based decision made by management. Assessing this need is ultimately a task for a mature risk management function at a company: the value of an asset, the threat community, vulnerabilities and company impact if something bad were to happen needs to be thoroughly researched, assessed and articulated to management.

Regularly assess controls around desktop systems

This, again, is a function of a mature risk management department and one that may have prevented the latest Heartland breach, if executed properly and consistently. Once a company has a good idea of where its sensitive data is, has made a decision on whether or not to encrypt it and in what form, take stock of the other controls that protect the system. Remember, encryption can be defeated or circumvented, users make mistakes and there are some very smart criminals out there. Layered defense is your best bet.

There are generally three accepted types of controls: Administrative, Logical and Physical. Assess all three on a regular basis.

Administrative controls, when applied to sensitive data on desktops, include policies, procedures, user awareness training and any applicable law or regulation. The data classification policy previously mentioned is an example. Policies around protecting data, incident response, how/when to encrypt and other topics are included in this category. Training users around good practices and handling of data is also considered an administrative control.

Logical controls, also known as technical controls, include encryption software, anti-virus, intrusion detection, access control and many, many more. In the case of Heartland Payment Systems, one would want to assess whether or not full-disk encryption is warranted on the desktops at their Santa Ana, Calif., location. Other considerations are what software to use (e.g. BitLocker), the encryption algorithm, key length and how to secure the key. Heartland wasn’t employing full-disk encryption because, if the company was, a data breach would not have occurred under California law.

Last, we have physical controls. Second only to at-rest encryption, physical controls may have prevented Heartland’s headache. Physical controls are what stand between your systems and a burglar breaking into your office and taking computers. These include video cameras, security guards, locks on doors, barricades, etc. Information security departments often overlook this category because other departments responsible for physical security usually handle this, but it should be built into risk models nevertheless. This also underscores the importance of collaboration across functions. A data breach is a data breach, regardless if it’s from a SQL injection attack or if someone walked off with a server.

The Heartland incident proves that a company is at as much risk from common criminals as they are from sophisticated attackers, and perhaps more so. Remember the fundamentals and remember to apply them to every corner of your company. And let’s hope that for Heartland Payment Systems, bad things don’t come in threes.

Originally published at www.csoonline.com on June 15, 2015.