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

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 Defense Storm, 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. Litsa. Litsa.

Litsa Electronic. That's right. And before then, Cisco Systems, the software development engineer. Welcome to the show, Sean.

Thanks for having me. A lot of our listeners, they 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. 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 hacked sites 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 pull the plug challenges and now it's called Over the Wire. 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 the security industry proper.

I found that a lot of companies wanted like a 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 to prove it.

No, that's awesome. I love that. So you're like, no one's going to give me the opportunity, so I'm going to create my own opportunities. 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. And you were there at Defense Storm for four years. That's right.

Yeah. And that was cool because it was 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 were building a SIM, 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. And so who did you, who was your primary customer, your target market back in your startup days? We were focused on banks and credit unions.

And so Defense Storm is 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. So they like to buy solutions like Defense Storm 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 really proud of the product we built. That's amazing. I can hear the pride in your voice and that'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. 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.

Our section response team, it was really fun to be able to build out this like entire security organization from the ground up. Yeah, I could imagine. You brought it all the way from zero all the way up to 25, huh? That's right.

It's been a lot of hiring. Most of my day is spent interviewing and hiring people. It must be difficult to find good folks in this job market too. I hear that there's a real shortage.

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. Yeah. Also, it's good to leverage internal transfers because our security team does a lot of good work. And so our team is quite popular internally.

So we've had several people successfully transfer onto our team, which has helped our hiring process. 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. They also tell you very interesting things like, oh, did you know that feature risk assessment that you ask 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. 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. Yeah, in this way, I'm a little lucky about Asana's culture, which is a very high trust culture, actually probably the most I've 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 the 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 is 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 that's something that's on my mind, like how do we maintain this high degree of trust as we scale our organization? I guess it's a balancing act a little bit.

Yeah. 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? Yeah.

So I'd say my best day was actually somewhat recently. This happened around the Log4Shell vulnerability. Thursday night, we started working on the Log4Shell vulnerability, but by Friday, we realized that this was going to be an industry-defining moment. And Asana was very lucky in a way of 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, I'm worried that, like, what if they say, 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 at Asana 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. 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. in teams that when the stock goes up, everyone is a winner. When you don't get haps 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? Yeah, so I'm thinking of maybe two different ones. So one was I was working with a peer of mine 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 it on the 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. I misjudged this comment. It was now I realized it's totally innocent kind of comment.

And so now I'm much better about making sure I have focused 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, this is going to put my overall like 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, you know, 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 and help 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. Constructive feedback can be one of those tough ones.

Yeah, this is something that I've definitely had the chance of getting wrong before. I just like I said, this is a lesson I've learned again and again, apparently. And it's very easy just to do because you've 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.

It could drastically improve it. And done poorly, it could be the end of your relationship. So you need to really treat it with the depth the instance 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 here. Like just wing it. Yeah, 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 or 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. But and then they're like, oh, did you know there was this requirement that made me not able to do that? It's, 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. 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.

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 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 the what you had said, which is like specific and actionable because it's very about, here's what was going on. Here's what you did, the impact that it had, and here's what you should do next time.

Coin, I'm going to remember that because that's a lot easier than timely, prescriptive, and specific. I like the timely. How do I include timely into COIN? Because COIN is a lot less useful if you wait six months to deliver that feedback.

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. That's right. 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, you know, 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, like you said it complete. It should instead be an opportunity to take a step back and look at a higher level of your performance and your feedback. And that's what I like to use those for.

I've always had the pleasure of managing, 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 the 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. It's one of the absolutely most valuable, important parts of my job is seeing people do better.

And so something that I feel is important that 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 a pair of teammates? 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. 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. If I could convince people that they deserve to be here, they're important and smart, I wish I could because the imposter syndrome is like a scourge in the human psyche.

I wish it didn't exist. Yeah. 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.

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, I love this sort of perspective.

Right? Yeah. What would you say to me? I'm like, oh, well, 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 have some self-compassion and 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 never, it was like my, it was like a mind exploding moment for me. Wow, I had never even thought of doing this before.

So yeah, I totally agree. Self-compassion is extremely important. That sounds like you have some amazing friends in your life. I am very, I'm very lucky to have a great many compassionate and kind friends.

I'm very happy for you. This is important. But going back to Asana real quick. Yes.

If you fast forward. 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 in how Asana will get there? 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. And I view it in a similar way of AWS, right? Imagine if AWS had a reputation for not being secure, and people would build their infrastructure atop somewhere else. The same thing is true of this emerging category of work management.

So 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 and stop with Asana, and we will be 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 at the bar, 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 really 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 that we solved that problem. We'll be 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 bed the red team within that team and have a tight feedback loop here of, okay, did we find the red team? Did the alert fire? Did it action it?

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 a low level.

Like how are these specific metrics doing? Are we improving over time? No, I love that, how you've constructed feedback loops between your red team and your detection 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. 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, I totally understand that perspective. But the way I think about it is there's always an X because 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, people trying to exploit those problems. But that's a really inspiring to me. It's not like someone who's working for like an NFL team is like, 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. So important. In fact, what I like to say all of the time and 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 work to do, but we can acknowledge also and celebrate the victories that we take along the way to get there.

That's right. Celebration is really important. Like we just did our, maybe two months ago, we did our end of year wrap-up celebration. 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, we didn't get this.

This is important work. Extremely important to morale and to your own self-worth. And 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? 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 and such person don't leave. 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 could go down. They could go down the hero path of, oh, I'm great. I solved the day here.

I am 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 how you get it. 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 invested 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 were, I've been saying this for years, we should fix this.

And finally it came to pass. All those guys, they find a lot of very interesting things that people wouldn't normally tell you about. You can lead it 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 somebody's job is an incident responder and an incident, it's 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, you know, interrupting and asking questions or maybe legal coming in and 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 the days 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 a lot of self-reflection have looked like self-growth and how they think about them. 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? 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 database isn't working on the indices. We're doing this. It's like, oh, 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. 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? I think of a team as really like the fundamentally needed work is not a person, the team. So I think of what kind of work I want to accomplish and then think about how to build people around that. So sometimes I like to say, okay, let's start with the 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 mission, 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 a song. We had one team that we called Products Theory. And this team had two very distinct big jobs.

One job was to build frameworks for product engineers to use in a more secure way, like they built our OWL framework, for instance. And they built that because the previous OWL framework that we had used as open source was riddled with security bugs and very hard to use. So we built our own, very secure. But also this team had another job of finding and building solutions that like 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 solved in 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 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 they're already. How do we find these bugs? And now these two teams can 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, 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, build the OWL framework, 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 trying to drive that number up.

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 too heavily on the AppSec side or vice versa? And I really like that way we've put it back in.

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, do you, what sort of culture do you see driving your top performing security teams? I guess they're all like very high performing security teams, but what sort of culture do you associate with that high performance? 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 like 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 is outcomes, not being right. I want the best security outcome for a SADA to make 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 and you need to be humble to make sure you're assuming more than you, what you really know. Yeah, I love that. So not being prescriptive, letting the other team take, continue with a strong sense of ownership over their projects, over their deliverables, over their services. Very few people want to ship an insecure product.

If you ask them, 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, it's 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.

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

And just that, that's exactly what I like to, 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 all applying here. And just by being open and curious here, not only do you learn a lot, but usually you find something else out. 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. We can mitigate this, but in the meantime, wait for that sprint and then we can get it going. 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 like, oh yes, oh good, was 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 front model, what's out of the front model so we can still ship quickly. Yeah, I like that. I like that way of framing it. So the quote that I'm reminded of is by Jeff Belknap, the CISO of LinkedIn.

He phrased it this way about good security is solving technical problems, but great security is about solving business problems. And see, that's what your business cares about. So what are these business problems? And so sure, you can argue about these technical details and how you have to get this fixed, but at the end of the day, you have 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. Yeah, for sure.

And I strive very hard to be that second type of security person, just to reinforce like positive relationships and be a team player, someone that is on board with the business to move fast, ship cool products, change the world while you're doing it. Absolutely. 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 would 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? 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 do we see interns for internal folks to either be bribed, tricked, or some kind of insider threat event to use internal tools against the company.

This happened to Okta. This happened to other companies recently. This happened to Twitter. Yes, yes, it did just happen to Okta recently.

And Okta has a great security program. So if Okta finds it challenging to deal with other people. Absolutely. And so the natural solutions to this of, oh, get Chromebooks or something.

Like Chromebooks have a pretty negative view among this. So I actually brought this up to our customer service people and I'm 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 of these 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 then take over their computer.

Like they should be able to download and install any desk. So there's some things out there that do this, right? Application allow listings that they, and, but it's tricky to roll out. 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 see, even 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 you have one to tell me. 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.

Yeah, thank you for having me. Would you like to leave any of our listeners with the parting words of wisdom? I would be remiss if I didn't say Asana Security was hiring. We're hiring.

We're a great crew. Consider applying to one of our many open roles. 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. I was just gonna say thanks again for having me. No, thanks for joining, Sean. Until next time, I'm your host, John McLaughlin, and stay tuned for another episode of The Security Podcast in Silicon Valley.

Thanks, everyone.