Product Stage Direction - Defend

  1. You are here:
  2. GitLab Direction
  3. Product Stage Direction - Defend

このページのコンテンツ

Protecting cloud-native applications, services, and infrastructure

GitLab Defend enables organizations to proactively protect cloud-native environments by providing context-aware technologies to reduce overall security risk. Defend is a natural extension of your existing operation's practices and provides security visibility across the entire DevSecOps lifecycle. This visibility empowers your organization to apply DevSecOps best practices from the first line of code written and extends all the way through to greater monitoring and protection for your applications that are deployed in production.

Defend Overview

Stage Overview

The Defend Stage focuses on providing security visibility across the entire DevSecOps lifecycle as well as providing monitoring and mitigation of attacks targeting your cloud-native environment. Defend reduces overall security risk by enabling you to be ready now for the cloud-native application stack and DevSecOps best practices of the future. This is accomplished by:

Groups

The Defend Stage is made up of two groups supporting the major categories focused on cloud-native security including:

Resourcing and Investment

The existing team members for the Defend Stage can be found in the links below:

3 Year Stage Themes

Cloud native first

Defend will focus first on providing reactive security solutions that are cloud native. Whenever possible, Defend capabilities will be cloud platform agnostic, including support for self-hosted cloud native environments.

For example, GitLab's current Defend capabilities leverage numerous open source cloud-native projects that integrate cleanly with Kubernetes to provide additional security in containerized environments. Any future expansion of security capabilities will come after the cloud native capabilities are mature.

Visibility first, protection second

Defend will focus on detecting and alerting on malicious traffic and activity as a first step followed by introducing prevention as a second step. This is valuable to you because it means that you can introduce Defend within your cloud native applications, services, and infrastructure gradually over time without disrupting your end users. This allows you to examine the alerts generated by Defend using detection policies to ensure all security settings are appropriate and accurate for your cloud native deployment prior to moving to protection policies. This allows you to eliminate false positives and prevents your users from having a poor user experience with your applications and services. Furthermore, Defend will provide you with evidence of malicious traffic and activity as well as any actions taken, allowing you to meet and exceed your compliance goals and requirements.

As examples, GitLab will provide:

Blur the line between development and security operations

One of the key advantages to GitLab being a single application for the entire DevOps lifecycle is that all of our stages are tightly integrated. This empowers Defend to both provide information into other stages, such as Plan, as well as to receive information from other stages, such as Secure.

Defend will leverage knowledge from the Secure Stage and provide virtual patching of security policies within Defend Categories. Additionally, Defend will eventually leverage Secure scanning capabilities to provide on-going scanning of applications after they have been deployed to production. This allows for detection of any new threat vectors or vulnerabilities that were published after the original push to production.

Defend will identify and protect against threats as they happen, and will also strive to provide actionable next steps to close a vulnerability or point of exploit, not just defend it.

Not only does shifting left and acting on results earlier give your apps better security, it helps enable collaboration with everyone at your company. We believe that security is everyone's responsibility and that everyone can contribute. Informing other stages is a powerful way to do this.

As examples, GitLab will provide:

Improve OSS security standards

Defend will leverage OSS security projects to build our solutions. Defend will contribute improvements to these projects upstream helping everyone be more secure.

For example, GitLab recently added a Policy Audit Mode to the upstream open source Cilium project to allow users to test their policies before enforcing them.

Emphasize usability and convention over configuration

Defend capabilities will be pre-configured to provide value to protecting your applications. Rather than require you to read documentation manuals and provide complex configuration files, GitLab will always provide reasonable defaults out of the box.

We will provide the ability for advanced and customized configurations, but these will only be needed based on your specific use case and when you feel comfortable doing so.

For example, GitLab is currently working on an intuitive policy editor UI to allow for configuration of Network Policies. While advanced Network Policies can be created and managed by editing the .yaml file, the majority of policy use cases can be accomplished with the simpler UI.

3 Year Strategy

Effectively protecting applications running in production requires the following key software capabilities that will be developed over the next 3 years:

  1. A streamlined workflow for triaging, investigating, and mitigating application attacks. This workflow will be tightly integrated into the rest of the GitLab product.
  2. Seamless two-way integrations with other security products to both allow GitLab to share alerts with other tools as well as to allow other tools to share information about attacks with GitLab.
  3. A best-in-class policy editor that is both powerful and easy to use. By providing clear information about what policies are deployed, misconfigurations and accidental security holes can be avoided.
  4. Analytics that save time and reduce errors by leveraging GitLab's knowledge of the application code to reduce false positives by tuning policies, effectively prioritizing alerts, and auto-suggesting security best practices.
  5. In-depth introspection into the overhead, uptime, and performance of Defend technologies to ensure that security protections are always up and running without interfering with application performance.
  6. Enterprise-grade user permissions, audit logging, change control, and reporting to ensure that the GitLab application itself is safe from threats.
  7. Managed Security Service Provider (MSSP) support to allow partners to effectively and efficiently monitor the security posture of their clients' applications.

1 Year Plan

Although the Defend stage has grandiose aspirations and a broad vision, the next 12 months of effort are entirely focused on building a foundation of security tools and capabilities that can be expanded later as the stage matures.

High-level 12-month Roadmap

Defend Overview

Please note that all roadmap items and timelines are subject to change

Q3 FY'21 - (August 2020 - October 2020)

Q4 FY'21 - (November 2020 - January 2021)

Q1 FY'22 - (February 2021 - April 2021)

Q2 FY'22 - (May 2021 - July 2021)

What's Next for Defend

Currently the Defend stage is entirely focused on building out its container security capabilities. Specifically this includes support for applications that run in a containerized Kubernetes environment. Support is agnostic as to whether the application is hosted on premise or in the cloud as long as it is inside Kubernetes. Key initiatives in this group over the next 12 months will include establishing a baseline level of functionality in the following areas:

Towards the end of the next 12-month period, we plan to begin work on our Insider Threat category and deliver some initial capabilities there at a minimal maturity level.

What We're Not Doing

Although we will likely address many of these areas in the future (as described above in our 3 year strategy), we are not planning to make progress on the following initiatives in the next 12 months:

Key Performance Metrics

The following metrics are used to evaluate the success of the Defend stage:

Target Audience

GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.

Today

To capitalize on the opportunities listed above, the Defend Stage has features that make it useful to the following personas today.

  1. 🟨 Security Operations Engineer / SecOps Teams
  2. 🟨 Security Analyst
  3. ⬜️ DevOps Engineer / DevOps Teams
  4. ⬜️ Security Consultants

Medium Term (1-2 years)

As we execute our 3 year strategy, our medium term (1-2 year) goal is to provide a single DevSecOps application that enables SecOps to work collaboratively with DevOps and development to mitigate vulnerabilities in production environments.

  1. 🟩 Security Operations Engineer / SecOps Teams
  2. 🟩 Security Analyst
  3. 🟨 Internal Security Analyst / Internal teams responsible for Insider Threat
  4. 🟨 DevOps Engineer / DevOps Teams
  5. 🟨 Security Consultants

Security Teams

Security teams and Security Operations teams are the primarily day-to-day users of Defend features. Over time, GitLab aims to become the primary tool they use to protect, monitor, and manage the security of their production environments. As most organizations have limited resources and/or security talent, we will strive to make the entire user experience as simple and easy to use as possible so as to minimize the skill set and number of individuals required. Additionally, summary-level dashboards and reports will eventually be provided to allow for clear reporting up to executives.

Personas

User Adoption Journey

Defend is fundamentally different from all other GitLab stages because its primary target user sits outside the Development organization in a Security team that is most commonly within a larger IT department. Consequently there are two primary paths to adopting Defend.

  1. Start with the security team; expand to the development organization later - this user adoption journey involves the security team adopting Configure and then Defend to use GitLab to provide security for their production environment. Initially another tool may even be used for their source code management, their CI/CD pipelines, and any other DevOps functions. Once Defend is being used by the Security Team, additional user adoption then follows along the traditional GitLab user adoption journey model with the development organization typically starting with the Create stage.
  2. Start with the development organization; expand to the security team later - this user adoption journey involves the customer first using GitLab for any one or more of our other stages, such as Secure, as part of their development workflow. At any point along that adoption journey, the Security Team can then choose to start using Configure to connect to their production environment and then Defend to manage the security of their deployed applications. The development organization does not need to have adopted Configure first.

料金

Defend is focused on providing enterprise-grade security capabilities to protect production environments. The intent is to provide enough value in paid features so as to allow Defend to contribute in a significant way over the next 3 years toward GitLab's company-level financial goals.

Although paid features are the primary focus, there are several reasons why features for unpaid tiers might be prioritized above paid features:

  1. The Defend stage has a powerful potential to help improve the security of projects everywhere. Features with the potential to significantly improve the security posture of all projects will be highly prioritized and made available in an unpaid tier.
  2. To continue to be good stewards in the open source community, any basic integration with open source projects will be available in an unpaid tier, along with the "table stakes" set of functionality required to allow that feature to be usable with GitLab.

Core/Free

This tier is the primary way to increase broad adoption of the Defend stage, as well as encouraging community contributions and improving security across the entire GitLab user base.

As a general rule of thumb, features will fall in the Core/Free tier when they meet one or more of the following criteria:

Some examples include:

Starter/Bronze

This tier is not a significant part of Defend's pricing strategy.

Premium/Silver

This tier is not a significant part of Defend's pricing strategy.

Ultimate/Gold

This tier is the primary focus for the Defend stage as the security posture of an organization is typically a primary concern of the executive team and even the board of directors. Just as a major security incident has far reaching consequences that impact the entirety of an organization, the features and capabilities that successfully protect against those types of attacks tend to be valued with equal weight. The types of capabilities that fall in the Ultimate/Gold tier vs an unpaid tier should be those that are necessary for an organization, rather than an individual, to provide for adequate security of their production environment.

As a general rule of thumb, features will fall in the Ultimate/Gold tier when they meet one or more of the following criteria:

Some examples include:

Categories

There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.

Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.

WAF

Web Application Firewall（WAF）は、ウェブアプリケーションに送信されるトラフィックを調べ、 悪意のあるトラフィックが到達する前に検出してブロックします。 Auto DevOpsを使用すると、ModSecurity WAFがKubernetesクラスターのIngressコントローラの背後にインストールされます。 デフォルトでは、OWASP ModSecurityのコアルールセットを実行するように設定されています。 This category is at the "minimal" level of maturity.

Priority: medium • Documentation • Direction

コンテナホストセキュリティ

Kubernetes、ネットワーク、ホストレベルでのセキュリティ脅威を検出し、対応できます。 This category is at the "minimal" level of maturity.

Priority: high • Documentation • Direction

コンテナネットワークセキュリティ

コンテナネットワークセキュリティでは、Kubernetesにネットワークポリシーを実装して、 ポッド間やクラスターとインターネット間の不正なネットワークトラフィックを検出してブロックすることができます。 This category is at the "minimal" level of maturity.

Priority: medium • Documentation • Direction

UEBA

UEBA（User and Entity Behavior Analytics）は、機械学習など技術を活用して、の ユーザーやシステムの異常な振る舞いを検知し、アラートを出し、ブロックするソリューションです。

Priority: high • Direction

Other Top Level Features

There are several top-level features that span across all groups and categories in the Defend stage.

Alert Dashboard Vision

The alert dashboard is the central location for viewing and managing alerts. The long-term plan is to aggregate alerts from all categories at the project, group, and instance levels and visualizing those alerts in both a list-view as well through explorable charts and graphs. Alerts will be eventually be capable of being prioritized based on the severity of the alert (defined by the policy that generated the alert) as well as an analytical algorithm that scores the alert based on its level of risk. The alert dashboard will also host the central workflow for taking action on alerts, including any auto-suggested remediation actions or recommended policy tuning changes.

Policy Management Vision

The policy management experience is the central location for policies across both the Secure and Defend stages. Here users will be able to have the flexibility of managing policies directly in code or in a streamlined UI editor. As part of the long-term vision for the policy management experience, users will be able to view a complete history of all changes and easily revert to a previous version. A two-step approval process can optionally be enforced for all policy changes. Eventually the policy management UI will be extended to provide visibility into the performance overhead of each policy. Suggestions into policy adjustments that might help either reduce false positives or increase overall security coverage will be provided in this section as well.

Upcoming Releases

Other Interesting Items

There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.

Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!


Last Reviewed: 2020-07-16
Last Updated: 2020-07-16

このページを編集 — 貢献をお願いします Creative Commons License