FTC on encryption software: meet standards or expect a fine

The FTC has levied a $250,000 fine on the manufacturer of dental support software that tracked personal health information (PHI) over its nonstandard encryption.

The FTC claimed that the software provider falsely claimed that it provided a level of encryption that was consistent with standards and would keep data safe as required by HIPAA.  But the FTC alleges that the company didn't actually offer AES encryption, which has long been the "standard" recommended by NIST.  According to the FTC, the failure to offer the advertised "industry standard" level of encryption was deceptive.

There’s a lot to be gained by examining this from an infosec angle.  At Rendition Infosec we always advocate encryption for our customers, particularly when dealing with sensitive or regulated data.  The dental software specifically dealt with HIPAA regulated data and as such should have been protected.  And users of the software probably thought it was.  But as the FTC notes, the software did not use AES as recommended by NIST standards.

Organizations who adopt software where claims of encryption are made should ask what types of encryption are used.  "We use proprietary encryption" is a HUGE red flag.  "Our encryption algorithm is very difficult to explain" is another such red flag.  Even when vendors claim to use AES, audits should be performed to determine whether:

1. The encryption actually is AES
2. The encryption is implemented correctly

Last year Rendition audited commercial software that protected PHI for a customer (unfortunately, I can't name the vendor or client due to NDA).  We found that the software did use AES.  However, the encryption key for the data was static across all installations of the software.  If the attackers had access to one installation of the software (available as a demo) they had the keys to decrypt all data encrypted with the software in any installation.

World readable keys (or keys hardcoded into world readable executables) are other common implementation mistakes we see at Rendition.

As a software vendor, the FTC settlement should send shivers down your spine.  Honestly, how often does the marketing team stretch the truth a little when describing a product's capabilities?  Probably more often than we’d care to admit.  This FTC ruling shows that flippantly saying "yes, of course we adhere to industry standards" can cost you big if you actually don’t.

If you doubt that marketing staff might stretch the truth a little too far, look no further than the idea of "negative day threat protection."  A few years ago at BlackHat, when everyone else was focusing on zero day exploit mitigation, $vendor was advertising "negative day" threat protection.  Despite talking with them, we never did figure out how they were pulling this off...  Later, they defined what they meant the term "negative day" to mean, but that's a thought for another time.