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
Don't Gold-Plate your Application
Although at first sight it seems like a nice gesture to include some extra features that weren't originally in the specification - this is considered bad management.
More often than not, teams barely have time to build what is in the specification. If you've got time to spare, it's likely that something was overlooked. Instead of focusing time, money and energy into out-of-spec upgrades, first, make sure that the rest of the product is as good as it can be.
Adding any type of new feature also brings in its own risks. Again, risk management shouldn't be an afterthought. Adding features due to extra time is an afterthought.
Encrypt Your Data and Traffic
Although modern encryption algorithms have proven to be virtually unbreakable, their low usage among development teams is alarming. Unlike a long time ago, modern systems can handle encryption without affecting app performance. Encryption is the first and one of the most basic ways to protect your data's integrity, and definitely shouldn't be skipped.
Ensure that you encrypt both web traffic and the data stored in your server to limit the damage that can be done when your application is exposed to a risk.
Focus on Testing and Maintenance
Any risk treatment solution you choose should be tested for its effectiveness. Setting the right Key Performance Indicators (KPIs) will help you gauge whether it is effective enough or not.
This is not the end of it; you need to keep tabs on the effectiveness of these solutions as time goes by. Risk treatment solutions’ effectiveness might change as new threats arise or once you make changes to the application. It would be wise to constantly reassess your risk management strategies to ensure your application is as reliable as possible.
Risk management should be an innate part of web application development, instead of an afterthought. With it playing a center-stage role in the development of your application, it becomes easy to resolve common issues at their root long before they can turn into a menace.
Implement risks management practices to maintain the trust key stakeholders have in your business.
About the Author
Jordan MacAvoy is the Vice President of Marketing at Reciprocity Labs and manages the company’s go-to-market strategy and execution. Prior to joining Reciprocity, Mr. MacAvoy served in executive roles at Fundbox, a Forbes Next Billion Dollar Company, and Intuit, via their acquisition of the SaaS marketing and communications solution, Demandforce.