Any project or software includes potential risks. Will it do the job or fail? Will it leak user information? Will it serve as a springboard for attacking other systems? When you realize the need to learn how risky your software is, there are a number of approaches to assessing that risk.
If a piece of software never impacts anyone else and accesses no data that you don’t control, you may be able to ignore risk. A production system is another matter. Despite that fact, we repeatedly see companies fail to manage risk resulting in serious consequences for the company, their customers, and even various bystanders.
To deal with risk, you need to:
- assess the risk
- determine your risk tolerance
- eliminate the risks that you can
- mitigate the remaining risks
- repeat the above, as needed
Assess the Risk
The idea behind assessing risk is determining what can go wrong, the effects when it goes wrong, and whether or not we need do anything about it going wrong. This is actually a big enough topic that I’m going to have a whole separate post on it next time.
As an example for the following steps, let’s assume we are looking at an e-commerce site. You would probably have user accounts and credit card information. This is a pretty obvious risk. If you lose control of your customer’s credit card information, you could easily lose your business.
Eliminate Some Risks
You can start by eliminating whatever risks you can. Only add functionality to the software that it requires for its goal. Don’t add extraneous features, knowledge, or privileges. The third post in the series will talk further on ways to eliminate risk.
Mitigate Remaining Risks
In many cases, you cannot eliminate all of the risk in a system while maintaining the required functionality. The only option is to attempt to mitigate the remaining risk. Once again, risk mitigation is a large enough topic that I’m going to devote a post to it. But, the short description is to reduce the impact or likelihood of the risk. The fourth post will discuss ways to mitigate risk.
Repeat
In real life, the system or software and its environment will change over time. This also means that risks changes over time. A prudent developer should revisit the risks in the system each time it is changed or they become aware of a change in the environment.
Incident Handling
This is the final stage in risk management. No matter how carefully you have considered the risks and what you have done to prepare, something will inevitably happen. It is important that you have procedures in place to deal with an incident. Without defined procedures, people make snap decisions based on the urgency of the moment. That can easily make the incident worse. The final post in the series will make some suggestions on handling incidents.