[FEEDBACK] - The traditional logging paragraph needs refactoring

[spud023]

Summary

The traditional logging paragraph needs refactoring for SHOULD and MUST directives:

Traditional logging, alerting and incident management practices also apply to APIs, along with additional considerations that SHOULD be applied:

• Correlating API requests with specific back-end system activity and the resulting API responses to support end-to-end tracing - capture timestamps, user/consumer information and actions performed
• Logging of user actions (login, logout) SHOULD be monitored
• Identifying specific API requests from consumers to help resolve API consumer problems
• Detecting events that may indicate a malicious attempt to access an API
• Logs MUST be stored in a tamper-proof and secure location

The SHOULD in the header should not be repeated for only some of the bullet points below it. Either all should contain the SHOULD keyword, or none. Furthermore, the last bullet point contains a MUST directive, which is inconsistent with the header stating that things SHOULD be applied. I suggest:

Traditional logging, alerting and incident management practices also apply to APIs.

In addition the following additional considerations MUST be applied:

• Logs MUST be stored in a tamper-proof and secure location

And the following additional considerations SHOULD be applied:

• [the other bullets rewritten with consistent use of SHOULD]
• ...

Link to standards item

https://apistandards.digital.health.nz/api-security/SecurityControls#monitoring-logging-and-alerting

Which area of the standards does this apply to?

• [ ] Part A - API Concepts
• [X] Part B - API Security
• [ ] Part C - API Design and Development
• [ ] Part D - FHIR
• [ ] Community guidelines

[ChrisSquats]

Thanks for the feedback, issue resolved as per PR https://github.com/tewhatuora/api-standards/pull/83