OWASP Top Ten Series: Sensitive Data Exposure
What is Sensitive Data? There is an argument to be made for saying that all data is sensitive. Certainly, some data which might be sensitive for one person, another person might not worry about posting on a blog or social media. In the context of data security, however, sensitive data is usually classed as information relating to healthcare records, financial information (credit card details, banking details), personal information (address, date of birth, national insurance number, social security number), and user account information for IT systems.
It’s vital that information like this, which is sensitive or could be used to identify individuals, is protected and kept secure at all times. This includes when the data is at rest in databases and on servers, when it is in transit across public and private networks, and when it is being used by an application and displayed to users.
Failure to ensure that sensitive data is protected can be catastrophic for both individuals and any organization that has failed to protect the information. Consequences such as identity theft, financial loss, and privacy violations can affect people whose information is compromised. And organizations can experience reputational damage, financial penalties, contractual disadvantages and a loss of trust in their brand and messaging.
How to protect against Sensitive Data Exposure
Security is a multifaceted endeavor. As outlined in the OWASP Series article on Security Misconfiguration, there are many ways to expose vulnerabilities in web applications. You should definitely read and think about the advice in that post and the other OWASP articles. In specific reference to preventing Sensitive Data Exposure, some advice is given below.
- Have a policy that outlines what sensitive data is so that staff understand the issue. What constitutes sensitive data is often defined by Information Governance rules or HIPPA Privacy rules. If your organization is subject to Information Governance or HIPPA rules, then these should be followed and IT systems should help implement them.
- Make sure that data encryption is in use. Both when the data is at rest and when in transit. If all data is encrypted then a data leak will not expose any information. Just some encrypted files that will be unusable without the means to decrypt them. Several recent high profile data loss incidents would have been trivial if the data exposed had been encrypted. Learn this lesson. Make sure that systems that automatically encrypt data, such as database engines, don’t automatically decrypt it again when accessed. If they do then the data is vulnerable if there is a successful SQL injection attack.
- Base64 encoding isn’t encryption. Use proper encryption and make sure the encryption keys are protected. Consider using FIPS-140 validated encryption modules.
- Encrypt backups as well. Data needs to be backed up. Make sure that backups are just as well protected by encryption. Don’t allow your backups to be a back door to sensitive information.
- Make sure that SSL or TLS encryption is used to protect data in transit over networks. Don’t allow any parts of your web applications to use HTTP rather than HTTPS. No one should be able to tap into data streams coming and going from your web application servers and see plain text data. Consider deploying dedicated network load balancers that can handle the processor intensive SSL encryption and decryption on your network. LoadMaster SSL offloading is a feature of the KEMP LoadMaster range and is designed to enable fast and efficient SSL processing.
- Don’t cache information. Caching information and data in the client browser or on servers provides another location where the data could potentially be compromised.
- Turn off autocomplete. Having client applications and browsers autocomplete strings in fields runs the risk of presenting information to users that they shouldn’t see. It is possible that autocomplete will fill in information that wasn’t what the user was going to enter. This can also lead to the wrong information being displayed after queries (See the OWASP Series: Security Misconfiguration article that recommends authorization checks on every data query to guard against this sort of data leakage). Make sure that autocomplete is turned off in email clients to help prevent emails being sent to the wrong recipients.
- Implement an email content checker that stops sensitive information in emails and email attachments from leaving the organization. Scan for trigger words, Credit card type numbers, bank details, health-related numbers etc. Quarantine suspect emails to ensure data isn’t being leaked via email.
- Don’t show any data on screen if it is not immediately relevant to the task at hand. Make sure that screen lock policies prevent casual viewing when a screen is left unattended. This always needs to be a compromise between locking the screen when there is no activity and not making the security policy too onerous for users. Biometric login devices can play a useful role to allow screens to be unlocked quickly.
- Data you don’t have can’t be exposed. Don’t store information if you don’t need it. Assume you don’t need it as a default position. If you think you do need it, then have another review. If you really need it then make sure it’s encrypted.
- Make sure user rights and roles are set correctly and that the Principle of least privilege is used. Give access to data if required. Don’t try and give general access and then remove access rights from users who shouldn’t it.
- Have a well-defined password policy and then enforce it. Ensure that passwords are stored using an encryption method such as bcrypt that is specifically designed to protect passwords.
- Have a way to remotely wipe any computing device that is lost or stolen. Even if there are no data files on devices, then there could be exposure via any email or messaging accounts set up on them.
- The OWASP site has several Cheat Sheets that detail procedures for protecting against Sensitive Data Exposure. In addition, the KEMP Web Application Firewall Pack (AFP) for LoadMaster includes tools that continuously monitor traffic to application and web servers. It detects and counters known vulnerabilities, including those outlined by OWASP. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities system administrators may not have heard about are countered.