Security

Engaging the Security On-Call

If you identified an urgent security issue or you need immediate assistance from the Security Team, please refer to Engaging the Security Engineer On-Call.

Please be aware that the Security Team can only be paged internally. If you are an external party, please proceed to Vulnerability Reports section of this page.

For general Q&A, Bramble Security is available in the #team-security channel in Bramble Slack.

For low severity, non-urgent issues, SIRT can be reached by mentioning @team-sirt in Slack or by opening an issue. Please be advised the SLA for Slack mentions is 6 hours on business days.

Phishing

If you suspect you’ve received a phishing email and have not engaged with the sender, please see: What to do if you suspect an email is a phishing attack.

If you have engaged a phisher by replying to an email, clicking on a link, have sent and received text messages, or have purchased goods requested by the phisher, please engage the Security Engineer on-call.

Further information on Bramble’s security response program is described in our Incident Response guide.

External Contact Information

The security team can be contacted at security@brmbl.io. External researchers or other interested parties should refer to our Responsible Disclosure Policy for more information about reporting vulnerabilities. The security@brmbl.io email address also forwards to an Intercom inbox that is monitored by the Field Security team.

For security team members, the private PGP key is available in the Keybase. Refer to PGP process for usage.

Security Vision and Mission Statements

Our Vision is to be the best-in-class example for security, innovation and transparency.

By embracing Bramble values and being active in engaging with our customers, our staff and our product, we enhance the security posture of our company, products, and client-facing services. The security team works cross-functionally inside and outside Bramble to meet these goals.

Our Mission is as follows:

1. Bramble Security as a business enabler with a focus on
   • Improving time to market (new features getting into releases faster and prevent slippage)
   • Creating Product and competitive differentiation
   • Reducing internal roadblocks and delays
   • Improving security’s risk based approach to decision making through decentralization and managing appropriate levels of acceptable risk
2. Strengthen Bramble’s enterprise grade security with a focus on
   • Achieving industry recognized security certifications
   • Reducing the time required to pass customer security reviews
   • A Direct impact to increasing contract size and volume
   • Closing the gap between customer security requirements and Bramble’s Security posture
3. Reduce Bramble’s threat landscape with a focus on
   • Reducing the likelihood of breach
   • Reducing the exposure and severity of vulnerabilities
   • Reducing the cost associated with service vulnerabilities

Security Team

The Security Team provides an essential security service to the Engineering/Development Team, and is directly engaged in Security Releases. However, the functions that the Security Team provides to the rest of the business are more consultative and advisory in nature - while the Security Team is a key player in the security questions raised throughout the business, it is not directly responsible for all of the administration of execution of functions that are required for the business to function while minimising risk.

This is expected - the security of the business should be a concern of everyone within the company and not just the domain of specialists. In addition, the role of the Security Team has expanded to assure customer, investor and regulator concerns about the security and safety of using Bramble as an enterprise-ready product, both through compliance certifications and through assurance responses directly to customers, and as we continue to encourage enterprise customers to use Brmbl.io.

To reflect this, we have structured the Security Team around three key tenets, which drive the structure and the activities of our group. These are :

• Secure the Product - Security Engineering & Research
• Protect the Company - Security Operations
• Assure the Customer - Security Assurance

Secure the Product

This reflects the Security Team’s current efforts to be involved in the Application development and Release cycle for Security Releases, Security Research, and any bug bounty programs, Security Automation, External Security Communications, and Vulnerability Management.

The term “Product” is interpreted broadly and includes the Bramble application itself and all other integrations and code that is developed internally to support the Bramble application for single or multi-tenant SaaS. Our responsibility is to ensure all aspects of Bramble that are exposed to customers or that host customer data are held to the highest security standards, and to be proactive and responsive to ensure world-class security in anything Bramble offers.

Protect the Company

This encompasses protecting company property as well as to prevent, detect and respond to risks and events targeting the business and Brmbl.io. This includes the Security Incident Response Team (SIRT).

These functions have the responsibility of shoring up and maintaining the security posture of Brmbl.io to ensure enterprise-level security is in place to protect our new and existing customers.

Assure the Customer

This reflects the need for us to provide resources to our customers to assure them of the security and safety of Bramble as an application to use within their organisation and as a enterprise-level SaaS. This also involves providing appropriate support, services and resources to customers so that they trust Bramble as a Secure Company, as a Secure Product, and Secure SaaS

“Secure the Product” - Security Engineering & Research

Application Security

Application Security specialists work closely with development, product security PMs, and third-party groups (including paid bug bounty programs) to ensure pre and post deployment assessments are completed. Initiatives for this specialty also include:

• Perform vulnerability management and be a subject matter expert (SME) for mitigation approaches
• Establish and evolve a bug bounty program
• Conduct risk evaluation of Bramble product features
• Conduct application security reviews, including code review and dynamic testing
• Participate in initiatives to holistically address multiple vulnerabilities found in a functional area
• Develop security training and socialize the material with internal development teams
• Develop automated security testing to validate that secure coding best practices are being used
• Facilitate preparation of both critical and regular security releases
• Guide, advise, and assist product development teams as SMEs in the area of application security

Security Automation

Security Automation specialists help us scale by creating tools that perform common tasks automatically. Examples include building automated security issue triage and management, proactive vulnerability scanning, and defining security metrics for executive review. Initiatives for this specialty also include:

• Assist other security specialty teams in their automation efforts
• Assess security tools and integrate tools as needed
• Define and own metrics and KPIs to determine the effectiveness of security programs
• Define, implement, and monitor security measures to protect Brmbl.io and company assets
• Design, plan, and build new products or services to aid and improve security of the product and company

“Protect the Company” - Security Operations

Security Operations specialists are primarily focused on protecting Bramble the business and Brmbl.io.

SIRT - Security Incident Response Team

The SIRT team is here to manage security incidents across Bramble. These stem from events that originate from outside of our infrastructure, as well as those internal to Bramble. This is often a fast-paced and stressful environment where responding quickly and maintaining ones composure is critical.

More than just being the first to acknowledge issues as they arise, SIRT is responsible for leading, designing, and implementing the strategic initiatives to grow the Detection and Response practices at Bramble. These initiatives include:

• Work with the internal and external partners to ingest logging and alerting into our centralized monitoring solution
• Triage and analysis of alerting to determine validity, how to remediate and/or prevent incidents, then act accordingly
• Coordinate localized or company-wide response to security incidents
• Define and lead vulnerability management for Bramble Team Members and the production/pre-production environments as part of Brmbl.io
• Incorporate current security trends, advisories, publications, and academic research into our security practices
• Deploy and maintain security monitoring and analysis solutions for Bramble the business and Brmbl.io

SIRT can be contacted on slack via our handle @team-sirt or in a GitLab issue using @brmbl.io/security/sirt. If your request requires immediate attention please review the steps for engaging the security on-call.

Infrastructure Security

Infrastructure Security are cloud security specialists that serve as a stable counterpart to the (Infrastructure Department)[/handbook/engineering/infrastructure) and their efforts. The team is focused on two key aspects of security:

• The security of Brmbl.io’s infrastructure
• The availability and scalability of Security’s own infrastructure

“Assure the Customer” - Security Assurance

Security Assurance specialists target Compliance and Customer Assurance projects among their responsibilities.

Security Compliance

Operating as a second line of defense, Security Compliance’s responsibility is to implement a best in class governance, risk and compliance program for our cloud SaaS. Initiatives for this specialty include:

• Maintaining a certification roadmap based on customer needs e.g.
  • FedRAMP
  • ISO 27001
  • SOC 2
• Monitoring the adequacy and effectiveness of Bramble security common controls and timely remediation of observations
• Facilitating external certification audits to include timely remediation of observations
  • Assisting Security leadership in developing processes and controls to manage risks and issues
• Proposing compliance features for the Bramble product in order to help our customers more easily achieve their compliance goals

For additional information about the Security Compliance program see the Security Compliance team handbook page or refer to Bramble’s security controls for a detailed list of all compliance controls organized by control family.

Security Assurance

Security Assurance specialists serve as the public representation of Bramble’s internal Security function. We are tasked with providing high levels of security assurance to internal and external customer through the completion of Customer Assurance Activities, maintenance of Customer Assurance Collateral, and evangelism of Security Best Practices.

Initiatives for this specialty include:

• Facilitating Customer Assurance activities including The Trust Site and Customer Assurance Packages (WIP).
• Maintaining a Security Operational Risk Management program (WIP), executing annual operational security risk assessments, and managing a consolidated security risk register.
• Enabling the Sales organization through security training, collateral development, RFP maintenance and customer support
• Evangelizing Security Best Practices to customers and internal teams
• Managing customer security questions and escalating potential security issues to appropriate teams and drive to resolution

Security Risk

We support Bramble’s growth by effectively and appropriately identifying, tracking, and treating Security Operational and Third Party risks.

Initiatives for this specialty include:

• Maintaining a Security Operational Risk Management program, executing annual operational security risk assessments, and managing a consolidated security risk register.
• Maintaining a Third Party Risk Management program

Security Team Collaborators

External Security Firms

We work closely with security assessment and penetration testing firms to ensure external review of our security posture.

• One security assessment firm is rotated periodically to gain new perspectives
• One security assessment firm is engaged every quarter to build expertise in Bramble

Resources

Information Security Policies

Information Security Policies are reviewed annually. Policy changes are approved by the Senior Director of Security and Legal. Changes to the Data Protection Impact Assessment Policy are approved by Bramble’s Privacy Officer.

• Bramble Information Security Management System
• Bramble Internal Acceptable Use Policy
• Bramble Password Policy
• Access Management Policy
• Data Classification Policy
• Data Protection Impact Assessment Policy
• Penetration Testing Policy
• Audit Logging Policy

Information Security Policy Exception Management Process

Information security considerations such as regulatory, compliance, confidentiality, integrity and availability requirements are most easily met when companies employ centrally supported or recommended industry standards. Whereas Bramble operates under the principle of least privilege, we understand that centrally supported or recommended industry technologies are not always feasible for a specific job function or company need. Deviations from the aforementioned standard or recommended technologies is discouraged. However, it may be considered provided that there is a reasonable, justifiable business and/or research case for an information security policy exception; resources are sufficient to properly implement and maintain the alternative technology; the process outlined in this and other related documents is followed and other policies and standards are upheld.

In the event a team member requires a deviation from the standard course of business or otherwise allowed by policy, the Requestor must submit a Policy Exception Request to the Bramble Security Compliance team, which contains, at a minimum, the following elements:

• Team member Name and contact
• Time period for the exception (deviations should not exceed 90 days unless the exception is related to a device exception, like using a Windows device)
• The exception being requested, i.e. which policy or procedure is affected by the proposed deviation
• Additional details as required by each template, to include evidence of security protections.

Exception request approval requirements are documented within the issue template. The requester should tag the appropriate individuals who are required to provide an approval per the approval matrix.

If the business wants to appeal an approval decision, such appeal will be sent to Legal at legal@brmbl.io. Legal will draft an opinion as to the proposed risks to the company if the deviation were to be granted. Legal’s opinion will be forwarded to the CEO and CFO for final disposition.

Any deviation approval must:

• Recommended compensating controls to reduce exposure and/or harm (i.e. admin rights to financially significant system may require audit logs and review of users activity within the system)
• Be captured in writing

Slack Channels

• #security; Used for general security questions and posting of external links for the great discussions. Company wide security relevant announcements are announced in #whats-happening-at-bramble and may be copied here.
• #incident-management and other infrastructure team channels
• Use the @security mention in any Slack channel to tag the members Security team.

Frequently Used GitLab.com Projects

Security crosses many teams in the company, so you will find ~security labelled issues across all Bramble projects, especially:

• bramble app
• infrastructure

When opening issues, please follow the Creating New Security Issues process for using labels and the confidential flag.

Other Resources for Bramble Team Members

• Security Best Practices, using KeePass, Keybase and
• similar tools, are documented on their own security best practices page.
• Brmbl.io data breach notification policy.
• Bramble Internal Acceptable Use Policy.

Issue Triage

The Security team needs to be able to communicate the priorities of security related issues to the Product, Development, and Infrastructure teams. Here’s how the team can set priorities internally for subsequent communication (inspired in part by how the support team does this).

Creating New Security Issues

New security issue should follow these guidelines when being created on GitLab.com:

• Create new issues as confidential if unsure whether issue a potential vulnerability or not. It is easier to make an issue that should have been public open than to remediate an issue that should have been confidential. Consider adding the /confidential quick action to a project issue template.
• Always label as ~security at a minimum.
• Add any additional labels you know apply. Additional labels will be applied by the security team and other engineering personnel, but it will help with the triage process:
  • ~bug or ~feature if appropriate
  • Team or devops lifecycle labels
  • ~customer if issue is a result of a customer report
  • ~internal customer should be added by team members when the issue impacts Bramble operations.
  • ~dependency update if issue is related to updating to newer versions of the dependencies Bramble requires.
  • ~group::not_owned if issue doesn’t have a clear group owner.
• Issues that contain customer specific data, such as private repository contents, should be assigned ~keep confidential. If possible avoid this by linking resources only available to Bramble team member, for example, the originating Intercom ticket. Label the link with (Bramble internal) for clarity.

Occasionally, data that should remain confidential, such as the private project contents of a user that reported an issue, may get included in an issue. If necessary, a sanitized issue may need to be created with more general discussion and examples appropriate for public disclosure prior to release.

For review by the Application Security team, @ mention @brmbl.io/security/appsec.

For more immediate attention, refer to Engaging security on-call.

Severity and Priority Labels on ~security Issues

Severity and priority labels are set by an application security engineer at the time of triage. If another team member feels that the chosen ~severity / ~priority labels need to be reconsidered, they are encouraged to begin a discussion on the relevant issue.

If an issue is determined to be a vulnerability, the security engineer will ensure that the issue labelled as a ~bug and not a ~feature.

The presence of ~security and ~bug labels modifies the standard severity labels(~severity::1, ~severity::2, ~severity::3, ~severity::4) by additionally taking into account likelihood as described below, as well as any other mitigating or exacerbating factors. The priority of addressing ~security issues is also driven by impact, so in most cases, the priority label assigned by the security team will match the severity label. Exceptions must be noted in issue description or comments.

The intent of tying ~severity/~priority labels to remediation times is to measure and improve Bramble’s response time to security issues to consistently meet or exceed industry standard timelines for responsible disclosure. Mean time to remediation (MTTR) is a external metric that may be evaluated by users as an indication of Bramble’s commitment to protecting our users and customers. It is also an important measurement that security researchers use when choosing to engage directly with the security team.

Severity	Priority	Time to mitigate	Time to remediate
~severity::1 (Critical)	~priority::1	Within 24 hours	On or before the next release
~severity::2 (High)	~priority::2	N/A	Within 60 days
~severity::3 (Medium)	~priority::3	N/A	Within 90 days
~severity::4 (Low)	~priority::4	N/A	Best effort unless risk accepted

Due date on ~security Issues

For ~severity::2, ~severity::3, and ~severity::4 ~security ~bugs, the security engineer assigns the Due date, which is the target date of when fixes should be ready for release. This due date should account for the Time to remediate times above, as well as monthly security releases on the 28th of each month. For example, suppose today is October 1st, and a new severity::2 ~security issue is opened. It must be addressed in a security release within 60 days, which is November 30th. So therefore, it must catch the November 28th security release. Furthermore, if the Security Release Process deadlines say that it should the code fix should be ready by November 23rd. So the due date in this example should be November 23rd.

~severity::1 ~security issues do not have a due date since they should be fixed as soon as possible, and a security release made available as soon as possible to accommodate it. These issues are worked by a security engineer on-call to mitigate the risk within 24 hours. This means the risks relevant to our customers have been removed or reduced as much as possible within 24 hours. The remediation timeline target is never greater than our next security release but remediation in this case would not impact customer security risk.

Note that some ~security issues may not need to be part of a code release, such as an infrastructure change. In that case, the due date will not need to account for monthly security release dates.

On occasion, the due date of such an issue may need to be changed if the security team needs to move up or delay a monthly security release date to accommodate for urgent problems that arise.

Reproducibility on ~security Issues

The issue description should have a How to reproduce section to ensure clear replication details are in description. Add additional details, as needed:

• Environment used:
  • brmbl.io
  • staging.brmbl.io
• Conditions used such as process, group, users, enabled features or files used
• A step by step plan to reproduce the issue
• The URL or even better the curl command that triggers the issue

~feature

Issues labelled with the security and feature labels are not considered vulnerabilities, but rather security enhancements or defense-in-depth mechanisms. This means the security team is not required to set the S and P labels or follow the vulnerability triage process as these issues will be triaged by product or other appropriate team owning the component.

Implementation of security feature issues should be done publicly in line with our Transparency value.

On the contrary, note that issues with the security, bug, and severity::4 labels are considered Low severity vulnerabilities and will be handled according to the standard vulnerability triage process.

~“security request”

The security team may also apply ~internal customer to issue as an indication that the feature is being requested by the security team to meet additional customer requirements, compliance or operational needs in support of brmbl.io

Transferring from Security to Engineering

The security engineer must:

• Mention the product manager for scheduling, such as @pm for scheduling.
• The engineering team lead should be @ mentioned and followed up with when necessary as noted below for different severity levels.

The product manager will assign a Milestone that has been assigned a due date to communicate when work will be assigned to engineers. The Due date field, severity label, and priority label on the issue should not be changed by PMs, as these labels are intended to provide accurate metrics on ~security issues, and are assigned by the security team. Any blockers, technical or organizational, that prevents ~security issues from being addressed as our top priority should be escalated up the appropriate management chains.

Note that issues are not scheduled for a particular release unless the team leads add them to a release milestone and they are assigned to a developer.

Issues with an severity::1 or severity::2 rating should be immediately brought to the attention of the relevant engineering team leads and product managers by tagging them in the issue and/or escalating via chat and email if they are unresponsive.

Issues with an severity::1 rating have priority over all other issues and should be considered for a critical security release.

Issues with an severity::2 rating should be scheduled for the next scheduled security release, which may be days or weeks ahead depending on severity and other issues that are waiting for patches. An severity::2 rating is not a guarantee that a patch will be ready prior to the next security release, but that should be the goal.

Issues with an severity::3 rating have a lower sense of urgency and are assigned a target of the next minor version. If a low-risk or low-impact vulnerability is reported that would normally be rated severity::3 but the reporter has provided a 30 day time window (or less) for disclosure the issue may be escalated to ensure that it is patched before disclosure.

Security issue becoming irrelevant due to unrelated code changes

It is possible that a ~security issue becomes irrelevant after it was initially triaged, but before a patch was implemented. For example, the vulnerable functionality was removed or significantly changed resulting in the vulnerability not being present anymore.

If an engineer notices that an issue has become irrelevant, he should @-mention the person that triaged the issue to confirm that the vulnerability is not present anymore.

Internal Application Security Reviews

For systems built (or significantly modified) by Departments that house customer and other sensitive data, the Security application security reviews to ensure the systems are hardened. Security reviews aim to help reduce vulnerabilities and to create a more secure product.

When to request a security review?

1. If your changes are processing, storing, or transferring any kind of RED or ORANGE data, it should be reviewed by the security team.
2. If your changes involve implementing, utilizing, or is otherwise related to any type of authentication, authorization, or session handling mechanism, it should be reviewed by the security team.
3. If your changes have a goal which requires a cryptographic function such as: confidentiality, integrity, authentication, or non-repudiation, it should be reviewed by the security team.

How to request a security review?

There are two ways to request a security review depending on how significant the changes are. It is divided between individual merge requests and larger scale initiatives.

Individual merge requests or issues

Loop in the application security team by /cc @brmbl-io/security/appsec in your merge request or issue.

These reviews are intended to be faster, more lightweight, and have a lower barrier of entry.

Larger scale initiatives

To get started, create an issue in the security tracker using the Security Review template. The complete process can be found at here.

Some use cases of this are for epics, milestones, reviewing for a common security weakness in the entire codebase, or larger features.

Is security approval required to progress?

No, code changes do not require security approval to progress. Non-blocking reviews enables the freedom for our code to keep shipping fast, and it closer aligns with our values of iteration and efficiency. They operate more as guardrails instead of a gate.

What should I provide when requesting a security review?

To help speed up a review, it’s recommended to provide any or all of the following:

• The background and context of the changes being made.
• Any documentation or diagrams which help provide a clear understanding its purpose and use cases.
• The type of data it’s processing or storing.
• The security requirements for the data.
• Your security concerns and a worst case scenario that could happen.
• A test environment.

What does the security process look like?

The current process for larger scale internal application security reviews be found here

My changes have been reviewed by security, so is my project now secure?

Security reviews are not proof or certification that the code changes are secure. They are best effort, and additional vulnerabilities may exist after a review.

It’s important to note here that application security reviews are not a one-and-done, but can be ongoing as the application under review evolves.

Vulnerability Reports

Bramble receives vulnerability reports by various pathways, including:

• security@brmbl.io
• Reports or questions come in from customers through Intercom.
• Issues reported by automated security scanning tools

For any reported vulnerability:

• Open a confidential issue in the appropriate issue tracker as soon as a report is verified. If the vulnerability was reported via a public issue, make the issue confidential. If triage is delayed due to team availability, the delay should be communicated.
• An initial determination should be made as to severity and impact. Never dismiss a security report outright. Instead, follow up with the reporter, asking clarifying questions.
• For next steps, see the process as it is detailed below, and adhere to the guidelines there for vulnerabilities reported in other ways as well in terms of frequency of communication and so forth.
• Remember to prepare patches, blog posts, email templates, etc. on dev or in other non-public ways even if there is a reason to believe that the vulnerability is already out in the public domain (e.g. the original report was made in a public issue that was later made confidential).

Handling Disruptive Researcher Activity

Even though many of our 3rd-party dependencies, and the static about.brmbl.io,www.brmbl.io and blog.brmbl.io sites are listed explicitly as out of scope, they are sometimes targeted by researchers. This results in disruption to normal Bramble operations. In these cases, if a valid email can be associated with the activity, a warning such as the following should be sent to the researcher using an official channel of communication such as Intercom.

Dear Security Researcher,

The system that you are accessing is currently out-of-scope for our bounty
program, or has resulted in activity that is disruptive to normal Bramble
operations. Reports resulting from this activity may be disqualified from
receiving a paid bounty. Continued access to this system causing disruption to
Bramble operations, as described in policy under "Rules of Engagement,
Testing, and Proof-of-concepts", may result in additional restrictions on
participation in our program:

Activity that is disruptive to Bramble operations will result in account bans
and disqualification of the report.

Please contact us at security@brmbl.io with any questions.

Best Regards,

Security Team | Bramble
security@brmbl.io
https://www.brmbl.io/handbook/engineering/security/

Vulnerability Management

Vulnerability Management is the recurring process of identifying, classifying, prioritizing, mitigating, and remediating vulnerabilities. This overview will focus on infrastructure vulnerabilities and the operational vulnerability management process. This process is designed to provide insight into our environments, leverage Bramble for vulnerability workflows, promote healthy patch management among other preventative best-practices, and remediate risk; all with the end goal to better secure our environments.

To achieve these goals, we’ve partnered with Snyk and have deployed their software-as-a-service (SaaS) solution, as our vulnerability scanner. Snyk allows us to focus on what is important; scanning for vulnerabilities, analyzing, and ingesting vulnerability data into Bramble as the starting point for our vulnerability management process. For more information, please visit the vulnerability management overview.

Annual 3rd-Party Security Testing

Along with the internal security testing done by the Security team, Bramble annually contracts a 3rd-party penetration test of our infrastructure. For more information on the goals of these exercises, please see our Penetration Testing Policy.

The following process is followed for these annual tests:

1. Application Security specialists will partner with the Security Operations specialists and other relevant teams to define the scope of the test.
2. The Infrastructure team will be notified in accordance with their procedures
3. The Security team will manage the relationship with the 3rd-party vendor. Included in this role will be communicating the chosen scope and soliciting feedback.
4. Based on feedback from all parties, testing dates will be defined and communicated to teams for appropriate actions.
5. Testing will be done by the 3rd-party vendor and the results communicated to Bramble.
6. The Security team will triage the findings and create issues in accordance with the Issue Triage process.