Proposal: Add Field-Level Encryption Standard for Sensitive Data in ASVS

[ImanSharaf]

Sensitive applications often store customer or user data that, in the wrong hands, can have profound implications for user privacy and security. While ASVS does touch upon data protection in storage and transit, the granularity of protection mechanisms at the database field/column level isn't explicitly addressed.

A clear example of where this can be crucial is in environments where a database administrator (DBA) has full access to the database contents. Even if they're trusted personnel, it's a best practice to implement a principle of least privilege and reduce the risk of unintentional data exposure or leaks. Field-level encryption can ensure that sensitive data fields remain encrypted, rendering them unreadable to a DBA or any other unauthorized role, while still allowing them to manage the database.

I propose the addition of a standard (or a set of standards) that highlights the importance and best practices for implementing field-level encryption in applications where sensitive data is stored.

[elarlang]

We have requirements like:

#	Description	L1	L2	L3	CWE
1.8.1	[MODIFIED, MERGED FROM 8.3.4, LEVEL L2 > L1] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data.	✓	✓	✓	213
1.8.2	Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture.		✓	✓

Those requirements are for having security decisions in place.

From implementation side we have:

#	Description	L1	L2	L3	CWE
8.3.7	Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity. (C8)		✓	✓	327

From big picture for me it seems that we have the topic covered.

Do you see that we need new extra requirement for addressing something specific or we should modify some existing requirement to make something more clear?

[csfreak92]

I think adding a field-level encryption requirement for databases would be a good addition as pointed out especially if it mitigates another threat than a malicious DBA. Is there any other use case it is dealing with that we are missing, @ImanSharaf? I was thinking what if the DB was dumped, then would field-level encryption prevent reading it?

[elarlang]

What fields you need to encrypt must be analyzed and documented (1.8.1, 1.8.2) and checked from implementation via 8.3.7. The question stays - what we need extra or what we need to improve?

[ImanSharaf]

@csfreak92 having malicious DBA is a valid case. Also, the DBA machine can be infected by a malware and the attacker then can dump the db. Also, an RCE could lead to this scenario. @elarlang field-level encryption can be an L3 requirement. Any sensitive data for an L3 app could be classified under this item.

[elarlang]

You are recommending to encrypt all fields or only sensitive ones? If only sensitive ones, then my comment (https://github.com/OWASP/ASVS/issues/1754#issuecomment-1762774461) is still valid.

What fields you need to encrypt must be analyzed and documented (1.8.1, 1.8.2) and checked from implementation via 8.3.7. The question stays - what we need extra or what we need to improve?

[ImanSharaf]

I believe we only need encrypt sensitive fields and I consider PII, Health Information, Financial Information, Biometric Data, Legal Information, Credentials related (such as security questions and answers) information, Business Secrets and Intellectual Property as sensitive information.

[elarlang]

So - 3rd time - if those fields, which need to be encrypted, are documented and analysed via 1.8.1 and 1.8.2. Are those encryptions implemented correctly are checked via 8.3.7.

What we need extra or what we need to improve?

[tghosth]

I agree with the concept but I think this needs to be part of how sensitive data is defined and protected. I think we should push this until the big rework on chapter 8.

[jmanico]

I really like the idea of having field-level encryption in the database as a L3 requirement. This is so even when the database is stolen the data is still protected - hinging on the security of some sort of KMS.

Here is a example of how this can be implemented with a KMS in the cloud, using envelope encryption, at one of the worlds largest online payment services.

https://code.cash.app/app-layer-encryption

[tghosth]

So having thought more about it, I don't love this because it would lead to us being very prescriptive and requiring a specific type of protection. Practically speaking there may be questions around which fields this needs to be done for, under which circumstances this should be done, etc, which I don't think we can answer.

As Elar notes above, we have a catch all to encourage this sort of discussion in 1.8.2:

#	Description	L1	L2	L3	CWE
1.8.2	[MODIFIED, SPLIT TO 8.1.9] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.		✓	✓

[jmanico]

So having thought more about it, I don't love this because it would lead to us being very prescriptive and requiring a specific type of protection.

Just my take, database level encryption is not so much a specific type of protection to me, but a very general and high level protection category that can be implemented in a number of ways. I sent you more info over email, Josh.

[tghosth]

I saw the email and I understand the importance of database level encryption. The problem is that we end up with a requirement like: "Use database level encryption for sensitive data" and then we have to explain what we mean by sensitive data and if we have requirements about where the key is stored, etc, etc. The point of 1.8.2 mentioned above is to avoid these questions and make it clear that they need to have had a plan for identifying and protecting sensitive data.

Maybe we could modify 1.8.2 to make mention of this?

[jmanico]

We already mention "sensitive data" all over the place, see below. Why is this any different? Suggesting database level encryption for sensitive data as a L3 requirement seems like a really good idea. It's a fairly standard practice for high-secure apps.

1.6.3 | Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data. |   | ✓ | ✓ | 320 1.6.4 | [GRAMMAR] Verify that the architecture treats client-side secrets (such as symmetric keys, passwords, or API tokens) as insecure and never uses them to protect or access sensitive data. |   | ✓ | ✓ | 320 1.8.1 | [MODIFIED, MERGED FROM 8.3.4, LEVEL L2 > L1] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data. | ✓ | ✓ | ✓ | 213 1.8.2 | [MODIFIED, SPLIT TO 8.1.9] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. 8.1.1 | [MODIFIED, MERGED FROM 8.1.2] Verify that the application prevents sensitive data from being cached in server components such as load balancers and application caches or ensures that the data is securely purged after use. |   | ✓ | ✓ | 524 8.1.8 | [ADDED] Verify that defined sensitive data is not sent to untrusted parties (e.g. user trackers) to prevent unwanted collection of data outside of the application's control. |   | ✓ | ✓ | 200 8.1.9 | [ADDED, SPLIT FROM 1.8.2] Verify that controls around sensitive data are implemented as defined in the documentation for the specific data's protection level. |   | ✓ | ✓ 8.2.1 | [MODIFIED] Verify that the application sets sufficient anti-caching headers (i.e. Cache-Control: no-store) so that sensitive data is not cached in browsers. | ✓ | ✓ | ✓ | 525 8.2.2 | [MODIFIED, MERGED FROM 3.2.3] Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session identifiers. | ✓ | ✓ | ✓ | 922

[tghosth]

• 1.6.3 - The requirement is about key/password rotation. The type of data doesn't matter. We could also just say data without changing the meaning of the requirement.
• 1.6.4 - The requirement is about treating client-side secrets as insecure. Again, the type of data doesn't matter. We could also just say data without changing the meaning of the requirement.
• 1.8.1 - So this is where we talk about the need for protection levels which basically means defining what is sensitive data.
• 1.8.2 - Once they have defined protection levels to categorise sensitive data they can then define controls to protect them based on their specific use cases.
• 8.1.1, 8.1.8, 8.2.1, 8.2.2 - In these requirements we are not defining how they should protect the data but rather we are ruling out specific mechanisms. I agree this is a slightly more of a grey area but it is an important distinction that we are not mandating an additional control but rather ruling out unsafe storage.
• 8.1.9 this is the application of 1.8.2

So none of those requirements define a specific type of protection but 1.8.1, 1.8.2 and 8.1.9 are designed to guide them through their own process of deciding on appropriate controls to implement depending on the type of data.

[jmanico]

Maybe we could modify 1.8.2 to make mention of this?

I think this is a great idea. Perhaps:

1.8.2	[MODIFIED, SPLIT TO 8.1.9] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.		✓	✓

[tghosth]

Opened #2104