[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.