Every computer application, no matter how complex, consists of components that lie in the following categories
a) Processes
b) Data channels
c) Data stores
d) Interactors
[Readers familiar with DFDs or data flow diagrams will instantly recognise that these categories.] Start out by decomposing the system into smaller components and start creating DFDs of the same. Creating the DFDs will help the reviewer in the following way:
- Will give you a deeper understanding of the system.
- Will force application teams to think about their application and stimulate security discussions even before the security review begins!
Identify Threats
Behavioural Tips
Do not adopt an extremist stance when identifying threats. Do not give the app teams the impression that you are policing and judging their application. Remember, you goal is to prise out as much as possible from the app team. They are your best source of threats! Dont start out with "Do you realize that your application can be attacked in this manner?". Instead say something like, "Lets try and find out how the application responds to this threat.".
Technical Tips
I have come to realize after no matter what your threat, they will always lie in one or more of the following categories:
- Loss of confidentiality - Data ends up getting read by someone other than the intended user.
- Loss of integrity - Data has been tampered with and the system (or user) can no longer trust the data.
- Loss of availability - The application has gone for a toss and is no longer providing the expected quality of service (sluggish or totally down system)
- Damage of the contract between a user and his credentials - This manifests in the form of repudiating (user denying having carried out certain operations), impostoring (user forging as someone else or worse still, getting through without authenticating to the system)
