When developing software, there are many different dimensions of risk you might consider. There is an enormous amount of information available on Risk Assessment, consider this to just quickly skimming over the topic. Depending on your understanding of risk (or your paranoia), trying to assess risk can be a difficult task. There are several approaches that people use to assess risk. Most of the names for these approaches are not official, they are just what I think of when trying to describe what I have seen.
Ignore and Hope
Many people and companies use this approach. They might say No one is going to attack us, we’re not a big enough target.
Or, all of our users know this is just a hobby project and they shouldn’t trust us with real data.
If you are working on anything more than quick script that only you run, on your own system, you probably have more risk than you think.
Gut Check
The next level of risk assessment is a simple exercise in What could go wrong?
Some experienced developers have developed a feel for changes or features that make them nervous. Those things are definitely more risky. They often ignore risks until they see something that triggers those concerns. Examples might include:
- Restricted access, through log in, etc.
- Credit card handling
- More than n users (where n is 1,000, or 10,000, or something)
- Big companies start using their software
For many, the transition from ignore and hope to gut check comes from either experiencing a failure, or hearing about one in a similar system or industry.
SWAG
This is where people start being intentional about identifying risk. They may begin with a list of things that have happened in the past, or a list like the OWASP Top 10. The main difference between this level and the gut check is that the developers are actively thinking about risks and trying to guess how vulnerable the software is.
The risk assessments from this stage are usually not repeatable. The assessments depend very much on the experience of people doing the assessment. Since the process is not well defined, it is very hard to teach new people to do assessments.
Qualitative Risk Assessment
Some questions you might ask to decide how to think about risk in your software include:
- Is the software used by just you or by others?
- Are the others technical people or users?
- Is the software running in a production environment?
- Does the software handle important information?
- Does the software deal with money or payments?
- Do people depend on the software to do their jobs?
- Do people’s lives or health depend on the software?
At this level of risk assessment, we are beginning with the software and analyzing the ways it interacts with the environment. These questions are often informed by a list of risks like the OWASP Top 10. The team looks more carefully at their own data, usage patterns, and environment. Most of the focus is on what can go wrong.
This approach is more repeatable than the previous versions, but still misses an important dimension. Since this stage does not focus on the likelihood of failure, it can result in too much attention paid to unlikely risks or too little attention being paid to very important risks. A couple of unlucky breaks can derail an team’s risk management strategy for quite a while.
Quantitative Risk Assessment
People who are serious about risk management suggest that the least you should do for risk assessment is to identify every risk you can and score them on two dimensions: likelihood of occurrence and impact of failure. These dimensions give the team a framework to use to determine which risks to focus on. If a risk is extremely likely to happen and would result in the company failing, it’s obviously more important that an extremely unlikely event that might result in the ability to display innocuous data.
Different systems exist for rating the dimensions. For likelihood, you could use s fuzzy categorization such as: Rare, Unlikely, Normal, Likely, and Very Likely. Or, you could calculate the odds of the event occurring, resulting in an actual number. Likewise you could list impacts in different categories: Data Loss, Money Loss, Reputation Loss, Attack on User’s Systems, etc. You could even measure impact in terms of lost revenue or fines.
Conclusion
Whichever method you use, assessing risk in a critical part of managing risk.