Post-OPM Hack, An Opportunity to Retool Encryption

Chuck Archer, former assistant director of the FBI, is executive chairman at Covata.

The recent Office of Personnel Management hacking incident has triggered much debate  – at times heated – over the precarious state of government data. As a result, the very relevance of encryption methodologies for still-ubiquitous legacy systems has come into question.

And this is a good, not bad, thing. Because the conversation will hopefully inspire federal leaders to rethink the way we’ve done encryption for so many years. The only way encryption can work in the modern age, after all, is to build in new technology architectures, policies and practices to respond to today’s highly fluid, multi-touch point user base – even when the system in question is a legacy.

First, here’s what we know about the hack (so far): On June 4, officials disclosed OPM had fallen victim to a significant, long-running breach believed to be affiliated with the Chinese military. Initially, records related to Social Security numbers and mailing addresses of 4.2 million former and current government workers were reportedly exposed. The data was located in an Interior Department data center which stores payroll, accounting and contracting information.

There was also a second identified breach affecting records of those who are authorized to access classified information after going through required background check procedures.

Officials now say the hacks have likely affected records of 14 million people. The Interior data center hosts a large volume of files for other agencies, so it’s possible we’ll learn additional ones were compromised.

During hearings about the situation, OPM officials revealed Social Security numbers were not encrypted because the agency’s legacy systems date back to the 1980s and are written in the programming language COBOL, which is considered antiquated. OPM Director Katherine Archuleta has testified that “it is not feasible to implement (encryption) on networks that are too old.” (COBOL was designed in 1959.)

The Department of Homeland Security has indicated, however, that encryption wouldn’t have prevented the intrusion anyway because the adversary had user credentials which allowed for data access even if it’s masked.

What does this tell us? That it’s fair to conclude the hacker had assistance (whether from a willing party or through an unintentionally helpful privileged user) from inside OPM. That’s how they obtained user credentials. This would follow the pattern of the high-profile Target and Anthem breaches.

We know that, typically, not all employee information is encrypted equivalently. Files frequently accessed by multiple parties – such as a new employee undergoing a top clearance approval – are less subject to encryption. An abundance of users constantly seek all sorts of details from these records, and administrators allow for ease-of-use here by avoiding any masking which the users would perceive as onerous.

But we believe OPM likely did encrypt the archival COBOL files of retired employees. Such records are routinely updated with respect to changes of address, survivor information, etc. in order to process benefits. But they aren’t called up very often, so there’s generally no user push-back in terms of ease-of-access issues that strong encryption would cause.

Data related to current employees already approved for clearances would be subject to encryption as well, but probably more as a “judgment call” on the part of the IT administrator or department head. (In most cases, this data is accessed more than that of retired employees, but not as frequently as data for clearance-approval candidates.)

The problem is that encryption at many levels of government hasn’t really changed over time for COBOL systems. In private networks, both the data and the encryption “key” to the data are kept in the same figurative “place.” The COBOL administrators responsible for the data – calling the shots on whether it’s encrypted and, if so, overseeing the masking process – are the same ones who keep the keys to undo the encryption. The adversary would only have to form an alliance with one of these privileged users (or find a way to get this user to unwittingly expose his or her credentials) to infiltrate OPM.

What’s needed is a system of what we call symmetric duality – there is separation between the encrypted data and the keys to it. If a group of administrators is in charge of one component, that group cannot access the other. Otherwise, your encryption system is no better than placing the keys to your house under the welcome mat, especially when the robber knows where to find them.

This speaks to technology, of course, but it also calls for new policies. Authentication standards should address current challenges and establish separation of duties and rights. You want to limit, for example, the number of files in a sequence that a privileged user can download.

Beyond policy, we have to take the “boogeyman” out of equation. Employees should not view encryption as something to circumvent because it makes their lives difficult. We must come up with easy-to-use, low-friction software so users embrace encryption instead of trying to “go around it.” And given the increasing complex and global demands of government, data must be shared among multiple jurisdictions in a highly scalable way.

In other words, we need to redefine encryption in a more holistic manner to acknowledge the way the world works today. And yes, we can do so with the proper technologies and policies in place – even for something as old as a COBOL legacy.

(Image via wk1003mike/ Shutterstock.com)