CVE-2023-44400: Admin (portal user) Audit Logs and Activities · Issue #3481 · louislam/uptime-kuma

NIST SP 800-58 only targets VOIP => irrelevant

@CommanderStorm, Sorry I meant NIST SP 800-92; it was a late night brain fart. It’s not just that one security standard that requires logging in to the system, e.g., if you consider the Microsoft Threat Modeling (STRIDE) as the port of the SSDLC process in a company, not having logs enabled can cause repudiation as a threat.

SOC2+ISO27001 seems to have a form of audit trail requirement from what I can gleam of publicly accessible documents
could you provide screenshots of the exact requirements in these documents?

We follow NIST SP 800-53 to implement and build SOC2 controls/policies (as a general guideline), and we dig into more details on other standard releases (e.g., FIPS)

More information:
Some of the controls in NIST SP 800-53

• AU-2: Auditable Events
• AU-3: Content of Audit Records
• AU-6: Audit Review, Analysis, and Reporting
• AU-12: Audit Generation

and Some of ISO 27001 controls/requirements:

• A.12.4.1: Event Logging: This control requires that event logs recording user activities, exceptions, faults, and information security events should be produced, kept, and regularly reviewed.
• A.12.4.2: Protection of Log Information: This control requires that logging facilities and log information should be protected against tampering and unauthorized access.
• A.12.4.3: Administrator and Operator Logs: This control requires that system administrator and system operator activities should be logged and the logs protected and regularly reviewed.
• A.14.2.5: Secure System Engineering Principles: This control is about using secure engineering principles for developing and maintaining systems. While not specific to logging, it includes principles that could apply to logging.

more: https://infosavvy.home.blog/2021/04/22/iso-27001-annex-a-12-4-logging-and-monitoring/

Hottake:
Audit-logs are only relevant if more than one user can be present at one time
⇒ uptime-kuma can currently only ever be used by one user which does privileged actions.
⇒ imo only a feature which could become relevant if somebody gets around to implementing https://github.com/louislam/uptime-kuma/issues/128 or one of the duplicates like https://github.com/louislam/uptime-kuma/issues/3272

Naturally IRL, when this happens, we share the password in a shared team key vault or anywhere FIPS 140-2 Level 2 compliance and have an update process that we follow (e.g., RACI model) to make sure we minimize the possible risks. We have a process that privileged user follows to increase business continuity…

All actions are currently written to the log
=> I don't have access to the specs, is this sufficient?

but it’s still good to have more meaningful portal-level logs rather than application and database levels.

On the other hand, this Project is open source and open to PRs. Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md`

Yeah, I thought of that as well, but not sure if I am a good JS/TS developer; I will try my best 👍