Initial Access Case Study

00:00

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 minor. And so you might be asking. Well, what is it that we're going to be looking at? Well,

00:16

we're going to be looking at HSBC discloses a security incident and so I'm got for us here. Some excerpts from the notification letter under there. What happened and what information was involved. Section

00:32

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, is your going through this process?

00:45

So what happened? So HSBC became aware of online accounts being access by unauthorised users. Between October 4th 2018 and October 14th 2018

00:56

when HSBC discovered your on line account was impacted, we suspended online access to bribe prevent further unauthorised entry of your account.

01:06

You may have received a call or email from us so we could help you change your arm on banking credentials and access your account. If you need help accessing your account, please call and a number was provided there.

01:18

We apologize for this inconvenience. HSBC takes this very seriously and the security of your information is very important to us.

01:26

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,

01:40

pay account information and statement history where available

01:45

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 simp own numbers, that would have been, Ah, little, you know, frustrating because then we're dealing with maybe spammers or something like that,

02:01

but data, birth, email, address, phone numbers, mailing addresses, account types and balances.

02:07

Everything that's involved here is a perfect storm for threat actors or identity thieves to try and compromise other accounts or opposes thes users because they have a lot of legitimate information that was involved here. So

02:24

what should have been done? So this is where you come into play as faras dealing 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 user names and passwords, which may have been obtained from a previous breach. Okay,

02:44

so that's important. We discussed this invalid accounts when we talked about valid accounts.

02:52

In that threat, actors will purchase or compromise one system and get a list of user names and passwords,

03:00

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 its initial access vector, most suits this scenario.

03:15

And would the mitigating factors under that vector have prevented or reduced the risk with compromise? And so what I encourage you to do

03:23

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

03:42

that could have reduced risk or potentially

03:45

prevented such a thing from happening Now, the other thing that we run into here is

03:51

when we talk about this potentially being from a separate compromise where user name and passwords were exposed

04:00

and the threat actors just used the user names and passwords that were used on other sites by the end users.

04:09

Do the users of the bank have any culpability

04:13

if they re used credentials? And so you have to ask yourself,

04:15

in this day and age, when we're aware of

04:20

the threats that are out there when we're being told to not reuse passwords across multiple accounts, especially banks or mortgages or, you know things of that nature, financial information, credit, check data, health information

04:33

and we've got tools out there that help us to manage passwords and set complex passwords and implement multi factor authentication,

04:43

do the end users have any culpability? They're now The bank ultimately

04:46

has to,

04:48

you know, clean up the mess and implement additional controls. They could have been, you know, done certain things that we won't discuss here because that's part of your case study.

04:58

But you have to bring into this, you know, user culpability. And while it's ultimately

05:04

not 100% the banks fault or 100% the end users fault,

05:10

there needs to be better hygiene and better practices there as well. So think about some controls that, as in users, we need to take advantage of to protect ourselves as well. Edger writing up this particular review and looking at controls against this particular case. So with that in mind,

05:28

I want to thank you for your time today,