Security Requirements for Development and Deployment
The Security Department and its subteams are responsible for a number of applications and other resources that process various types of sensitive data in service of supporting GitLab.com.
The scope of the requirements and practices documented in this page are Security Department tools and resources that collect, process, and store RED data.
What’s in this page
- Infrastructure requirements for security team tools that collect, process, and and store RED data.
What is not in this page
- An exhaustive list of security best practices for network, host, and infrastructure security.
- An exhaustive list of security best practices for application, database, cloud function, or other development resources.
- Prescriptive guidelines for development and change management.
Future work: At this time, we don’t have defined process for architecture and implementation review like we have for AppSec Reviews. Such a process will be the responsibility of a future Security team.
The following requirements are driven by 3 high level guidelines:
Identity, Authentication, and Authorization
Accounts and Credentials
- Shared user accounts MUST NOT be used.
- Multi-factor (MFA) authentication MUST be enabled for all user accounts.
- Access to service account credentials MUST follow the access control of the resources to which the credentials grant access.
- Service account credentials MUST be rotated every 365 days.
- Non-MFA user account credentials (for example, API keys) MUST be rotated every 90 days.
- An identity provider MUST be used for all external accounts.
- Service accounts MAY be authenticated using static credentials, such as API tokens or shared private keys.
- User access to sensitive data MUST be granted through security groups.
- Individual access for disaster recovery MAY be granted to system owners as specified in the tech stack tracking file.
Service Account usage
- Service accounts names SHOULD be meaningful.
- Service accounts with access to RED data MUST follow the Access Request process.
- Service accounts with access to RED data MUST be limited to single logical scope; for example, a single GCP project.
- All network firewalls MUST be configured such that the default policy is DENY.
- Network firewall rules SHOULD deny egress by default.
- All external communication MUST be encrypted in transit using up to date protocals and ciphers.
- All internal communication SHOULD be encrypted in transit if possible.
Data Handling and Isolation
- Data retention policies MUST be followed.
- Data MUST be encrypted at rest.
- Data MAY be encrypted using provider managed keys.
- Data of different types MUST be logically seperated at rest.
- Virtual networks (for example, VPC in GCP) MAY be used as a mechanism for data and workload isolation.
Examples of different data types:
- User content, such as repository contents or attachments
- Production derived data, such as logs
- DFIR (Digital Forensics and Incident Reponse) artifacts, such as system logs and disk images
Vulnerability and Patch Management
- Resources MUST be covered by the Security Vulnerability Management process.
Change Management and Tracking
- Changes to systems that process RED data MUST be tracked in a corresponding issue, merge request, or other reviewable process.
- Environment audit logs MUST be enabled and stored in accordance with retention policies.
- Application audit logs, if supported and available, MUST be enabled and stored in accordance with retention policies.
- Logs MUST be forwarded and processed in a centralized location that provides access to any operational team, such as Security Operations.
The following practices are meant to provide more specific technical implementation examples to meet the above criteria.
Disable legacy metadata endpoints
The legacy metadata endpoints should be disabled on all projects.
Development and deployment should occur in a minimum of 2 environments, in addition to local development:
- A shared testing, integration, or other non-production environment.
- A production environment which meets or exceeds the requirements in this page.
The environments should be configured as closely as possible as a best practice to reduce errors in deployment due to inconsistent configuration.
GCP Security Group (firstname.lastname@example.org) Conventions
Security groups for
gitLab.com organization resources should be named
Remove default service account permissions
When services are enabled, the default service account may be created with
- This default mapping should be removed.
- A service account for each workload should be provisioned with the least privileges required.
Use Lifecycle Management for GCS
Buckets which store data subject to retention requirements should use lifecycle management to automate deletion.
Shielded VMs should be used in all cases. This can be enforced with
organization or folder policy. Since this can’t be enforced on the existing
gitlab.com organization due to existing workloads, it should enforced at
the folder or project level for new folders and projects.
VPC Firewall Rules
A default DENY rule for both egress and ingress should be added to all VPCs:
Least Privileges Review
GCP now has a permission recommender which will recommend least privilege based on actual usage. It can be used to determine minimum permissions in non-production environments. It should be reviewed periodically as part of scheduled reviews and maintenance.
Okta is our corporate identity and authentication provider. Configuration of applications using Okta as a SAML provider is the preferred solution. It meets operation needs for security monitoring of activity and can be provisioned by IT Ops using the standard Access Request process. Applications designed to work as SAML Service Provider should be able to work with other identity providers if that changes in the future.
For applications requiring shell access for daily work, Okta ASA should be implemented for ssh authentication.