Bramble takes the security of our clients’ information extremely seriously. In keeping with Bramble’s value of transparency we believe in communicating about security incidents clearly and promptly.

This communication response plan maps out the who, what, when, and how of Bramble in notifying and engaging with internal stakeholders and external customers on security incidents. This plan of action covers the strategy and approach for security events which have a ‘high’ or greater impact.

Process for infrastructure incident response

For Infrastructure incidents, please follow the infrastructure incident management and communication process.

What is an incident?

The Bramble Security team identifies security incidents as any violation, or threat of violation, of Bramble security, acceptable use or other relevant policies. You can learn more about how we identify incidents in the Bramble security incident response guide.

Defining the scope/severity of an incident

The Security Engineer On-Call will determine the scope, severity and potential impact of the security incident. Once the potential impact has been determined, implementation of the appropriate internal and external communications strategy should begin.

Roles and responsibilities

Security team roles and responsibilities

Security Engineer on Call (SEOC): This is the on-call Security Operations Engineer. The individual is the first to act, validate, and begin the process of determining severity and scope.

Security Incident Manager on Call (SIMOC): This is a Security Engineering Manager who is engaged when incident resolution requires coordination across multiple parties. The SIMOC is the tactical leader of the incident response team, typically not engaged to perform technical work. The SIMOC assembles the incident team by engaging individuals with the skills, access, and information required to resolve the incident. The focus of the SIMOC is to keep the incident moving towards resolution, keeping stakeholders informed and performing CMOC duties.

Communications Manager on Call (CMOC): This is the Security Incident Manager On-Call (SIMOC) or Security Assurance Engineer who will coordinate external communications efforts according to this security incident response plan and liaise across the extended Bramble teams to ensure all parties are activated, updated and aligned.

Security External Communications: this function partners with and advises incident response teams in reviewing and improving messaging for external audiences (including customers, media, broader industry). This role laises with marketing teams for any necessary reviews or messaging deployment. This function should be engaged once first draft content has been developed using the Security incident external response issue template.

More about the CMOC responsibilities

As security practitioners and incident response engineers, our security assurance and security operations teams and engineers are best positioned to develop initial messaging and serve in the CMOC/Communications manager on call role.

Each team-appointed CMOC is the DRI for:

  • Opening the Security incident external response issue template and tagging in potential stakeholders and contributors
  • Drafting the initial message(s)
  • Tracking development and deployment of the various content and
  • Identifying key stakeholders for contribution, review and approval (support, security/SIRT leadership, legal, etc)
  • Routing and securing approvals from various parties (support, security/SIRT leadership, legal, etc)
  • Keeping stakeholders updated and informed on the progress of communications development in the related incident response slack channel and issue(s)

More about the Security External Communications function responsibilities

The Security External Communications function is the DRI for:

  • Editing and improving first drafts provided by CMOC
  • Advising on appropriate channels and forms of communication needed
  • Acting as an approval point on final messaging to ensure it’s ready for external use
  • Liaising with corporate communications for additional reviews and/or messaging needs (public/media statements)
  • Deploying the messaging via collaboration with our Content Marketing (blog post) and Marketing Operations teams (email response)
  • Posting final communications materials to slack channel #customer-support for awareness and use.
    • Support manager on call will manage support team awareness

Extended team roles, responsibilities and points of contact

Communicating internally

Security incidents can be high-pressure, high-stress situations. Everyone is anxious to understand the details around the investigation, scope, mitigation and more. Ensuring that stakeholders across security, infrastructure, engineering and operations teams are informed and engaged is one of the chief responsibilities of the Security Incident Manager On Call. The Security Incident Manager should focus on providing high-level status updates without delving too deeply into the technical details of the incident, including:

  • Current Risk
  • Users Impacted (some, many, all?)
  • Services Impacted (production, enterprise apps, other)
  • Timeline of events
  • Mitigation steps that have been taken
  • Current status of the incident
  • Next steps

Communicating with Bramble team members

Any time there is a service disruption for team members, the CMOC should post details regarding the disruption and related issue(s) in #incident-management, and cross-post in any related channels. It is important to identify if this is a production incident affecting brmbl.io or a service used by the organization.

Incident response channel on Slack

In the cases of incidents that are on-going and require constant communication the Security Engineer on Call will set up an incident response Slack channel. All security incident team members and extended POCs should be invited. If the nature of the incident allows, the Slack channel will be public to Bramble and a link to this channel will also be shared in #team-security Slack channel to increase visibility.

Engaging key internal stakeholders (when/how)

Group & Contacts When to Engage DRI to Engage At what Cadence In what Channel
Director of Security Operations For S1 incidents immediately upon determination of the S1 severity rating SIMOC/CMOC 30 minute intervals (unless otherwise requested) In incident response Slack channel
VP of Security For S1 incidents immediately upon determination of the S1 severity rating Director of Security Operations 30 minute intervals (unless otherwise requested) Slack direct message
Broader e-group Immediately in cases of a data breach or an RCE with evidence of exploitation VP of Security 30 minute intervals (unless otherwise requested) #e-group Slack channel
Sr. Director of Corporate Marketing and Director of Corporate Communications Immediately, if the incident has been publicly reported or if there is a regulatory requirement to make an announcement. In other cases, once the full impact and associated risk has been determined. SIMOC/CMOC Continuous In incident response Slack channel
Legal If Bramble if the security incident includes a data breach including but not limited to:
Exposure of PII / Personal Data
Private Projects
Financial Information
VP of Security Continuous incident response Slack channel

Communicating externally

External communications should happen as soon as possible after the scope and impact of the security incident is determined, using concise and clear language. The first external communications are directed to affected parties. Examples include: Affected customers and third parties, providers of products, services or organizations involved in the supply chain for system components as related to the incident. Regulatory authorities are contacted based on incident scope, regulatory and legal requirements.

Turnaround on customer messaging

Once it has been determined that external response is needed, the SIRT team should develop, gain approval on a final customer communication and distribute and/or publish within 24 hours.

Communications channels and forms

The communications channels and forms that should be used in an incident or event can vary but should align with our need to be responsive to our customers and our transparency value, and be balanced with the potential risk and exposure to customers.

Commonly used forms and channels of communication:

  • Our most common form of customer response is via direct email communications to affected customers.
  • When a deeper dive response is needed, or to ensure broader coverage on a security incident or event, a blog post may be developed on an urgent basis.
  • See deeper dive explanations on forms and channels for consideration

Helpful templates and runbooks

Preparing and enabling external facing teams

It is important to keep in mind, any time we are communicating externally, we need to advise our support, customer, social and community relations teams that we’ll be making external communication about an issue that affects customers and/or the community.

For this reason, each incident response (direct email, media statement, blog post, etc) should have accompanying:

  • Social media statement
  • FAQs for our Support and customer-facing teams

On-going, live incidents on Brmbl.io

For on-going, live site incidents on Brmbl.io, updates are provided by the SIMOC/CMOC through our status site to http://status.brmbl.io/ .

External statements and other public, official communications

Depending on scope, impact or risk associated with the incident, our Marketing team may determine that additional outreach is necessary. Any official statements about the security incident would be made by Bramble’s CEO, COO or VP of Marketing.

Process for security incident response, external communications

  1. Once we’ve determined that we need to make an external statement or communicate with customers in some way, open a new issue using the Security incident external response issue templateThis issue will be used by the SIMOC/CMOC to track content development, reviews and approvals.
  2. The new security incident external response issue should be assigned to the CMOC
  3. Once all the actions under the “CMOC actions to take upon opening this issue” section are completed and a first draft(s) is/are in place, tag @lee into the issue for first review and consult on communications forms/channels (more details below).
    • For urgent issues/incidents, tag @lee in slack.

Communications review, approval and deployment process

  1. Once a draft is ready, the CMOC should tag @lee in the related security incident external response issue for first round review and edits.
  2. In parallel, our Security External Communications function will engage the appropriate marketing teams for support (Marketing Ops, Content teams) and begin creating the related issues for parallel marketing support and message deployment efforts.
  3. When this first round of review and edits are complete, the CMOC should route the communication doc to the assigned On-call Support Managerand Security External Communications (second round review) for their collaboration and review.
  4. Once all feedback and edits have been synthesized by the CMOC, they should move the draft communication(s) on for further review by any other stakeholders and/or Security leadership for review. This review and their approval(s) should be documented in the associated security incident external response issue.
  5. The Security External Communications function should be tagged in to conduct a third/final review in parallel with the CMOC to ensure the communication(s) are ready for distribution.
  6. When the communication(s) is/are final, Security External Communications will work with the appropriate marketing and communications teams to deploy the communications to the appropriate external and internal audiences.
  7. Security External Communications will ensure all final materials and associated deployment details are noted in the related communications issue and close the issue.

Other helpful information

Reference information

Potential channels for use in a security incident

Communications Channels Purpose/Message Additional Details
Incident Response Customer Email Provides incident background, response, potential, impact, follow-up actions, and who to contact with questions. Drafted by SIMOC/CMOC and reviewed by DRIs from Support, Legal, External Comms and Security. Sent from security@brmbl.io with reply to security@brmbl.io. Should be in plain text with no link tracking.
Mitigation and response blog post Details the background, Bramble response and any action required by our customers. If it is determined that a longer, more-in-depth response is needed (i.e. a blog post), the team will follow the Marketing rapid response process in which the VP of Corporate Marketing is engaged immediately (via slack or text) and proposes the path forward. This includes determining the appropriate channel, response and timing and engaging the appropriate resources across marketing and corporate to collaborate, review and/or be advised of the response (corporate communications, content, community and legal teams). Content for the blog post is provided by the SIMOC/CMOC, the content team performs copy edits and the corporate communications and legal teams review and approve message. Once the message is approved, the Content team will merge the blog post. Note: collaboration and work on the response blog post should happen in the related incident response channel on slack.
Bramble Security Release Alert/Email Indicates required action for customers and links to related mitigation and response blog. Email sent to all Bramble customer nominated points of contact.
Customer Frequently Asked Questions (FAQs) List of early customer questions and responses, or probable questions and responses. Created by SIMOC/CMOC and Support DRI. Provided to appropriate Support group.
Social media post For distribution of related blog post, details our response to X issue. Security External Communications engages @community-team in the incident response Slack channel. Provides Community Expert(s) with tweet text and blog link. Bramble social media team should also be alerted for ongoing awareness and monitoring, using @social in slack.

Sync meetings to develop and review customer communications

When appropriate, key stakeholders for contribution, review and approval should meet synchronously in a Zoom session to create and fine-tune customer communications (emails, FAQs, blog post, etc). Meeting synchronously in this case allows us to expedite the development of communications with key inputs from stakeholders in security, customer support and beyond and quickly move into the review stage.

Process flow for incident response communications

The chart below illustrates the process flow between incident and impact investigation and the communications decisions and actions needed: