Headline: "Enterprises take huge risks with our personal data". Please.
Not a big surprise to security professionals as we are constantly "fighting" for adequate security.
By adequate, I mean normal, sensible, security.
I was contacted by several journalists this morning with regards to a services portal that operates in the municipal space as an SAAS provider.
This "service" manages something to do with leisure activities. I don't want to name them since I like my enemas handled by qualified doctors and not legal teams with an absence of comprehension of security hygiene means.
So this portal supports 100's of municipalities and has 100's of thousands of users, yet security was never addressed.
Why do I say "never addressed", simple.... I cannot say never reviewed, because I do not know if these things where simply ignored or judged not important at the time, or if they simply did not know.
I'm actually still on the fence with which I like best, someone who lies to me or someone who is incompetent.
The issue is simple (and multiple issues should have been identified by a qualified security expert).
For one, the site uses a sequential ID in the calling URL. This means (you guessed it), changing the ID means accessing someone else's file.
That alone is already an issue, but it gets worst.
You don't need credentials to get to it. Anyone can create an account without any email validation, so once you have created your fake account, you can read everyones file.
But wait ! There is more!
The personal data includes home address, phone number, birthdate, medical conditions and allergies !
But wait ! There is yet more!
Social insurance numbers are not only stored non hashed within the database but it is returned to your browser when you view your file (or anyone's file since you can change the ID number to "see" someone else's file).
Here is the awesome protection on that one field..... it is return with the awesome html type = "HIDDEN" so it doesn't display on your screen ;-)
So what is the lessons learnt here....
1) Municipalities (and private sector) should not trust an SAAS provider just because they say "everything is fine. "These are not the drones you are looking for" is not a security approach.
2) If the SAAS provider tells you they have awesome security because they are hosted as a CLASS 1 datacenter called AZURE, AWS, GOOGLE, etc. run ! The means they do not grasp that the security of their hosting provider is only the plumbing section and it means nothing as far as the "quality" application that the provider is throwing on top of the certified infrastructure.
3) Security testing is a MUST and it must be performed by someone qualified.
4) Account creation should be limited to valid email addresses
5) Authentication mechanisms should limit the sessions visibility into data (certainly no client side security)
6) Being a small unknown company in the wild and huge world we call the Internet doesn't mean you do not need security. Crossing your fingers and hoping for the best is also not the best approach.
7) Logging and alerting when someone is leaching your entire client database is probably a good idea.
I'm going to stop, because I'm getting sarcastic again. I really do need therapy.
On a very serious note. When dealing with sensitive, regulated PIPEDA type data, perhaps some security is a fair expectation and a reasonable minimum.
From a GDPR perspective, everyone involved here is a potential winner of a multimillion euro grand prize.
Eric Parent is a senior security expert, specialized in coaching senior executives. He teaches CyberSecurity at l'Ecole Polytechnique and HEC Universities in Montreal, and is CEO of Logicnet/EVA-Technologies, one of Canada's oldest privately owned security companies.
Follow Eric on: