Security Architects are the
trusted security advisors of GitLab Engineering. Security Architecture is a natural extension of the
greater Architecture initiative at GitLab. It is the
preliminary and necessary work to build software with security considerations.
Objectives
Security Architecture protects the organization from cyber harm, and support present and future
business needs by:
avoid being a bottleneck in the software development life cycle
deliberately simple and concise
automated as much as possible
DRY with strong notes
Scope of Security Architecture
Any change in our product offering (whether it is a feature, a service, or an acquisition), that
would impact our security posture. Our security posture is defined by:
the components we build upon
the components we embed
everything infrastructure
3rd party services
software architecture
reference architectures
Security Architecture Requirements
Application Security
The Application Security team provides guidelines and requirements to follow during all the life
cycle of source code:
Broad privileges allow malicious or accidental access to protected resources.
How
Give only the minimum level of access rights (privileges) that is necessary to a user or service
to complete an assigned operation. This right must be given only for a minimum amount of time that
is necessary to complete the operation.
Do not use administrative accounts for application access
Use separate accounts for sensitive data
Examples
Run service processes as their own users with exactly the set of privileges they require
Grant read-only permissions when no updates are required
When updates are required, limit to the scope to the target resource only
Many security problems caused by inserting malicious intermediaries in communication path
How
Assume unknown entities are untrusted
Have a clear process to establish trust
Validate who or what is connecting
Always use a kind of authentication (certificate, password, …)
Network controls
Do not dynamically load 3rd party code
Examples
Services can’t be considered as secure as soon as they are not exposed to the Internet.
SSRF can let attackers freely access
them.
The best way to authenticate users is to apply this general security principle: Provide something
you know (ex: password), and something you own (ex: certificate). This is what we apply with MFA,
for example by providing a password you know, along with a
TOTP that is generated by an
application.
Downloading 3rd party libraries or scripts at runtime can lead to many security issues, including
cache poisoning, XSS, and whatnot. Without checking the integrity of the external asset, malicious
actors can tamper the files, like this example of BGP
Hijacking
Attack-ability or attack surface of the software is reduced
How
Avoid complex failure modes, implicit behaviours, unnecessary features
Use well-known, tested, and proven components
Avoid over-engineering and strive for MVCs instead
Examples
Introducing a new server in GitLab means updating Omnibus builds, Helm charts, our reference
architectures, our docs, and so on. This is something to balance carefully against the benefits of
adding a component which seem to be a perfect fit.
Related to above, some components might fail over to a plain user/password authentication (with
default credentials) under certain conditions, like a service not reachable.
Some frameworks tend to render error pages with details that should not be shared, like hostnames
and paths, when they cannot connect to some resources.
Hiding things is difficult, someone is going to find them, accidentally or on purpose
We’re a very transparent company and are more likely to share
implementation details, sometimes leaking something sensitive.
Offboarded employees leave with sensitive knowledge. While tokens can be rotated, we can’t ensure
this knowledge won’t leak
How
Assume attacker with perfect knowledge
Examples
Recon can help attackers find servers that are not publicly documented. These servers could expose
vulnerable components, and lead to east-west movement.
Changing the path to a admin section won’t prevent attackers from finding it eventually.
Sometimes consider the humans (users) as the weakest link. Phishing is still widely used for a
good reason
Examples
Some resources are very well protected in the UI, and never exposed to unauthorized users. Yet, if
the API is not correctly implementing security controls, these resources could be passed as raw
models without filtering sensitive data.
Data encrypted in transit but not at rest.
The weakest link could also be a user. Not enforcing strong passwords and MFA could lead to
sensitive data exposure, but users can also do harmful actions without being aware of it.
OS (system) commands often leads to bypassing most, if not all, the security controls of an
applicaton. It is a common vector for RCEs and should be avoided as much as possible.
As part of the Production Readiness Process, it is highly recommended to include a Security
Architecture review.
The Security Architecture review process is detailed in this page.
Measuring results
Security Architecture, by nature, doesn’t generate measurable data, apart from the number of
architecture diagrams and reviews. While this could be used as a metric, it’s only reflecting work
load, and not achievements. Instead, we are measuring success in terms of maturity.
The OWASP SAMM framework is currently used, but this is subject to change (see discussions in this
issue).
We are targeting the Maturity Level 1 for FY23-Q1, and our roadmap is discussed in this
issue.
Overview Security Architecture review is a holistic assessment of security layers across infrastructure, application, people, and processes.
Purpose Meet Security and Compliance requirements Ensure best practices are used Ensure Security Architecture Principles are followed Ensure identified security threats are mitigated Bring Risk management early in our processes (design, implementation, management) Provide recommendations to minimize damage when a component is compromised When to conduct a Security Architecture review? The review process is integrated into the broader Architecture workflow, but can be triggered for:
Zero Trust As part of raising that bar, GitLab is implementing Zero Trust, or the practice of shifting access control from the perimeter of the org to the individuals, the assets and the endpoints. You can learn more about this strategy from the Google BeyondCorp whitepaper: A New Approach to Enterprise Security.
In our case, Zero Trust means that all devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized.
