Over the last few years, the OPM breach and other attacks on federal government and commercial information systems have captured the attention of officials and lawmakers. These cyberattacks have created a shift in thinking throughout the public sector, and the expectation now is that all agencies have already been breached; the attackers are already in our networks, even if we don’t yet know it. With that assumption, the next logical question is, “What do they have access to if they’re already in?” The answer to that is easy: unencrypted, sensitive information.
Encryption as a cybersecurity tool is nothing new; in fact, it has long been thought of as a “silver bullet” for protecting data on Capitol Hill. Given its reputation and the landscape of presumed cyber insecurity, it was no surprise when lawmakers came together to prioritize cybersecurity, enacting new laws and mandates, including the data security provision the Senate Intelligence Committee added to the Cyber Security Act of 2015, and the new DFARS 252.204-7012 protecting Controlled Unclassified Information housed in federal contractors. While agencies share concerns over data security and understand the need to comply with new regulations, five myths about encryption continue to worry would-be adopters. Let’s take a closer look at these myths and debunk them one by one.
Myth #1: Encryption will break applications.
This one is historical in nature, originating from a time when encryption involved changing the format of information. For example, in the case of credit cards, a 16-digit number would become more characters and crush the database. That’s not the case today. NIST passed a new standard in 2016 called “Format Preserving Encryption,” a form of the already accepted Advanced Encryption Standard (AES), which enables encryption with the same format, the same 16 digits. The only difference is that those 16 digits are themselves encrypted and you can selectively disclose a certain number for use or analysis while continuing to make use of the encrypted data.
Myth #2: Encryption is enough on its own.
Encryption is a tool, but it’s not the only tool. Just as there are multiple ways for attackers to break into databases, agencies need multiple layers of security to keep data safe. Someone could get into a system using a phishing scam, for example, attaching to an identity within the organization with access to the database. Encryption may not prevent harm in this scenario, unless you are using Format-preserving Encryption (FPE) and sensitive data remains fully encrypted. The agency has to do a good job with its anti-phishing efforts too. Additional layers of security should include identity management, as well as scanning new software for vulnerabilities, since most software today is being developed without security in mind.
Myth #3: Encryption will slow down applications and impose a burden on IT infrastructure.
Historically, encryption would indeed tax CPU and memory and add overhead on transactions. It used to be that one had to decrypt the whole piece of data in order to look at just a part of it – using whatever size key was originally used to encrypt it. The fact that encryption and decryption processes added only microseconds to transaction, that time added considerable overhead. For that reason, organizations sensitive to transaction time – like those processing credit card transactions – rejected encryption unless mandated.
Today, encryption and CPU horsepower, as well as being able to selectively encrypt and decrypt, solves that problem. We are now able to encrypt data once but leave portions unencrypted so that operators, analysts and people who need to use it can do so without having to decrypt it.
Myth #4: Encryption and the cloud don’t mix.
When organizations first began moving to the cloud, agencies were initially reluctant to move everything over, stopping short of touching things that contained PII data or other sensitive information. There was concern about not being able to manage encryption in the cloud or control the keys. Today, identity-based encryption makes it far more secure to transfer all kinds of data to the cloud because no one specifically holds the keys to it. Rather, the keys are derived dynamically when they are needed. Organizations manage their own root key, which then gets used by the organization, and only people who are supposed to have access to the data can unlock physical parts of it in the cloud.
Myth #5: Newer encryption tools won’t work with legacy systems.
Legacy systems are common in government agencies, making this myth especially powerful when it comes to decisions about where to spend budgeted funds for IT maintenance versus new programs. Currently, about 70-75 percent of budgets go toward maintaining legacy systems. Agencies need to look at ways of leveraging maintenance dollars on existing systems and retarget some of those funds to being able to better protect them.
There are ways now, for example, to put a shim in between an application that people are going to use on the front end and a legacy system on the back end. With APIs in the middle, application developers can now ensure that data gets encrypted when it gets put in and selectively decrypted when it gets pulled out.
Encryption and Accountability
Protecting data is clearly a top government priority, as evidenced by recent laws enacted by a concerned congress. The question now will be in execution: how do agency leaders prioritize data protection? CIOs will ultimately be responsible for the next breach and may have to answer the question, “Why was that data not encrypted?”
Encryption is an important part of many layers of security tools that every agency should employ – some would even call it the “last line of defense.” The myths that have grown up around encryption as a tool are simply not true and should not discourage agencies from taking advantage of the newest developments in encryption technology.
Robert Roy is Chief Technology Officer for Micro Focus Government Solutions.
The post Data-Centric Security: Myths and Reality… Guidance for Federal Adoption appeared first on Voltage.
This is a Security Bloggers Network syndicated blog post authored by Rob Roy. Read the original post at: Voltage