How Asana uses Asana: Security incident response

Typically, security teams coordinate security incident response with a few tools, such as text chat, video chat, collaborative documents, and so on. Asana’s Security team, unsurprisingly, uses Asana for most everything, including for incident response! We developed a Security Incident Response Project Template* to manage and track this work end-to-end with our global team. Read on for six ways that using this template has helped us collaborate better to run more effective security incident response.

1. Knowing who is doing what, by when

Nearly everyone who has been part of a security incident has had the experience of not knowing the status of either a specific task, the entire incident, or even where to start. We wanted to make sure that was not the case here.

We set up our project template to make incident roles explicit by having a section at the top of our project called Roles. This section defines who is responsible for which roles in our incident response process. If anyone is unsure of who is responsible, or who is working with us from cross-functional teams like Legal or Communications, they can use this section of the project to find out. It’s also handy for long-running incidents when people need to rotate off of the incident.

Note: All project images in this post are examples. They are not actual projects and tasks used by our Security team.

Even though these roles are Asana tasks, we’re using them as reference tasks in this case and don’t complete them until the incident is completely done. At Asana, we often use tasks this way to document responsibilities.

We also keep track of what we need to do with an Emergency Mitigations section, which has assignees and due dates. It’s clear what has and has not been done. Any member of the incident response team is allowed to submit proposed migitations. For complex incidents, we often use automation to assign newly proposed mitigations to the Incident Response Coordinator for approval.

2. Asking questions without interruption

One of the biggest sources of frustration in any complex incident is when stakeholders ask questions while the rest of the team is trying to remediate as soon as possible. These questions can feel like interruptions, but many times, the questions they ask are important!

To mitigate these interruptions, we have a section in our project template for Investigative Q&A. Anyone from the incident response coordinator, to stakeholders, to team members, etc. can add questions as tasks in this section. The questions are there waiting for us to answer when we can, and sometimes, we mark questions as dependent on other questions or remediation work. This makes it clear what steps we need to take to answer the question and when the question will be answered.

3. Tracking approvals

Sometimes in incident response, we need to make tough calls, like disabling key functionality, notifying affected customers, or spending a significant amount of money on something. Other times, we only need to make sure the message we’re sending is accurate.

We track these decisions through Asana’s approval tasks. One common pattern we use is having a parent task with a message or decision with subtasks for approvals. Key decision makers can approve, request changes, or reject approval tasks.

If someone rejects or requests changes, we revisit the proposal and try to adapt it to best fit the situation.

4. Clear status updates

For significant incidents, there are usually many people who care about staying informed on progress. We use status updates in our project to keep all of our stakeholders in the know about our security incident so they do not have to follow along with the minutia within the project.

If stakeholders have questions, they can either post a comment on the status update, or ask them in the Q&A section of the project.

By using status updates, we also have an easy way to see the history of an incident. We can use that information in a five whys process reflecting on something that may have gone wrong, and for auditing purposes.

We hold ourselves accountable to posting periodic status updates for incidents, and even have internal KRs (key results) set to keep us consistent in posting these updates.

5. Assigning action items

One of the most commonly missed parts of incident response is the follow-up action items. Once an incident is closed, responders quickly lose context if action items are not addressed. After the incident is over, it’s important to keep track of how you ensure that you improve your security posture. If you don’t, you risk having the same security incident again and again.

We use multi-homing to keep track of important action items. Multi-homing means that the same task is stored in more than one project. When the task is edited or changes in any way, it is automatically reflected in every project that task is in. Each remediation item goes in a team’s backlog. If the same remediation item shows up in multiple incident projects, then we know we need to fix it ASAP!

Any task that is added to the Long-term Mitigations section is automatically multi-homed into another project called Security Incident Action Items. A best practice is to routinely monitor this backlog to prioritize high impact action items out of security incidents. We use a custom Asana bot that routinely bumps action items for prioritization and timely response.

6. Running multiple incidents at once

We use a primary security incident portfolio that stores all of our security incident projects. This way, we can keep track of multiple incidents at once. We label these with a custom field for Severity to sort these projects so we can make sure we pay the most attention to SEV0 incidents.

We make regular portfolio status updates about our security incident metrics and for high level updates and insights.

Better collaboration to improve security incident response

Using Asana to manage security incident response has made a significant improvement in how we collaborate by getting us into one centralized place and out of chat, video calls, and collaborative documents. It enables us to work seamlessly with our teammates around the globe to not only to understand who is doing what by when, but also to keep our stakeholders up-to-date.

What do you think? How do you coordinate security incident response at your company?

*The original design of this project template was deeply inspired by Ryan McGeehan’s breach response agenda blog post. Thanks, Ryan! Our roles were inspired by PagerDuty’s incident commander framework.