Security is a big deal. It's also, very unfortunately, an afterthought for a lot of companies and apps at which point there could potentially be a number of technical and political challenges to implement the necessary changes.
The stark reality that a lot of people don't like to face is that there's no way to prevent every attack. There are new types of attacks that surface all the time. The only way to truly secure a machine is to turn it off and lock it away. But that's not practical if you want clients to be able to use it. Of course, there's a lot of ways to secure it that are not quite that drastic including minimizing attack surface by shutting off things you don't use, closing ports you don't need, having intelligent firewalls, having a proper data tier that scrubs for SQL injection attacks, encrypting your data at creation, in transit and at rest and so on. But realize that many of the security protocols you can implement have other consequences, some of which are performance related and others straight up limit functionality. Even with all of those measures in place, there will still be breaches.
So the question is what should you spend your time, energy and money on?
First, make sure that you have absolutely amazing and comprehensive logs so that you can perform a retrospective on any intrusion. You'll need to be able to track down how they got in, what they had access to and if at all possible look for motivations.
Second, my recommendation is that you start with threat modeling. Threat modeling offers a structured strategy to look at potential threats and secure your application and data.
One great resource for this is the Microsoft Security Development Lifecycle.
- Identify assets - make a full list of anything that could be considered an asset in the application and rate the impact if it's compromised in some fashion including deleted, stolen and/or altered.
- Create an architecture overview - this includes a full set of diagrams of the application architecture, state diagrams, data flows and your trust boundaries.
- Decompose the application.
- Decompose the architecture of your application - including the underlying network and host infrastructure design, to create a security profile for the application. The aim of the security profile is to uncover vulnerabilities in the design, implementation, or deployment configuration of your application.
- Identify the threats - this is the step that I always have fun with. You need to think like an attacker. What are their actual goals? Reality is that different attackers have different goals so you'll have to brain storm what are the different types of attackers. Are they trying to steal something from you? Are they trying to destroy something? Are they using your system to attack something else? For example, I was working with an IoT startup that does a motion activated security camera. It's a cool concept and they had some a great job with a lot of the security except that I pointed out that if there was data on the wire, someone was at home, if not, nobody is home. This was something that they hadn't thought of not because they weren't being thorough but because they weren't thinking like a home invader.
- Document the threats - make sure that you capture the same data for all of the potential threats so that you can do the next step appropriately.
- Rate the threats - not all threats are equal. Look through the possible threats and with each one rate the possible fallout if there is a breach. This will give you your priority list of things to secure. Turns out that there are some threats that are low enough on the priority list that the effort involved outweighs the danger. For example, if someone deletes cached data but not the source data, chances are you can recover from that without a lot of issues. But if someone can alter the source data, that's a lot bigger of an issue.
But don't forget to log everything and do proper retrospectives on every breach.
I strongly recommend reading the Improving Web Application Security: Threats and Countermeasures - yes, it's from 2003 but it's still an awesome resource. Also, leverage the resources at the security development lifecycle.