Hello and welcome to
another application of the minor
attack framework discussion,
so today we're going to be going
through our case study for
the initial access phase of MIDA.
And so you might be asking, well,
what is it that we're going to be
looking at? Well, we're
going to be looking at HSBC
discloses a security incident.
And so I've got for
us here some excerpts
from the notification letter under
there. What happened and what
information was involved?
S.
Now, I do encourage you to
you can you can do a quick Google
search and just find this PDF
document and you can
view it and see it and kind
of feel it and mark it up, whatever
the case may be as you're going
through this process.
So what happened?
So HSBC became aware
of online accounts being accessed by
unauthorized users between October
4th, twenty eighteen and
October 14th.
Twenty eighteen.
When HSBC discovered your
online account was impacted, we
suspended online access to
prevent further unauthorized entry
of your account.
You may have received a call or
email from us so we could
help you change your online banking
credentials and access your account.
If you need help accessing your
account, please call.
And a number was provided there.
We apologize for this inconvenience.
HSBC takes this very seriously
and the security of your information
is very important to us.
What information was involved,
the information that may have been
accessed include your full name,
mailing address, phone number,
email address, date of birth,
account number, account types,
account balances, transaction
histories, Paey account
information and statement
history where available.
Now, in my mind,
this was a very
big amount of information
as far as the type of information,
had it just been names and maybe
some phone numbers, that would have
been a little
frustrating because then we're
dealing with maybe spammers or
something like that.
But date of birth, email address,
phone numbers, mailing addresses,
account types and balances,
everything that's involved here is
a perfect storm for
threat actors or identity thieves to
try and compromise other accounts
or pose as these users
because they have a lot of
legitimate information
that was involved here.
So what
should have been done?
So this is where you come into play
as far as doing this case study.
So sources indicated that credential
stuffing was a likely reason that
accounts were compromised.
So this is when an attacker uses a
combination of usernames and
passwords which may have been
obtained from a previous breach.
OK, so
that's important.
We discussed this in valid
accounts when we talked about valid
accounts in that threat,
actors will purchase or
compromise one system
and get a list of usernames
and passwords and
then they will pass those through
other systems and attempt to gain
access to user accounts.
So the first thing that we want to
look at is in the minor framework,
which in your initial access
factor, most suits this scenario.
And would the mitigating factors
under that vector have prevented or
reduce the risk that compromise?
And so would I encourage you to do?
Is read the information
concerning the HSBC
security incident.
Understand the language that they're
using and the scenario,
and then see if there were
any particular mitigating
factors that could have been applied
based on the vector
you choose that
could have reduced risk or
potentially prevented such
a thing from happening.
Now, the other thing that we run
into here is
when we talk about this
potentially being from a separate
compromise where usernames
and passwords were exposed
and the threat actors just
used the usernames and
passwords that were
used on other sites by the end
users.
Do the users of the bank have any
culpability if they
used credentials?
And so you have to ask yourself
in this day and age when we're aware
of.
The threats that are out there when
we're being told to not
reuse passwords across
multiple accounts, especially banks
or mortgages or things of
that nature, financial information,
credit check, data, health
information, and we've
got tools out there that
help us to manage passwords and set
complex passwords and implement
multifactor with indication.
Do the end users have any
culpability there?
Now, the bank ultimately
has to, you
know, clean up the mess and
implement additional controls.
They could have done certain things
that we won't discuss here because
that's part of your case study.
But you have to bring into
this user culpability.
And while it's ultimately
not one hundred percent the bank's
fault or one hundred percent the end
users fault, there needs
to be better hygiene and better
practices there as well.
So think about some controls that
as end users we need to take
advantage of to protect ourselves as
well as you're writing up
this particular review and looking
at controls against
this particular case.
So with that in mind,
I want to thank you for your time
today, and I look forward to seeing
you again soon.