Emma Armstrong

27 May 2014

Take security in your STRIDE

When you phone up for house insurance, the insurance company asks you; ”Do you have a five lever mortice deadlock? Does it comply to BS3621? Do you have a burglar alarm and so on?  These are all very standard questions for this situation, and we need to make sure we are asking similar questions of the security of the software we’re producing. Just like with other parafunctional aspects of our applications like performance & usability, we need to assess the security needs and make decisions based on this.

Identifying potential points of vulnerability in your system

Draw a reasonably high level architecture diagram of your product, showing where parts of the system will be housed/hosted and identify the communication points. On this diagram, identify the points where data in your system or the execution of the application change their level of “trust” (a trust boundary) e.g. where it communicates over the public internet.

Now for the Spanish inquisition

Question your system based on the types of threat it could come under, using the STRIDE mnemonic:

Spoofing (where someone masquerades as someone else and gains access.)

• check whether the credentials are being sent or stored in plain text
• can the authentication be bypassed? e.g directly calling an internal page
• are we using security tokens (e.g. cookies), and can they be reused to bypass security?

Tampering (the data itself is tampered with)

• can the data be captured and rehashed?

Repudiation (whether the actions can be traced)

• can incorrect data be entered into the logs?

Information Disclosure (people can see information that they shouldn’t)

• can the application be made to fail in a way that exposes information it shouldn’t?

Denial of Service (the system can be prevented from providing access to valid users)

• can the system be flooded with requests such that it stops responding to valid ones?

Elevation of Privilege (someone can gain access to a privileged part of the system)

• when are we checking a user’s authorisation to view information?

Once you’ve thought about these things, you can assess the impact of any vulnerabilities being exploited, and determine whether or how to mitigate the risk. For the testers amongst you, you can use these to determine tests that you would carry out to try and exercise these threats against the system. Please remember the levels of risk that these issues pose are relative, and the safeguards that we need to use will differ based on how and where the software is being used.

But the need to ask the questions does not change!