**Using Risk Management and Mitigation in Web Development**
R = V * I * L
$$ Where: R = Risk of an attack, V = Value of the web application or asset, I = Impact of the risk and L = the likelihood of the risk occurring. For instance, take a server whose value is rated at 10. If the impact of it being down due to a DDoS attack is 10 and the likelihood of it happening stands at 10 too, the risk is calculated as: $$
R = 10 * 10 * 10
$$ This is the highest risk that your business can be exposed to (1000). You shouldn’t overlook this. Address the elephant in the room and focus resources and expertise on this issue to reduce the chances of it coming to life. Risks like these should always have the highest priority. In contrast, imagine that your business is based on serving content, such as a blog or informative website. The only data being sent between your users and the application are simple HTTP requests to the server to return the requested content. An attack like a MitM won’t yield any important information to the attacker, other than the IP address of the user – which isn’t all that useful in the vast majority of the cases. Thus, the server value is 10 (it’s integral to serving data to the users), but the impact of the MitM attack isn’t all too high. Say, we assign it a 5. Since such an attack doesn’t yield the attacker much value, the likelihood of it happening isn’t too high either, so let’s assign a 5 for that as well. Thus, the risk of this attack would be: $$
R = 10 * 5 * 5
$$ The risk value of this attack (250) is significantly lower than the aforementioned attack.
Introduction
Customers and key stakeholders place a lot of trust in the reliability of your web application. They trust that their data is secure from unwanted access on the servers, while still seamlessly allowing wanted access while they’re using it. Many things can happen to compromise data-safety and application reliability. Some of these are common and some are rare, but it’s a fact that they’re inevitable. You cannot avoid malicious users from trying to exploit the holes in your application’s armor. For instance, a Denial of Service (DoS) attack can take your service offline by overloading the traffic your servers can take. In practice, these attacks are distributed (Distributed DoS, or DDoS for short) over a large network of attackers, making them even harder to track down. While the service is down, the best-case scenario is just users being unsatisfied. The worst-case scenario would be users losing an obscene amount of money due to the services being out. These attacks are countered with filtering and picking out the invalid connections and denying them access to the service. Another common attack is the Man-in-the-middle (MitM) attack, where a malicious user acts as a middleman between the data being sent between a client (user) and your servers. There are multiple types of MitM attacks such as ARP Spoofing, IP Spoofing and DNS Spoofing. Furthermore, they can sniff the data being sent, hijack the session and take control of it or even inject packets to compromise the original data package. This data can be trivial, but it can also be highly sensitive – like credit card or personal information. These attacks are countered by adequate encryption of data that’s being transferred. Even if there is a middleman collecting it, they can’t make sense of it. Furthermore, using secure channels such as HTTPS over HTTP also helps. Database-driven services are more prone to SQL Injection attacks, where an unwanted user gains privileges in your database. It’s enough to have the most basic database privileges to be able to extract enough information to cause havoc, depending on how sensitive the data is. These attacks are made possible with even the slightest oversight in the design and architecture of the application and the lack of query checks in the back-end. Cross-site Scripting (XSS), Eavesdropping attacks, Malware attacks, Phishing, DNS Tunneling – there’s a myriad of well-known attacks that your application can be subjected to. And again, it’s inevitable to experience at least a single one. That being said, from start to finish, data-integrity and application security should not be an afterthought. Focusing on risk management is an essential part of ensuring customer safety and satisfaction. It’s up to you and your team to identify which attacks your application will be prone to, and which protection measures you’ll be implementing. Here is how you can use Risk Management and Mitigation to increase the reliability of your web app.Start with Risk Assessment
The first step for achieving effective risk management is to create a list of the risks that your web application faces. If your application transfers sensitive information between clients and servers – expect a MitM attack. If your application sends a lot of emails with attachments – expect a Phishing attack. If your application handles time-based transactions, such as stock market brokers – a DDoS attack can turn everything upside down. Next, you will need to quantify the risks that the application faces. Quantification makes it easy to compare risks, identify the most impactful ones, and pick suitable risk control measures. When quantifying the risk, you will need to rate the value of your asset, the severity of the risk, and the likelihood that the risk will occur. In most cases, a scale rating that ranges from 1 to 10 will suffice - with 10 holding the greatest weight. To quantify a possible risk, simply use this equation: $$R = V * I * L
$$ Where: R = Risk of an attack, V = Value of the web application or asset, I = Impact of the risk and L = the likelihood of the risk occurring. For instance, take a server whose value is rated at 10. If the impact of it being down due to a DDoS attack is 10 and the likelihood of it happening stands at 10 too, the risk is calculated as: $$
R = 10 * 10 * 10
$$ This is the highest risk that your business can be exposed to (1000). You shouldn’t overlook this. Address the elephant in the room and focus resources and expertise on this issue to reduce the chances of it coming to life. Risks like these should always have the highest priority. In contrast, imagine that your business is based on serving content, such as a blog or informative website. The only data being sent between your users and the application are simple HTTP requests to the server to return the requested content. An attack like a MitM won’t yield any important information to the attacker, other than the IP address of the user – which isn’t all that useful in the vast majority of the cases. Thus, the server value is 10 (it’s integral to serving data to the users), but the impact of the MitM attack isn’t all too high. Say, we assign it a 5. Since such an attack doesn’t yield the attacker much value, the likelihood of it happening isn’t too high either, so let’s assign a 5 for that as well. Thus, the risk of this attack would be: $$
R = 10 * 5 * 5
$$ The risk value of this attack (250) is significantly lower than the aforementioned attack.
Choosing Risk Mitigation Options
Different risks can be treated differently by your business, depending on the available resources and the impact that the risk can have. There are four risk treatment options - transferring the risk, mitigating it, ignoring it, and accepting it. For risks that can be shared with another individual or organization, consider transferring them. For instance, buying cyber-insurance can help you mitigate the risks of many types of standardized attacks. There’s no need to implement solutions in-house for this, if you don’t have the time or resources. Of course, a certain amount of in-house solutions to common problems shouldn’t be hard to implement – such as encrypting transfer data, using secure transfer mediums, hashing passwords, etc. If a risk is too trivial to have an impact, you should ignore it. For risks that can't maim your web development process and application, without you having solutions to them, you should completely ignore them.Solutions to Web Development Risks
Use Agile Techniques to Deal with Technical Debt
In the interest of development cost and the time to market, development teams are sometimes forced to leave applications with some loopholes that can lead to issues down the road. The goal is to revisit such issues later on and solve them once the application is already on the market. However, there are cases where the unsolved issues heap up, making resolving them a huge financial investment and time commitment. Technical debt is increased with each step you take, as long as an underlying issue isn’t resolved. The more fixing these issues is put off, the more of an investment it will be to fix them. Additionally, your team will likely be more inclined to keep building upon what exists, instead of dismantling it to fix loopholes. This can easily lead down the slippery slope of putting it off in the name of development cost and meeting deadlines – which ultimately results in unstable and unreliable applications. Instead of waiting to stress your guests with bugs and causing headaches for everyone in the team, you could use agile techniques to help solve these issues early on.“If you think good architecture is expensive, try cheap architecture”. – Brian Foote
