Latest / Tech Talks With Kinsoft / Bendigo Bank - 1,598 Accounts, One Password, and the $8 Million Bill That Arrived Three Years Later

Transcript

Bendigo Bank - 1,598 Accounts, One Password, and the $8 Million Bill That Arrived Three Years Later · Tech Talks With Kinsoft

• 0:00
  Picture this, if you will. It is March 2023.
• 0:03
  Okay. And a cyber attack on a pretty major Australian
• 0:07
  bank is just kicking off. But at that exact moment,
• 0:11
  1 ,598 customer accounts at this institution
• 0:15
  are secured by a single identical password. Oh,
• 0:18
  wow. Yeah. And that password was literally 123456.
• 0:23
  I mean, that is just is painful even here. It
• 0:25
  really is. So welcome to today's deep dive. We
• 0:28
  are unpacking a really fascinating August 2026
• 0:31
  episode of Tech Talks with Kinsoft. Right, which
• 0:34
  goes into all the details of this breach. Exactly.
• 0:36
  And our mission today for this deep dive isn't
• 0:38
  just to, you know, gawk at terrible security
• 0:41
  hygiene, though there is plenty of that. Oh,
• 0:43
  yeah, there definitely is. But we are really
• 0:45
  analyzing this massive regulatory paradigm. shift
• 0:47
  because this relatively small theft of about
• 0:50
  $490 ,000 resulted in a crushing $8 million penalty.
• 0:55
  Yeah, which is just a staggering scenario to
• 0:57
  encounter in modern finance. I mean, when you
• 0:58
  hear a statistic like nearly 1 ,600 accounts
• 1:01
  using 123 -456, and this is in the year 2023,
• 1:05
  you know? Yeah, it's not 1998. Right. It completely
• 1:08
  shatters our baseline assumptions about institutional
• 1:11
  competence. Oh, absolutely. We naturally assume
• 1:13
  the foundational walls of a heavily regulated
• 1:15
  entity are built of reinforced concrete. But
• 1:18
  in this specific corner of the bank, there wasn't
• 1:21
  even a screen door. OK, let's unpack this, because
• 1:24
  to really grasp how regulators arrived at an
• 1:27
  $8 million penalty for a fraction of that and
• 1:31
  actual losses, we have to look at the mechanics
• 1:33
  of the breach itself. We do, yeah. So the Australian
• 1:37
  Prudential Regulation Authority, or APRA, they
• 1:40
  identified three specific vulnerabilities. And
• 1:44
  I'm telling you, they defy every assumption you
• 1:46
  probably have about modern banking. You look
• 1:48
  at it. So first, obviously, the complete lack
• 1:51
  of a restriction. Right. There were just no guardrails
• 1:59
  at all. None. And second, they allowed multiple
• 2:02
  accounts to share identical passwords. Which,
• 2:04
  you know, fundamentally changes the math for
• 2:06
  an attacker. How so? Like for the listener who
• 2:09
  isn't a pen tester. Well. You no longer have
• 2:11
  to guess the correct password for a specific
• 2:13
  user. You just take the most statistically common
• 2:16
  password in the world and you simply spray it
• 2:18
  across the entire user base. Right. You just
• 2:21
  try the same key on every single lock. Exactly.
• 2:23
  You guess once and you apply it everywhere. Right.
• 2:26
  But then there's the third vulnerability, which
• 2:28
  is the one that actively assisted the attackers,
• 2:30
  honestly. Oh, yeah. Account enumeration. Yes,
• 2:33
  account enumeration. For you listening, I want
• 2:35
  you to think of it this way. It's like a burglar.
• 2:38
  Walking down a long, dark hotel hallway, just
• 2:42
  jiggling door handles. And every single time
• 2:45
  they touch a handle, the door loudly announces
• 2:48
  someone lives here or this room is empty. That's
• 2:52
  a great analogy, actually. Thanks. I mean, the
• 2:55
  login process for this banking platform was essentially
• 2:58
  doing exactly that for the attacker. It was confirming
• 3:01
  exactly which user identifiers were real and
• 3:03
  which ones were completely fake. Yeah. And the
• 3:05
  source material has this brilliant phrase about
• 3:07
  this. It says these three flaws combined turned
• 3:10
  a search problem into a shopping list. A shopping
• 3:13
  list. I mean, that is just it's chilling, honestly.
• 3:16
  What's fascinating here is. These are not sophisticated
• 3:19
  zero -day exploits. Right. No one is writing
• 3:22
  custom malware here. Exactly. They are depressingly
• 3:25
  ordinary everyday user experience decisions.
• 3:29
  Wait, UX decisions? Yeah. Think about it from
• 3:32
  the perspective of a UX designer. Like, when
• 3:35
  a user forgets their login, the designer wants
• 3:38
  to be helpful. Sure. You don't want the user
• 3:39
  to get frustrated. So they program the system
• 3:42
  to explicitly say, we don't have an account under
• 3:44
  that email address. Oh, right. Because it feels
• 3:46
  like good customer service. Exactly. But from
• 3:49
  a security standpoint, you are actively doing
• 3:52
  the reconnaissance for the threat actor. Wow.
• 3:54
  Yeah, you're literally handing them the map.
• 3:56
  Right. Because if an attacker doesn't have enumeration,
• 3:58
  they are just blindly throwing both usernames
• 4:01
  and passwords into an infinite void, just hoping
• 4:04
  they eventually line up. But with enumeration,
• 4:06
  the void just disappears. It does. They now have
• 4:09
  a confirmed, validated list of actual customer
• 4:12
  IDs. It's just wild. I mean, the math literally
• 4:15
  stops being hard. You have the exact usernames
• 4:18
  and you know almost 1 ,600 of them are using
• 4:21
  the six most predictable characters on the keyboard.
• 4:23
  Yeah, it's barely even hacking at that point.
• 4:25
  No, it's just logging in. But if the attack was
• 4:29
  that elementary, someone inside had to see it
• 4:32
  coming, right? You would think so. And looking
• 4:33
  at the timeline from the source material, they
• 4:35
  absolutely did. Yeah, the timeline is precisely
• 4:37
  where this narrative shifts. It goes from a technical
• 4:40
  failure to a catastrophic governance failure.
• 4:43
  Okay, so let's look at this three -year window
• 4:46
  outlined in the source. In 2020, three full years
• 4:49
  before the breach, a penetration test successfully
• 4:52
  identified these exact security weaknesses in
• 4:55
  the environment. Three years. Three years, but
• 4:58
  they weren't remediated. Then, jump forward to
• 5:00
  October 2022, an actual threat actor attempts
• 5:03
  a brute force login attack on the platform, and
• 5:06
  they fail. Right, the system actually held them
• 5:08
  off that time. Yeah. And following that failed
• 5:12
  attack, the banks board was explicitly told that
• 5:15
  they were at a, quote, critical point of needing
• 5:18
  further investment in resourcing and capability.
• 5:21
  But no substantive review was undertaken. Nothing.
• 5:24
  Five months go by. And then in March 2023, an
• 5:27
  attacker comes back and this time they walk right
• 5:31
  through the front door. You know, that October
• 5:33
  2022 event, it really cannot be overstated. Because
• 5:37
  they knew someone was knocking. Exactly. In the
• 5:39
  security world, a failed attack is essentially
• 5:41
  free intelligence. Free intelligence. Yeah, it
• 5:44
  is a massive gift because it tells you exactly
• 5:47
  what somebody wants. It shows you the methods
• 5:49
  they're using to get it. And most importantly.
• 5:51
  It tells you they've chosen you. Exactly. It
• 5:54
  tells you that they have specifically chosen
• 5:55
  you as a target. The alarm bells were absolutely
• 5:58
  ringing. Well, okay, let me play devil's advocate
• 6:00
  for a second here. Sure. Because I want to look
• 6:01
  at this from the perspective of the IT teams
• 6:03
  working in the trenches. Realistically, enterprise
• 6:06
  security operations centers, they get thousands,
• 6:09
  maybe tens of thousands of automated alerts every
• 6:12
  single day. Oh, yeah. The noise is deafening.
• 6:15
  Right. The Internet is constantly scanning and
• 6:17
  probing literally everything with an IP address.
• 6:20
  So if an automated script fails to log in, isn't
• 6:23
  that just like a regular Tuesday? That's a fair
• 6:26
  point. Like how is a massive bank supposed to
• 6:29
  overhaul its entire infrastructure every time
• 6:32
  a brute force attempt fails? And that is a completely
• 6:36
  valid defense if we're talking about an isolated
• 6:38
  alert that just got buried in a log file at the
• 6:41
  analyst level. Because it's easy to get lost
• 6:43
  in the noise. It is incredibly easy to get lost
• 6:46
  in the noise. But that defense totally evaporates
• 6:49
  when you look at the source material for this
• 6:51
  specific case. Right. Because of who was told.
• 6:54
  Exactly. The highest levels of leadership were
• 6:57
  briefed. The board was told in the direct aftermath
• 7:01
  of that failed attack. that the system was at
• 7:03
  a critical point. Wow. The warning successfully
• 7:06
  traveled all the way up the chain of command,
• 7:08
  bypassing the noise of the SOC. And yet, nothing
• 7:12
  structural changed over the next five months.
• 7:14
  Just crickets. Right. And knowledge is only valuable
• 7:17
  when it is applied. Having a 2020 penetration
• 7:20
  test report sitting in a digital folder somewhere,
• 7:23
  you know, that isn't security. No, not at all.
• 7:26
  It is simply a dated, written record of your
• 7:29
  negligence. Wow. A dated written record of negligence?
• 7:33
  I mean, you'd think after a failed brute force
• 7:36
  attack that actually reached the board level,
• 7:38
  someone would just, I don't know, pull the plug
• 7:40
  or force a mandatory password reset for the entire
• 7:43
  user base. You would certainly hope so. But no
• 7:45
  one did. And reading through the source material,
• 7:47
  I noticed something strange about the corporate
• 7:49
  structure that might actually explain why nobody
• 7:51
  acted. Ah. Yes. You're referring to the governance
• 7:53
  gap. Yes. I was looking at these notes and getting
• 7:56
  a bit confused, honestly. So the parent company
• 7:58
  here is Bendigo and Adelaide Bank, which is Australia's
• 8:02
  sixth largest bank. You're right. They're the
• 8:04
  ones who got fined. But the customers who actually
• 8:06
  got hit belong to ServiceOne Alliance Bank. So
• 8:10
  how does a massive, heavily regulated banking
• 8:13
  system operate a platform where the legal entity
• 8:17
  and the operational entity are so detached? Well,
• 8:21
  it is a classic white label arrangement, and
• 8:23
  it creates a massive structural blind spot. Okay,
• 8:28
  break that down for us. So Bendigo and Adelaide
• 8:31
  Bank held the overarching banking license. Therefore,
• 8:34
  Bendigo carried all the regulatory accountability.
• 8:37
  Okay, that makes sense. But they provided a digital
• 8:39
  banking platform to a network called Alliance
• 8:42
  Bank, which was made up of several authorized
• 8:44
  representatives, including ServiceOne. Got it.
• 8:47
  So that basically rented out the tech. Essentially,
• 8:50
  yes. Yeah. But the platform those Alliance customers
• 8:53
  used fell into this bizarre, undocumented middle
• 8:57
  ground. Like a no man's land. Exactly. It was
• 9:00
  a system serving Bendigo's regulatory obligations,
• 9:03
  but nobody within Bendigo's IT or risk departments
• 9:06
  had been explicitly told this specific platform
• 9:09
  is your problem. Oh, geez. It was an orphan system.
• 9:13
  See, here's where it gets really interesting.
• 9:14
  Because of this orphan system. When Bendigo ultimately
• 9:17
  faced the regulator, they admitted to four specific
• 9:20
  failures. And if you read them, not a single
• 9:22
  one of those failures is, we got hacked. No,
• 9:25
  they aren't. They admitted they failed to maintain
• 9:27
  authentication controls. They failed to test
• 9:30
  those controls. They failed to ensure accountable
• 9:32
  persons covered the IT system. And they failed
• 9:36
  to maintain risk management governance. Right,
• 9:39
  all governance. I mean, how does a modern enterprise...
• 9:43
  Just not have a specific human being's name attached
• 9:46
  to a live banking environment. Well, it happens
• 9:48
  far more often than you would think, unfortunately.
• 9:51
  Especially in the wake of acquisitions, white
• 9:54
  label partnerships, or complex managed service
• 9:59
  contracts. It just gets lost in the shuffle.
• 10:01
  It does. And if we connect this to the bigger
• 10:03
  picture. This structural void is exactly why
• 10:06
  the regulatory response was so unique. The regulator
• 10:09
  in this case wasn't the usual privacy or data
• 10:12
  protection commission. Right, because there was
• 10:13
  no mass exfiltration of personal data, right?
• 10:16
  Like no database of passports or driver's licenses
• 10:18
  was just dumped on the dark web for sale. Precisely.
• 10:21
  The regulator was APRA, and the instrument they
• 10:24
  used was BEAR. BEAR, which stands for? The Banking
• 10:27
  Executive Accountability Regime. Okay, so it's
• 10:29
  focused on the people at the top. Exactly. BEAR
• 10:32
  is a framework explicitly designed to force personal
• 10:36
  accountability onto senior executives and directors.
• 10:39
  So they can't just hide behind the corporate
• 10:41
  logo. Right. The punishment here was strictly
• 10:44
  and entirely about the failure of governance.
• 10:47
  It was about the fact that leadership could not
• 10:49
  point to a single person responsible for the
• 10:52
  platform's security posture. Which brings us
• 10:55
  to the math. Because that absolute void in accountability
• 10:58
  is what triggered a financial penalty that completely
• 11:01
  destroys traditional enterprise risk modeling.
• 11:04
  It really does throw the old models out the window.
• 11:06
  Let me give you the numbers punchily for anyone
• 11:07
  listening. The attacker gained access to 257
• 11:10
  accounts. Right. They made 286 unauthorized transactions.
• 11:15
  In total, about $490 ,000 was stolen. Which in
• 11:19
  banking terms is relatively small. Exactly. Now
• 11:21
  the bank fully reimbursed every single affected
• 11:24
  customer. The bank itself, as a multibillion
• 11:26
  -dollar entity, was never financially threatened.
• 11:29
  Not at all. But the penalty handed down by the
• 11:31
  federal court, $8 million. Plus another $2 .6
• 11:35
  million in legal costs. Right. Over $10 million
• 11:38
  total for a $490K loss. And that arithmetic right
• 11:42
  there is the most critical takeaway for anyone
• 11:44
  listening who has to justify a security budget
• 11:47
  or assess corporate risk. Well, I have to push
• 11:50
  back on this, though. Okay. Let's hear it. I'm
• 11:52
  looking at this from the perspective of a CFO
• 11:55
  or a risk manager. If I build a quantitative
• 11:58
  risk model, I look at this platform and say,
• 12:01
  worst case statistical scenario. We lose half
• 12:04
  a million bucks to fraud. Statistically, yes.
• 12:06
  Right. So when the IT director asks for a $2
• 12:10
  million budget to overhaul the white label platform,
• 12:13
  I decline the spend. It makes pure financial
• 12:16
  sense. Under the old way of thinking, sure. So
• 12:18
  getting hit with an $8 million penalty for a
• 12:21
  $490K loss, I mean, doesn't that sound like massive
• 12:24
  regulatory overreach? If I'm an executive, I'm
• 12:27
  appealing that as absurdly disproportionate.
• 12:29
  It's like getting a speeding ticket that costs
• 12:31
  more than the car you were driving. It is. Your
• 12:33
  analogy is spot on, but your risk model is exactly
• 12:36
  what the regulators are trying to break here.
• 12:38
  Okay. Explain that. The $8 million penalty was
• 12:40
  not a punishment for losing $490 ,000. It was
• 12:44
  a punishment for the three years of dead air
• 12:46
  between the penetration test finding the flaw
• 12:49
  in 2020 and the fix that didn't happen until
• 12:52
  after the breach in 2023. Ah, so it's a penalty
• 12:55
  for the silence. Exactly. Regulators under the
• 12:58
  Bayer framework are drawing a very hard, deliberate
• 13:00
  line. If an unknown, highly sophisticated zero
• 13:04
  -day vulnerability is exploited by a state -sponsored
• 13:08
  actor, that is considered bad luck. Right, because
• 13:10
  nobody could have seen it coming. Yes, you mitigate
• 13:12
  it, you report it, and you move on. But the cost
• 13:15
  of a known, documented, and internally reported
• 13:18
  vulnerability that you simply chose not to fix.
• 13:21
  That's different stories. Completely different.
• 13:22
  That is no longer bad luck. That is an $8 million
• 13:24
  corporate decision. An $8 million corporate decision?
• 13:28
  Wow. That phrasing completely changes how you
• 13:31
  have to view a backlog of IT tickets. It really
• 13:33
  should. So how do you, the listener, actually
• 13:36
  avoid making an $8 million decision in your own
• 13:39
  organization? The source material lays out five
• 13:42
  incredibly clear lessons. Let's really dig into
• 13:45
  these because they apply whether you are running
• 13:48
  a startup, managing an IT department, or just
• 13:51
  trying to be a more informed professional. Sounds
• 13:53
  good. Let's go through them. Lesson number one.
• 13:56
  An unremediated penetration test is worse than
• 13:59
  no penetration test at all. Yeah. And this is
• 14:01
  a harsh reality of legal discovery. Yeah. As
• 14:04
  we discussed, an ignored pentest stops being
• 14:07
  a proactive security tool and immediately becomes
• 14:09
  legal evidence against you. Right. You're basically
• 14:11
  doing the prosecutor's job for them. Exactly.
• 14:13
  When a breach happens, the very first thing regulators
• 14:16
  and opposing counsel will ask for is your history
• 14:19
  of external audits. If they find a PDF from three
• 14:22
  years ago outlining the exact vulnerability that
• 14:24
  was just exploited, you have lost all deniability.
• 14:27
  There is no we didn't know. None. If you commission
• 14:30
  a test, you must have a named accountable owner
• 14:33
  for every single finding, a strict due date for
• 14:36
  remediation, and an aging report that gets escalated
• 14:40
  to the board if those dates are missed. If it
• 14:43
  just sits in a drawer, you are manufacturing
• 14:45
  your own liability. That makes perfect sense.
• 14:48
  Okay, moving to lesson number two. Treat failed
• 14:51
  attacks as real incidents. We touched on this
• 14:54
  earlier, but what does that practically mean
• 14:56
  for a security team? Well, it requires a fundamental
• 15:00
  shift in mindset. Many organizations view a blocked
• 15:03
  attack as a success. Right, like, hey, the firewall
• 15:06
  held, the login failed, we're good. But a failed
• 15:09
  brute force attempt, especially a sustained one,
• 15:11
  is a rehearsal. It requires a formal incident
• 15:14
  review with a concrete outcome. Like you have
• 15:16
  to ask the hard questions. Yes. What were they
• 15:19
  targeting? Where did the traffic originate? Did
• 15:21
  they pivot to another subsystem when the front
• 15:23
  door held? If your infrastructure can't even
• 15:26
  provide the visibility to answer those questions
• 15:28
  after a massive spike in failed logins, you don't
• 15:31
  have a security program. You just have a very
• 15:33
  busy firewall. Which brings us to lesson number
• 15:35
  three. Actually measure your password policy.
• 15:38
  Don't just assume it works because HR sent out
• 15:41
  a memo. Oh, this is a big one. Everyone claims
• 15:44
  to have a robust password policy. But you have
• 15:47
  to measure its reality against user behavior.
• 15:50
  Are you actively checking your Active Directory
• 15:52
  against known breached password lists? And more
• 15:56
  importantly, let's talk about multi -factor authentication,
• 15:59
  or MFA. Right. The source material explicitly
• 16:01
  mentions the failure of MFA here. Yes. And the
• 16:05
  lesson is brutal. It is. If MFA is available
• 16:08
  but optional, you must assume, statistically,
• 16:11
  that it is completely off. Optional equals off.
• 16:13
  Exactly. User friction is the enemy of adoption.
• 16:17
  If you give a user the choice to skip entering
• 16:19
  a six -digit code on their phone, the vast majority
• 16:21
  will absolutely skip it. Yeah, I've skipped it
• 16:23
  myself when I'm in a hurry, honestly. We all
• 16:25
  have. But you cannot tell a regulator, well,
• 16:28
  we offered them the security tool. Security isn't
• 16:30
  an opt -in newsletter. If it protects sensitive
• 16:32
  data, it must be mandatory. Available but optional
• 16:35
  equals off? That is a fantastic rule of thumb
• 16:38
  for any product manager to keep in mind. Okay,
• 16:42
  lesson number four. Fix account enumeration.
• 16:45
  Right. We talked about how the system told the
• 16:47
  attacker which accounts were real. But how do
• 16:50
  you actually fix that without ruining the user
• 16:52
  experience? It requires a bit of technical discipline.
• 16:54
  The lull in, password reset, and account registration
• 16:57
  flows must return identical responses, regardless
• 17:01
  of whether the email address exists in your database
• 17:04
  or not. So no more email not found pop -ups.
• 17:08
  Right. Instead, the system should say, if an
• 17:10
  account exists for this email, a password reset
• 17:12
  link has been sent. But... You know, it goes
• 17:15
  deeper than just the text on the screen. Wait,
• 17:17
  how so? Timing attacks. Timing attacks, like
• 17:19
  literally measuring time. Yes. If your database
• 17:21
  takes 50 milliseconds to realize a user doesn't
• 17:24
  exist, but it takes 500 milliseconds to verify
• 17:27
  a password for a user that does exist, an automated
• 17:30
  script will measure that time difference and
• 17:32
  enumerate your database anyway. Oh, wow. I never
• 17:35
  even considered that the processing time itself
• 17:36
  could give away the existence of an account.
• 17:38
  Most people don't. Your engineering team has
• 17:41
  to ensure uniform response times across all authentication
• 17:44
  flows. It is a remarkably cheap fix at the code
• 17:47
  level, but almost no one tests for it. And fixing
• 17:51
  it completely denies attackers that validated
• 17:54
  chopping list we talked about earlier. That is
• 17:56
  fascinating. Okay, finally, lesson number five.
• 17:59
  Outsourced IT still carries your accountability.
• 18:02
  And this is the governance trap that caught Bendigo.
• 18:04
  You can outsource the technical labor. But you
• 18:08
  cannot outsource your regulatory or reputational
• 18:11
  responsibility. You can't just point fingers
• 18:13
  at the vendor. Exactly. If a managed service
• 18:15
  provider runs your infrastructure, you own that
• 18:18
  risk. If you acquired a smaller business three
• 18:21
  years ago that is still quietly running its old
• 18:23
  legacy tech stack in the background, you own
• 18:26
  that risk. If you use a third -party software
• 18:28
  as a service or SaaS platform that is branded
• 18:31
  with your company's logo. You own that risk.
• 18:34
  You own that risk. So you essentially need a
• 18:35
  map of everything. You need a map and you need
• 18:37
  names. Yes. You must be able to write down every
• 18:41
  single digital system your customers interact
• 18:43
  with and put one specific executive's name next
• 18:46
  to it. Not just the IT team. No, not a whole
• 18:49
  department. One person. Because, as the source
• 18:53
  material proves, if you don't proactively pick
• 18:56
  someone to be accountable, the regulator will
• 18:58
  gladly step in and pick someone for you. What
• 19:01
  does this all mean for you listening? I want
• 19:03
  you to genuinely visualize your own workplace
• 19:05
  right now. Think about the software you log into
• 19:08
  every day. Think about the vendors your company
• 19:10
  partners with. Do you have a SaaS platform handling
• 19:14
  client data or maybe an old acquired business
• 19:16
  unit operating under your brand that no specific
• 19:19
  human being actually owns? Because if you look
• 19:22
  closely and you realize there is an orphan system
• 19:24
  sitting out there in the digital ether, Well,
• 19:27
  right now, that is a massive, multimillion -dollar
• 19:30
  blind spot. Yeah, and just to summarize what
• 19:32
  we've unpacked from this source material today,
• 19:34
  we have officially crossed the threshold into
• 19:36
  a new regulatory era. We really have. Regulators
• 19:39
  are no longer just waiting to punish companies
• 19:42
  for losing massive databases of personal information.
• 19:44
  They are actively and aggressively punishing
• 19:48
  companies for failing to govern their own known
• 19:50
  risks. Even if the actual data loss is small.
• 19:53
  Right. The absence of internal oversight? The
• 19:57
  lack of a named owner? The ignored audit report?
• 20:00
  These are now treated as severe compliance failures
• 20:02
  in their own right, regardless of the direct
• 20:04
  financial impact of the breach itself. It is
• 20:07
  a whole new world of accountability. Thank you
• 20:09
  so much for joining us on this deep dive. We've
• 20:11
  covered a tremendous amount of ground, from burglars
• 20:14
  in hotel hallways to the intricacies of the federal
• 20:17
  court and timing attacks. But I want to leave
• 20:19
  you with one final lingering thought to mull
• 20:21
  over today. Let's hear it. The source material
• 20:23
  makes it abundantly clear that a three -year
• 20:25
  -old security... finding with no designated owner
• 20:27
  isn't an oversight. It's a deliberate choice.
• 20:30
  So thinking about your own organization, your
• 20:32
  own department, or the projects you manage right
• 20:34
  now, what decisions are currently sitting quietly
• 20:38
  in your backlog just waiting for the right attacker
• 20:40
  to find them? Because you definitely don't want
• 20:42
  the answer to be one, two, three, four, five,
• 20:44
  six.