Not much of a contest actually, as CMS hasn’t officially moved the HIPAA bar at all. Maybe the HITRUST alliance will have an impact in healthcare, but probably not, unless they have some regulatory backing and an actual audit function.

GLBA and the FFIEC InterAgency Guidelines (and the Information Security Handbook) have seen extensive changes over a longer period of time. 

OK, so it’s a standard not a regulation. In the standards world we have formal de jure standards, and de facto (industry) standards. Same goes for compliance regulations. PCI is a defacto regulation really, compliance is enforced by the industry, and it isn’t optional.

I finally took a detailed look at 1.2, which is a whopping 72 pages. PCI 1.1 was 16 pages. PCI QSA’s are loving it. I wonder what that does to the average cost of a quarterly scan, or an annual audit?

A big part of increase is that they changed the format of the document to allow for audit test descriptions, but still, there’s a lot more in the new version. A couple of interesting things that the PCI SSC is doing as of 1.2:

-          They explicitly reference the OWASP top 10 vulnerabilities, and they require that if the OWASP list changes, the compliance requirement also changes (presumably in your next quarter’s PCI scan)

-          They have language for each requirement for audit test procedures, which is a REALLY good step IMHO (it eliminates some subjectivity from the QSA presumably). Version 1.1 just described the requirement, with 1.2 organizations can see the actual test procedure that the QSA will use, so they know exactly what to expect- no surprises.

Whether you love or hate PCI, I think it’s fair to say that it is the only major regulation that is changing anywhere near as fast as the threat environment is.

I have been doing some research in preparation for an upcoming conference that I am helping to organize (The Open Group Security Practitioners Conference), where cloud computing security will be one of the big topics of discussion. I will likely be doing a lot of blogging on this topic…I see really significant security (and privacy) issues that need to be aired out, thought through, and resolved, if secure cloud computing for the enterprise is to happen. Things like:

-           From a security concerns standpoint, cloud use cases are very different – a single enterprise using an application in the cloud like SalesForce or Netsuite, is very different the cloud collaboration use case, is very different from a developer level cloud API service, is different from using “storage in the cloud”

-          Transparency (or lack thereof) of the security controls used by the cloud provider. Saying that you have a SAS70 Type II means pretty much nothing…

-           Validation and verification of cloud provider security controls by big customers- 3^rd party vendor risk is a big deal in many industries, and in areas like financial services, it is not optional, it is required by law and by regulators. How are the cloud providers going to respond to an assessment request from a financial organization customer that asks 2,300 specific questions about controls? How will they react to a request for an onsite audit request?  

-          Compliance impacts- regulations such as PCI are pretty prescriptive about the security controls. Same for GLBA/FFIEC. How will that translate to cloud services? Here’s a prediction, the first cloud service provider that gets proactive about documenting their compliance posture relative to compliance regulations in a specific niche like PCI will do very well.

I wonder if the big cloud providers really understand the barrier to adoption that security concerns represent for large enterprises?

 BTW, one of the great things about SBN, Twitter, etc. is the “group learning” that goes on. My hat is off to Hoff, Mogull, and others who spend a lot of time thinking about these issues, who are able to distill things down to core issues, and to communicate things clearly.

Jim

I guess this is what happens when you are the home state of TJX and BJ's Wholesale.

Massachusetts has passed a regulation that adds *significant* prescribed security controls in support of their data privacy regulation passed in 2007. The new regulations require (for businesses that process or store the PII of Massachusetts residents) security programs with these controls in place:

- written information security program
- passwords, encryption for laptops
- risk assessments
- security policies around records retention
- policies and procedures to prevent terminated employees from gaining access
- physical access control policies and procedures
- security incident response policies
- monitoring for unauthorized access
- encryption of PII on laptops and other portable devices
- encryption of PII data in transmission

Massachusetts sets the new high water mark for privacy legislation, and the degree to which they are prescribing specific security controls.

The regulation becomes effective 1/1/2009. Enforcement is up to the Massachusetts Attorney General, and the legislation applies to businesses anywhere that have MA residents in their databases.

Most of these security controls are best practices sorts of things, and they are the kinds of things that you see in GLBA, PCI DSS, ISO 27002, and other regulations and industry standards. So they shouldn't come as much surprise to large businesses. But the existence of this new state regulation adds to your risks if  you get security wrong, and it should further help to justify security spending to management.

Jim

I missed this a few months ago when it first appeared, but today ran across an article from September in  Computerworld  that described the penalties levied by DHHS against Providence Health in Seattle for HIPAA violations. The amount they were fined, $100,000, is significant. It's the $25,000 maximum HIPAA fine times four, for the four EPHI loss incidents. The loss incidents had to do with laptops stolen from the organization that housed EPHI.

What is even more significant is the set of actions (3 year Corrective Action Plan is here) that were mandated by DHHS. These include:

- a risk assessment (an annual HIPAA requirement anyways)
- implementing security measures to reduce risks and vulnerabilities
- physical safeguards around offsite storage of EPHI, safeguards addressing transport of EPHI offsite
- encryption of portable devices, encryption of backup media
- physical security controls for portable computers
- workforce training
- monitor reviews of staff at the organization- essentially quarterly audits to ensure the prescribed controls are acually put into practice
- unannounced site visits
- annual reports, and more

It is nice to see DHHS taking HIPAA Security Rule compliance seriously enough to impose these security controls on a healthcare organization that has had issues. I don't think any of these security controls are particularly onerous- really they are best practive sorts of things. Healthcare organizations will treat IT security more seriously in the future, and fund it appropriate to the set of risks, including (now) increased regulatory compliance risk.

Jim

Nevada is set to start enforcing compliance with a law governing how businesses operating in the state can transmit personally identifiable information (PII). The law (see article here, or see the actual statute here) was passed last year, and it goes into effect October 1st. It requires the use of encryption (or something that might faintly resemble data encryption) when PII is transmitted.

Like a lot of the state legislation dealing with privacy and security, it has a few problems....Nevada's law applies to all PII transmitted electronically except via facsimile. I'm not familiar with the state of the art in sniffing and hacking facsimile transmissions, but I'm guessing it isn't rocket science. The definition of encryption in the statute is bears no resemblence to any other definition I have ever read, and it opens the door to many different security controls potentially being permissable under the definition. See the definition at the end of the article, which should give cryptographers a lot of heartburn. You could use a simple letter substitution and have it pass for encryption using their definition. Well intended, but poorly executed in my book.

The proliferation of state laws dealing with privacy and security continues, and it raises some interesting bigger picture questions to think about...

• Keeping track of the various state's individual regulations and requirements is becoming a real quagmire, as they are diverging in terms of what comprises PII, what the organization needs to do in terms of breach notification, and what controls must be put in place.
  
• State compliance regulations like this are all bark and no bite- it's not like Nevada is going to have an enforcement group running around checking to make sure that every business that deals with PII is using encryption (as they define it). I guess if you had a breach, that fact that you might not have been using encryption might open you up from a liability standpoint.
  
• Are state legislatures really equipped to define best practices for securing access to PII? The answer is pretty clearly no.
  

It seems to me that we really need a federal law that is carefully constructued in this area.

Jim

NRS 205.4742 "Encryption" defined. "Encryption" means the use of any protective or disruptive measure, including, without limitation, cryptography, enciphering, encoding or a computer contaminant, to:

1. Prevent, impede, delay or disrupt access to any data, information, image, program, signal or sound;

2. Cause or make any data, information, image, program, signal or sound unintelligible or unusable; or

3. Prevent, impede, delay or disrupt the normal operation or use of any component, device, equipment, system or network.

 

Following the lead of Minnesota, the California legislature recently passed legislation (AB 1656) that requires retailers to implement data protection controls if they retain customer’s personal information. The California bill does not require retailers to compensate card issuers for the costs of closing accounts and reissuing cards, but it does require the retailers to notify consumers affected by security breaches, with the cost of notification being borne by the retailer. With significant amendments from the original bill that was vetoed by the governor in 2007, this version of the bill is expected to now be signed.

The Minnesota law, signed into law in 2007, goes further by putting the liability for the cost of card reissuance on the retailer rather than the issuing bank.

My prediction is that we will see continued legislative pressure to move the costs of breach cleanup away from card issuing banks, to those responsible for the breach (oftentimes the retailers).  

An interesting aspect of this new bill is that it is more prescriptive than the state data privacy laws typically are. The bill has specific language around storage of cardholder data, a requirement to have and implement a policy regarding customer information data retention, limiting access to only those whose job requires access, and use of encryption to protect cardholder data.

At a glance, the language used seems to mirror the controls found in PCI 1.1, which is good. But it is one more set of controls that have to be understood and accounted for if you are a firm that operates in the payment card processing chain, and if you are doing business in California.

As with SB1386, this law applies to breaches involving California consumers , meaning if you have California consumers in your customer base, the law applies to you.

I am reading Geekonomics at present, and while there are many reasons to praise the book, one of the key takeaways for me has been something that I haven't thought about previously. Namely, that the data breach laws that have come into existence in the past few years have put IT in an untenable situation, because they require disclosure of security breaches (and likely open the company up to legal consequences), but the company has no recourse on the back end. This is because even though many breaches can be directly traced to the software manufacturer's lack of software QA, as David Rice points out in the chapter entitled "Absolute Immunity: You Couldn't Sue Us Even If You Wanted To", software license agreements are highly one-sided, providing almost no ability for the user/IT organization to pursue the manufacturer.

The combination of data breach laws with the antiquated and one-sided license agreements prevalent in the software industry has put IT organizations into a "squeeze play" of sorts.

The Joint Commission, which is a non-profit organization that publishes standards for healthcare organizations and runs  an accreditation program, is updating some of their standards for 2009, including some which impact information security.

The Joint Commission, previously known as JCAHO, is updating some of the standards and elements of performance relating to information management, privacy, and security. Many healthcare organizations seem to pay more attention to the Joint Commission standards than they do to HIPAA, because have JCAHO accreditation is very important to the organization's business performance. JCAHO accreditation is an independent measure of healthcare quality of performance, across many areas of their business (information management being one). Liability insurers look to JCAHO accreditation as a measure of quality and risk, so this tends to be a big deal.

Joint Commission information management standards which are changing include:
IM 02.01.03, EP 5, which now reads "The hospital protects against unauthorized access, use, and disclosure of health information". The previous language just said "The organization implements the policy".

IM 02.01.03, EP 8, which now reads "The hospital monitors compliance with its policies on the security and integrity of health information".

The language is obviously not overly prescriptive in terms of how healthcare organizations are supposed to achieve these standards. One assumption is that the organizations will turn first to the HIPAA Security and Privacy Rules for guidance. Maybe they will also look at ISO27002 for more specific controls relating to information security.

These and the other changes to the JCAHO information management (security and privacy) standards are important because healthcare organizations now have the Joint Commission accreditation process at risk if they fail to adequately implement their information security program.

Jim

The story about China hacking into politicians systems has been in the news the today (Network World coverage).  Maybe it's actually a good thing in the long run, because this kind of activity has the chance to actually stimulate our politicians in the US to think about how to  address security issues.

I have been reading Geekonomics, and the further along I get in it the more I think that the systemic problems we face in IT security need to be solved at a lot higher level than throwing security technologies at each new problem that emerges. (BTW- it is an excellent must read for those in the security industry, and particularly for those who aren't but who need to understand where we are at, and how we got here)

I was also reading an interview in the most recent issue of IEEE Security & Privacy with Jon Swartz, who has covered IT security for USA Today, and who has a new book out called Zero Day Threat. There was a line in it about sabre rattling in Washington DC after some Senators identity information was stolen, but then losing interest when a Supreme Court appointment came up.

Maybe this latest set of hacking incidents will stir our elected representatives to actually look at and do something about security.

Jim

Martin McKeay recently posted a blog entry on behalf of Eric Irvin that describes Google's personal health record services, and their posture relative to HIPAA requirements. The short version of the story is that Google apparently is not legally required to comply with HIPAA because they are neither a provider of healthcare services, nor a payer, hence they are not a covered entity as described in the HIPAA act language.

I agree with Eric that Google should comply with HIPAA privacy and security rule requirements, after all, they set a fairly low bar on the security side. I also think that CMS should start thinking about these cases, because we will see more of this in the near future, both from Google and Microsoft, but also from regional health information networks, and other medical record sharing entities that are not technically providers of healthcare services.

Jim