Meet our Security team

Welcome to our new Meet the Team series, where we interview a member of one of our Engineering teams to learn more about what that team does and how.

In this post, we sat down with our Head of Security, Sean Cassidy. Sean is the interface between the rest of the company and Security, and between Asana’s customers and Security. Read on to learn how the Security team keeps our customers’ data secure, what technologies they use, and why they love their dumpster fire candle — in Sean’s words!

What does the Security team do at Asana? 

The Security team is responsible for keeping Asana and our customers secure. This includes finding and remediating vulnerabilities in Asana or our AWS infrastructure, detecting and containing adversarial activity, and responding to security incidents. We work very closely with the Infrastructure and IT teams because our cloud and corporate infrastructure are critical to Asana’s security.

An oft-repeated phrase at Asana is Security, Availability, Performance, Features, which is how we think of tradeoffs. Security is first because without keeping the data safe that our customers have entrusted to us, it doesn’t matter what features we have. This buy-in from the rest of the company helps our team scale way beyond what we could do without their help.

What is the team’s favorite thing about building Asana? 

There is a lot of “work about work” typical of other security teams, like meetings, compliance, and keeping stakeholders up-to-date. By helping to build Asana, the team can focus on what the Security team does best (managing risk!), rather than getting bogged down in meetings or updates.

We also use Asana super heavily internally in Security, which makes it way easier to be informed of decisions and kept up-to-date. It’s fun to use your own product so heavily and see its improvements from month to month.

What technology do you use in your day-to-day? How does the Security team choose the technology it works with? 

We use Scala and Node to build Asana, and we use those and Python internally to write our own security tools (with a bit of Rust, too). We’re huge users of AWS and we leverage a lot of their infrastructure to design our security from the ground up. 

At Asana, we think carefully about adding new technology to our stack. It should solve a new need rather than just be a new and interesting tool. In Security, we’re very cognizant of this philosophy as we’ve developed expertise in some toolchains and the added cost of new tools.

What’s something the Security team has launched recently that you’re particularly proud of? 

We’ve implemented MFA for SSH using the secure enclave built in to our Macbooks. This provides not only MFA but proof of presence, which is a stronger security guarantee. By adding a second factor for SSH in the secure enclave, we’ve made sure that key compromise is much less likely, and that certain kinds of endpoint compromises are much more difficult to exploit.

How do you use Asana as an engineer? Any tips?

There are two main things that come to mind when I think about how the Security team uses Asana: 

1. We set up each of our OKRs as a project and post a status update it once per sprint. If it’s At Risk or Off Track, we make some tasks to either try to bring it back on track or inform stakeholders that we’ll miss. This way we don’t get bugged for updates.

2. Also, our risk registry is in Asana! We keep it really low level (for instance, what if an attacker uses “PassRole + RunInstances” to escalate AWS privileges) so it’s useful. We keep it up to date and use it as part of our planning process to focus on the highest impact risks.

If you want to try using Asana on your Security team, I’d recommend a few things:

• Make one project per system, add new tasks that represent risks, and use custom fields to represent the confidence you have in your security controls. Use the project status update feature to inform stakeholders about your progress against your risks

• Put your vulnerability management findings as new tasks into an Asana project. You can triage them via a custom field or sections. We use a custom field for both CVSS scores and our own judgements of likelihood and impact. 

• Create a custom template for incident response. Ours has sections called Setup, for all tasks that have to happen to start an incident, another called Indicators of Compromise, which has one task per IoC, a questions and answers section for open questions, and mitigation sections. We typically multi-home mitigations into another Bugs project, vulnerability projects, or other team’s backlogs. We also use the project status update feature to inform stakeholders of our incident response. Here’s an example of one of our internal projects in Asana:

Tell us about some new members of the Security team!

I am the newest member of the Security team! I joined as the Head of Security a few months ago from Patreon where I also headed up Security. Before that, I co-founded a Security company called DefenseStorm. 

I like to focus on building a security-done-right culture at companies. Security-done-right culture means that security is part of all Engineering and Product teams, and we focus on teaching and leveling up the entire company rather than remaining in a silo. This helps the Security team to scale and focus on the most leveraged work we can do. 

Do you have any fun traditions on the team? What are they?

We have a new award for excellence in incident response: The dumpster fire candle! One member of our team recently did such a good job on an important incident that he really earned this award.

What makes you excited to be a part of the Asana Security team right now?

The Security team is so important to Asana, and we’re here to protect our customers. Scaling up the Security team as Asana grows in number of customers, amount of data stored, and number of employees is a great opportunity for the members of the team to develop their skills and grow as engineers.

We have a lot of fun challenges and there’s a huge opportunity to lead major security initiatives here. For instance, we’re launching a company-wide CTF this fall with the goal of educating our developers and employees on the best ways to keep Asana (and themselves) secure against attackers. That’s just one of the things I’m looking forward to as I hire more security engineers!

Want to work with Sean and the Security team at Asana? Check out our open roles and apply.