Time
3 hours 11 minutes
Difficulty
Beginner
CEU/CPE
3

Video Transcription

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.
09:05
Thank you. And I hope you enjoy the series.

Up Next

Fundamentals of Cybersecurity Architecture

This cyber security architecture class aims to give an appreciation of the various aspects of consideration that goes into a proper security architecture.

Instructed By

Instructor Profile Image
Ian Loe
Sr. Vice President at NTUC Enterprise Co-operative Limited
Instructor