Clarify intro to "V7 Error Handling and Logging"

[mjang-cobalt]

Hi, in the same vein as https://github.com/OWASP/ASVS/issues/1106, I'm proposing to rewrite the intro "Control Objective" part of "V7 Error Handling and Logging".

Later in the same page, I see references to OWASP Top 10 2017:A10. At minimum, I think we should change that to OWASP Top 10 2021:A9, based on https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/. But IMO that's a subject for a different issue. I'm limiting this issue to the noted intro.

If my change is too extensive, I'm happy to limit my proposal -- or split it into separate issues. In this list, I present the current paragraph (or list) followed by my proposed changes (with comments). It might be "easier" to present and discuss this in a PR.

Control Objective

Current: The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise.

Proposed: Error handling and logging should provide useful information for users, administrators, and incident response teams. High quality logs minimize irrelevant information.

/* I'm trying to simplify the text -- I've also replaced the "signal than discarded noise" reference, as it can be a misleading idiom */

Current: High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include:

Proposed: As high quality logs often contain private and sensitive data, you must protect them per applicable privacy laws. We suggest following these practices:

/* I've removed "local" from the paragraph, as we know the reach of regulations like GDPR, and have added "private" as I think that's all we need from the paragraph after the bulleted list. */

Current:

• Not collecting or logging sensitive information unless specifically required.
• Ensuring all logged information is handled securely and protected as per its data classification.
• Ensuring that logs are not stored forever, but have an absolute lifetime that is as short as possible.

Proposed:

• Ensure all logged information is handled securely and protected. /* I've removed "per its data classification", as that begs for a link to different classifications */
• Ensure that all log information is deleted after you've collected necessary security information.
• Do not include sensitive information in your logs unless specifically required.

Current: If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.

Proposed: Delete paragraph.

/* I'm not sure the paragraph on "private or sensitive data" adds anything. The way it's written suggests that what attackers do varies by country. So I propose deleting this paragraph. (I've added "private" to the paragraph before the bulleted list */

[elarlang]

Side note for @mjang-cobalt, when doing v5.0, most likely we heavily change the structure categories and subcategories and therefore current text will be changed as well.

It's nice to make those current ones better, but it's fair to say, that we may need to change them a lot and some of the current work may be removed.

[mjang-cobalt]

Thanks for the caution, @elarlang . As a tech writer for Cobalt, one of my purposes is to learn the intricacies of OWASP standards. If these standards change, I'll learn more as I watch the discussion.

[jmanico]

And @elarlang since 5.0 is going to be such a massive change, I am not opposed to releasing a 4.0.4 release as well if we note any mistakes there.

[tghosth]

I would be happy to see a PR on this but I would echo what Elar says in that things could move around and, even more than that, it is possible that these description sections may be significantly reduced/downsized as well.

[elarlang]

We probably going to change V7 quite a lot. Before putting effort into it, it makes sense to wait outcome from https://github.com/OWASP/ASVS/issues/997

[tghosth]

Pushing this to draft stage as it is not requirement specific