Security Compliance, Dedicated Markets Team

Security Compliance (Dedicated Markets) Mission

Our Mission is to advance customer trust with a focus on customers operating in highly regulated industries or who otherwise have unique security and compliance requirements. We will accomplish this mission by:

1. Enabling GitLab Dedicated to be the most trusted DevSecOps offering in the market, demonstrated by security certifications and attestations.
2. Achieving and maintaining industry-specific security certifications such as FedRAMP and FIPS 140-2 compliance for the U.S. Public Sector.
3. Applying compliance automation and compliance-as-code guardrails to minimize toil and enable product, development, and infrastructure teams.
4. Use our own product (dogfooding) to meet key security controls, improve our offering, and demonstrate to customers how they can do the same.

For more information on the direction of the GitLab Dedicated category, please see this page.

Core Competencies

As a member of the Security Assurance sub-department, and fork of the existing Security Compliance team, we share many of the same core competencies. The difference between our teams is in the product/system scope (GitLab Dedicated and any future offerings for highly regulated markets) and the security certifications we are pursuing.

1. Security Certifications, Attestations, and Initiatives
   • External Audit Coordination
   • Gap Assessments/Readiness Assessments
2. Observation and Remediation Management
   • Identifying control weaknesses and gaps (observations)
   • Remediation recommendations
   • Tracking remediation plans to completion
3. Continuous Monitoring of GitLab’s Security Controls which are mapped to applicable regulatory requirements and security certifications/frameworks we have committed to.
   • User Access Reviews
   • Business Continuity Plan (BCP) and Information System Continuity (ISCP) testing
4. Industry and Regulatory Monitoring and Insights
   • Monitoring drafts and changes to relevant laws, executive orders, directives, regulations, policies, standards, and guidelines.
   • Collaborating on responses to relevant RFIs, RFQs, RFPs, and requests for public comment.
   • Monitoring changes government contractual language that could impact public sector security and compliance posture.

Some of our work is not public for now. Please see the internal handbook to find out more about what our team is working on, or reach out to us.

Vision and Focus Areas

Security Compliance is part of the 2nd line of defense and our goal is identify and treat risks early before they have more severe impacts later on (i.e. regulatory or reputational). We strive to partner with the 1st line of defense (Engineering, Product, and other parts of the organization) to shift compliance left where it is both more effective and less burdensome. To achieve that vision, we need to focus on the following areas and solicit feedback from other parts of the organization:

• Meet our stakeholders where they are
  • Learn the key projects, architectures, and technologies of the products we support
• Reduce toil for control owners and ourselves
  • Automate controls as part of the 1st line of defense and look for efficiencies
• Modernize and scale
  • Identify and implement Governance, Risk, and Compliance (GRC) best practices and “cloud native compliance” solutions
• Measure success and impact on customer trust
  • Identify actionable key performance indicators (KPIs) and key risk indicators (KRIs) for leadership

Where we work

The single source of truth for all of our work will soon be the SecComp Dedicated Markets issue board.

We primarily work out of projects in the Security Assurance sub-group including our team issue tracker, the FedRAMP Certification project, the GitLab instance inside the FedRAMP Authorization Boundary (limited access, AWS GovCloud), and the GitLab Dedicated issue tracker.

How we work

Much of our work is not visible to the rest of GitLab due to regulatory mandates outside of our control. In order to bring as much transparency ans visibility into our work, it is critical that we continue to use the gitlab.com/gitlab-com/ group as much as possible, even if used to track tasks that are completed elsewhere. This is important to take extra steps to increase visibility into our work because it directly enables sales for new SaaS offerings, contributes to the security of self-managed GitLab, and makes it possible to enter new markets that were not previously possible.

Scheduled meetings

We try to avoid meetings at all costs and prefer to work async. We have a weekly call with all of Security Compliance, which includes time for a breakout discussion specific for Dedicated Markets. In addition to that, we also have recurring calls necessary for our FedRAMP program which are necessary for contributing the working group, and logging meeting minutes (external audit artifacts) associated with the configuration control board and compliance sync.

We also have weekly 1:1s and skip levels in line with the GitLab philosophy.

Agile Project Management

We use an agile project management approach for our work, leveraging as many GitLab platform features as we can. We use epics, issues, and issue/epic boards to organize our work, as they complement each other. For some of the work, we also use roadmaps, milestones, burndown charts.

Issue Board

The single source of truth for all of our work will soon be the SecComp Dedicated Markets issue board.

We encourage, but currently do not require, the use of issue weights, to log estimated hours, and health status. The exception is for recurring continuous monitoring tasks which do require both of these.

Epics

We currently have the following epics:

• Epics tracking our FedRAMP Continuous Monitoring tasks for that month
• Epics to track quarterly user access reviews
• Epics to track annual contingency/disaster recovery planning and incident response tabletop, which we help facilitate
• Epics tracking annual external audits and penetration tests
• Miscellaneous epics

We are currently investigating whether Epic Boards would add value to the way we organize and view all the work we’re doing.

Labels

At GitLab, we like to label everything. It provides critical metadata on epics and issues because GitLab issues do not support custom fields.

1. All issues should have our sub-department label: Sub-DepartmentSecComp Dedicated Markets.
2. Team labels: team::fedramp compliance or team::dedicated compliance.
3. Scoped seccomp workflow:: labels.

Any new labels should be created at the gitlab-com group level so to that it can be used across sub-groups and projects.

Workflow labels

We leverage scoped workflow labels to track different stages of work. These are important because we rely on our issue board for team meetings, reporting up to leadership, metrics, and spreading visibility into our work.

Milestones and burndown charts

Currently, we use monthly milestones and a burnup/burndown chart to track recurring FedRAMP continuous monitoring tasks. Here is an example. The work itself is taking place within the FedRAMP Authorization Boundary, however this allows us to increas visibility into that work and include it in metrics. For more informatioin on these tasks, including how the issues are imported at the beginning of every month, please refer to this document.

Metrics and Measures of Success

1. Security Control Health
2. Security Observations
3. FedRAMP Vulnerability Posture (limited access)
4. Vulnerability Deviation (Exception) Requests

Contact the Team

• Slack
  • Feel free to tag us with @dedicated_compliance or @sec-compliance-team to reach the entire Security Compliance team
  • The #sec-assurance slack channel is the best place for questions relating to our team (please add the above tag)
  • FedRAMP questions should be directed to the # wg_fedramp channel
• Tag us in GitLab
  • @gitlab-com/gl-security/security-assurance/team-security-dedicated-compliance
• Email
  • security-compliance@gitlab.com
• Here are our team’s GitLab.com subgroups and projects
• Interested in joining our team? Check out more here!