Jason Chan, ex-Netflix, and the trusted contractor | The Tabletop

Follow The Tabletop on YouTube or wherever you get your podcasts.

‍

Episode description

What do you do when an attacker doesn’t break into your network, but simply walks in by turning your own multi-factor authentication against you? In this episode of The Tabletop, Jason Chan takes the hot seat and works the problem in real time.

‍

Jason spent over a decade building and leading Netflix’s information security team, an organization that became as well known for giving back to the security community as it was for protecting one of the world’s most-watched platforms: 30-plus open source releases, a long run of conference talks, and a genuine belief that a rising tide lifts all boats. Before Netflix, he ran security at VMware and cut his teeth in consulting. If anyone knows what a real incident looks like from the inside, it’s him.

‍

In this episode, host Khush Kashyap drops Jason into the following scenario: He’s roleplaying the CISO at Clustrd, a 30,000-person tech company with a 107-person security team. Mid-afternoon on a Thursday, a marketing employee sends him a screenshot. Someone has posted in a company-wide Slack channel, 800 members strong, claiming they have access to Clustrd’s internal systems, with a shot of the admin dashboard as proof. The monitoring stack shows zero alerts. The access logs tell a different story: a contractor account, logged in through a legitimate remote-access tool, session still live. The way in wasn’t an exploit or malware, just an attacker spamming the contractor with MFA prompts until fatigue did the rest. Across escalating injects, the intruder moves laterally through a forgotten production script with hard-coded credentials and no owner, and Jason has to scope a breach he cannot fully see.

‍

Jason walks through out-of-band communications when your own Slack is compromised, the cost-benefit of watching a live intruder versus cutting the session, the security archeology of tracing an unowned script, and the quiet regulatory risk of logs that were never retained. Along the way, he makes the case that the real work - the trust with engineering, the identity hygiene, the discipline not to overload users until they reflexively click approve - happens long before the incident does. At the end, he renders his verdict: real incident or constructed fiction?

‍

Time stamps

[00:00] Welcome to The Tabletop: Meet Jason Chan and Today's Scenario

[01:01] The Rules: CISO at Clustrd, a 30,000-Person Company with a 107-Person Security Team

[01:31] Inject One: A Slack Post Claims Access to Clustrd's Internal Systems

[03:07] They Didn't Break In, They Walked In: MFA Fatigue and the Contractor Account

[07:56] The Attacker Wants You to Know: Going Public in Your Own Slack

[08:40] Forced Choice: Coordinating a Response When Slack Is Compromised

[08:40] Building a War Room You Can Actually Trust

[09:53] Inject Two: A Forgotten Production Script with Hard-Coded Credentials

[10:06] Two Fires at Once: A Live Session and an Unknown Blast Radius

[14:23] Inject Three: A Reporter Calls and the Clock Goes Public

[15:19] Scoping a Breach Without Evidence: Four Services You Can't Account For

[16:40] Accessed or Compromised? Why the Distinction Matters

[20:02] Two Weeks Later: The One Decision That Set Clustrd on This Path

[20:46] The Moment of Truth: Real Incident or Fiction?

[21:18] Off the Table: The Control Employees Treat as a Formality

[23:13] The Lesson the Industry Still Hasn't Absorbed

[25:28] Security for AI, AI for Security: What Jason Watches Now

‍

Transcript

Khush Kashyap: Today on the Tabletop, our guest will role-play as the CISO of a company experiencing an incident. In this incident, an attacker bombarded a contractor with MFA push notifications until the fatigue did the work for him. Jason Chan spent over a decade building and leading Netflix's information security team, an organization that became as well known for giving back to the security community as it was for protecting one of the world's most watched platforms.

‍

30-plus open source releases, a parade of conference talks, and a genuine belief that a rising tide lifts all boats. Before Netflix, he ran security at VMware and cut his teeth in consulting. But today, [00:01:00] Jason in the hot seat playing CISO at Clustered. Jason, thank you so much for joining us. 

‍

‍Jason Chan: Thank you for having me.

‍

Khush Kashyap: So the rules: Jason Chan is now a CISO at Clustered, a 30,000 people globally recognized tech company with a security team of 107 people. A scenario will unfold with multiple injects. Jason will give his live reaction, and at the end, he'll decide real incident or a fake one. Are you ready for the tabletop?

‍

Jason Chan: Let's do it.

‍

Khush Kashyap: Inject one. It's mid-afternoon on a Thursday. An employee in your marketing department sends you a direct message with a screenshot. Someone has posted in a company-wide Slack channel, a channel with over 800 members, claiming they have access to Clustered's internal systems. They have included what appears to be a screenshot of your internal admin dashboard as a proof. The post is 11 minutes old. It has 14 replies, most of them from confused employees asking if it's a joke Jason, what are your initial thoughts? 

‍

Jason Chan: Oh, it's gonna be a long day. Um, my initial thoughts would be if it's in an internal system, that I would want to, uh, make my initial communications outside of that system if I feel like the attacker or adversary may have compromised that system.

‍

So I would probably, uh, want to get somebody on the phone, I would want to get to somebody's desk or some sort of out-of-band communication to, to spin up an investigation in an incident. 

‍

Khush Kashyap: So let's say you pull up your security monitoring dashboard, zero alerts, no anomaly flags, no triggered rules. You check the access logs manually.

‍

There it is, a contractor account logged in to two hours ago via a legitimate remote access tool. The session is still active. Here's how they got in. The attacker spammed the contractor's phone with MFA push notifications [00:03:00] until they hit approve. No exploit, no malware, just per-persistence and a moment of fatigue. The attacker didn't break in, they basically walked in. A marketing employee found this before your security stack did. What does that tell you, and what do you do in the next 10 minutes?

‍

Jason Chan: What does that tell me? Yeah, I mean, that's... Yeah, to some degree, that's, uh, sort of human nature. Um, people just wanna get their job done, so if they feel like they're getting bothered by something legitimate, it's, it's reasonable to say okay.

‍

Um, it tells me that that user had its cr- his creden- his or her credentials taken, or his username and password, and then the attacker just wanted that final step to get in, which was the, the MFA code. Um, so yeah, there's something there in terms of how this person's credentials were compromised. Um, once that person's in, it would kind of explain why there are no alerts because the, the adversary used essentially legitimate authorized access to do unauthorized things.

‍

Uh, next 10 minutes or so, I'd pro... Yeah, I'd want to [00:04:00] be talking to my incident response team. Um, I'd wanna be talking to my, uh, legal counsel that's involved with security and privacy issues. Um, generally, you know, in those early stages of an incident that feels like it could be something, um, I wanna kinda spin up the, our normal process, which is going to involve those folks, gonna pull in the right folks who are on call, uh, and wanna give some sort of heads-up that, you know, we're, we're looking into it.

‍

'Cause a lot of t- a lot of what I'm trying to do when, when you're working on an incident is certainly you want to resolve it, you want to understand what's happening, but you also want to allow other folks to kinda continue their work and not be interrupted, and it sounds like there was already a little bit of churn if, if the message has gotten some replies.

‍

Khush Kashyap: Hmm. One thing I wanna go back to is the monitoring piece. So we saw that the monitoring didn't detect anything. You're now running an active incident response process with your team, but you don't know if your alerts are silent because nothing else is happening, or because your detection has a [00:05:00] blind spot you haven't found yet How does that uncertainty change how you respond?

‍

Jason Chan: Yeah, I mean, I would say to some degree, like troubleshooting things like detection pipelines and alerts is, uh, I, I... For me, I would, I would kinda put that in a parking lot. I'd be like, I certainly wanna understand, like, should we have seen this? I don't know if I'd wanna do that right away. Um, for something like this, where it's like, okay, well, we have an individual user that's been compromised, and they were kinda tricked into, uh, accepting the MFA, you know, I'd, I'd wanna understand, okay, so they posted this in, in Slack or whatever the internal chat is. I'd wanna understand what else has this user done during this session, and try to get some sense of how long has it been happening. 

‍

Khush Kashyap: Got it. Okay. So the session is still active, the attacker is still in. Do you kill it immediately, the session, or do you watch it for a few minutes to understand what they're doing?

‍

Jason Chan: Uh, generally, I mean, I think there's, there's... To me, there is some value in [00:06:00] letting it go. I would, I would probably let my IR team kind of make the call there. Um, I'd get a sense of... I'd first wanna understand, like, so they're logged into, uh, the network or the environment, what systems have been accessed, to kinda get a sense of, of before I made a call there.

‍

Khush Kashyap: What's the mental framework in deciding how long to let it go to just view what the adversary may be doing? 

‍

Jason Chan: Yeah, it's definitely, you know, it's a little bit of a cost-benefit analysis. You're trying to gather some information. I mean, certainly there, if the attacker has already posted something, then they're not really trying to be stealthy anymore, so they sort of know that, that they're, um, that they're understood.

‍

And, and part of what, what I would wanna do is, like, try to figure out how bad is this, how, how deep is, or how broad have they accessed the systems, accessed data, things like that. 

‍

Khush Kashyap: I wanna go back to the fact that they weren't trying to be stealthy, because they did post it on the Slack channel where 800 people saw the post.

‍

The attacker knows that you know [00:07:00] now. How does that change the dynamic, or does that make a factor into your mental model and how your incident response process works? 

‍

Jason Chan: It certainly would. I mean, I'm... I tend to be... I think like a lot of security people, you're always kinda thinking worst case scenario. So for me, if I, if I know an adversary has done something like this, I'm thinking this is probably, like, pretty significant in terms of, like, their level of access.

‍

So- From what I would assume or what I would believe is certainly possible is that they've had access for quite some time, and they've been able to sort of do their thing, and they've, um, they may have gained access to certain pieces of data that are sensitive. And, you know, once they have taken whatever they wanted or, or done with, then they sort of say, "Hey, FYI, I'm here."

‍

Um, so yeah, I mean, I would... My, my thought, my sort of general security brain would go to like, ooh, this is probably pretty bad. So yeah, that's kinda how I would go through thinking. 

‍

Khush Kashyap: So now there is a forced choice. Um, here's what I want to [00:08:00] know. The attacker is still in your systems. They can see everything you're doing in Slack right now.

‍

You mentioned something about going off-band communications. So how would you continue to coordinate your response? Will it be in the open? There is a risk of tipping them off. What would be off-band? What would be in the main systems? 

‍

Jason Chan: It's, that's a tough one. I would say I would not do it in Slack. I, I would do...

‍

If I, if I know that that's compromised, then I, I wouldn't do there. I would probably look at creating, uh, like a video conference, uh, you know, or a conference call where I can have a limited number of participants and sort of spin that up and kinda go from there. 

‍

Khush Kashyap: Like a virtual war room? 

‍

Jason Chan: Yeah. I mean, that would be a fairly normal...I mean, I think a lot of teams, just because they're distributed, would tend to use something like Slack because it's, um, just a little bit easier to participate. But here, if we know that that medium is already compromised, then I would probably wanna go to a, like a video conference, something like that.

‍

Khush Kashyap: What are some of the best practices of out-of-the-box [00:09:00] communication look like in practice, which can be really useful in scenarios like these? 

‍

Jason Chan: Yeah, I think the best practice is that you have something that you can verify is not compromised, like quite easily. Uh, obviously that's gonna be more expensive. I mean, I remember way back when we used to have, you know, you'd have analog phone lines because you were, you know, if, if something went down.

‍

So ideally you want, if you're considering Slack or, you know, that is kinda like burned and that no longer trustworthy, then you want something that, I mean, ideally would use some other kind of authentication mechanism, so. 

‍

Khush Kashyap: Inject two. 40 minutes in, the attacker is still inside. While your team was scoping the contractor account, they found something else. He didn't stay in his lane. He moved using a script that's been running in production for years It has hard-coded credentials, never rotated, broad access to internal tooling. There's no owner. It's not present in the asset inventory either. Never been flagged. Now you have two problems: a live session you haven't killed yet, and an unknown blast radius from credentials that have been sitting unguarded for years. How do you triage both at once, and where do you even start on figuring out what that script touched?

‍

Jason Chan: Ooh, geez. That, that would never happen in real life, a script that no one owns. Um, yeah, I would want somebody on the technical invi- investigation team to sort of track that down to figure out, um... You, you mentioned there's not an owner, but, like, what is... Like, just read the code. Like, what is this thing doing?

‍

What is its purpose? 'Cause I wouldn't want to just necessarily rotate those credentials, stop that if it's running some critical business process. 'Cause we're always, in these scenarios, we're trying to balance, uh, you know, risk with benefit. Um, so yeah, I would have somebody try to figure out what's the nature, this, on this sort of intention of the script, and then, um, assuming we have some logs, I would s- wanna see, okay, what were these credentials [00:11:00] used that are...

‍

'Cause it's, if it's been running for a long time, then I should have some logs of this being used. I would wanna see what changed. When did it change? So what has this credential set been accessing that it doesn't normally? 

‍

Khush Kashyap: So what I'm hearing is in your triage, you would definitely prioritize understanding the ownership of the script and what business operations repercussions it might have.

‍

Jason Chan: Yeah, yeah. So the ownership is always important. I think that that's kind of one of the main tasks of a security team is to sort of stitch things together. Like, where does this code sit and who owns it, who runs it, what business process is it associated with? So yeah, I think cultivating that is super important.

‍

I'd wanna understand, like, how, how big of a deal is it going to be if all of a sudden we ro- rotated those credentials or stopped that script from executing on whatever its normal schedule was. 

‍

Khush Kashyap: So the credentials in that script could have been used before today. How do you determine whether this is the first time they have been, been exploited or whether someone else found them months ago?

‍

Jason Chan: I mean, I would want to see... I mean, my sense is if this thing's been there for a while, and it's been running for a while, then it's [00:12:00] probably... I wouldn't say, I wouldn't just default to thinking that it's legitimate, but that it's been running, so I would wanna see, you know, what is its normal access. Like, when does it happen?

‍

What systems does it log into? Um, my sense is that you'd probably be able to have a pretty reasonable baseline of what normal would look like, and then you sort of go back as far as you can just to sort of make sure that that's true. 

‍

Khush Kashyap: Hmm. Now, imagine when you are in your triage, your, your team is trying to find out the ownership for the script, what business operations repercussions will it have, what are some of those dependency graphs in it. If they're not able to come up with something, and they're not able to identify an owner, the answer is silence. What do you do then? 

‍

Jason Chan: If we felt like a reasonable amount of time had passed and we couldn't track that down, then i- if we have verification that that credential set has been used by this adversary to access other systems, then I think it's reasonable- 

‍

Khush Kashyap: Hmm

‍

Jason Chan: to start thinking about changing it. I would certainly wanna make sure, like, the SRE team is aware, being like, "Hey, we're going to make this change. It may have some, some level of impact, but we think that there's sufficient value in doing so." 

‍

Khush Kashyap: That makes sense. And it's a company with 30,000 people. They should have robust programs and robust SREs taking care of some of the more critical pieces of internal tooling as well that- Yeah.

‍

Jason Chan: Just sort of like generally monitor- Yeah ... your, your metrics. Yeah. 

‍

Khush Kashyap: Got it. So if you can't safely kill the script without knowing what depends on it, and the person who built it may not be in the company anymore, do you shut it down blind and accept that you might break production, or do you leave a known compromised credential running while you try to map the dependencies? Like, sh- just walk us through your mental model. How would you think about it, and how would you coach and guide your team?

‍

Jason Chan: Yeah. I would be very, very skeptical that you couldn't get some information, just having been in security. I mean, archeology is kind of part of our jobs, is, like, figuring out what does this thing do.

‍

So if I... For example, if I look at the script and I see, okay, well, it's calling this endpoint, somebody is gonna know what that endpoint's for. I can look, okay, well, what is that, what [00:14:00] is that system doing? Um, what's, what systems does that talk to? So there's always a way to kind of figure it out. I tend to look at, like, you know, what endpoints are being calling, or being called, what IP addresses are involved, what host names, things like that.

‍

Like, usually, there's going to be something in there that will give you a clue. So I would be pretty skeptical- Hmm ... that you wouldn't be able to get some sort of, uh, information that would help you make your decision with a little more confidence. 

‍

Khush Kashyap: Inject three. So before our next inject, there is a twist. Uh-oh. A reporter just emailed asking about for your comment on the internal security incident at Clustered You know you have a clock now. Whatever decisions you make from here, you're making them knowing this could be public within the hour. So we wanna do a value straight off with you.

‍

Your team has map- mapped the blast radius of the hard-coded credentials. The script touched seven internal services. Three, you can account [00:15:00] for. You can see what was accessed and when. Four, you can't. Um, logs either don't exist or weren't retained long enough. Legal wants a clear scope of notification. Your security team is telling you that line doesn't exist yet.

‍

How do you make a scoping decision when the evidence isn't there? And what do you do about the four services you simply cannot completely account for? 

‍

Jason Chan: So there's always the possibility that there's, this information is available external to the company, I mean, beyond just the adversary. So, uh, typically, I mean, there's a few things.

‍

I mean, I, we, we would certainly, in a, in a company this size, you'd have some sort of, um, integration with your, your PR team, your external communications, you, your legal team. So they would have this idea of, like, there's a holding statement, right? When there's some sort of investigation going on. So I would make sure that folks understood, you know, if you do get pressed by reporters, that we have a playbook for that.

‍

Um, doesn't mean you need to reveal anything. It says you're investigating, and, you know, more information will be forthcoming if it's, if it's required. On the sort of [00:16:00] missing logins, if there's these sort of, like, three or four... Again, I would wanna know, like, what's the nature of those four systems. If we, if we can't tell what happened, like what did this adversary do, we would at least know what those systems, uh, what sort of data they had access to, so we could understand, like, are we gonna have some sort of compliance issue?

‍

Are we gonna have... I think you mentioned notification issues, where there, there could potentially be some notification. Because whenever there's notification, there's always a timeline associated with that. Mm. Right? You have to let people know within a certain amount of time, so... 

‍

Khush Kashyap: Got it. Um, do you treat the unknown services as compromised by default, or do you wait for evidence before expanding your response on them?

‍

Jason Chan: Um, I would... I don't know that I would say they're compromised by default. I, I would s- certainly they would go into, you know, the, the bucket of investigation. Um, I wouldn't assume just because somebody had a login that that service is completely compromised. Now, the data may have been accessed inappropriately. The system may have been accessed inappropriately. But when I think compromised, I think, okay, that user, uh, or [00:17:00] that, that, uh, adversary has, has control over that system, and then could sort of leverage that control for, for further access. 

‍

Khush Kashyap: The people who build a script may still be at the company or may not be at the company. Would you want to bring the team members in, um, to reconstruct what it touched, knowing that the moment you do, every engineer, you know, in the office is watching to see whether this becomes a blame exercise or a learning one? How, how do you deal with the engineering sentiment in this? 

‍

Jason Chan: I mean, it's, it's always interesting. I think you wanna have as much context as possible to help your decision-making. I think a lot of that work is done Before an incident happens, right? If you haven't been able to establish trust with engineering teams and other teams, then you're going to be on the back foot to begin with. So assuming that we built that trust, I think it's reasonable.

‍

I would say, you know, in a security team this big, you know, with over 100 few people, I should... I, I would have folks that would be able to look at that code and understand without necessarily involving people. Because I think, you know, as I mentioned earlier, a lot of what you're trying to do is let the rest of the company function as close to normally as possible while an incident's happening.

‍

Could be because, you know, opportunity cost is one of these big things that we tend not to think about. So yeah, I mean, I wanna keep people focused on their jobs. So to the extent that I felt like it was really important, like there was something missing, some, some context missing, then I would potentially bring in folks. Um, but you know, you're trying... I wouldn't say you're necessarily trying to keep the circle small, but you're trying to, like, lower the churn. You don't want people who, you know, whose job is to be doing something else tied up with, with an investigation if they're not going to be materially beneficial to it.

‍

Khush Kashyap: That makes sense. I, I wanna go back to the absent logs a little bit and understand your mental framework and how you see it. Because at some point, the absent logs can become potentially a legal or a regulatory problem, not just a technical one. When does that clock start, and are you already on it? 

‍

Jason Chan: Yeah. I would say typically with an incident, right, [00:19:00] you're, you're having... You're, you're sort of running multiple streams, right? You're doing the technical investigation. You're handling communications, not, not just externally, but internally to the company, to executives, things like that. And you're also sort of keeping track of, like, oh, I really wish we would've had logs for this system.

‍

So I would have sort of put that in the parking lot, um, to recognize, like, hey, this, this, we felt like the investigation would've gone better if we had this. Let me understand more about why we don't have those logs. Um, was it a, um, some sort of decision, some sort of trade-off, or, you know, is it something that the adversary may have done, like gotten rid of logs?

‍

Khush Kashyap: Yeah. Does absence of logs, um, or absence of some controls ever become a regulatory challenge later when you look at incidents? 

‍

Jason Chan: Uh, it certainly can be. Yeah, it certainly can be. It's, uh, one of these things where, you know, compliance is te- tends to be, we think about it point in time, right? Yeah. When you get audited. And, well, when I get audited, I might show that those logs existed for the la- whatever that reporting period is, but that doesn't guarantee it going forward. So yeah, it certainly could.

‍

Khush Kashyap: Now let's fast-forward. Fast-forward two weeks, the attacker has been identified, the contractor account has been deprovisioned, the hard-coded credentials have been rotated, and a full audit of legacy script is underway. Looking back at the full arc, the MFA approval, the contractor access, the forgotten script, the public announcement inside your own tools, what was the single decision or non-decision that put Clustered on this path?

‍

Jason Chan: Decision or non-decision? I mean, to me, it's, it was certainly the... I mean, again, I'm not gonna, I'm not gonna blame the user, uh, blame the employee that, that clicked okay, or I would say it's, it's the internal posting. That's really when things start to accelerate. That's when the pulse starts to go up. 

‍

Khush Kashyap: So moment of truth, Jason, uh, based on everything you have just walked through, do you think this scenario is based on a real incident, or is it something completely fictional that we constructed?

‍

Jason Chan: Unfortunately, this is definitely based on a real incident.

‍

Khush Kashyap: Well, that's amazing. It is a real incident. Specifically, this is based on the twen- 2022 data breach in which the hacking group gained access to a major rideshare company's internal systems through an MFA fatigue, um, through a social engineering attack.

‍

Jason Chan: Yeah. Sounds right. 

‍

Khush Kashyap: Now let's do a quick round of Off the Table, our opportunity to get off-the-cuff answers on big security questions. 

‍

Jason Chan: Okay. 

‍

Khush Kashyap: Um, what's the security control employees treat as a formality that actually matters more than they think? 

‍

Jason Chan: I would say probably keeping systems up to date. 

‍

Khush Kashyap: Legacy security, legacy IT, and all that debt.

‍

Jason Chan: y- yeah, I mean, just if there's one thing... Or there's two things that end users can do, I would say it's, you know, good identity hygiene, um, and keeping your systems, keeping your endpoints updated. Like, those are the two things that have- And patching Yeah, patching, updates. Huge impact. 

‍

Khush Kashyap: Not the most exciting part of the work, but definitely an essential one.

‍

Jason Chan: Yeah, I mean, it's, it's... If you can only do two th- two things, I say that do those. 

‍

Khush Kashyap: Mm-hmm. Where is the most common place that hard-coded credentials are hiding right now in most organizations? 

‍

Jason Chan: It's probably, like, those kinda one-off scripts that- Mm-hmm ... that somebody ran, somebody was testing something out to test, to connect to a database or connect to some endpoint, and they've been, you know, kind of forgotten about. So that tends to be... 'Cause if I think about, you know, most production runtime systems are gonna have some mechanism to deliver secrets and manage secrets, um, reasonably. So it tends to be those things that are on the edge, production, or excuse me, outside of production kinda testing, things like that.

‍

Khush Kashyap: What's one thing you would change about how companies handle contractor access? 

‍

Jason Chan: I think the, the main thing with contractor access is that, you know, again, assuming, like, good identity hygiene, is that contractor... Well, most folks, they tend to need only a relatively few, you know, access to a few systems, a few applications. So I would say really spend time on scoping what those things are. 

‍

Khush Kashyap: Mm-hmm. 

‍

Jason Chan: Because if you can limit the number of systems somebody can access, you're gonna almost by definition control the blast radius before anything happens. 

‍

Khush Kashyap: That makes sense. What's the biggest lesson in the industries that still hasn't been fully absorbed from an incident like this one?

‍

Jason Chan: Well, I, I think, I think there, there's a couple things, right? Is that incidents, um, they are an everyday thing for a company of a reasonable size. Like, you're probably going to be running, dozens of incidents a quarter. So it's kind of like a, a normal thing for the security team. It shouldn't really be looked at as like, uh, you know, something... I wouldn't say something special or, but something out of the ordinary, like things happen. And yeah, I, you know, I mentioned it a couple times during the exercise, but I think it's really important for internal teams to kinda manage the internal communications so that they are, again, like letting the rest of the workforce kinda do their thing.

‍

So we... Even if it's a fairly significant incident, you don't want everyone kinda running around, you know, being excited and [00:24:00] not, not working on what actually they s- whatever value it is that they bring to the company. 

‍

Khush Kashyap: Yeah. There's definitely a huge hidden cost around business operations and continuity that we sometimes don't factor in when we do a look back on incidents and what it really costed a company.

‍

Jason Chan: Yep. 

‍

Khush Kashyap: Anything else that we didn't cover in our conversation today about this incident? 

‍

Jason Chan: Oh, yeah. I mean, I, we've talked about it a little bit, but I think it's, it's important to, to recognize that, you know, sometimes our security controls get used against us, and we also wanna be sort of cognizant of the, the load that we're placing on our end users to actually use the systems.

‍

We don't want them to become like, "Oh, well, I'm just gonna click yes, click yes," because then you're kind of... You're subverting the intent, so. 

‍

Khush Kashyap: Yeah. And I also really like the point that you made about culture and trust, which is built not during the incident and the remediation process, but much, um, before as an ongoing exercise with engineering, R&D, and other teams.

‍

Jason Chan: Yeah, exactly. I think that's, that's the biggest, probably one of the biggest things that the security leader's job is to do, is to [00:25:00] sort of build a relationship with everybody else when times are, you know, less stressful. 

‍

Khush Kashyap: Jason, would love to understand, um, since you've retired, what is it that you're noticing in our technology and industry landscape now which you feel like, "Oh my gosh, I wish I was there, and I wanna be part of it and go through the security journey with organizations dealing with that today"?

‍

Jason Chan: Oh, geez. Um, well, yeah, so I retired in 2021, so certainly AI has been, you know, both kind of... So everything I hear now is either security for AI or AI for security. Um, I think it's a super interesting technology. I think, I think ultimately just sort of being an outsider and kind of, um, you know, talking to folks who are still doing it, it still feels like a relatively, um, or a s- kind of a similar cycle as we've seen before, where you have a business really excited about a technology that's quite transformational, and security team's kinda struggling to keep up.

‍

Khush Kashyap: Yeah. Well, Jason, you survived the Tabletop. Mm. Right. Thank you so much for being here. 

‍

Jason Chan: Thank you for having me. Thank you.