You wouldn’t leave the house without making sure your doors and windows were locked, and that any valuables were hidden or secured in a safe. That way, if you were robbed, the burglar would have a difficult time accessing your most precious assets. In the same way, you need to make sure your organization’s critical data is well protected.
While layers of defense such as firewalls and IDS/IPS are essential, they are not 100% fail proof - a determined attacker will find a way into your network and access your most sensitive information. At that point, you will want to have encryption in place to protect the data so that it appears random and meaningless to anyone who finds it.
Before you can deploy encryption, you need to first develop a policy to provide guidance around the proper use of encryption in your organization. Here are some things to include when writing this policy:
Get familiar with encryption standards
An excellent place to start when exploring encryption options is to know what standards you need to follow. For example, if you adhere to PCI DSS, the PCI Security Standards Council publishes guidance on how encryption should be handled. In general, Advanced Encryption Standard (AES) is the recommended method for encrypting information. It is used by the U.S. government to protect classified information and is used in software and hardware around the world to encrypt sensitive data. In addition to being favored by PCI DSS, AES is also the standard for regulated industries such as HIPAA/HITECH and GLBA/FFIEC.
Use TLS everywhere
Keep in mind that in addition to storing data securely, you need to be able to transmit it safely as well, and that’s where Transport Layer Security (TLS) comes into play. TLS ensures information can be securely transmitted over a network and is used in many applications such as Web browsers, instant messaging programs, VPN connections, and file transfer portals. TLS has minimal performance impact, so it should be used any time sensitive data is transmitted. Many sites are fully implementing TLS to ensure a secure experience regardless of what kind information is being viewed or sent.TLS offers several versions, and again, the ones you use might be dictated by the regulations you need to follow. Here is a brief description of each:
- 1.0 - this is the first version of TLS. It’s widely used around the world, but is also prone to several vulnerabilities and is generally deemed insecure and unsafe for use.
- 1.1 - this version fixes some of the security problems in 1.0, and is the minimum required by PCI DSS as of summer 2018.
- 1.2 - this is the latest version of TLS, and is the version many vendors such as PayPal, Stripe, and Authorize.net support to eventually refuse TLS 1.0 connections.
In general, non-TLS sites are becoming less and less trusted by browsers. Many browsers will warn you if insecure protocols are being used. Consumers are also more aware of browser security and have begun to question why a site is not using TLS - especially for collecting sensitive information like credit card numbers or PII.
Steer clear of SSL
If you read up on TLS, you might see it used interchangeably with SSL (Secure Sockets Layer). However, SSL is the predecessor to TLS 1.0 and contains several vulnerabilities. SSL, like TLS, comes in several versions:
- 1.0 - this version was never publicly released due to security flaws
- 2.0 - this version was released in early 1995 and also contained several security flaws, which called for the creation of version 3.0.
- 3.0 - the final release of SSL, which was a complete redesign of the protocol, was a collaborative effort between cryptographers and Netscape engineers.
In recent years, the security community has pushed hard to move Web sites away from using any version of SSL. In 2014, a vulnerability called POODLE (Padding Oracle On Downgraded Legacy Encryption) was discovered which allows attackers to decrypt information transmitted between users’ browsers and the SSL version 3 sites they visit. In the same way, the DROWN (Decrypting RSA using Obsolete and Weakened Encryption) attack of 2016 lets attackers snoop on encrypted traffic that uses SSL version 2.
Several free resources are available to help site administrators check for and disable insecure protocols. The popular Qualys SSL Labs tool will generate a report from any public-facing URL and make detailed recommendations on how to make the site more secure. From there, administrators can use free tools like IISCrypto to adjust crypto settings on servers according to best security practices.
Keep in mind that while disabling insecure protocols can be relatively quick and accessible from a technical adjustment point of view, the changes can have a significant impact on your end-users. Before making any crypto adjustments to your site, make sure you know whether or not your customers are using older operating systems or browsers, as some don’t support newer encryption protocols.
Should endpoints be encrypted?
In addition to encrypting sensitive data, you should seriously consider encrypting your organization’s endpoints as well. First, you will need to create an inventory of the endpoints in your network to get a complete picture of the device types, operating systems, and supported encryption methods. Next, explore if and how they can be encrypted. For operating systems, BitLocker will provide full disk encryption for Windows machines, and FileVault will encrypt Macs. Don’t forget about phones/tablets, removable media and other storage devices as well.
In recent years, the lack of endpoint encryption has been disastrous for many companies - specifically those working with PII and PHI. For example, in early 2017 an employee from a company called Lifespan suffered a car break-in and lost control of 20,000 patient records stored on an unencrypted MacBook. A few years prior, the Cancer Care Group had over 50,000 PII records stolen, which ultimately cost the company $750,000 in a HIPAA settlement.
When dealing with a security incident, you want many layers of defense between the attackers and your data. Encrypting your data - both at rest and in transit - is an effective way to protect your company and its customers. The costs of investing in implementing encryption up front will be much less than what you will spend trying to earn your users’ trust back after a breach.