Welcome to my comprehensive series on the Top 5 Security Considerations for a New Web App. This post, focusing on Data Encryption and Protection, is part of a broader effort to equip developers, IT professionals, and web administrators with essential security knowledge for proactively safeguarding their web applications. Throughout this series, we explore the critical security measures that are fundamental to the development and launch of a secure web application. For a complete overview and the context of this series, I invite you to read the Introduction post. This foundational understanding will enhance your grasp of why each consideration plays a vital role in the lifecycle of a web application in the initial buildout and the days immediately following the launch. Join me as we delve into the best practices, strategies, and real-world applications that underscore the importance of implementing robust security measures from the ground up.
Last time, I covered Authentication and Authorization. Now it’s time to look at:
3. Data Encryption and Protection
Applications have depended on secret values for decades. Some of these secrets belong to the application, such as the database credentials, and its TLS private key and CA certificate. Other secrets are supplied by the user, most notably their password. In addition to these secrets, all applications use some type of data. For some applications this data is not really sensitive (e.g. a meme generator). However, many applications have core usages that depend on handling sensitive data. This means that as soon as these applications are in the hands of real users, they are going to be dealing with data that needs to be appropriately protected. This means that the following considerations are necessary before an application can go to production at all.
Data Encryption in Transit: This involves encrypting data as it moves between the server and the client or between back end other servers and services. Implementing Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocols is vital. These protocols ensure that the data, while traversing through the internet, remains encrypted and incomprehensible to interceptors.
Data Encryption at Rest: This refers to encrypting data stored on servers or databases. It's crucial for protecting sensitive data in case of unauthorized access to physical servers or storage systems. Techniques include file-level or disk-level encryption and database encryption. However, it is important to recognize that the application needs access to the unencrypted form of the data.
Other Data Protection at Rest: While encryption is the right choice for many cases, it is important to consider which data needs to be stored in a retrievable way. In cases where the application only needs to be able to compare the stored value to a supplied value to determine if they match, a one-way hashing algorithm is generally the recommended way to store it. You typically want to combine this with a salt value, as it adds extra cost to cracking the values in case of a breach. This is widely understood to be the correct practice for storing passwords, but there are certainly other cases where this is applicable. For example, consider the responses to security questions (E.g. “What street did your best friend live on in grade 8?”). Some organizations use these verbally for telephone support, so they need to store them in a retrievable way, and hashing would not work in that case. However, if they are only being used in the context of an application comparing the supplied response to the stored value, you can apply the same type of hashing and salting that we do for passwords. You should also be vigilant about data that does not need to be stored at all or can be stored for just a short period of time. The best guarantee that data will not be retrievable to successful attackers is to have never stored it on (or already purged it from) your systems.
Key and Certificate Management: Effective encryption relies heavily on secure key management. This involves generating, storing, and handling cryptographic keys in a secure manner. No matter how strong the cipher, having your data encrypted is only valuable if the decryption key is not stolen along with the data. Similarly, where you are using a certificate to sign payloads as a means of guaranteeing they are legitimate and unmodified, that guarantee is entirely dependent on that signing cert being kept secret. This means it is worth carefully considering how and when keys and certificates must be rotated. Furthermore, you should have a plan for the case where they are made public, whether the cause is accidental or malicious. For example, if you have an API client that relies on a cert trust with a certain CA certificate on the server, you want to consider how you safely revoke the old trust and establish a new one when you need to rotate that certificate.
A Case study - Breach of unencrypted patient data - Anthem (2015)
The Anthem Inc. data breach of 2015 is a pivotal case study in the discussion of data encryption and the protection of sensitive information. Anthem Inc., one of the largest health insurance companies in the United States, experienced a cyberattack that led to the exposure of personal information for nearly 80 million individuals. This breach included names, birthdates, social security numbers, addresses, and employment information, including income data.
The attackers gained unauthorized access to Anthem's IT system by using various techniques, including phishing scams to obtain employees' credentials. Once inside the network, they were able to navigate freely and extract sensitive data that was not encrypted. The absence of encryption for data at rest was a critical vulnerability that significantly magnified the impact of the breach. Anthem had encrypted data in transit, but the attackers accessed the data in a state where it was not encrypted, highlighting a crucial gap in Anthem’s data protection strategy.
The breach underscored the importance of encrypting sensitive data not just in transit but also at rest, as a means to render the data unintelligible and useless to unauthorized parties. Encryption at rest is a critical layer of defense that can significantly mitigate the damage in the event that perimeter defenses are breached.
Following the breach, Anthem faced extensive legal and financial repercussions, including a settlement of $115 million in a class-action lawsuit, which at the time was the largest settlement for a data breach. The company also committed to enhancing its data security practices, including encrypting sensitive information stored on its servers and improving its cybersecurity framework to prevent future incidents.
This case study reflects the events as reported by Anthem Inc. and regulatory findings, underscoring the critical role of encryption in protecting sensitive data. The detailed aftermath and response strategies highlight the broader implications for data security in the healthcare industry and beyond.
In Summary
First, use TLS when sending data across a network or the Internet. For quite some time it has been considered unacceptable to serve web apps unencrypted. In addition to that, I have included several key questions below that you would want to answer early in the process, certainly before deploying production infrastructure for a new application. The theme is identifying what data needs to be protected, what protection is appropriate for it, and who should be able to retrieve it.
For secrets, including credentials, keys, and certificates used by the application:
- When do they expire?
- How frequently should they be rotated?
- Who has access to them?
- Is there a risk that my application’s build or deployment process can expose? For example, by accidentally including them in a mobile application?
- Have they ever been stored in my code repository? (If so, I recommend rotating them and taking steps to avoid committing them there in the future)
- Are they retrievable in any means outside expected channels? For example, are they included in application logs?
- Have decryption keys been adequately separated from the data they decrypt?
- Are these keys stored in a way that ensures audit history when they are retrieved or used?
- Do the cipher strengths and key complexities meet any applicable regulatory or compliance requirements? (Kathy discusses this further in our Knowledge Center article on Security Requirements)
For user-supplied or application-specific data:
- What data do I need to store to support the application’s functionality?
- Does any of this data fall under regulatory or compliance requirements? How have I ensured I am meeting these requirements?
- What is my organization’s classification for the data (e.g. Internal vs Confidential vs Restricted)? Are we adhering to our own policies regarding storage, transmission, and destruction based on the classification?
- Which data needs to be encrypted at rest? Or am I using a strategy that encrypts all of it?
- For any data that is sensitive either in terms what it is or how I use it:
- Do I need to store it?
- Do I need to be able to retrieve it, or can I use something like a hash comparison instead?
Additional Materials
- OWASP Password Storage Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)
This provides a set of recommendations for which hashing algorithms to use, and how they should be configured to meet a minimum standard of security. It also includes additional factors that can be used to increase security, such as including the use of a pepper. - Cloudflare’s Learning Center - TLS
(https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/)
Cloudflare has provided an approachable guide on SSL and TLS. This digs into topics such as certificates, certificate authorities (CA), public key cryptography, and how the TLS handshake works. - CIS Encryption Standard (docx)
(https://www.cisecurity.org/-/media/project/cisecurity/cisecurity/data/media/files/uploads/2020/06/Encryption-Standard.docx)
This is a couple years old, but is a concise breakdown that includes recommended minimum cipher strengths for different cryptography purposes.
Next: Logging And Monitoring
