Latest / Tech Talks With Kinsoft / WA Government – Systemic Microsoft 365 Security Failures

Transcript

WA Government – Systemic Microsoft 365 Security Failures · Tech Talks With Kinsoft

• 0:00
  Welcome to Tech Talks with Kinsoft. I mean, this
• 0:02
  is the show where we take, you know, complex
• 0:04
  tech and security news, and we try to extract
• 0:07
  the most important, actionable insights for you
• 0:10
  to apply to your own work. And today... Well,
• 0:13
  imagine spending millions of dollars to build
• 0:16
  this state of the art digital fortress for your
• 0:18
  organization. Oh, yeah. Best firewalls, massive
• 0:21
  budgets. Exactly. You have the complex passwords,
• 0:23
  the security teams, but then your entire system
• 0:26
  gets completely compromised. And it's not by
• 0:29
  some team of elite hackers burning zero day exploits.
• 0:33
  It's because the foundational architecture basically
• 0:35
  leaves the back door propped open with a brick
• 0:38
  just because someone couldn't remember their
• 0:40
  key. It's terrifyingly common. We constantly
• 0:43
  look for these exotic threats on the horizon.
• 0:45
  But I mean, the most devastating breaches, they
• 0:47
  usually just stem from mundane, everyday configurations.
• 0:50
  Right. We all just sort of assume that enterprise
• 0:53
  software is secure by default. And that assumption
• 0:55
  is, well, it's incredibly dangerous. Yeah. Which
• 0:57
  brings us to our core source for today's discussion.
• 1:00
  So on March 6th, 2026, the Western Australian
• 1:03
  Office of the Auditor General, the OAG, released
• 1:06
  this report. It uncovered systemic Microsoft
• 1:10
  365 security failures across seven different
• 1:13
  state government entities. Seven. That's a huge
• 1:17
  sample size for systemic failure. It really is.
• 1:19
  And to put this into perspective for you listening,
• 1:22
  Microsoft. It isn't just an email client anymore,
• 1:25
  is it? Oh, no. Far from it. It's essentially
• 1:28
  the central nervous system of a modern enterprise.
• 1:31
  It handles your identity management, internal
• 1:33
  comms, file storage, data processing, automation,
• 1:36
  all of it. Yeah. So if that system suffers from
• 1:39
  systemic vulnerabilities, I mean, the attacker
• 1:41
  doesn't just have your emails. They have the
• 1:43
  literal keys to your entire operational kingdom.
• 1:46
  Right, which is a perfect segue. I want to avoid
• 1:48
  just, you know, reading off a dry, gross -free
• 1:50
  list of technical vulnerabilities today. So let's
• 1:52
  look at... how these weaknesses actually stack
• 1:53
  up in the real world. The report details this
• 1:56
  anatomy of a $71 ,000 theft. Yes, the BEC incident.
• 2:01
  Exactly. And the timeline of how it unfolded,
• 2:04
  it's just a masterclass in how threat actors
• 2:07
  exploit these seemingly minor misconfigurations.
• 2:10
  So where does this start? Well, it's a textbook
• 2:12
  business email compromise, right? Or BEC. And
• 2:16
  it demonstrates exactly how patience pays off
• 2:19
  for a threat actor. It began with a senior officer
• 2:23
  at one of these audited government entities.
• 2:25
  Their account was compromised through a highly
• 2:28
  targeted phishing attack. Okay, let's pause right
• 2:31
  there. Because IT departments are constantly
• 2:33
  telling us, you know, multi -factor authentication,
• 2:36
  MFA, that's the silver bullet against phishing.
• 2:38
  Right, the golden rule. Yeah. If I have a password
• 2:40
  and an MFA prompt on my phone, I should be safe.
• 2:43
  But the attacker just defeated the system's MFA.
• 2:46
  They walked right through it. Right. And we'll
• 2:48
  get into the mechanics of exactly how they bypassed
• 2:50
  in a minute, but I really want to focus on what
• 2:52
  happened immediately after they got through that
• 2:54
  front door. Because once they were inside, the
• 2:57
  attacker registered their own unmanaged device
• 2:59
  from an overseas location. Yeah, and that specific
• 3:02
  action registering a brand new device, that is
• 3:06
  where the technical failure becomes catastrophic.
• 3:09
  How so? Well, think about it. In a properly configured
• 3:12
  environment, an overseas IP address attempting
• 3:15
  to register an unrecognized mobile device, for
• 3:19
  a senior official no less, that should trigger
• 3:21
  a massive alert. Right. sirens going off everywhere.
• 3:24
  Exactly. The system should automatically block
• 3:27
  the action or, you know, at the very least force
• 3:29
  a manual review by an admin. But because the
• 3:33
  governance controls at this entity were just
• 3:34
  so loose, the system basically treated it as
• 3:38
  a normal. everyday user action. No alarm sounded
• 3:41
  at all. None. Zero. So it's basically like a
• 3:44
  burglar stealing your house keys, walking in,
• 3:46
  and then changing the locks on the doors so you
• 3:48
  can't get in. That is exactly what happened.
• 3:50
  They effectively locked the legitimate owner
• 3:51
  out of their own account without anyone noticing.
• 3:53
  That's wild. And then they didn't just, you know,
• 3:55
  smash and grab. They set up email forwarding
• 3:58
  rules to automatically funnel specific communications
• 4:01
  out of the inbox to hide their tracks. Yeah.
• 4:03
  And then they just sat there for weeks. Yeah,
• 4:06
  that's what we call dwell time. They were just
• 4:08
  conducting quiet reconnaissance. For a whole
• 4:11
  month, the attacker sat... In the guest room,
• 4:15
  so to speak, and studied the officer's emails.
• 4:17
  A whole month. A whole month. They mapped out
• 4:20
  the organizational chart. They learned the internal
• 4:22
  jargon. They observed exactly how the billing
• 4:24
  process worked. They figured out, you know, who
• 4:27
  authorized the payments. That's they're learning
• 4:30
  the actual rhythm of the business. Precisely.
• 4:32
  And they use all that intelligence to construct
• 4:35
  a highly believable payment scenario. They submitted
• 4:39
  a fraudulent invoice that looked perfectly legitimate.
• 4:43
  I mean, it used the correct internal billing
• 4:45
  codes and it mirrored the senior officer's exact
• 4:48
  communication style. Because they've been reading
• 4:50
  their sent folder for a month. Exactly. And because
• 4:52
  it originated from the actual authenticated internal
• 4:55
  account of a senior leader. It bypassed all standard
• 4:59
  email security filters. The entity paid out $71
• 5:02
  ,000. Oh, wow. And the craziest part to me is
• 5:06
  when investigators finally came in to figure
• 5:08
  out what went wrong. They hit a total brick wall.
• 5:11
  The report says the entity hadn't retained sufficient
• 5:14
  logs, so a full forensic review was literally
• 5:17
  impossible. They were completely blind. Completely.
• 5:20
  But I want to circle back to the point I flagged
• 5:22
  earlier because I think a lot of people listening
• 5:23
  are wondering the same thing. You mentioned the
• 5:25
  attacker defeated the MFA. Yes. If an attacker
• 5:28
  steals my password, they still need that six
• 5:30
  -digit code from my phone. Right. How on earth
• 5:33
  do they bypass that without having my physical
• 5:36
  device in their hands? Yeah. So that brings us
• 5:38
  to the audit's findings on identity and access
• 5:40
  management, which honestly is the most critical
• 5:43
  takeaway here. The entities were operating under
• 5:46
  this illusion of security, assuming that all
• 5:48
  MFA is created equal. And it's not. Not at all.
• 5:52
  The audit found that all seven entities relied
• 5:54
  on weak, fishable MFA methods. We are talking
• 5:57
  about SMS text messages, voice calls, and email
• 6:02
  one -time passwords or OTPs. But wait, I'm going
• 6:04
  to play devil's advocate here. SMS codes feel
• 6:07
  so convenient. And if the code goes directly
• 6:10
  to my specific phone number through my cellular
• 6:13
  provider, how is a hacker sitting in another
• 6:15
  country getting their hands on it? Is the risk
• 6:18
  really that high or is this just like security
• 6:20
  paranoia? It is not paranoia. There are two primary
• 6:23
  methods and neither of them requires physical
• 6:25
  access to your phone. The first one is a SIM
• 6:28
  swapping attack. This is pure social engineering.
• 6:31
  The attacker gathers some basic personal info
• 6:34
  about you. They call your telecommunications
• 6:36
  provider, pretend to be you and say, hey, I lost
• 6:38
  my phone. Oh, no. Yeah. They convince the customer
• 6:42
  service rep to transfer your phone number to
• 6:44
  a new SIM card that the attacker controls. The
• 6:47
  moment that rep clicks approve, your actual phone
• 6:50
  loses service and the attacker starts receiving
• 6:53
  all your SMS sends. So the telecom provider actually
• 6:56
  just hands over the access. They do. It happens
• 6:58
  every single day. But the second method is even
• 6:59
  more common, and it's called an adversary in
• 7:02
  the middle attack or ATM. Adversary in the middle.
• 7:04
  How does that work? So the attacker sends you
• 7:07
  a highly convincing phishing email that directs
• 7:10
  you to a fake Microsoft login page. You type
• 7:13
  in your username and password. The fake page
• 7:16
  instantly forwards those credentials to the real
• 7:19
  Microsoft server in real time. Okay, so Microsoft
• 7:22
  thinks it's me logging in. Right. So Microsoft
• 7:24
  generates an SMS code and sends it to your real
• 7:26
  phone. And because I think I'm logging in, I
• 7:29
  look at my phone. get the code and type it into
• 7:31
  the fake website exactly the fake site then passes
• 7:34
  that code back to microsoft now here is the critical
• 7:37
  part microsoft verifies the code and issues what's
• 7:41
  called a session token a session token yeah think
• 7:43
  of a session token like a vip wristband at a
• 7:46
  concert once you have the wristband You don't
• 7:49
  need to show your ID to the bouncers anymore.
• 7:51
  You can just walk in and out. Oh, I see. The
• 7:53
  attacker intercepts that session token, drops
• 7:55
  it into their own browser, and boom, they are
• 7:57
  fully logged in as you. They bypassed the MFA
• 8:01
  entirely because they stole the mathematical
• 8:03
  proof of the authentication, not just the password.
• 8:06
  Wow. OK, that perfectly explains why the Australian
• 8:09
  Signals Directorate, the ASD, they noted in this
• 8:13
  report that these weak MFA methods were responsible
• 8:16
  for 58 % of all security incidents affecting
• 8:19
  the Australian government in 2024 and 2025. More
• 8:22
  than half. It's wild. But the OED report also
• 8:26
  pointed out that the vulnerabilities weren't
• 8:28
  just the methods, right? It was also the actual
• 8:30
  devices being used to authenticate. Right. So
• 8:33
  the entities were allowing staff to use personal
• 8:35
  devices to register for MFA, which is common,
• 8:38
  but they weren't enrolling those devices into
• 8:40
  a mobile device management system or MDM. Meaning
• 8:43
  the IT department had zero visibility into whether
• 8:46
  the personal phone receiving the secure code
• 8:48
  was actually secure itself. Exactly. If an employee's
• 8:51
  personal phone has a malicious app or malware
• 8:53
  installed, the organization's network is instantly
• 8:56
  exposed the moment that device interacts with
• 8:58
  the corporate environment. That's a huge blind
• 9:00
  spot. It is. And the OAG report actually drew
• 9:03
  a direct parallel here to the massive 2022 Medibank
• 9:07
  data breach. Remember that. It exposed the private
• 9:09
  health records of nearly 10 million Australians.
• 9:12
  Oh, yeah, that was a disaster. And that catastrophic
• 9:14
  breach also originated from an exploited personal
• 9:17
  device used for authentication. Which is just
• 9:19
  terrifying. The governance failures in this report
• 9:23
  went even deeper. It noted that in some cases,
• 9:27
  any user could create a new Microsoft 365 tenant
• 9:31
  and become a highly privileged administrator.
• 9:34
  Now, for you listening, if you don't manage cloud
• 9:37
  infrastructure, what does creating a tenant actually
• 9:39
  mean in this context? Why is that dangerous?
• 9:42
  So a tenant is essentially a dedicated, isolated
• 9:45
  instance of the cloud environment. Imagine your
• 9:48
  organization's Microsoft 365 environment is a
• 9:51
  giant digital skyscraper. Okay. By allowing any
• 9:54
  user to create a new tenant, you are essentially
• 9:56
  letting an employee build their own unmonitored
• 9:58
  annex attached to your skyscraper. Without a
• 10:00
  permit. Without a permit, without security guards.
• 10:04
  compromises a low -level account, spins up a
• 10:06
  new tenant where they are the absolute global
• 10:08
  administrator, and uses that trusted, connected
• 10:11
  environment to launch attacks or, you know, siphon
• 10:14
  data out. And your central IT team never even
• 10:17
  sees it on their dashboard. Exactly. They have
• 10:19
  no idea it exists. So we've seen how attackers
• 10:21
  break in through the front door. Because the
• 10:23
  identity verification is fundamentally broken.
• 10:26
  Yeah. But sometimes DACAs don't even need to
• 10:28
  break in because your own employees are basically
• 10:30
  just throwing the data out the window themselves.
• 10:32
  Yeah. The internal threat. Yeah. Let's look at
• 10:35
  how data actually leaves the building, which
• 10:37
  brings us to the second. major incident in the
• 10:39
  OAG report. It was a massive data spillage. And
• 10:42
  this incident is a perfect example of internal
• 10:45
  failures compounding external risks. An unnamed
• 10:48
  government entity emailed personal and highly
• 10:51
  sensitive information about 32 individuals to
• 10:53
  a third -party service provider. And crucially,
• 10:57
  the report notes this data included information
• 10:59
  on minors. Yes. Which changes the entire legal
• 11:03
  and ethical landscape of the breach. It is so
• 11:06
  much worse. Right. So they email this highly
• 11:07
  sensitive data to a vendor. What does the vendor
• 11:10
  do? They just upload that data to a standard,
• 11:13
  unmanaged Dropbox account. Yep. And then later
• 11:16
  on, that Dropbox account gets compromised in
• 11:18
  a completely separate cybersecurity incident.
• 11:20
  Yeah. Exposing the sensitive data of those miners
• 11:22
  to an unknown threat actor. The government entity
• 11:25
  failed on multiple structural levels here. I
• 11:28
  mean, first, during the vendor onboarding process,
• 11:31
  they had not conducted any security assessment
• 11:33
  of the third -party provider. They just trusted
• 11:35
  them. Blindly. They handed over sensitive data
• 11:37
  without verifying if the vendor had the technical
• 11:40
  capability to actually protect it. But the internal
• 11:43
  tracking failure is what really stands out to
• 11:45
  me here. The audit explicitly states the entity
• 11:48
  had zero data loss prevention. or DLP, controls
• 11:52
  across their Microsoft 365 apps. No DLP on OneDrive,
• 11:57
  SharePoint Exchange Teams, nothing. Which is
• 11:59
  staggering for a government entity. Right. Now,
• 12:02
  I understand DLP is a concept like stopping data
• 12:05
  from leaving. Yeah. But how does it actually
• 12:07
  function mechanically to prevent something like
• 12:09
  this from happening? Think of DLP as a deeply
• 12:11
  embedded, automated compliance officer that reads
• 12:14
  every single document and message in real time.
• 12:17
  It uses mathematical algorithms, regular expressions,
• 12:20
  even AI now, to identify sensitive patterns.
• 12:23
  Like what kind of patterns? Like credit card
• 12:24
  formats, tax file numbers, or specific health
• 12:27
  terminology. When a user tries to email a spreadsheet
• 12:30
  containing the personal details of 32 minors,
• 12:33
  the DLP system flags it instantly. And then what?
• 12:37
  Does it just warn them? Depending on how you
• 12:39
  configure the policy, it can automatically block
• 12:41
  the email from sending entirely. Or it can mandate
• 12:45
  that the file be encrypted. Or it can force the
• 12:48
  user to provide a written justification right
• 12:50
  there on the screen before the system releases
• 12:53
  the data. OK, so because they lacked DLP, there
• 12:57
  was no digital die pack attached to the data.
• 12:59
  It just flowed out of the organization and they
• 13:01
  had no technical mechanism to even detect that
• 13:04
  it had left. None. And the audit. found this
• 13:06
  culture of careless data handling was everywhere.
• 13:09
  I mean, all seven entities allowed external data
• 13:12
  storage on unmanaged services. Oh, wow. Yeah,
• 13:14
  we're talking about a massive shadow IT problem.
• 13:17
  Staff are just syncing official work data to
• 13:19
  personal Dropbox accounts, Facebook, Google Drive,
• 13:22
  completely bypassing corporate oversight. It's
• 13:24
  literally like having a highly secure bank vault,
• 13:27
  but you're allowing the tellers to stump wads
• 13:30
  of cash into their personal backpacks to just
• 13:32
  count at home. That is a perfect analogy. It
• 13:35
  is a... Right. Okay, I get that from a strict
• 14:01
  security perspective, banning everything sounds
• 14:03
  great. But from an operational... standpoint,
• 14:05
  how do organizations actually balance the genuine
• 14:08
  need to collaborate with external partners without
• 14:12
  completely losing visibility of where their data
• 14:14
  goes? Because if you just block external sharing,
• 14:16
  the business grinds to a halt. Right. And people
• 14:20
  will just find workarounds anyway. Absolutely,
• 14:22
  they will. You solve it by shifting from implicit
• 14:24
  trust to explicit mathematical verification.
• 14:27
  You don't block the sharing. You secure the data
• 14:30
  itself. Secure the data. Not the perimeter. Exactly.
• 14:33
  You implement advanced DLP policies that automatically
• 14:36
  classify and tag the data based on its sensitivity.
• 14:39
  So a public marketing document that can be shared
• 14:42
  freely. Makes sense. But a file containing personally
• 14:46
  identifiable information that is automatically
• 14:49
  encrypted. And that mathematical restriction
• 14:51
  travels with the file. Oh, that's interesting.
• 14:54
  So even if they put it in Dropbox? Even if an
• 14:56
  employee uploads it. to an unsanctioned Dropbox
• 14:59
  folder and a hacker downloads it, the file remains
• 15:02
  locked. It will only open if the person double
• 15:05
  -clicking it can actively authenticate themselves
• 15:07
  back to your central Microsoft 365 server as
• 15:10
  an authorized recipient. That is a brilliant
• 15:13
  way to handle it. So the security lives inside
• 15:15
  the file itself? Yes. Okay, so we've covered
• 15:17
  the front door with authentication and we've
• 15:18
  covered the back door with data sharing. But
• 15:20
  looking deeper into this report, the structural
• 15:22
  integrity of the environment itself was compromised
• 15:25
  by unvetted apps and a lack of logging. Oh, the
• 15:29
  apps. This is such a widely misunderstood threat
• 15:31
  vector. The audit found that staff weren't restricted
• 15:34
  from installing unapproved Microsoft Teams applications,
• 15:38
  and they were allowed to use external code from
• 15:40
  Microsoft Power BI. See, I don't totally get
• 15:43
  this. Why is an app? in Teams, a security risk.
• 15:47
  I mean, I use third party calendar integrations
• 15:51
  and like little polling apps all the time. Because
• 15:53
  Microsoft 365 operates almost like an operating
• 15:56
  system now. When a user installs a third party
• 15:59
  app into Teams, that app requests permissions.
• 16:02
  Like on your phone when you download an app.
• 16:04
  Exactly. But these are often broad permissions
• 16:07
  to read emails, view contacts, or access files
• 16:10
  across SharePoint. If the user clicks allow,
• 16:13
  they are granting that app access using their
• 16:15
  own identity. If that third -party app is built
• 16:18
  by a malicious actor or, and this happens a lot,
• 16:21
  if the developer's servers are poorly secured
• 16:24
  and get hacked, the attacker can leverage the
• 16:26
  app's permissions to siphon data straight out
• 16:29
  of your environment. They don't even need your
• 16:30
  password. They don't need your password or your
• 16:32
  MFA. The app already has authorized access. giving
• 16:35
  a contractor the master key to the building and
• 16:37
  then just never checking if the contractor loses
• 16:40
  the key. Yeah. And speaking of poor security,
• 16:43
  most of the entities did not enforce content
• 16:45
  security policies for Microsoft's Power Platform.
• 16:49
  The OAG noted this increased their susceptibility
• 16:52
  to cross -site scripting or XSS attacks. How
• 16:56
  does an XSS attack actually work inside a business
• 16:58
  application like that? Well, Power Platform allows
• 17:01
  businesses to build custom internal apps really
• 17:03
  easily, right? But if those apps don't have strict
• 17:06
  content security policies to sanitize the data
• 17:09
  that users input, it creates a vulnerability.
• 17:12
  An attacker can type a malicious piece of JavaScript
• 17:15
  into a standard text field, say a customer feedback
• 17:19
  form. Later, when a highly privileged administrator
• 17:22
  opens that form to read the feedback, the malicious
• 17:25
  script executes silently inside the administrator's
• 17:28
  browser. While they're logged in. While they're
• 17:29
  logged in. It can immediately hijack their active
• 17:32
  session, effectively giving the attacker administrative
• 17:34
  control without ever triggering a login prompt.
• 17:37
  Wow. The hidden traps are just everywhere. And
• 17:40
  when things do go wrong, like we saw in the $71
• 17:42
  ,000 theft, you need a trail to follow. And the
• 17:46
  detail that really caught my eye here was regarding
• 17:48
  the system logs. Ah, yes, the logging failure.
• 17:52
  The audit found that log files were sometimes
• 17:54
  only retained for six months. Now, it's specifically
• 17:58
  noted that the Australian Signals Directorate
• 18:00
  recommends keeping them for at least 18 months.
• 18:03
  To someone running a regular business, six months
• 18:06
  of data storage might sound like a long time.
• 18:08
  Why is 18 months the magic number? Well, think
• 18:11
  of system logs as the black box of an airplane.
• 18:14
  They record every login, every file download,
• 18:17
  every permission change. We discussed earlier
• 18:19
  how the attacker in that BEC fraud just sat quietly
• 18:22
  in the account for a month. Right. The dwell
• 18:24
  time. Exactly. Advanced persistent threats, whether
• 18:27
  it's state sponsored actors or organized cyber
• 18:30
  criminal syndicates, they don't usually smash
• 18:32
  and grab. They infiltrate and then they wait.
• 18:34
  They map the architecture, escalate privileges,
• 18:36
  find the most valuable data. So they might be
• 18:38
  inside the network for the better part of a year
• 18:40
  before they actually detonate ransomware or wire
• 18:42
  money out. Exactly. Industry metrics consistently
• 18:45
  show that it can take an organization over 200
• 18:49
  days just to realize a breach has even occurred.
• 18:52
  200 days. Over 200 days. If your logs are set
• 18:55
  to auto -delete after 180 days, which is about
• 18:58
  six months, by the time your security team realizes
• 19:00
  you've been compromised, the initial evidence
• 19:03
  showing exactly how the attacker got in and what
• 19:05
  backdoors they created has been permanently erased.
• 19:08
  You have no black box. You have nothing. 18 months
• 19:11
  ensures that Even with a massive dwell time,
• 19:14
  your forensic investigators have the historical
• 19:17
  data required to find the root cause and properly
• 19:20
  eradicate the attacker from the network. It is
• 19:23
  incredibly sobering when you look at the aggregate
• 19:25
  of all these findings. But, you know, it's easy
• 19:27
  to read this report and just point fingers at
• 19:29
  the government. I actually think this audit is
• 19:31
  a perfect checklist for you, the listener, to
• 19:33
  evaluate your own organization. Oh, absolutely.
• 19:35
  So how do we turn these systemic failures into
• 19:38
  practical, actionable defenses? If our listener
• 19:42
  is sitting at their desk right now feeling a
• 19:44
  little overwhelmed and they only have the political
• 19:46
  capital at their company to push for one of these
• 19:48
  changes tomorrow, what is the absolute most critical
• 19:52
  first step? The first non -negotiable step is
• 19:55
  upgrading to phishing -resistant MFA. You have
• 19:58
  to move away from SMS codes and email OTPs. Okay,
• 20:01
  and what does true phishing -resistant MFA actually
• 20:05
  look like mechanically? It looks like hardware
• 20:07
  security keys, such as FIDO2 tokens. These are
• 20:10
  physical USB keys that you plug into your machine.
• 20:13
  They use asymmetric cryptography. So no more
• 20:15
  typing in six digits. Right. When you log in,
• 20:18
  the physical key mathematically verifies the
• 20:20
  actual domain of the website you are on. So even
• 20:23
  if an attacker tricks you into visiting a perfectly
• 20:25
  forged login page, the hardware key knows the
• 20:28
  domain doesn't match Microsoft's actual servers.
• 20:31
  And it just blocks it. It simply refuses to complete
• 20:33
  the cryptographic handshake. The phishing attack
• 20:36
  fails instantly. That is a phenomenal upgrade,
• 20:39
  especially for those privileged administrative
• 20:40
  users. Okay, what's next on the defense list?
• 20:44
  Next, you need to implement broad data loss prevention
• 20:47
  controls across the entire M365 suite. Right,
• 20:51
  the digital dye packs. Exactly. You need total
• 20:53
  visibility. Policies must span OneDrive, SharePoint,
• 20:57
  Exchange, and Teams. You have to know exactly
• 21:00
  when sensitive info is attempting to leave the
• 21:02
  environment. And you need the technical mechanisms
• 21:05
  to mathematically restrict that data, regardless
• 21:07
  of where it travels. And tied directly to that,
• 21:10
  I assume, is controlling and strictly limiting.
• 21:12
  that unmanaged cloud storage we talked about.
• 21:14
  You must eliminate the shadow IT. If work data
• 21:17
  is stored in the cloud, it must be in an approved,
• 21:20
  monitored, and secured corporate tenant. No more
• 21:23
  rogue Dropbox folders syncing sensitive client
• 21:25
  data to personal laptops. Yeah, and the report
• 21:28
  also heavily recommends implementing robust business
• 21:31
  email compromise defenses. Yes, which involves
• 21:34
  configuring anti -spoofing protocols like DMRC
• 21:36
  so attackers can't impersonate your partner domains,
• 21:39
  but it also means establishing automated threat
• 21:42
  hunting alerts. Like what kind of alerts? Well,
• 21:44
  if an end user suddenly creates a forwarding
• 21:46
  rule that sends all their inbox traffic to an
• 21:49
  external Gmail address, that shouldn't just be
• 21:52
  logged. It should trigger an immediate high priority
• 21:54
  alert that pages your IT security team. Right,
• 21:58
  because that's exactly what happened in the $71
• 22:00
  ,000 theft. Precisely. And finally, you should
• 22:04
  be adopting the ASD's Essential 8 framework and
• 22:07
  ensuring thorough security assessments of all
• 22:10
  third -party vendors before handing over any
• 22:12
  data. I mean, the vendor security is your security.
• 22:16
  Yeah, you really have to treat your identity
• 22:17
  and your data as the new security perimeter because
• 22:20
  that old concept of a trusted internal network,
• 22:24
  it simply doesn't exist anymore. It doesn't.
• 22:26
  And, you know, to kind of leave you with a final
• 22:28
  thought to ponder here, we talked about how the
• 22:30
  attacker spent a month manually studying an inbox
• 22:32
  to craft one perfect fraudulent invoice, right?
• 22:35
  Well, as generative AI becomes increasingly integrated
• 22:38
  into these cybercriminal toolkits, threat actors
• 22:41
  won't need a month. AI will be able to ingest
• 22:45
  an entire mailbox, mimic the communication style
• 22:47
  perfectly, and dynamically generate thousands
• 22:50
  of highly personalized, context -aware BEC attacks
• 22:54
  across an organization in seconds. That is terrifying.
• 22:57
  It is. If your defense relies on an employee
• 23:00
  manually spotting a slightly suspicious tone
• 23:02
  in an email, you will lose. Mathematical trust
• 23:05
  through hardware keys and data encryption is
• 23:07
  the only way forward. Because remember, the default
• 23:10
  settings on enterprise software platforms are
• 23:12
  designed for maximum convenience and immediate
• 23:14
  collaboration. They are not designed for maximum
• 23:16
  security. If you haven't actively configured
• 23:19
  your security settings, you aren't secure. You're
• 23:21
  just lucky. That is such a powerful point. If
• 23:24
  today's episode made you second guess your own
• 23:26
  setup, don't wait for an audit or a massive financial
• 23:29
  loss to find out what's missing. Visit www .kinsoft
• 23:32
  .com .au to discuss your security and IT needs.
• 23:36
  Thank you so much for joining Tech Talks with
• 23:37
  Kinsoft. Stay curious, stay secure, and we will
• 23:40
  catch you next time.