FTC Fines Software Vendor Over False Data Encryption Claims (softpedia.com) 37
An anonymous reader writes: The US Federal Trade Commission (FTC) has fined a software vendor for lying about its product's encryption capabilities, despite being publicly warned by US Computer Emergency Readiness Team (CERT) not to do so. The software vendor is Henry Schein, who deliberately ignored CERT and FTC warnings and continued to sell its CRM for dentists, even if it knew it did not comply with HIPAA rules. The vendor got "only" a $250,000 fine.
Re: (Score:1)
irstfat ostpay. Get it right :)
Re: (Score:2)
oops :)
Yet another proprietary fail (Score:1)
This is yet another example of why rolling your own encryption is a very bad idea. Not only is it a weak algorithm but it also relies on obscurity. Their literature even says that due to it's proprietary nature that makes it even more secure because it's more difficult to reverse engineer. Good job, morons!
Re: (Score:3)
Really now, there are very good algorithms out there. Would it have really been that hard to sub out the encryption module of their source code with a vetted encryption algorithm?
Oh--- right-- Probably not using properly modularized code! Because FIRST TO MARKET or some similarly retarded reason.
Re: (Score:3)
The flaws you are referring to are in the implementation of the crypto algo, not the algo itself.
Re: (Score:2)
How many of the bugs in OpenSSL or LibreSSL or GnuTLS are bugs in the actual implementation of the encryption algorithm and how many are bugs in higher level protocols (SSL, TLS etc)?
Re: (Score:3)
Also, how many go completely unpatched by the vendor because they don't understand encryption?
At least with OpenSSL etc, the problems are fixed quickly.
Re: (Score:2)
This is yet another example of why rolling your own encryption is a very bad idea. Not only is it a weak algorithm but it also relies on obscurity. Their literature even says that due to it's proprietary nature that makes it even more secure because it's more difficult to reverse engineer. Good job, morons!
They were using DES. DES is an encryption algorithm. DES with cypher block chaining is quite secure, given that the information is not financial data. Financial data would be studied to determine the encryption keys, but dental records do not carry financial data.
Can dental information be monetized? Please explain to me why someone would want to decrypt a dental database? A typical dental practice rarely has more than 10k patients active and perhaps adds 2k patients per year and prunes that many records
Re:Does Rust ensure HIPAA-compliant software? (Score:4, Informative)
"Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information."
"Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate."
That's pretty much the tech level of the entire document, there are no actual technologies referenced in it. Technically you could indeed use Pig Latin as your "encryption", but actually don't need to have any encryption at all.
Re: (Score:1)
Not exactly. HIPPA has provisions for both PHI and e-PHI. If your business works with another by passing either PHI or e-PHI, you either have to be compliant or you don't do business with them. In practical terms, this means that if you're a dentist and you want to be reimbursed by insurance, it doesn't matter if you're submitting paper or pixels - you have to be HIPPA compliant. If you want to do a cash-only business and you don't need to work with any other HIPPA-compliant business, you can roll HIPPA
not scarequotes needed (Score:5, Informative)
yes, they were only fined $250K. Henry Schein is a multibillion dollar multinational company. [wikipedia.org] $250K is "cost of business" expense because they make millions selling their software. this isn't even a slap on the wrist.
Re:not scarequotes needed (Score:4, Informative)
Re: (Score:2)
And yet they won't; per HIPAA encryption is "Addressable" and not "Required". 45 CFR 164.312 is actually really short and is completely tech agnostic.
N.B. the application in question is only supported today on Windows 8.n.
We could go down the rat hole that WindowZ is the weaker link.
Encryption is only an issue for data should it be lost. i.e. if computer hardware is
stolen or recycled badly.
The nature of the HIPAA procedures place a lot of responsibility on the dentist
not the application vendor beyond requiring logging in by name and managing the
administrator password.
The single dentist office installation is small and there is little risk of a wide
class
Re:not scarequotes needed (Score:4, Informative)
You have to read the FTC complaint and have experience dealing with Schein to understand what's really going on. It's my opinion that the use of encryption was not for the purpose of protecting patient information from unauthorized release to ne'er–do–wells, but to make the difficulty of migrating Our data to a new vendor's Dental Practice Management System unnecessarily difficult.
Schien as a company is like a stereotype of all the worst qualities of Microsoft, Oracle and SAP.; they are my company of last resort.
Re: (Score:3)
Sounds like it's time to take care of it the "American way." Sue them.
Everyone who bought the software can now sue them for not providing what they claimed to provide. Sue them for the cost of the software plus punitive damages to cover the hassle of having to switch over to some software that does proper encryption.
Re: (Score:2)
It would get settled for a free upgrade to the most recent version of the software which uses AES encryption.
Good (Score:2)
Rickety pile of smouldering crap (Score:4, Informative)
It seems like someone wrote a basic customer-tracking database for Windows that happened to be focussed on dental patients, and then Henry Schein bought them and built the rest by "buying" (or "licensing") connections to a pile of other third-party software. In addition to MS-SQL and Microsoft Office, this seems to include Adobe Flash in places, "integrators" for at least two different third-party imaging software packages, a messaging system, and who knows what else.
Looking at the CERT notice, I'm guessing they "bought" (/"licensed") their special "proprietary encryption" as a package from Faircom and just bolted it on without any further examination. They were probably happily going along continuing to brag about their encryption because Faircom was, and they figured Faircom could be blamed for it.
It doesn't help that "Dental-patient record tracking software" isn't a particularly big niche, so there's likely very little competition and any half-assed thing they throw together will continue to generate license fees because Big Multibillion-Dollar Corporation can easily outmarket the very few competitors they may have (and who may not actually be any better). Many years ago, I worked for a proprietary retail inventory-and-point-of-sale software developer. Their product was also a rickety pile of smouldering crap, but it still seemed to be better than most of their few competitors back then. Horrifying, but I suspect Henry Schein is in an analogous situation (compounded by being a massive conglomerate).
Re: (Score:2)
Most medical administration software I came across is atrocious on any level. It's usually technologically at the very least 10 years behind, has a user interface that makes SAP look intuitive and consistent and contains more security holes than the average HackMe app for teaching people the OWASP Top 10.
Thinking about it, most of the applications could actually be used as a poster child for teaching the OWASP Top 10. They usually have them all in one way or another.
Seriously, if you look for the worst writ
They're never satisfied. (Score:2)
First they wanted to backdoor all encryption, now they've got a fully-backdoored encryption and it's still not good enough.
Wait! Has the FTC Done Something?!! (Score:2)
OMG, I can't believe that FTC did something. This is where people would chime in and point out a list of FTC accomplishments, if people could.
Ha-ha!