Risks, Compliance, Standards, and MFA

Risks, Compliance, Standards, and MFA

In most organizations, security solutions (and in particular MFA, multi-factor authentication) are not requested by the security department or even IT, they are mandated by the risks & compliance team. Indeed, although protecting information systems against intrusions and using specific technology for that sounds obvious, very few companies deploy a protection in anticipation. They more than often delay it until they are required to – or until they are hit so badly that they nearly go out of business (giving recent examples would make this blog post considerably too long).

MFA Compliance vs. MFA Features

So, when a company decides to implement MFA and looks for a solution, it usually looks first at “compliance”. Unfortunately, this is not a product feature listed by vendors in their datasheets. Hence some misunderstandings… There’s another bias in the selection process: technical standards. Not to say that technical standards aren’t useful. Most of the time, they are proxies for nice attributes such as interoperability, investment protection, lower vendor switching costs, and so on.

The odd thing with MFA though is that neither compliance nor standards say much about the actual robustness. Some standards are even a clue that the solution boasting compliance provides little security. Not to say that OATH, or FIDO, or HIPAA, or PCI (…) are not well designed technical or industry standards. But looking only for them in the selection process is likely to be insufficient. The “proprietary part” of an MFA solution – despite it sounds so not politically correct – says much more about its security, its flexibility, and its user experience, to name just a few. Implementation matters more than standards for most of the attributes usually expected in an MFA solution. Make sure that you check the boxes that will make your company compliant, but that’s only the beginning of the assessment of an MFA solution, not the end.

Let me take two examples, since I can ‘see’ some incredulity.

HIPAA

Quoting HSS.gov: “The Security Rule (…) applies to health plans, health care clearinghouses, and to any health care provider who transmits health information in electronic form in connection with a transaction (…). The HIPAA Privacy Rule protects the privacy of individually identifiable health information, called protected health information (…), which is all individually identifiable health information a covered entity creates, receives, maintains or transmits in electronic form “.

Back to the MFA solution selection process, should you require your vendor to be HIPAA compliant? I haven’t just made up that question, I have actually seen this kind of requirements in most recent RFPs in the healthcare sector. I can’t positively answer for the whole industry, but as far as inWebo is concerned, we’re not a “provider who transmit health information in electronic form”, and we do not “create, receive, maintain, or transmit” any kind of e-PHI (electronically protected health information).

So, the correct answer for that checkbox is neither “Yes” or “No”, it’s “N/A”. The same applies for PCI (replace ‘health’ by ‘payment’ in this paragraph). The requirement has no relevance in this context.

OATH

To make it short, OATH specifies an algorithm for calculating and verifying one-time passwords, using one-way cryptographic functions (hash) applied to a symmetric key or seed. To say it even more quickly, the security of an MFA solution greatly depends on how these keys and seeds are protected, both on the server side and on the user side.

When OATH was designed, most MFA solutions were provided as onprem servers and keychain tokens embedding a secure element. Keys and seeds were therefore pretty well protected (the RSA breach in 2011 put in evidence a backdoor in this mechanism, but this is a different story). Some years passed. Software-only SaaS MFA solutions are now mainstream but some solutions – and not the least – still boast their OATH compliance, despite in the new paradigm, keys and seeds are not inherently protected, making the robustness of such solutions ‘questionable’, to say the very least.

The same applies for FIDO, or the identity blockchain, or most of the buzzwords that MFA is full of. As a technology, all this is very sound. But these technologies say little about robustness, user experience, flexibility… Implementation does. Implementation defines how authentication factors are protected and kept independent. Implementation defines what the user experience is, not just during the authentication, but also for user on-boarding and credentials management. And so on. The devil  - and what you should really look for in an MFA solution – is in the details, not in the buzzwords.

Beware of analysis shortcuts

All this is common sense, but it illustrates that compliance and standards sometime work in a counter-intuitive way and that putting some effort and analysis in the MFA selection process is going to help reach the expected benefits of an MFA deployment, more than ticking boxes or looking for ‘certified’ vendors. How do these boxes and certifications really align with your business, compliance, and technical objectives?

Written by Didier PERROT

Didier is the CEO & Founder at inWebo, particularly looking at innovation, business models, and technologies in the online identity and authentication areas