7.1 Proposal for Masked Data Logging Need

[mesutgungor]

In some application, mostly DLP , Data discovery, Data Classsification type applications, need to create logs for auditing and/or troubleshooting containing some part of the sensitive data in cleartext and remaining part in masked format. I would propose the following addition to 7.1.1

V7.1 General Logging

Current :	#	Description	L1	L2	L3	CWE
7.1.1	[MODIFIED, MERGED FROM 7.1.2] Verify that the application does not log credentials, payment details or any data defined as sensitive based on local privacy laws or relevant security policy. Session tokens should only be stored in logs in an irreversible, hashed form.	✓	✓	✓	532

Proposal :	#	Description	L1	L2	L3	CWE
7.1.1	[MODIFIED, MERGED FROM 7.1.2] Verify that the application does not log credentials, payment details or any data defined as sensitive based on local privacy laws or relevant security policy. Session tokens should only be stored in logs in an irreversible, hashed form. If logging sensitive data is unavoidable, ensure that only essential parts of the data are logged in clear text, with the remaining portions masked to protect sensitive information. To access this partial cleartext data additional measures should be implemented(ie. additional password, approval flow)	✓	✓	✓	532

[elarlang]

Hi, as I reorganized the V7 chapter and logic between V1 (documentation) pre-condition requirements, I'll explain the logic behind the current situation.

First - thank you for the clear issues - although I do not support the proposed changes (I will explain why), I can clearly understand, what and why was proposed.

7.1.1 text can be improved, but I would not go to too descriptive or educative long texts. The goal is to keep requirements as short as possible and all educative parts should be the goal for the Cheat Sheet project.

I watch proposals more as handling sensitive data. For each application and organization, the sensitive data or the way to handle it can be quite different, although there are many regulations in place to dictate how to handle them. The point is, here we can set abstract requirements and principles - document your needs and follow them.

For documenting the sensitive data we have requirements:

#	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	[MODIFIED] Verify that all protection levels have an associated set of protection requirements and that these are applied in the architecture. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.		✓	✓

Maybe add note about logging into the V1.8.2?

[jmanico]

How about a new logging requirement similar to:

Verify that logging mechanisms are in place for all protection levels to document the application of protection requirements. This includes logging events for encryption, integrity verification, data retention, privacy, and other confidentiality measures, capturing specific protection requirements and any deviations for auditing and compliance purposes.

[tghosth]

So it feels like there are a few things going on here.

@mesutgungor's request

Mesut seems to be suggesting a requirement extension that where logging sensitive data is required, it should be partially masked and extra controls are required to access that logged data.

@elarlang's perspective

Elar sees this additional requirement as part of the "protection requirements" which are defined based on the "protection level" of an item of data. i.e. for data at a particular level of sensitivity, the following controls are required to protect that data. In this case, that would include how the data needs to be protected if it is logged.

@jmanico's requirement

I think this is proposing that the use/application of the "protection requirements" (as noted in 1.8.2) should itself be logged.

---

My thoughts (part 1)

So based on what Mesut and Elar said, I would propose the following:

Add logging to 1.8.2:

#	Description	L1	L2	L3	CWE
1.8.2	[MODIFIED] Verify that all protection levels have an associated set of protection requirements and that these are applied in the architecture. 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.		✓	✓

Clarify 7.1.1 to bring it in line with the protection level concept:

Current :	#	Description	L1	L2	L3	CWE
7.1.1	[MODIFIED, MERGED FROM 7.1.2] Verify that when logging sensitive data, the application considers the protection level of the data. For example, it may not be allowed to log certain data such as credentials or payment details. Other data such as session tokens may only be logged having been hashed or masked, either in full or partially.	✓	✓	✓	532

@mesutgungor @elarlang what do you think?

My thoughts (part 2)

@jmanico do you think your proposed requirement significantly adds to the security logging requirements in section 7.2?

[jmanico]

Hey @tghosth I think it does, but I'm not at 100% confidence that is is necessary. I just want a detailed audit-log of any data protection measures. I think its important, but i'm really ok if you want to drop it since this area is already rather beefy in ASVS.

[elarlang]

I'm ok with proposals for 1.8.2 and 7.1.1.

If we already going to touch 1.8.2, maybe we remove the implementation note (and that these are applied in the architecture), as it is documentation requirement.

[jmanico]

I think this is a good suggestion from @elarlang

[tghosth]

I split 1.8.2 to documentation and implementation and made the relevant changes to 1.8.2 and 7.1.1 in #2052

@elarlang review please :)