in

This Blog

Syndication

Tags

News

AlertBoot offers a cloud-based data and mobile device security service for companies of any size who want a scalable and easy-to-deploy solution. Centrally managed through a web based console, AlertBoot offers mobile device management, mobile antivirus, remote wipe & lock, device auditing, USB drive and hard disk encryption managed services.

AlertBoot Endpoint Security

AlertBoot offers a cloud-based data and mobile device security service for companies of any size who want a scalable and easy-to-deploy solution. Centrally managed through a web based console, AlertBoot offers mobile device management, mobile antivirus, remote wipe & lock, device auditing, USB drive and hard disk encryption managed services.

HIPAA Encryption: What Does the HHS Do For Their Data Encryption Needs?

HIPAA-governed entities may need to use data encryption software to protect sensitive data--usually known as ePHI, electronic personal health information--depending on what their security needs happen to be.  Encryption is not a requirement, at least not yet (although some beg to differ).

Which is weird because HHS apparently holds itself to a higher standard.

HHS Won't State "Use This"

Generally, the guidance given by HHS, formally known as the Department of Health and Human Services, is that ePHI does not require encryption to be used by HIPAA-entities as long as there are other adequate ways of security information: locked doors, laptops fixed to a desk somehow, etc.

HHS's guidance won't specifically state which encryption software programs to use.  This is common when government entities give out recommendations, since they have to appear impartial--they wouldn't want to be accused of favoring one provider versus another.

So, HIPAA-entities are often stuck trying to figure out which encryption package to choose, knowing that the wrong choice could mean that heads will roll when something goes wrong.

What Does HHS Use?  Does It Use Anything at All?

Unsurprisingly, HHS also has policies governing encryption for itself.  What is surprising, though, is that HHS requires the use of encryption on its machines, specifically laptops.  From the "HHS Standard for Encryption," (Dec 2008):

"...applies to all Department of Health and Human Services (HHS) employees, contractors, and others acting on behalf of HHS.  Media is subject to this encryption standard until it is sanitized or destroyed."

And,

"All HHS laptop computers shall be secured using a Federal Information Processing Standard (FIPS) 140-2 compliant whole-disk encryption solution."

Compare the above with the requirement for HHS desktop computers:

"All sensitive information stored on government-furnished desktops and non-government-furnished desktops used on behalf of the Department shall be secured either through a FIPS 140-2 compliant encryption solution or through adequate physical security and operational controls at the desktop’s residing location."

Note how there is no encryption waiver for laptops.  Also note how, in all instances, they require the encryption solution to be FIPS 140-2 "compliant" (we'll get to this later--there is a difference between compliance and validation).

What does this mean to you, HIPAA-entity that wants to be in compliance?  This means that perhaps first and foremost, you ought to make sure the encryption product suite you're looking at has been FIPS 140-2 validated.  After all, what's good for the goose is good for the gander, right?  Seeing how HHS overseas HIPAA enforcement, the health department can't hold it against you for using a solution that holds the same FIPS 140-2 validation (er, I think.  Speak with your lawyers, although I'd bet a pretty penny that common sense would rule in this case).

Then, you can ponder the technical specs such as whether the encryption package is centrally managed, features integrated audit reports, has key management; is easy to install and deploy; etc.

What's the Deal with FIPS 140-2?

The purpose behind FIPS 140-2 is to ensure that an encryption module actually works.  There is a lot of money to be made in the computer security business, and it brings forth its share of willing and accidental digital snake-oil salesmen, the latter truly believing their solution works...until someone proves it otherwise.

This "proving otherwise" is the idea behind FIPS 140-2: after going through a battery of tests, if a particular encryption package passes, it's assumed to be safe for protecting information.  In fact, it's accepted by the US and Canadian federal governments as a product that can be used "for the protection of sensitive information."  The FBI won't be using something that's not FIPS validated, for example.

So who does the testing and gives the passing ones the shiny FIPS 140-2 sticker?  The National Institute of Standards and Technology (NIST, for the US) and the Communications Security Establishment Canada (CSEC, for--wait for it--Canada).

What's the Deal with FIPS 140-2 Validation?

This brings us to "validation" vs. "compliance."  FIPS-validated means that an encryption package went through the NIST-CSEC battery of tests and passed.  FIPS-compliant just means that a package falls in line with FIPS requirements but has not actually gone through the testing.

Based on the above, it's quite obvious that you want a FIPS-validated solution.  So why does the HHS require that their encryption solution be FIPS-compliant?  Because the HHS uses footnotes.

If you read the footnote to what they mean by "FIPS 140-2 compliant," you'll see the following:

The cryptographic module used by an encryption or other cryptographic product must be tested and validated under the Cryptographic Module Validation Program to confirm compliance with the requirements of FIPS Publication 140-2 (as amended). For additional information, refer to http://csrc.nist.gov/cryptval. [my emphasis]

So, make sure that the encryption package you're looking at is FIPS 140-2 validated.  Compliance is good; validation is better (and what counts).


Related Articles and Sites:
http://www.hhs.gov/ocio/policy/20080007001s.html

 
<Previous Next>

Portable Drive Encryption: SFN Professional Services Tatum Division Has Breach

Laptop Encryption Software: HHS At 6-Month Mark Shows 66% Of Breaches Via Storage Devices

Comments

No Comments

About sang_lee

Sang Lee is a Senior Account Manager and Security Analyst with AlertBoot, Inc., the leading provider of managed endpoint security services, based in Las Vegas, NV. Mr. Lee helps with the deployment and ongoing support of the AlertBoot disk encryption managed service. Prior to working at AlertBoot, Mr. Lee served in the South Korean Navy. He holds both a B.S. and an M.S. from Tufts University in Medford, Massachusetts, U.S.A.