Cisco Blogs


Cisco Blog > Security

Cisco Web Security and the Health Insurance Portability and Accountability Act (HIPAA)

Spurred by the Health Insurance Portability and Accountability Act (HIPAA), which outlined a set of standards and guidelines for the protection and transmission of individual health information, as well as the subsequent amendment to address standards for the security of electronic protected health information, customers often ask me the following questions:

  • Is your product HIPAA certified?
  • Is your product HIPAA compliant?
  • Will your product meet HIPAA standards?
  • If I implement your products, will I be HIPAA compliant?

While this blog post is in no way to be construed as legal advice, I wanted to provide an overview pertinent to answering the above questions.

The Reality

In short, the answer to the above questions is NO! Here is why. There are no products on the market that are HIPAA certified or HIPAA compliant! I know this sounds challenging and some vendors have claimed that implementing their products will make the customer HIPAA compliant, but that is not the case.

HIPAA cannot be addressed with a single product or set of products. HIPAA is a series of policies and procedures that “covered entities” must implement to safeguard information. Products manufactured by Cisco and other technology companies can be used to implement those defined policies and procedures but the simple inclusion of a technology in the network does not automatically make an entity compliant. Products have to be configured to adhere to the standards set forth by HIPAA.

For a better grasp on the implications of HIPAA, let’s take a look at some of the details outlined in the Act.

Covered Entities

First, let’s examine a 2“covered entity” as defined by HIPAA.

HIPAA standards apply only to:

  • Health care providers who transmit any health information electronically in connection with certain transactions
  • Health plans
  • Health care clearinghouses

What is a Health Care Provider?

Any person or organization who furnishes, bills, or is paid for health care in the normal course of business

Protected Information

1The statute requires the privacy standards to cover individually identifiable health information. The Privacy Rule covers all individually identifiable information except for: (1) Education records covered by the Family and Educational Rights and Privacy Act (FERPA); (2) records described in 20 U.S.C. 1232g(a)(4)(B)(iv); and (3) employment records. (see the Privacy Rule at 65 FR 82496. See also 67 FR 53191 through 53193).

3The Privacy Rule protects all “individually identifiable health information” held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. The Privacy Rule calls this information “protected health information” (PHI).

“Individually identifiable health information” is information, including demographic data, that relates to:

  • the individual’s past, present or future physical or mental health or condition,
  • the provision of health care to the individual, or
  • the past, present, or future payment for the provision of health care to the individual,

and that identifies the individual or for which there is a reasonable basis to believe it can be used to identify the individual. Individually identifiable health information includes many common identifiers (e.g., name, address, birth date, Social Security Number).

The Privacy Rule excludes from protected health information employment records that a covered entity maintains in its capacity as an employer and education and certain other records subject to, or defined in, the Family Educational Rights and Privacy Act, 20 U.S.C. §1232g.

Technical Safeguards

HIPAA defines security controls around the storage, access, control, and transmission electronically of the above noted protected information.

1Technical Safeguards (§ 164.312)

We proposed five technical security services requirements with supporting implementation features: access control, audit controls, authorization control, data authentication, and entity authentication. We also proposed specific technical security mechanisms for data transmitted over a communications network, communications/network controls with supporting implementation features; integrity controls; message authentication; access controls; encryption; alarm; audit trails; entity authentication; and event reporting.

In this final rule, we consolidate these provisions into § 164.312. That section now includes standards regarding access controls, audit controls, integrity (previously titled data authentication), person or entity authentication, and transmission security.

4Technical Safeguards Summary

  • Access Control—A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (e-PHI).
  • Audit Controls—A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.
  • Integrity Controls—A covered entity must implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed.
  • Transmission Security—A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network.

Cisco believes that today’s dynamic threat landscape, new business models, and complex regulatory requirements require a new threat-centric approach to security. This new security model reduces complexity, while providing superior visibility, continuous control, and advanced threat protection across the extended network and the entire attack continuum. This makes it easier for customers to act more quickly before, during, and after an attack, which is particular important to risk management and reduction.

In regards to Cisco Web Security products and transmission security conformance, Cisco Web Security products provide the necessary encryption services along with audit, entity authentication, and event reporting to help address the technical safeguards.

Cisco Web Security products do not determine that the receiving website is of the appropriate type or has implemented the appropriate controls for handling HIPAA protected data but ensures that the information was transmitted securely upon request by the transmitter (think data loss prevention, not covered in this paper). It is the responsibility of the customers’ security and administrative staffs to determine which sites are deemed acceptable for receiving or transmitting this data. Cisco Web Security products can provide transmission security, transmission entity authentication, event reporting, and integrity of the transmission via the HTTPS protocol.

Conclusion

The Department of Health and Human Services HIPAA Act of 1996 amended in 2003 has many complex provisions and should be reviewed on a regular basis by any covered entity’s security and administrative staffs for conformance. The intent of the Act is the protection of private health information via both administrative and technical safeguards. Cisco provides a range of security products that can be used by customers to meet many of the requirements outlined in the HIPAA standards but only if properly configured, maintained, and monitored. As stated earlier, deployment of a single product or set of products will not, in and of themselves, ensure HIPAA compliance.

References

  1. http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/securityrulepdf.pdf
  2. http://www.hhs.gov/ocr/privacy/hipaa/understanding/training/coveredentities.pdf 45 CFR §§ 160.102, 164.500
  3. http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html
  4. http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html

Tags: , , , ,

A New Model to Protect the Endpoint, Part 1: Continuous vs. Point-in-Time Security

The fundamental security problem that many defenders face is securing their environment in a world of continuous change. IT environments change. Threats change. But today’s threat detection technology doesn’t change. It’s stuck in time, point-in-time to be exact.

Sure, detection technologies have evolved. The latest improvements include: executing files in a sandbox for detection and analysis, the use of virtual emulation layers to obfuscate malware from users and operating systems, reputation-based application whitelisting to baseline acceptable applications from malicious ones, and, more recently, attack chain simulation and analysis detection. But predictably, attackers fundamentally understand the static nature of these security technologies and are innovating around the limitations associated with them to penetrate network and endpoint defenses.

These point-in-time detection technologies will never be 100 percent effective and are unable to identify the unfolding follow-on activities of the attacker which require continuous scrutiny. The disconnect stems from the fact that malware is dynamic and three dimensional. It doesn’t just exist in a two-dimensional point-in-time ‘X-Y’ plot waiting to be detected, where X is time and Y is the detection mechanism. Malware exists as an interconnected ecosystem that is constantly in motion. To be even remotely effective, malware defenses have to be multi-dimensional and just as dynamic, taking into account the relationship dimension as well.

Read More »

Tags: , , , ,

Steganographic Key Leakage Through Payload Metadata

Steganography is the ancient art of invisible communication, where the goal is to hide the very fact that you are trying to hide something. It adds another layer of protection after cryptography, because encrypted message looks like gibberish and everyone immediately notices that you want to hide something. Steganography embeds the (encrypted) secret message into an innocuous looking object such that the final communication looks perfectly normal. The “analog” form of steganography is the art of writing with invisible ink. The digital version hides the message by a subtle modification of the cover object. Probably the most researched area in digital steganography uses digital images as a cover media into which the message is inserted. The oldest (and very detectable) technique replaces the least significant bit (of each colour channel) with the communicated message. Shown below, the first picture is the cover object and the second one is the stego object.

cover

stego_2

Read More »

Tags: , , , ,

Enhance Your Security Investment with Security Optimization Service

Many organizations have the same challenges when it comes to security: blurring boundaries, more and more organized cybercrimes, difficulty in finding and retaining technical talent, and keeping up-to-date with the latest security threats and tools.

In my inaugural blog, I’d like to tell you about one useful offering: the Security Optimization Service (SOS) from Cisco Services. The service can help you keep current with what is happening in the industry and in your security fabric on an ongoing basis.

Your corporate security infrastructure fabric should be treated as a dynamic living and breathing ecosystem of policy, framework, hardware, software, applications, people, and processes, with errors, omissions, and commissions all inclusive.

Ongoing care, maintenance, optimization, change support, and user education is critical to get more out of your investments and future planning. This is the philosophy behind Cisco SOS.

Read More »

Tags: , , ,

Open Sourcing FNR an Experimental Block Cipher

Traditional block ciphers work on fixed blocks of data—as an example, AES is well-defined for 128/192/256 bits. But one of the issues is the need for padding—so if you need to encrypt small amounts of data you may end with a huge difference in input vs. output size. As an example, using AES/128 on ECB mode to encrypt an IPv4 address results in an input size of 32 bits, but an output size of 128 bits. This may not be desired for some applications.

To address such needs, we have designed the FNR encryption scheme. FNR stands for Flexible Naor and Reingold. Our proposed encryption scheme is a practical variant of Naor and Reingold’s[1] work. We are releasing the reference implementation of the FNR encryption scheme under open source license LGPLv2.

FNR is an experimental small domain block cipher for encrypting objects (< 128 bits) like IPv4 addresses, MAC addresses, arbitrary strings, etc. while preserving their input lengths. Such length preserving encryption would be useful when encrypting sensitive fields of rigid packet formats, database columns of legacy systems, etc. in order to avoid any re-engineering efforts for privacy preservation.

Read More »

Tags: , , , ,