Sean Cassidy: Head of Security at Asana, Crafting Security Excellence

0:00 Jon McLachlan

Hey, everyone, and welcome to another episode of the Security Podcast in Silicon Valley. I'm here today with a very special guest, Sean Cassidy, the head of security at Asana. He brings with him a lot of great experience going back in time. He was previously the head of information security at Patreon. Before then, he was the CTO of DefenseStorm, and he actually came up through the engineering [ranks]. And so he was a senior software engineer at Limelight Networks. Before then, an embedded software engineer at, help me pronounce this one, Sean.

0:36 Sean Cassidy

Leuze. Leuze.

0:38 Jon McLachlan

Leuze Electronic.

0:39 Sean Cassidy

That's right.

0:40 Jon McLachlan

And before then, Cisco Systems, the software development engineer. Welcome to the show, Sean.

0:46 Sean Cassidy

Thanks for having me.

0:48 Jon McLachlan

A lot of our listeners love to hear stories from what drove us into security. Sometimes that goes back to something from our childhood. Sometimes it's something we noticed when we started off our professional career. Maybe you'd be willing to share how you got into security.

1:05 Sean Cassidy

So I was definitely interested in computers from a pretty young age. I built my family's first computer when I was eight or nine years old, and quickly got into programming soon after that. I remember in seventh grade buying a C programming book and learning C, which I was just completely self-taught. And then in high school, a few of my friends were very interested in hacking, like [HackThisSite]-type hacking, which was a great site to learn this kind of stuff on. And [I had] a bunch of friends that way. And then in college, kind of continued. I joined the Information Security Club, and I really enjoyed, like, vulnerability research, exploit development. And, like, I remember going through all the PullThePlug challenges, and now it's called OverTheWire, but just, like, all the Vortex challenges were just so much fun, and I really got hooked. But then it wasn't until after my first job at Limelight, I was like, I actually found it a little hard to break into, like, the security industry proper. I found that a lot of companies wanted, like, a [lot of] security background, and just my expertise as a software engineer wasn't enough. And so I actually started my own security company. And that's how I was like, no, I'm really actually a security person here. I have my own security company, [and] prove it.

2:25 Jon McLachlan

No, that's awesome. I love that. So you're like, no, it's going to give me the opportunities. I'm going to create my own opportunities.

2:31 Sean Cassidy

Yeah, and that's something I've really always tried to do. I've always tried to think about how I can make my own luck in a way.

2:41 Jon McLachlan

And you were there at DefenseStorm for four years?

2:44 Sean Cassidy

That's right. Yeah, and that was cool, because it was just a combination of software engineering, my educational background, plus good information security. And the best part about that is I got to be part of many companies' incident response, because we're building a SIEM, lots of alerts, detection, logging, and as a result, lots of incidents, security incidents, data breach response. And so I was there for four and a half years, but I got, I don't know, maybe the equivalent of 10 years of incident response experience, because it was just drastically accelerated, how many interesting incidents we were a part of. And so I learned very quickly about what makes good incident response, what makes good detection, what makes good prevention, from the blue team side. So it was really invaluable experience. I really couldn't have gotten in any other way.

3:36 Jon McLachlan

And so who did you, who was your primary customer, your target market, back in your startup days?

3:42 Sean Cassidy

We were focused on banks and credit unions. And so DefenseStorm's actually still a company, and they're still focused on this market. And they really are unique in a way, because they have pretty mature security programs, but they tend not to have lots of engineers in all their security teams, who like to buy solutions like DefenseStorm did. And we had a kind of an all-in-one, like, send us all of your data type thing, and we will detect the suspicious activity on your data. And it worked out quite well, actually. I'm [super] proud of [the product we built].

4:17 Jon McLachlan

That's amazing. I can hear the pride in your voice. And it's always a great sense of accomplishment, not only to create your own opportunities, [but] be smashingly successful in the process. So, well played. And now, today, your career has taken you all the way up as head of security at Asana.

4:38 Sean Cassidy

That's right. Yeah, so I joined Asana about two and a half years ago as their first head of security. And our security team just had a tremendous amount of growth in this time. And we've really matured our security program a whole lot as the company's grown. We have all the security teams you'd expect, like application security and product security, and our detection response team. It was really fun to be able to build out this entire security organization from the ground up.

5:08 Jon McLachlan

Yeah, I could imagine. You brought it all the way from zero all the way up to 25, huh?

5:13 Sean Cassidy

That's right. [Also, quite a lot of hiring.] Most of my day is spent interviewing and hiring people.

5:19 Jon McLachlan

It must be difficult to find good folks in this job market, too. I hear that there's a real shortage.

5:26 Sean Cassidy

There is a big shortage. And so we try to be opportunistic in some ways. So we'll hire software engineers who are interested in security, and then put them through a boot camp and teach them everything they need to know about security. We also will hire security engineers who are maybe a little less on the software engineering side and do the same thing, because we're just trying to be opportunistic and trying to get good people who are interested in career growth. And we've had great success on both fronts. Also, it's good to leverage internal transfers, because our security team does a lot of good work. And so our team's quite popular internally. So we've had several people successfully transfer onto our team, which has helped our hiring process.

6:13 Jon McLachlan

Yeah, I imagine. And then when you get internal folks, they bring with them all of the context around how different services work, and it can really accelerate some of the things.

6:22 Sean Cassidy

And they also tell you very interesting things, like, oh, did you know that feature risk assessment that you asked people to fill out? Sometimes we don't fill it out. It's, oh, wow, I'm glad you've told me this. And you get, like, that real talk that you don't get, that if you ask for feedback on a survey or something, you tend not to get that kind of thing. But when you have people join your team, there's a slightly different air to it. Oh, wow, this process wasn't working for us, and now we can change it and make it better.

6:48 Jon McLachlan

Yeah. And at the core of all that is a strong sense of honesty and trust that it sounds like you've built right into that security team.

6:56 Sean Cassidy

Yeah. In this way, I'm a little lucky about Asana's culture, which is a very high-trust culture, actually, probably the most of any company I've ever worked at. And really, the way that works is by giving people lots of responsibility and autonomy. And if you give somebody lots of responsibility and autonomy, what they end up doing is typically exceeding your expectations, because they don't want to lose the trust you've placed in them. And so the same thing is true of our security team. So, for example, if security team tells the product team, hey, you need to fix this, almost every single time it's, yes, let's just fix it, because if the security team's telling us to do it, it is there, it is important. But as a security practitioner, you have to be a little worried about that sometimes, because what if we cry wolf a little bit? What if we lose this trust that we've built up, because it's so valuable to us? So something that's on my mind: like, how do we maintain this high degree of trust as we scale our organization?

7:55 Jon McLachlan

I guess it, it's a balancing act a little bit. When you think about your time there at Asana, and you've been there for well over two years, over two and a half years, it looks like, can you think back to maybe, and put your finger on the best day that you've had in your journey there so far?

8:15 Sean Cassidy

Yeah. So I'd say my best day was actually somewhat recently. This happened around the Log4Shell vulnerability. We, Thursday night, we started working on the Log4Shell vulnerability. But by Friday, we realized that, like, this was going to be an industry-defining moment. And I [thought I] was very lucky in a way, [that] we didn't use Log4j very much at all. We used one minor system that never touched customer data, and it had no access to the internet. So we were very lucky. But still, we had a lot of vendors who used it, and we needed to mobilize a lot of people. And I just sent out a message that was very, very quick to engineering, like, saying, hey, if the security team asks for your help today, please drop everything and just help us. And I got a message from a few of my fellow engineering leaders. And I didn't read the messages, because I was sort of busy in meetings and whatnot. And when I came back to them, I had that dread of, oh, like, I'm worried that, like, what if they say, you know, we have important stuff too, and you can't just rip people from my projects, because that's, like, what I was worried about them saying. And what they ended up saying is, Sean, do you have everything you need? Can I, can my team help? And it was just such an amazing show of support and camaraderie that it took this very stressful incident at any company and just turned it into something that was very supportive and welcoming. And so I super appreciate the folks that sent me those messages. And it made me feel like it wasn't just the security team versus the rest of the company. We were all in this together.

9:51 Jon McLachlan

Yeah, that's a great feeling, that we're all in the same boat together at the end of the day, even if there's a little bit of tension sometimes between security teams and engineering teams, that when the stock goes up, everyone is a winner. And you don't [unclear], like, everyone is a winner. So how about the worst day? Was there a day at Asana that you felt had some hard lessons learned?

10:14 Sean Cassidy

Yeah, so I'm thinking of maybe two different ones. So one was, I, I was working with a peer of mine on a, on a tricky project, and I interpreted what he said in a very, I was very suspicious of his, like, motives. I'm like, why are you saying this to me? And I don't understand. And I took it to mean something that it didn't mean. And his feedback to me was, hey, I, he also was confused and didn't understand. And I ended up, like, needing to step away. And I was like, what? Like, why am I feeling this way? And it turned out I was just very stressed. And what I had done is, usually for work, I allocate time on my calendar for focus work. And it's very important to me to keep up on what the industry is doing, and to read, and have time to reflect. And I had stopped doing this. I had stopped doing this because I had to temporarily manage another team. And I realized I didn't have this kind of key stress relief and key bit of flex in my day. And as a result, I had built up a lot of this [interest]. I didn't realize. And so it was causing me to, like, misjudge things. Like, I misjudged this comment, [and now I realize it's a] totally innocent kind of comment. And so now I'm much better about making sure I have focus time, making sure I have, like, flex in my schedule. And when I see, I use my Google Calendar, like, meeting load, to determine this. And if I don't have enough flex in there, I'm like, oh, this is going to put my overall job success in jeopardy if I don't lower my meeting load, which is also why it's very important to hire good leaders onto your team and to delegate work to them, because if you try to do everything yourself, you're just going to burn out very quickly. And the other one was, I gave somebody feedback recently, and I broke a rule that I have, which is, if I'm ever going to give somebody constructive feedback, I write it down first, and then I deliver it verbally. And I didn't deliver it verbally. I just gave them the written feedback. And as a result, it was very easy to misinterpret what I had said. And I also did not have the opportunity to adjust the feedback based on the conversation I had. And it didn't have a great outcome. It didn't have the outcome I wanted. And I felt really bad about this, because it was such a good opportunity to give this person some feedback. It helps them grow. And instead, it just had the result of me needing to put my foot in my mouth and just be like, sorry about this. This isn't how I wanted it to come across. And it really reinforced the lesson that I had, honestly, already learned, which is, constructive criticism is usually, almost always, best delivered in person, and followed up with written, and not the other way around.

13:08 Jon McLachlan

Constructive feedback can be, it is one of those tough ones.

13:11 Sean Cassidy

Yeah, this is something that I've definitely had the chance of getting wrong before. This is, like, this is a lesson I've learned again and again, apparently. And it's very easy just to do, because you got a lot of stuff to do in your day, you got 12 different things to do. I'll just write up this feedback, send it to the person, on to the next thing. But it turns out feedback is one of those, like, really important things that, if done well, is career-enabling. It could be career-defining for somebody. It can also define your relationship, drastically improve it. And done poorly, it could be the end of your relationship. So you need to really treat it with the deference it deserves. And my process is the feedback. And if you can't write it down, you shouldn't ever just go off the, [go off the cuff], like, just [wing it]. You got to write it first, because if you can't order your thoughts in that way, you're probably going to be rambling, and [rambling] does not help. So instead, write it down, then deliver it verbally, read off your notes, and then deliver the written feedback. But it's also good to adjust it as the person is saying it, because oftentimes you won't have the full picture. Oh, I thought you should have handled this project differently. And then they're like, oh, did you know there was this requirement that made me not able to do that? And, oh, I actually didn't know. So my feedback is, I have to adjust it. So it's super important to modify your feedback too. And that's that. As long as I follow that process, that's worked out really well for me.

14:36 Jon McLachlan

Yeah, no, that sounds like a great process for that. When I have to give constructive feedback, and I use this rule of three, it's always, it has to be something that's timely, so you have to catch something quickly. It has to be specific, so it has to be about a specific incident or event. And then it also has to be prescriptive: how could they handle the situation better? And, of course, delivered in private. If it misses any one of those three pieces, then it's, you know, it's a lost opportunity, basically.

15:08 Sean Cassidy

I completely agree. Another framework I've used that you might find useful is COIN. So it's context: you got to give the context of the situation, like, we were in a meeting together and the meeting was important. Then the observation of, you interrupted so-and-so. The impact: that person then didn't contribute to the meeting. And then the N is next steps, where you're talking about, okay, I want you to think about your place in the meeting and make sure you're encouraging others to talk. And by laying it out in that way, too, it nails most of what you had said, which is, like, specific and actionable, because it's very about, here is what was going on, here's what you did, the impact that it had, and here's what you should do next time.

15:54 Jon McLachlan

COIN, I'm going to remember that, because that's a lot easier than timely, prescriptive, and specific.

15:59 Sean Cassidy

I like the timely. Like, how do I include timely into COIN? Because COIN is a lot less useful if you wait six months to deliver that feedback.

16:08 Jon McLachlan

Yeah, yeah, it's basically worthless if it's, you talk about the ancient history. People are like, oh, what are you bringing that up for? Or they won't remember it, like, just legitimately have forgotten. And that's sometimes, like, one of the frustrating points of a performance review, because they happen at most every six months or so.

16:27 Sean Cassidy

That's right. So it's, so something I think about performance reviews is sometimes managers go pretty far into the, oh, feedback shouldn't be a surprise, which I, of course, agree with. Agree. But, yeah. So sometimes what is surprising during performance reviews is the patterns you spot. It's, okay, I gave you this kind of point feedback over the past six months, but I didn't realize until preparing your performance review that this is actually kind of a pattern of behavior. And, you know, let's figure this out. And so it's okay to have some surprises on your performance review. It shouldn't be completely known in advance. It should instead be an opportunity to take a step back, look at a higher level of your performance and your feedback. And that's what I like to use those for.

17:15 Jon McLachlan

I've always had the pleasure of managing, or the privilege, I should say, I've always had the privilege to manage very strong product security teams or architecture teams, where the vast majority of all of that feedback is very positive. And actually, one of the great joys of being a manager, people leader, whatever you want to call it, is you get to see people progress in their careers.

17:40 Sean Cassidy

It's one of the absolutely most valuable, important parts of my job, is to see people do better. And so something that I feel is important, and I, this is another part, one lesson, is reminding folks of how much they've improved and grown over time is really important. Do you remember two years ago when you found it hard to lead a meeting, and we were talking about this? And now you led this really complicated, stressful meeting with just apparent [ease]. Like, it's so, this is such a great growth for you. And just to see how much they've grown is, it's both very valuable and very motivating. And you can remind people, like, hey, you've come so far.

18:19 Jon McLachlan

Definitely. And then mix that with just a pinch of self-compassion, and you can shake all of the imposter syndrome, especially from the newer team members.

18:28 Sean Cassidy

If I could convince people that they deserve to be here, and they're important and smart, I wish I could, because imposter syndrome is, like, a scourge in the human psyche. I wish it didn't exist.

18:42 Jon McLachlan

I mean, I think we're, at the end of the day, we hold ourselves to impossible standards sometimes. And just a little bit of self-compassion is all we really need.

18:53 Sean Cassidy

You're absolutely right. I remember a friend of mine saying to me, because I was sharing something that was going on in my life and then beating myself up a little bit for it, and he said to me, imagine if I had the same problem. What would you say to me? And I was like, oh,

19:06 Jon McLachlan

I love this sort of perspective.

19:09 Sean Cassidy

Right? Yeah. It's so good. What would you say to me? I'm like, oh, well, and he's like, how would you feel for me? I'm like, I feel bad for you. I feel sorry. This is a really tough situation. And he's like, why don't you, like, have some self-compassion? Like, why don't you treat yourself in the same way? Like, you're going through something that's really tough. So that's okay. It's okay that you feel this way. And I was like, I have, it was like a mind-exploding moment for me. Yeah. Wow. I had never even thought of doing this before. So, yeah, I totally agree. Self-compassion is extremely important.

19:41 Jon McLachlan

That sounds like you have some amazing friends in your life.

19:46 Sean Cassidy

I am very, I am very lucky to have a great many compassionate and kind friends.

19:52 Jon McLachlan

I'm very happy for you.

19:54 Sean Cassidy

This is important.

19:56 Jon McLachlan

But going back to Asana, real quick, if you fast-forward into the future, and you look at that future, what do you think success really looks like for Asana? And I guess the quick follow-up is, how do you see security playing a role, and how Asana will get there?

20:14 Sean Cassidy

So we want people to effectively run their company using Asana as their work management platform. And to do that, people need to trust that Asana is going to safeguard their data. I view it in a similar way of AWS, right? Imagine if AWS had a reputation for not being secure. People would build their infrastructure atop somewhere else. The same thing is true of this emerging category of work management. I think it's, like, almost the infrastructure for how people are interacting with each other and assigning each other work and doing things. So it's this absolutely foundational role that can't be skipped. It's extremely important. Security is the enabler of us getting there. If we don't do a good job, people won't run their businesses [on top of] Asana, and we will be less, significantly less successful. And specifically for our security program, I like to really take a kind of an incremental and cyclical view of how we should improve security. Like, we should, like, one of my favorite quotes is about how the measure of progress is if you have a different set of problems from year to year. Maybe John Foster Dulles said that. And I really like that idea. As long as we're getting new problems, we're solving old problems, and we'll always have problems, we'll always have new struggles to deal with. I think that's a very nice mark of progress, that we'll be really able to say, okay, you know what? It turns out, like, phishing, okay, good, we're pretty convinced we solved that problem. Moving on to the next one. What about application security risks? What about database security risks? What about insider threats? As long as we're shifting that over time, I feel pretty good about the progress of our security program. But I also really like just very tactical measures here, like hiring red teams, number of findings, how quickly they were to get to certain objectives, improving it. Like, our new detection and response team, we're going to embed the red team within that team. And we have a tight feedback loop here of, okay, did we find the red team? Did the alert fire? Did we action it? [No.] If yes, great. If not, no, improve. And we can get really great metrics around this, around time to detect, false positive rate. And that's really how I treat it. Like, we should also treat that as an optimization problem. So you have to look at it from the high level, okay, let's take a super long-term view, but also low level. Like, how are these specific metrics doing? Are we improving on them over time?

22:51 Jon McLachlan

No, I love that, how you've constructed feedback loops between your red team and your detection and response team. And it produces not just something that you can measure, but it produces literally the next step towards a better future. And you're always solving problems, like you mentioned. And that's the first time that I've heard anyone describe the rate of change of problems that you're dealing with as a measure of success. And I really see it, because there's always, you're right, there's always going to be something that needs a bit of love, that needs to be fixed, that needs to be addressed. Sometimes that can be a strategic thing, sometimes that's a tactical thing, but there's always going to be a thing in the security [world].

23:34 Sean Cassidy

Yeah. And sometimes security people get down about this. I talk to them, and they're like, there's just always tech debt to solve. There's just always people who are saying no to fixing security problems. And I just can't come to work and deal with that all day. And I'm like, sure. Like, I totally understand that perspective. But the way I think about it is, there's always [a next], because we, security is unique in a way, if we have an adversary. And because that adversary is always growing and evolving, we will always have to continue to do this. We'll never have perfect security. We'll always have problems being found by people trying to exploit those problems. But that's really inspiring to me. It's not like someone who's working for, like, an NFL team is like, oh, we just can't be the best football team and then be done with it. It's like, no, well, those teams are trying to get better too. And I look at that as inspiring, and a way to focus on self-improvement and team improvement. And it's important to not get into that cycle of despair where, oh, we can't fix anything, because we can't fix everything, we can't fix anything. Incremental improvement is extremely important to success here.

24:43 Jon McLachlan

So important. In fact, what I like to say all of the time, what I'm always catching myself saying, is, I always talk about small, imperfect, good changes towards a North Star, or a better future. We can acknowledge that there's still works to do, but we can acknowledge also, and celebrate, the victories that we take along the way to get there.

25:07 Sean Cassidy

That's right. That's, the celebration is really important. Like, we just did our, maybe two months ago, we did our end-of-year wrap-up celebration. And it was really good just to talk about, wow, we didn't have this the previous year, I [got] this new. And even one quarter later, sometimes you forget all of the work you've done. So celebrating your wins is extremely important. Celebrating all of your successful incident response actions, celebrating your tabletops, even. Hey, this is important work. Extremely important to morale and to your own [self-worth].

25:43 Jon McLachlan

Tell me about your favorite interview question. What about it makes it your favorite? And what do you look for in interviews when you're looking to build out your team?

25:53 Sean Cassidy

Yeah, so my favorite interview question is really just, tell me about your time something went wrong and what you did about it. And for managers, it's usually, they answer something like, oh, such person [unclear]. Engineers sometimes tell me about, like, the time the site went down, or security people tell me about a good incident. And usually, when you ask about things that have gone wrong, it's extremely interesting, because you get a good sense for how they view their role. And there's, like, multiple avenues somebody can go down. They can go down the hero path of, oh, I'm great, I solve the day, here, I'm the hero, which is good. I'm glad that people solve these things. Heroing has a dark side of, maybe you don't do a great job at documenting what you're doing, or you always need to be in this role, because that's [unclear]. Like, how do you delegate? Can you delegate this? Can you make sure this doesn't happen again? I don't want you to always be the linchpin in any single event, right? Or they might go on the kind of [blaming] side, like, oh, because such-and-such team, you know, never invests in their tech, this. Or they might go another route of, they think that their company didn't invest in this, or they might think of how they were the ones who are, I've been saying this for years, we should fix this, and finally, it came to pass. All those guys find a lot of very interesting things that people wouldn't normally tell you about. You can get to that question quite easily. And it's so open-ended, it allows them to show you what they, also what they think is, like, something going wrong. Because [for somebody who's an] incident responder, an incident is not something going wrong. It's literally every day, this is what we do. So, like, for them, what's something going wrong might be, like, the head of security coming in and interrupting and asking questions, or maybe the legal coming in saying, oh, everything is privileged, now we're going to shut this all down, you can't talk to each other. Those are very interesting. Yeah, those are very painful, interesting incidents when things went wrong. And so my favorite answers to these questions are ones that show me a lot of self-reflection and self-growth, because it's very easy for you to be the hero, or for you to always be right, but it's hard for you to be like, and here's what I did wrong, and here's what I learned, and this is a painful lesson for me, but I'm glad I learned it. And those are usually the people that end up doing very well [in] interviews, that [have] a lot of self-reflection, have a lot of, like, self-growth, and how do you think about that.

28:25 Jon McLachlan

Yeah, it goes back to mindset, right? Like, how do you face challenges? How do you see challenges? Are you compassionate with yourself when you're in a challenging situation? Do you ask for help?

28:36 Sean Cassidy

Are you self-aware enough to see your own limitations and to know what they are? Because if you can't see your own limitations, you can't [grow]. So you need to know what you're good at, what you're not good at. You need a clear sense of this. And that question gets at all of those things. And also, the question sometimes goes into a deeply technical area, too, which we can also explore, right? Like, oh, the databases are working well, and the indices are doing this. And so, cool, I'm interested to talk about this too. So it's a very flexible question, and it allows me to get to what I want to very quickly.

29:06 Jon McLachlan

Yeah, that's very nice. And it works across the board. It's a universal question. And so when you're building teams, what types of teams do you build?

29:15 Sean Cassidy

I think of a team as really, like, the fundamental unit of work is not a person, it's a team. So I think of what kind of work I want accomplished, and then think about how to build people around that. So sometimes I like to say, okay, let's start with a problem we have, and we can figure out what team to build around that. So sometimes people like to build teams around, like, skills or expertise, but I really like to build it around, like, a team's initiative, what we're going to fix and solve, and the concrete problem that we'll have if we don't build this team. So here's an example from [Asana]. We had one team that we called [product security], and this team had two very distinct jobs. One job was to build frameworks for product engineers to use in a more secure way, like, if they built our [OAuth] framework, for instance. And they built that because the previous [OAuth] framework that we used for open source was riddled with security bugs and very hard to use. We built our own, very secure. But also this team had another job, of finding and building solutions that found bugs in our source code. And these two things were very different from one another, and it was hard to prioritize against. And the problems that this team was solving was, like, two different problems. It's, let's prevent engineers from making these mistakes in the first place, but also, like, we need to surface these bugs and bug classes. And they were really just lumped together because of shared expertise, like, they're the similar expertise. But they found it really hard to prioritize this work one for another. So what we did is we split this team into two. And these two teams now are able to focus on this, their specific problem. One team's problem is, we need to ship fewer bugs, and they're going to build tools and frameworks to make that happen. And the other team is, we need to find the bugs that we're pretty sure are there already. How do we find these bugs? And now these two teams could prioritize independently. And even though they're, you know, a little smaller than the team was, they're able to focus on this. One thing I like about both of these teams is they have the same North Star metric, actually, which is number of P0 vulnerabilities found, and they're trying to drive the metric in opposite directions. And I think that's fun and clever, because what product security is trying to do is just reduce the [unclear], let's reduce this, let's ship fewer of them. And the other team, the AppSec team, is trying to find more of them and try to drive that number up. But it's cool seeing how these teams, and you have to make sure you're not, like, giving promos or bonuses based on a metric that teams are driving in opposite directions. It's really just an interesting data point of, where is this metric going? Are we staffed, are we staffed too heavily on the AppSec side, or vice versa? And I, I really like that way we've [played that].

32:10 Jon McLachlan

No, that's really nice. So how do you, it sounds like there's some strong metrics, and sort of gives you a bit of visibility into what's going on organizationally, but on the softer side of the house, like, culturally speaking, what sort of culture do you see driving your top-performing security teams? I guess they're all, like, very high-performance security teams, but what sort of culture do you associate with that high performance?

32:37 Sean Cassidy

Really, my favorite thing here to say is, really, it's humbleness, because when we've been the most successful, we've approached other teams with asks, and we've been very specific about, hey, [busy], you know, we are smart, capable people, we want to add this to your roadmap. And that's always had a really great result. And when we've come from a more, hey, we know best, you need to do this, we don't care what else is on your plate, we haven't had as much success, even though we might be right in that case, if we actually think this is a huge risk. But just that approach drastically has different outcomes. And that's really the thing I care about the most: [outcomes, full stop], right? I want the best security outcomes for Asana, to make us a successful business. Really focusing on the outcome is important. And to do that, I think you need to make sure you approach other teams the right way. You need to be humble, and you need to make sure [unclear].

33:39 Jon McLachlan

Yeah, I love that. So, not being prescriptive, letting the other team continue with a strong sense of ownership over their projects, over their deliverables, over their services.

33:51 Sean Cassidy

Very few people want to ship an insecure product. If you ask them, hey, hey, would you love to ship all these major security vulnerabilities? No, that doesn't sound like something I want to do. And so if you give them the information, they tend to do the right thing. Does it always happen? Sure, there are some edge cases where it doesn't happen. But usually those people are thinking very short term. And then if you ask them to reflect, like, okay, are you going to feel, like, how are you going to feel in two years about this, if this goes sideways? That's usually a good way to help them think long term.

34:24 Jon McLachlan

Right. You can drive an entire conversation just with humble questions.

34:30 Sean Cassidy

Right, exactly. And just that, that's exactly what I like to do. I like to ask questions like, oh, okay, you think this isn't the most important thing? Why? Tell me about your thinking. Oh, you have a big marketing moment coming up. Tell me about how much you prepared for it. Tell me about what's going on here. And just by being open and curious here, not only do you learn a lot, but usually you find something else out of [it]. Oh, okay, you have this big marketing moment, but literally the sprint after it is, you're free, and we're able to do something there. So maybe we can do something to mitigate this, but in the meantime, wait for that sprint, and then we can get it going.

35:05 Jon McLachlan

Yeah, I love it. It goes with, just generally, in my career, I've noticed that there's two types of security people in the world. There's a type where, if you walk into a meeting room, now that COVID is pretty much over, we can meet in person again. So you walk into a meeting room, and everyone else in the room, maybe they're from engineering, maybe if they're from legal, or from customer service side of the house, if they [sigh] and they go, oh, no, so-and-so is here, they're going to extend the dates, and they're going to ask us to do all of these things, and they're going to put all these demands on the table and tell us, no, we can't [build] it this way. You have a reputation, and it's not super productive. Like, the mindset is of an adversary, not as a team player. But then there's another type of security person, where they enter the room, and everyone that's already there is, oh, yes, oh, good, [so-and-so's] here. They can help us build it securely and still move quickly, and help us solve all of these challenges that we're going to be facing, and help us think through and understand, like, what's in the threat model, what's out of the threat model, so we can still ship quickly.

36:10 Sean Cassidy

Yeah, I like that. I like that way of framing it. So a quote that I'm reminded of is by [Geoff Belknap], [CSO at] LinkedIn. He phrased it this way, about, good security is solving technical problems, but great security is about solving business problems. And so that's what your business cares about. It's about, what are these business problems? And so, sure, you could argue about these technical details and how you have to get this fixed, but at the end of the day, you had, your business has these problems. How are you going to do it? And great security really solves and helps solve these business problems. I really like that way of thinking about it.

36:43 Jon McLachlan

Yeah, for sure. And I strived very hard to be that second type of security person, just to reinforce, like, those relationships, and be team player, someone that is on board with the business, to move fast, ship cool products, change the world while you're doing it.

37:02 Sean Cassidy

Absolutely.

37:03 Jon McLachlan

So I know that we have a lot of entrepreneurs that actually listen to this podcast. So I'm going to ask a question on their behalf, and feel free to take it wherever you'd like. But if there were one tool or service that you wish someone would just build already, what do you think that would be? And would you use it at Asana?

37:25 Sean Cassidy

Yeah, I'm just trying to think of the things that, the problems that we're faced with right now. So, like, one problem that I'm thinking about is how easy it is for internal folks to either be bribed, tricked, or some kind of insider threat, to use internal tools against the company. It's happened to Okta, [it's happened] to other companies recently. It's happened to Twitter.

37:51 Jon McLachlan

Yes, yes, it did just happen to Okta.

37:54 Sean Cassidy

Famously. And Okta has a great security program. So if, if, if Okta finds it challenging to deal with, other people will do it.

38:02 Jon McLachlan

Absolutely.

38:03 Sean Cassidy

And so the natural solutions to this of, oh, get Chromebooks or something. Like, Chromebooks have a pretty, like, negative, like, view among this. So I actually brought this up to our customer service people, like, hey, how would you all feel if we gave you all Chromebooks? And we're like, and we feel like second-class citizens, right? Everybody else in the company has these great MacBooks that are super powered, and I have an underpowered Chromebook. And I'm like, but at the same time, it's really tricky, because I don't know, will our support people or contractors install remote access things because somebody pays them to do it, or because they're tricked into doing it? I don't know. And it's been happening to several things recently. So here, okay, the problem I want solved is, I want it to be hard for my customer support agents to be tricked into installing things that can take over the computer. They [should] be able to download and install AnyDesk. So there's some things out there that do this, right? Application allowlisting is a thing. And, but, it's tricky to roll out. There's, there's Santa, but it's challenging. And so when we look at it, we're like, wow, like, the amount of engineering effort that we're going to have to spend is quite large to have this happen. And same with rolling out Chromebooks, like, it's quite large. So I wish somebody would help me with this problem. And I don't have a great solution for it yet. So if you are working on this problem, or [somebody who] is, I'd love to [talk to] them.

39:33 Jon McLachlan

All right. All you entrepreneurs out there looking for great ideas, there's a market opportunity right there. With that, I'm going to thank you, Sean, for joining me on an episode of the Security Podcast in Silicon Valley. It was a great pleasure to have you on the show.

39:49 Sean Cassidy

Yeah, thank you, [unclear].

39:51 Jon McLachlan

Would you like to leave any of our listeners with parting words of wisdom?

39:56 Sean Cassidy

I would be remiss if I didn't say Asana Security was hiring. asana.com/jobs. We're hiring. We're a great crew. Consider applying to one of our many open roles.

40:05 Jon McLachlan

There we go. So if you've been in the industry a long time, or if you're even just looking to get into security, it sounds like Sean and his security team there at Asana have great opportunities, open and available. So go check them out. And, go ahead, Sean.

40:23 Sean Cassidy

I was just going to say, thanks again for having me.

40:25 Jon McLachlan

No, thanks for joining, Sean. Until next time, I'm your host, Jon McLachlan, and stay tuned for another episode of the Security Podcast in Silicon Valley. Thanks, everyone.