search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.6k stars 636 forks source link

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

Open ImanSharaf opened 8 months ago

ImanSharaf commented 8 months ago

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 commented 8 months ago
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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

@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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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.