[MUSIC]
Hello again. In this lesson, I want to continue
to use a STRIDE method and create a list of vulnerabilities,
that we want to fix. Using the example system
from our previous lesson. After this lesson you'll be able to
describe the individual components of STRIDE and
apply STRIDE in an example system. Let's dive in. S stands for Spoofing. Can a malicious user pretend
to be a different user? From the design document outlined
previously, we have not yet determined the mechanism to enforce
the type of user accessing the system. For example, we would need unauthorized
users to log in and obtain a token, then the user's access level is
determined by their token information. T for tampering. Can a malicious user modify
data used by the system? We have not yet specified an encryption
mechanism to protect the data flow between the client and the server and
the server and the database. Encryption would prevent data
tampering between these data flows. We would also want to
encrypt the data at rest. For example, when the data is saved. R for repudiation. Can a malicious user deny that they
have performed an action to change the system state? We have not yet specified logging
mechanisms for server requests. Logging would help us to keep an account
of what has been done in the system. I is for information leakage. Can a malicious user extract
information that should be kept secret? As with the tampering case, we have not
yet specified an encryption mechanism to protect the data flow between
the client and the server, and the server and the database. Encryption would prevent eavesdropping
between these data flows. We would also want to
encrypt the data at rest. In other words, when the data is saved. D for denial for service. Can a malicious user exhaust system
resources such that the system can no longer function as intended? Further testing and code review
must be done in order to ensure that system resources such as locks,
file handles, ports etc, have been properly accounted for and
cleaned up where no longer needed. Depending on client request numbers
that the stakeholders expect, perhaps a load balancer could
be used to front the server. E for elevation of privilege. Can a malicious user increase their
ability to work with system resources? From the design document outlined
previously, we have not yet determined the mechanism to enforce
the type of user accessing the system. For example, we would need unauthorized
users to log in and obtain a token. The user's access level is determined
by their token information. We would need to create
a mechanism such that the client would not be able to tamper with
a token to gain extended privileges. So from the initial list created
using the STRIDE method. In other words going
through this pneumonic. S-T-R-I-D-E for spoofing, tampering, repudiation, information leakage, denial
of service and elevation of privilege. We can use it as a way to brainstorm
different ways a threat actor could act against our system and take advantage
of either data or system resources. Now, having thought through that and seeing this example, we can see that we
need the following security requirements. Encryption for both data and
transit, and at rest. Some form of authorization,
perhaps a token or a similar mechanism. We would also need logging. That's related to system state changes. And we would also need to
perform further code review of the handling of system resources. Now, in conclusion, we can use the STRIDE
mnemonic, which stands for Spoofing, Tampering, Repudiation, Information
leakage, Denial of Service, and Elevation of privilege as a way to come
up with different ways to determine where threat actors will take
advantage of our system. And this brainstorming
method is a good first step in looking at where we would need to
modify our system and improve it. From this list that we've gathered we can
then view the list and think about how to prioritize where we want to spend
time improving it and making changes. And in this way, we can make our
system more robust, thank you.