Consider Adding Checks for Privacy Preserving Schemas in ASVS

[ImanSharaf]

While reviewing the ASVS, I've observed a potential gap: there isn’t a specific check or item considering the use of privacy-preserving schemas. In an era where data privacy and protection is paramount, it's crucial for sensitive applications to incorporate methods like differential privacy, Zero-Knowledge Proofs (ZKP), and other privacy-preserving techniques.

To illustrate the significance of such techniques, let's consider the use case of homomorphic encryption, specifically the Paillier cryptosystem. Imagine an application needs to compute the average of a series of data points, but the entity doing the computation should not have access to the actual raw data due to privacy concerns. Using the Paillier cryptosystem, this can be achieved as the system allows for specific computations on ciphertexts which, when decrypted, match the result of the operations as if they were performed on the plaintext.

Without getting too deep into the intricacies, here's a basic overview:

• Data providers encrypt their data points using a public key.
• The application, without ever decrypting the data, computes the average on the encrypted values.
• The result is decrypted by an entity with a private key to obtain the actual average, ensuring data privacy throughout the process.

By incorporating such a check in the ASVS for privacy-preserving techniques, we'd be offering guidelines for developers and security professionals to ensure that sensitive data operations maintain user privacy.

[tghosth]

Are you suggesting that in ASVS we specifically mandate that applications must use privacy preserving encryption, because that seems a little extreme... It's quite a major thing to require them to do, complex to implement (would probably require a vendor/appliance) and might not be relevant or possible in all scenarios...

[ImanSharaf]

Thank you for highlighting the nature of ASVS items as requirements. Reflecting on your feedback, I propose an alternative approach:

Considering that the ASVS predominantly consists of requirements, one approach could be to introduce a specialized category or an appendix dedicated to advanced privacy-preserving techniques. This section would focus on emerging and sophisticated data protection methods suitable for high-risk scenarios or sectors where data privacy is of utmost importance, such as healthcare, finance, or governmental applications. In this specialized section, the recommendations for privacy-preserving techniques like homomorphic encryption, Zero-Knowledge Proofs, or differential privacy could be framed as context-specific requirements. They would apply to applications where the nature of data and operations demands an exceptionally high level of privacy protection, thus making such advanced measures necessary rather than optional.

[tghosth]

So getting this specific and specialized sounds more like a cheat sheet than an ASVS section, do you think this would be a useful addition to the cheat sheets project?

[jmanico]

The US federal government calls this family of technologies “PET - Privacy Enhancing Technology” and there are many ways to handle this requirement from differential privacy design to Laplace noise to homomorphic encryption and more. I would suggest we mention that some form of PET should is in place when laws require, like the new presidential order on AI usage. Or maybe an appendix of these techs. Or maybe even a new ASVS just for privacy design. I’m not 100% certain but PET’s are super critical to the future.

[elarlang]

I don't know the topic content, so I just share abstract ideas or thoughts from ASVS structure point of view.

To the ASVS we can put things when we can require it (just recommending is not enough) - always and for everyone the same way, or if there are different solutions available to achieve the same effect, then it must be taken account.

I'm not fan of the appendix idea. We just trying to get ride of one. ASVS should mostly contain requirements.

Separate section we can do if all those requirements belong by content to the same criteria and there are enough of them to be worth of separate section. In general we have "level 3" for specialized requirements and we can add requirements to suitable section.

[ImanSharaf]

but PET’s are super critical to the future.

I am on the same page and I believe we should have a place for PET in the ASVS.

[jmanico]

but PET’s are super critical to the future.

I am on the same page and I believe we should have a place for PET in the ASVS.

I agree. This is a challenging requirement because there are so many options. Perhaps for ASVS an ASVS 3 requirement that says something to the effect of:

"Apply one or more privacy engineering technique such as:

• Data Minimization and Anonymization
• Secure Multi-party Computation (MPC)
• Cryptography Protection
• Zero-Knowledge Proofs (ZKP)
• Federated Learning and Analysis:
• Trusted Execution Environments (TEE)
• Consent Management
• Privacy-Preserving Data Discovery and Sharing"

[tghosth]

@jmanico do you not think this is a better candidate for a cheat sheet rather than an ASVS item?

[jmanico]

I can agree that privacy engineering should be a separate cheat sheet or even a whole separate version of ASVS for just privacy. However, privacy is becoming super fundamental around the world, and it’s directly related to secure software. I’d be happy with even one requirement that talks about PET’s in some way so we at least minimally address it.

[elarlang]

We have requirements like:

#	Description	L1	L2	L3	CWE
1.5.1	Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and other policy compliance.		✓	✓	1029
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.		✓	✓

Change my mind that all those regulations and directives are not covered by those. Whatever regulation or directive applies to you, you need to make your security analysis and requirements based on that.

[jmanico]

Especially with 1.8.2 I’m very satisfied and we can close this issues out as far as I’m concerned. Thank you Elar.

[elarlang]

Maybe the outcome here could be explaining section to the document, how to combine ASVS with regulations.

[ImanSharaf]

Can we mention PET in 1.8.2?

[tghosth]

What do we think about #1784?

[elarlang]

In general I prefer to have proposals in the issue.

[tghosth]

In general I prefer to have proposals in the issue.

This was a small item and I am trying to drive us forward faster :)

[jmanico]

Im ok to drop this for now.