GitLab logs critical information system activity to a secure repository. GitLab disables administrators ability to delete or modify enterprise audit logs; the number of administrators with access to audit logs is limited.
Logging is the foundation for a variety of other security controls including monitoring, incident response, and configuration management. Without comprehensive and reliable logs, large parts of our security compliance program wouldn't be possible. This control focuses on the integrity of audit logs by securely safeguarding the logs from modification or deletion by privileged GitLab team members.
An auditor will look to validate the in-scope system repositories containing audit logs are unable to be modified or deleted, administrator access is limited to minimum number of team members based on job-related need, and the systems utilized for storage have proper security hardening.
To validate the control is working properly, the auditor should require additional pieces of information to demonstrate audit logging is functioning properly. Those information items include:
This control applies to all audit log repositories within our production environment. The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This may include third-party systems that support the business of GitLab.com.
Audit log repositories should be secure (hardening best practices) and include the inability for GitLab adminstrators to modify or delete logs and for GitLab administrator access to be limited in number of GitLab team members. Any logs stored in Stackdriver cannot be deleted or modified by any person, per Stackdriver's own documentation; logs from Stackdriver are only deleted after the retention period has passed.
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the Audit Logging control issue.