Armouring your SaaS #1: My obviously bulletproof SaaS
Do you enjoy the feeling that your company is the best, and your products – bulletproof?
Armouring your SaaS #1: My obviously bulletproof SaaS
Do you enjoy the feeling that your company is the best, and your products – bulletproof?
This self-confidence is not uncommon among software companies and, in most cases, it is a positive thing. You can see the exact same confidence when it comes to security – “Of course we’re 100% secure. No question.”
But as when playing cards where the stakes are high, at some point someone has to call the bluff – and these confident players better have a great hand. This could be a question from a potential customer – “how secure are you?” (the better option), but just as well an attacker might try to hack your shiny toys (the far worse option, if he succeeds). In the first case, you lose one security-conscious customer, but in the other – real money is on the line.
In this series of articles, I will try to show you why you should not rely on your gut feeling, but rather go for hard evidence. I will also share some tips & tricks on how to make your SaaS more secure and truly bulletproof. Let’s have a look at some potential problems.
Customer data leaks
Think: what could happen if you leaked customer data?
Adobe was recently fined 1 million dollars to settle a lawsuit regarding a data breach affecting over 38 million people. Sounds scary? The EU isn’t any safer, and the General Data Protection Regulation is soon to come into force to regulate data breaches, fines included. The consequences can be disastrous: some companies had to file for bankruptcy after security failures – even some which operated in the security field.
Operational failure
Security issues don’t have to be related to the application only, but may affect the development process as well. Recently, it came to light that backup files stored on Capgemini’s web server for the international recruitment company Michael Page were exposed to the whole world due to enabled directory listing. This only shows that no one is exempt from these issues, not even global players.
The inside job
Can one individual bring down an entire company, or cause significant damage? There have been cases where this has happened accidentally – for example, the case of an “rm –rf “ command in some bash script, without a properly set directory, which wiped out everything it found, including customer related data and event backups. But what if such an act is malicious? Do you know and control who can access a given resource and who should not? What about that disgruntled employee with too much security clearance?
Us? Who would want to hack us?
You might also be thinking: “I’m not the target”. Well, maybe not. But how will the situation change as your company grows? What if you’re not the target, but just a means to attack one of your customers? This is what happened when a heating system of a building in Finland was disabled in the winter due to a DDoS attack. This particular case might seem amusing, but there are much worse examples of such attacks.
Third party components
Do you monitor if the libraries that you use are up to date and do not contain any known security issues? How often? Do you do this in an automated way? One of the Polish banks probably ignored these questions, and as a result lost serious sums of money. If you do not monitor your third party components, try OWASP Dependency Check. It’s a free utility worth having a look at.
Appearance vs reality
Sometimes, the way we perceive the security of our system and how secure it actually is are two completely separate realities. In my professional experience, I have seen countless examples where the software architect’s view of the application’s security was very different from the reality known to the programmers. “Yes, we have security requirements, and all my programmers are obliged to produce the code with those requirements in mind.” But then the other side says: “Yes, we know about those requirements, but nobody really follows them, and they’re either inadequate to the reality or we do not have enough time to focus on the security of our code because there is only enough time to make it work as expected.”
Security pitfalls in an agile environment
Security testing is often done too late. In a product developed with the agile approach, where the code changes with each two-week iteration, security or penetration testing done once a year (or even once every two years), without any other security-related activity, is simply not enough.
Fixing security issues only once a year will create a dangerous time window in which vulnerabilities can occur without being detected. Perhaps security issues should also be approached with an agile attitude: how about setting time aside for a sprint dedicated solely to security issues, maybe once every quarter? Simple steps can be implemented to aid not only learning about security threats, but also how to handle their prevention and detection, and even automation.
What did you do to cover your (S)aaS?
So, what about you? Is your SaaS truly secure, or do you just think it is?
Are you 100% certain that it is bulletproof?If I managed to get you to start asking yourself what the reality behind the security of your SaaS looks like, stay tuned. In the next part of this series, I will describe a few simple steps you can take right away, as well as pose some questions you should answer to help establish a general picture of how secure your SaaS really is. Let’s gather the hard evidence together.
Head of Web Security
