Refreshing transparency or naivete?

In the course of researching for next month's awareness module on security compliance, I came across a surprisingly honest security and compliance statement by UserVoice - a cloud based customer service provider.

I suspect, like all those website privacy policies, very few visitors are concerned or knowledgeable enough to read the compliance statement word-for-word.  A quick scan of the headlines tells us they comply with Safe Harbor, PCI-DSS and others.  It mentions SSAE16 certification. Sounds OK at this point - all very positive. They are making the right noises.

Most of the more technical security-related statements are similarly inspiring.  I am impressed to read, for instance:

"Development and test environments do not use customer data.  We use fake customer data in those environments."

I wish that approach was universal - in fact as I said just last week here on the blog, I tried (and failed!) to get advice along those very lines inserted into ISO/IEC 27002:2013.

Read on, though, and a few of the latter statements are not quite so confidence-inspiring e.g.: 

"We‘re running the latest version of Ruby on Rails 2.3 and we review/apply the latest security patches as they come out."

According to the Ruby On Rails site, it is up to version 4something now. Perhaps someone simply forgot to update the compliance statement ... but if so, what else might have changed and not been reflected in their fine words?

Later, it says:

"Your password is stored securely.  For performance reasons our database itself is not encrypted (though backups are; more on that below), but all user passwords are hashed using the SHA1 algorithm with salt. Hashing passwords is actually more secure than encrypting them, because that means we don’t have access to the original passwords, nor does anyone else. So even if our database is compromised, everyone’s passwords will stay secure."

Fair enough.  One might question their continued use of deprecated standard SHA1 but it makes sense to use one-way hashing rather than reversible encryption ... except that three paragraphs below we read:

"User passwords are encrypted.  For performance reasons our database itself is not encrypted (though backups are; more on that below), but all user passwords are encrypted."

So at this point I'm confused.  Possibly "user passwords" and "your password" are referring to different things? If not, those two statements seem directly contradictory. Again, this could just be a simple typo, misunderstanding or error in the compliance statement, and again it makes me wonder whether any of this is trustworthy.

Up to now, I could easily give them the benefit of doubt, but a couple of statements towards the end really stand out for me. They are what prompted me to write this blog piece:

"Do you have a have a rigorous screening process for your employees that includes credit checks, background checks, reference checks and cavity searches? No. We will often check references, we will always verify that local standard for proof of eligibility to work, and we‘ll make sure that potential team members fit our company values, but we will do little beyond that. We also have every employee sign a confidentiality agreement before he or she can work for us. We also do performance and peer reviews twice a year and retrospectives after any critical issue. If someone is not meeting our own performance standard, including being the root or contributing cause of a critical issue(s), we will not hesitate to terminate our working relationship with that person."

'We will often check references' is basically admitting that they don't always do so. Um. I'd argue that's a fundamental security control, an important guard against identity theft for starters - one of several unmentioned controls for new employees (such as security orientation, to name but one). Requiring employees to sign confidentiality agreements is fine, but what about contractors, consultants, suppliers and others? And aside from confidentiality, what about other aspects of information security and privacy - such as ethics for instance:

"Do you have a _____ ethics policy? No. We‘re guided by our company values and good old common sense. We believe that policies around ethics lead to less ethical behavior."

Oh, I see. The company values remind me of the Internet boom at the start of the millennium, with comments such as 'don't be a dick' and Don't take ourselves too seriously' painting a picture of a fun-filled laissez-faire work environment ... hardly one where good old fashioned ethical values stand out.

Perhaps I'm just an old fart. Perhaps I simply don't get it. But perhaps I have good reason to question their attitudes and approach towards information security.

So I'll leave you to ponder this. How would you feel if you were one of the backers behind a company that made such a compliance statement, at times brutally honest, contradictory and tongue-in-cheek? What if a security or privacy breach occurs, and customer interests are harmed, and the news media sink their teeth into this statement? I'd respectfully suggest it might be time to reconsider, or at least review and update the compliance statement.