Working in the Federal Government space, FISMA security control are required. One of those currently missing in SonarQube is a user audit trail. We’d like see security events such as user logon/logoff, roles created or modified and user/role changes for example in an audit trail with timestamps.
We’ve seen requests before for change audit-trailing but this is the first request I’ve see for login/out. Can you help me understand the reasoning behind that?
There are a number of important reasons for this request but two of the most important are:
- If we are investigating an actual or potential intrusion it is critical that we can track who logged, when and from where. Such attacks generally come from multiple vectors across the enterprise simultaneously. The ability to correlate access attempts across the enterprise is critical to understanding the nature of the attack as well as understanding its impact.
- Information System Security Officers (ISSOs) are responsible for a monthly audit of users in all applications. Part of this is verifying who has administrative rights but it also includes disabling accounts that are not actively using the system.
Have you had a chance to poke around with the
sonar.web.accessLogs.pattern system property, and the information it can provide in
access.log ? Check out this other discussion where it was mentioned for example:
Granted it’s about tracking activity at the log level, but it might certainly let you to detect specific requests/events, and I guess dedicated tools exist to monitor/aggregate such logging formatted information.
Using the access log pattern, I’ve configured the access log to write all parameters, and used the Elastic Stack to aggregate. This is effective for some of the audit requirements.
However, there are some notable issues.
- Without the use of a log parser (Logstash in my case), adding all of the parameters to the access log pattern makes the far too verbose. I would like to have a new pattern created for all non-null parameters in quoted key/value pair format, and line breaks are gracefully replaced.
- Using tokens to configure SonarQube connections in CI tools (Azure DevOps Server, in my case) do not allow us to identify the individual who initiated the scan. With the available documentation, it suggests you generate a token with your own account to configure the service connection. Access logs then identify this user as the actor. The best I can do here is to create a generic team user, log in with it to generate a token, and use that for the build tool. What I would like is to have the CI application pass details of the build requestor and URL to SonarQube for logging.
Audit trail functionality is needed to protect the integrity of the system and evaluations for security.
I’m in the same boat and web request logging is insufficient to meet ISO or Federal Government requirements. These requirements are documented in the National Institute of Standards Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations.
Examples of auditable events for Low, Moderate, and High impact levels are provided in security control AU-2 Supplemental Guidance: “Audit events can include, for example, password changes, failed logons, or failed accesses related to information systems, administrative privilege usage, PIV credential usage, or third-party credential usage. […] Auditing requirements, including the need for auditable events, may be referenced in other security controls and control enhancements. Organizations also include auditable events that are required by applicable federal laws, Executive Orders, directives, policies, regulations, and standards.” Reference: https://nvd.nist.gov/800-53/Rev4/control/AU-2
An example of another control and enhancement for systems categorized at the Moderate or High impact level is security control AC-6 (9): “The information system audits the execution of privileged functions. Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse, and in doing so, help mitigate the risk from insider threats and the advanced persistent threat (APT).” Reference: https://nvd.nist.gov/800-53/Rev4/control/AC-6#enhancement-9
This is a work-around at best. If Sonarqube is really going to be Enterprise-level it needs to have a separate audit log with a well-defined format and interface.
Hi, is there any update if this feature request has made it into the current product road map?
Feel free to vote for this:
FR-13 - Add Audit Trail Functionality in SonarQube Administration