This blog is about exactly eight-eight (88) free or low cost practices to make your applications more secure. I will not bore you to death by going all wayang about APTs (Advanced Persistent Threats), Big Data or BYOD (Bring Your Own Device). I just mention those buzzwords since the Google search algorithm thinks you are more relevant in your industry when you repeat the marketing terms of your competitors.
There are indeed exactly eighty-eight (88) ways to make your application more secure, no less, no more. Stuff that matters (sorry Slashdot) or that will matter in the future. Stuff that is nearly free, stuff that you can understand without explanation of a consultant, stuff that needs no tools.
Stuff that is not listed as best practice, but is based on the same level of academic scrutiny as everyone else’s best practices, which is unfortunately none in most cases.
I will list a few practices to start but I count on all of you, the brightest minds in or outside the application security industry, to come up with more of them. Just do something relevant next Friday afternoon.
Every rule is characterized by its name, the explanation of what it is, and an explanation of why this is so important that millions of hours will be lost to the advancement of humanity by
- Tweeting that you had a moment but not telling the rest of the world what is was. (“I looked into the mirror today, smiled and thought ‘Yes, this it is. This brings meaning to my life’. I told my puppy.”
- Posting a likeable post on Facebook that nobody cares to understand (“Good morning. An Apple fell on my head today and did not bring law suits.”)
- Posting the exact location where you had this flash of insight on Foursquare (“Under a tree”).
- Name: the name must fit in one, beautiful, short heading and explain what to do
- Why: no more than 5 sentences where you explain the reason to a non-technical and non-security educated audience.
- Notes: anything that contradicts everything you just described.
All rules are of course meant to be broken, especially in the security industry.
The Ultimate List
1. Install a real SSL certificate on your development and test servers
Why: A SSL certificate provides confidentiality by using encryption and can make sure that the app is connected to the right server. When your test servers use fake certificates, developers need to bypass standard mechanisms to verify that your app is indeed connecting to the right server. This bypass will end up in production. Users might unknowingly post their IDs, passwords or confidential data to the wrong server.
Notes: In reality, you should never rely on third parties (such as certificate authorities) to have any influence on the security posture of your app. The most secure implementation is to use self-signed SSL certificates and make your app check everything that this certificate offers. This would take me more than 5 sentences to explain however (hmm maybe not, any takers or should I do something relevant next Friday?). This comes free however and you don’t have to implement a process to make certain that you’ve updated the server certificates. Unfortunately, if your application runs in the browser, you will have to trust all certificate authorities that are accepted as thrust-worthy by the makers of the browser.
2. Forbid developers to load scripts from a Content Delivery Network (CDN)
Why: Your application might unknowingly incorporate code that is stored on Google, Yahoo, Microsoft or other third party servers. Their Terms of Service provide no guarantee for availability or security. The code will run in the browser of your users. What if a malicious admin or attacker could modify this code? Criminals might also simply re-direct the request to their servers. You might be a victim, even if you are not targeted. Your users might be tracked.
Notes: See my earlier post regarding CDNs and security. The above is not a problem when the full application is handled by a CDN (I trust that you thought about security in that case). It is a problem when developers load standard code (e.g. many of the popular frameworks, such as JQuery, Dojo) without you knowing.
3. Up to you
Let me hear your recommendations! If not, I will be forced to waste more electrons expanding this blog in the future.
Frequently asked questions
1. How do you know that the final number of practices will be exactly 88?
I am just incredibly good at my job. After years of studying analytics and processing patterns in Big Data, I noticed this one key thing that failed to get the importance it needed by other industry professionals: “if you are not targeted then you must consider yourself lucky, very lucky”.
Targeted by security vendors, I mean. Eighty-eight also means double luck or just bye-bye in chats. On another note, I am the owner of the list and can stop whenever I want.
2. Yes, but why stop at 88?
Eight-eight practices are too long to be listed in a PowerPoint presentation without the audience bursting out in yawns. Clever people such as security vendors will still try but fail miserably.
As soon as they explain how their tool, process or methodology implements the 88 practices and that this is all there is too it, your mind will be smashed against the wall like the first time you had a Pan-Galactic Gargle Blaster. In your last moments of sanity you will reach enlightenment and understand that their story is bull shit, which is, at least on earth, even more smelly than snake oil. Security vendors just don’t notice that because their heads are in the Cloud nowadays.
Magical numbers such as ten (10) and twenty-five (25) simply do not have the same effect on the survival rate and further advancement of the human species.
3. But, but, you only gave us 2 practices
You are probably too immature to hear the full story just now. Show some commitment and come back when you implemented these two.
Of course, I also earn my money as a consultant. If I would tell you everything there is to know at once, I would not make much money, would I?