Security and Risk Management Strategies Blog

New Disclosure Rules for Medical Information

Blogger: Eric Maiwald

The latest US Federal Government stimulus package included new rules for health information. You can read the details in the American Recovery and Reinvestment Act of 2009 (see page 144 or search for HITECH).

According to the law, physicians will now be required to track a patient’s medical information anytime it is disclosed to a third party – even if the patient has given permission for that disclosure. While this provision does not go into effect until January 1, 2014, patients will have the right to request disclosure information from up to three years in the past. That seems to make it a requirement that the disclosures be tracked from 2011.

While the tracking provision will cause medical institutions to incur additional costs, the breach provisions of the act may be of greater concern. The act is similar to state laws that require disclosure of any breach of personal identifiable information (PII). For medical information that is breached, the medical practice will need to contact the individuals and post about a breach affecting 10 or more patients on the practice’s web site. If the breach is larger (500 patients or more) the medical practice will have to inform local media and the government.

In reading through the act, I didn’t find a specific exception for encrypted information like we have seen in many of the state PII breach notification laws but I did find that the disclosure only applies to “unsecured protected health information.” Now unsecured protected health information means “protected health information that is not secured through the use of a technology or methodology specified by the Secretary in the guidance issued under paragraph (2).” If the Secretary does not provide the guidance, further definition is provided so that the term will mean “protected health information that is not secured by a technology standard that renders protected health information unusable, unreadable, or indecipherable to unauthorized individuals and is developed or endorsed by a standards developing organization that is accredited by the American National Standards Institute.” It seems likely that encryption will be such a technology standard.

So what does this mean? I think that over the next few years we will start to see stories in the media about lost computers belonging to hospitals and other medical practices. We will also see an increase in the use of encryption by the medical community.

“Log everything”

[Blogger: Trent Henry] 

I attended a conference this week at which a speaker said, “In today’s complex regulatory landscape, every scrap of information is important—save it all.” This sounds vaguely familiar to words spoken by IT teams (and sometimes their counsel) who are worried about electronic discovery: Since we have to preserve evidence in case of litigation, we better be on the safe side and never get rid of anything.

Bad choice.

First of all, there’s no need to save information that isn’t germane to your business or doesn’t have a specific regulatory mandate. Auditors don’t expect it, regulators don’t expect it, and neither do judges. So, whether it’s log data, electronic mail, or documents in a content management repository, take a hard look at what you're keeping. If the business isn’t asking for it, chances are it should be on a tighter retention schedule.

Second, I’ve heard the mantra “storage is cheap,” but looking at some enterprise’s bills, I’m not convinced. Furthermore, there’s a growing market of storage management solutions whose goal is to drive up storage utilization and minimize hardware costs. Data de-duplication projects are popular with executives—no sense having 1,000 identical copies of that 2MB e-mail attachment—so why exacerbate the problem by trying to keep the wrong stuff in the first place?

Third, we all have skeletons in the closet. There’s no reason to air them unnecessarily. I’m not saying that if you consciously violate service-level-agreement terms you should destroy the logs that prove it; or that if you have evidence of wrongdoing at your company you should cover it up. But once a contract is complete, it’s unlikely you need to retain it long-term. And you certainly don’t need to keep sensitive metadata—like document comments describing negotiation tactics or alternative pricing.

So, rather than “log everything,” repeat after me: “Don’t oversave.”

Did the PCI Security Standards Council finally admit a problem?

Blogger: Randall Gamby 

On Monday, November 17th the Payment Card Industry Security Standards Council (PCI SSC) put out a press release announcing the creation of a quality assurance program for the assessment community, https://www.pcisecuritystandards.org/pdfs/pr_081117_qa_program.pdf.  It is being implemented in order to, “…promote consistent interpretation of the PCI standards and ensure quality is maintained among all vendors.” Through the program, the Council and assessor community is committing to:

• Uphold the best interest of the assessor client;
• Adhere to validation requirements among the assessor company;
• Adhere to validation requirements among the assessor employee;
• Maintain consistent assessor procedures and reporting;
• Interpret the PCI standards appropriately as applicable to the client’s systems & environment;
• Remain current with industry trends and PCI SSC updates in the assessor community;
• Report all opinions as factual, documented and defendable, and;
• Maintain a positive relationship between the assessor and PCI SSC.

I should say up front that I stand up and applaud this decision.

But a lot of people have been asking, “Didn’t we have this already?”

The sad reality is actually we didn’t.  There have been unofficial rumors going around the PCI world that Qualified Security Assessors (QSAs), the organizations responsible for doing attestations for the PCI SSC, are providing inconsistent interpretations of attestation requirements; QSAs, who are H/W or S/W vendors, requiring the use of their products to meet PCI compliance; QSAs recommending costly solutions to address deficiencies only to later find out there were lower cost alternatives; and QSAs having different requirements for compliance based on the merchant’s vertical market.

It’s been hard enough for many merchants to modify the way they handle credit card transactions to meet the PCI DSS.  But many have found it even harder to consistently find a QSA who can attest to their compliance.  At Burton Group we get a lot of questions around the differences in how QSAs look at compliance and how to select a QSA. So in September I felt compelled to publish a podcast on these topics, http://podcast.burtongroup.com/ip//2008/09/selecting-a-pay.html. 

Think about it, as a PCI architect goes to their management team in this downturn economy and asks for funding; when management asks, “If we give you the funding for your request will this will make us PCI compliant?”  And you know they will.  The architect has to honestly respond, “Well, yes, assuming we can find a compatible QSA that will sign off on our architecture.”  Not a strong message to send to management while their “high risk” alarms begin to go off in their heads.  Compliance should be based on whether your actions and architecture actually “meet” the requirements of the standard, not whether the QSA “feels” you meet them. 

So as I said at the beginning, I applaud the PCI SSC’s decision to put a quality assurance program in place but until the program is in full effect (it will be rolled out in a four-stage process throughout 2009), merchants will still have to carefully select their QSA if they want to maximize their chance of achieving compliance.

PCI V1.2, a good start but still not enough

Blogger: Randall Gamby

Two weeks ago the PCI Security Standards Council released the preliminary details of the PCI Data Security Standard (DSS) V1.2 that’s due out in October.  While many Analysts and Reporters have already written on the topic (I’ll be releasing an extensive update on Burton Group’s PCI coverage around the October release date), they really haven’t commented on what’s still not been addressed by the standard for enterprises still working on attaining compliance.

While I applaud the PCI Security Standards Council in further clarifying and adjusting the standard, a lot of work still needs to be done.  I receive about one or two PCI questions a week from our clients and they seem to revolve around a couple of topics I’ve yet to see addressed:

• Guidelines for selecting a Qualified Security Assessor (QSA) – while there are a large number of QSA organizations listed on the PCI Security Standards Council web site; they can’t really recommend a particular QSA for an individual organization.  This leads a lot of organizations to struggle with determining what criteria they should use in selecting a QSA for their certification.
• The role of the QSA – organizations are also still trying to understand the role of a QSA.  Should they get a QSA involved in the gap and remediation process in advance of certification?  If so, should it be the same QSA that will do their certification (knowing there’s a risk that the QSA will be pre-disposed to only care about certain vulnerabilities)?
• Industry-specific best practices – while each organization may have different infrastructures, in general, most industries try to be consistent with the major functions they perform.  So are credit card transactions handled differently between say, a major retailer with 10,000 POS systems and an insurance company that has hundreds of independent agents receiving remittances? Probably, so what are best practices around these industry-specific configurations?
• Virtualized environments – while the PCI Security Standards Council recognizes that some organizations have moved to virtual services for consolidation and management, the DSS really doesn’t provide guidelines for QSAs to evaluate and certify these environments.
• Monitoring and audit – while the PCI DSS recommends minimum timeframes for scanning, doing pen tests, etc. what are the real levels of monitoring and audit needed for ensuring security?  With the Hannaford and Okemo breaches that occurred (both where PCI compliant), neither discovered the problem until months after the breaches had happened.  So identifying what should be scanned and tested and if some of this should be on a continuous basis still requires refinement.
• PCI as part of an overall security model – what are the best practices around merging PCI security requirements into an enterprise’s overall security model?  Should it be maintained separately? Should some components be integrated with similar security mechanisms?  Should PCI be at the top of the security model and other configurations be based upon its requirements?  There are really no answers coming forth on this topic and the other question is where will they come from? Surely enterprises won’t expect the PCI Security Standards Council to tell them how to run their security services.

I will be providing Burton Group’s perspective on most of these questions in my upcoming report, but rather than relying on third parties to resolve these, I’d hope that the PCI Security Standards Council will be able to continue to provide answers to the questions they can in future updates, and releases, of the PCI DSS.

PCI compliance, building the base

Blogger: Randall Gamby

An alarming trend is beginning to surface within SMB “PCI compliant” companies, like Hannaford Brothers (http://www.networkworld.com/news/2008/031708-hannaford-data-breach.html), Okemo Mountain Resort (http://www.okemo.com/okemowinter/security_update.asp), etc. Credit data is being stolen!  While this is exceedingly bad, I have a theory on why this is happening. 

Before I get into my theory I’d first like to talk about military bases.  As we all know, the military contains a lot of top secret information.  So how does, say the U.S. Army, protect it?  First, they classify what information needs to be protected.  Next they find a piece of property that they can physically secure.  Once the property has been thoroughly checked (no listening devices or mines buried in the ground) they construct a series of secure buildings to house the data. They then put up a fence with a limited number of gates with guard houses and guards to protect it. Then, most importantly, after certifying the security of the base, they use sentries to periodically patrol the perimeter of the grounds to ensure unauthorized access is not gained by spies sneaking in under the fence.

So what does this have to do with PCI compliance for SMBs?  Well the process of PCI certification is similar to what a military branch would do to secure their information.  Enterprises identify and classify what data falls under PCI compliance. They validate that the systems that contain the information are controlled properly and are locked down through processes and technologies. Then they build a fence of security around the systems to ensure only properly authorized personnel have access to them.  Finally they certify that the protections meet PCI compliance requirements. But unlike the military, I theorize that a lot of SMBs, short on personnel and resources, quit here.  In exploring the topic I’ve found that there’s an attitude by some executives that PCI compliance is a gate.  Once SMB organizations achieve PCI compliance, some move on to the next pressing security problem.  But this is the wrong attitude.  Just as the military found out eons ago, they must be constantly on guard because spies are always looking for kinks in the defense perimeter in order to slip in and gain access to information without authorization. 

It seems that SMBs are the most at risk of not having “guard patrols” constantly patrolling the perimeter due to the cost and resources needed to monitor and report on the security’s on-going effectiveness and the bad guys are now sneaking in stealing the very data they created these defenses to protect.

So what’s the warning? Whether you’re a SMB or Global Enterprise, PCI compliance is a gate, that’s pretty much a fact, but it can’t be left unguarded.  Time, money and resources must be allocated on an on-going basis else the bad guys will sneak in undetected and you may find yourself making a breach disclosure that wasn’t detected until it was too late.

Is PCI compliance creating a false sense of security?

Blogger: Randall Gamby

I was going to write a blog on small to medium businesses (SMBs) getting PCI compliant, but last week a breach changed all that.  Last Monday, Scarborough, Maine-based Hannaford Brothers Co., a regional Grocery Store chain the Northeast U.S. (and the store I shop at and pay using my debit card) had a breach that exposed up to 4.2 million credit and debit cardholders to potential fraud. 

The result of this breach so far has been about 1,800 instances of fraud as reported by company officials, all company information has been removed from their website (I’m assuming while they reevaluate their transaction strategy and architecture) except for a news brief from the CEO, http://www.hannaford.com/Contents/News_Events/News/News.shtml and the page containing their privacy statements, including their PCI compliance statement:

Hannaford Supermarkets has been certified as compliant with the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS is recognized as the accepted industry security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations protect customer credit and debit card account data.

So the question has to be asked, “Are we putting too much faith in PCI compliance to really reduce our risk of exposure?”  Apparently in the unfortunate case of Hannaford, whatever PCI compliance measures were taken to protect cardholder information weren’t enough to keep attackers from infiltrating the organization and stealing this valuable data.  Plus the question has to be asked, “What is a grocery store chain that mainly does Point-of-Sale (POS) transactions doing storing this information anyway?”  It’s not like cardholders have future payment options like they might have at Amazon.com--where their full credit card or debit card information is stored for checking out at a later date.  I guess believing that shopping at a PCI compliant merchant, over a merchant that isn’t PCI compliant, will reduce your chance of having your credit card data stolen isn’t always accurate.

Now I’m not saying PCI isn’t important, after all this breach may have never been found if PCI measures weren’t put in place, but enterprises have to look beyond the task of being compliance and take whatever additional steps may be needed to secure their data against breaches.   

In addition, on 22 January 2008, Visa released statistics on merchant compliance with PCI. Visa reported that as of the end of 2007, 77% of large merchants were PCI compliant (compared with 12% in March 2006) and that 62% of midsize merchants were compliant (compared with 15% at the end of 2006). These two merchant categories represent approximately two-thirds of Visa's transaction volume.  With other credit card issuers lagging, it seems that there’s still a lot of risk in using your credit/debit card out there in the big consumer marketplace.  So the warning of the week is to stay diligent in watching those credit and debit card statements and keep your guard up, whether the merchant has the PCI stamp of approval or not.  In the meantime, I’ll be getting a new debit card (my magnetic strip was wearing out anyway).