to the last episode
in the Cyber Security Architecture Fundamental series.
But this session
I would have an accelerated walk. True off a case study to help you visualize the process off cyber security architecture
going through all the things you have learned
in the last few lessons.
First, let's go to the background.
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.
This chaos will allow customers to test the products and make purchase Trent Interactive screen.
The idea would be to have many of these kills place around malls all over the city.
The security architect starts by asking the system architect for a diagram showing how the system will be deployed.
This is the diagram given to the security architect.
Starting from the left, an end user would goto a cures
and use the star WiFi to reach the clout
where the beck and processing is hosted.
This system will be accessible to the customer service agent
and also the logistic company that would pick and ship the product,
So the first thing the security architect would do is take a quick look at this and
identify all the threats he sees
moving from left to right. The first identified the 1st 1
which is the end. Users lock and credentials could be captured by a key logger in the chaos.
The next tread identified would be the WiFi connection.
Is it secure?
This raise concerns M would require the security architect to go back and ask more questions.
The next threat he sees.
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.
It's time for more questions.
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.
This example illustrates how important it is to get the iterative loop on getting the requirements and information.
You almost always never get all information up front.
As mentioned in my earlier sessions,
it's impossible to do this without a tool,
so the first thing I would do
let's take the model and put it into a tool. In this case, I'm using sea sponge.
Sea sponge is especially useful
to model deployment trends.
After putting in the model,
we start clicking on links and put in tread information.
In this case, I would say the ferry 1st 1 would be a key logging tread
once I hit. Enter the trip. It's now registered in the system as conceit in the lower left hand side of the window
track information window
off the modeling and identifying the treads. The next would be to categorize them.
In this case, if I use a strike model,
key logging would be under I information disclosure.
It could also be spoofing if the key is reused in the same attack.
After that, we would rank this treads. Now the exploit ability is pretty low, given that the always is locked down
and reproduce ability. It's all so low that it is a physical chaos that is also locked down with physical security.
The next step
is to apply some controls.
In this case, we would use all three types off controls for physical.
We will make sure that the terminal is securely locked,
not accessible, but unauthorized personnel.
From a technical control perspective,
we were ensure that the device is harden and do care is made to the configuration off the device
from an administrative control.
We were ensure that proper change control for updates has followed
and people cannot change the version or change the hardening configurations off the terminal.
Now we got to make assessment off the residue a risk
even with all the earlier controls put in place,
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.
This residue risk will be floated up to management to make a decision if it ISS within the risk tolerance level.
In this case,
management can employ additional background checks
to further supplement the controls
and then accept the risks.
This is a typical scenario you would see as an application architect.
With this recent controls in place, there are also architecture decisions to be made
for this case. I would choose one example.
We have to decide whether to use a physical keyboard at the cures or the software keyboard on the screen,
so creating the architectural design documents, first, less the subject
and the decisions to be made physical all software keyboard.
The next step is to state the issue,
which is easier
to steal credentials from
now. We have to put some assumptions in this.
The assumptions we have is that it's easier to pluck an inline USB key logger
toe a physical keyboard,
and you would not need any I T skills to do that
so you could bribe the security guard to do this. What was the motivation?
The motivation was to lower the risk for customers against keyboard logging.
What were the alternatives? Well, other than a USB keyboard, we could have considered using a Bluetooth keyboard.
The decision made was to use the onscreen keyboard
and why the justification would be physical keyboard pose a greater risk.
And while Bluetooth keyboards are safer,
they need power, which might increase operational costs.
Implications off this decision. Well, the screen will be touch a lot more and to us may need more maintenance.
any related decisions in this case there wasa decision to be made on the form of I D to be used.
I hope this example, shows you how a security architect would approach a problem
and how he would document some off the decision's made.
So in this session, re briefly walk true. A case study off how a cyber security architect would do his job.
We went through the model.
Do the tread identification.
Do the track model
come up with the controls and countermeasures,
identify the residue wrists submitted to management to make a decision
and also documents some off the architectural decisions made.
I hope you get a better understanding of how to string together all the previous sessions
to lend more. There are few Good resource is out there.
Firstly, in the S e I case study on approaching security from an architecture first perspective, they do walk true. How you could
the other is a Microsoft case study
on securing this talk to architecture.
Well, congratulations. This concludes the whole cause on cyber security architecture fundamentals.
Please stay tuned for more causes about security architecture.
Thank you. And I hope you enjoy the series.