7.1 Case Study

00:00

Welcome back

00:02

to the last episode

00:03

in the Cyber Security Architecture Fundamental series.

00:09

But this session

00:10

I would have an accelerated walk. True off a case study to help you visualize the process off cyber security architecture

00:19

going through all the things you have learned

00:22

in the last few lessons.

00:25

First, let's go to the background.

00:28

The back wall off This case study is the PR play e commerce company that wants the launch of physical cures that will allow bias without critic heart to use Q r code to pay for your orders.

00:40

This chaos will allow customers to test the products and make purchase Trent Interactive screen.

00:46

The idea would be to have many of these kills place around malls all over the city.

00:54

The security architect starts by asking the system architect for a diagram showing how the system will be deployed.

01:02

This is the diagram given to the security architect.

01:07

Starting from the left, an end user would goto a cures

01:11

and use the star WiFi to reach the clout

01:15

where the beck and processing is hosted.

01:19

This system will be accessible to the customer service agent

01:23

and also the logistic company that would pick and ship the product,

01:30

So the first thing the security architect would do is take a quick look at this and

01:36

identify all the threats he sees

01:40

moving from left to right. The first identified the 1st 1

01:44

which is the end. Users lock and credentials could be captured by a key logger in the chaos.

01:52

The next tread identified would be the WiFi connection.

01:57

Is it secure?

01:57

This raise concerns M would require the security architect to go back and ask more questions.

02:06

The next threat he sees.

02:07

It's the rotor use by the store. This could be the route a supplied by the mall, and he has no idea what the security off that rotter is. Again.

02:20

It's time for more questions.

02:23

The next thing he noted was that it's on the clock, but he has no idea which cloud and what service's are on the cloud.

02:32

This example illustrates how important it is to get the iterative loop on getting the requirements and information.

02:40

You almost always never get all information up front.

02:46

As mentioned in my earlier sessions,

02:50

it's impossible to do this without a tool,

02:53

so the first thing I would do

02:55

let's take the model and put it into a tool. In this case, I'm using sea sponge.

03:04

Sea sponge is especially useful

03:06

to model deployment trends.

03:09

After putting in the model,

03:12

we start clicking on links and put in tread information.

03:17

In this case, I would say the ferry 1st 1 would be a key logging tread

03:23

once I hit. Enter the trip. It's now registered in the system as conceit in the lower left hand side of the window

03:31

track information window

03:35

off the modeling and identifying the treads. The next would be to categorize them.

03:40

In this case, if I use a strike model,

03:44

key logging would be under I information disclosure.

03:50

It could also be spoofing if the key is reused in the same attack.

03:55

After that, we would rank this treads. Now the exploit ability is pretty low, given that the always is locked down

04:04

and reproduce ability. It's all so low that it is a physical chaos that is also locked down with physical security.

04:15

The next step

04:16

is to apply some controls.

04:19

In this case, we would use all three types off controls for physical.

04:26

We will make sure that the terminal is securely locked,

04:30

not accessible, but unauthorized personnel.

04:33

From a technical control perspective,

04:36

we were ensure that the device is harden and do care is made to the configuration off the device

04:46

from an administrative control.

04:48

We were ensure that proper change control for updates has followed

04:54

and people cannot change the version or change the hardening configurations off the terminal.

05:02

Now we got to make assessment off the residue a risk

05:08

even with all the earlier controls put in place,

05:11

the rested we'll risk could be a malicious insider who can hide a key logging malware into the source code and be uploaded in the next release cycle.

05:24

This residue risk will be floated up to management to make a decision if it ISS within the risk tolerance level.

05:33

In this case,

05:35

management can employ additional background checks

05:39

to further supplement the controls

05:42

and then accept the risks.

05:46

This is a typical scenario you would see as an application architect.

05:51

With this recent controls in place, there are also architecture decisions to be made

05:58

for this case. I would choose one example.

06:01

We have to decide whether to use a physical keyboard at the cures or the software keyboard on the screen,

06:10

so creating the architectural design documents, first, less the subject

06:15

as authentication

06:17

and the decisions to be made physical all software keyboard.

06:24

The next step is to state the issue,

06:27

which is

06:29

which is easier

06:30

to steal credentials from

06:32

now. We have to put some assumptions in this.

06:35

The assumptions we have is that it's easier to pluck an inline USB key logger

06:43

toe a physical keyboard,

06:45

and you would not need any I T skills to do that

06:47

so you could bribe the security guard to do this. What was the motivation?

06:54

The motivation was to lower the risk for customers against keyboard logging.

07:00

What were the alternatives? Well, other than a USB keyboard, we could have considered using a Bluetooth keyboard.

07:09

The decision made was to use the onscreen keyboard

07:13

and why the justification would be physical keyboard pose a greater risk.

07:18

And while Bluetooth keyboards are safer,

07:21

they need power, which might increase operational costs.

07:26

Implications off this decision. Well, the screen will be touch a lot more and to us may need more maintenance.

07:33

Lastly,

07:34

any related decisions in this case there wasa decision to be made on the form of I D to be used.

07:43

I hope this example, shows you how a security architect would approach a problem

07:48

and how he would document some off the decision's made.

07:54

So in this session, re briefly walk true. A case study off how a cyber security architect would do his job.

08:03

We went through the model.

08:05

Do the tread identification.

08:09

Do the track model

08:11

come up with the controls and countermeasures,

08:13

identify the residue wrists submitted to management to make a decision

08:18

and also documents some off the architectural decisions made.

08:24

I hope you get a better understanding of how to string together all the previous sessions

08:31

to lend more. There are few Good resource is out there.

08:35

Firstly, in the S e I case study on approaching security from an architecture first perspective, they do walk true. How you could

08:46

the other is a Microsoft case study

08:48

on securing this talk to architecture.

08:54

Well, congratulations. This concludes the whole cause on cyber security architecture fundamentals.

09:01

Please stay tuned for more causes about security architecture.