In a recent article in eSecurity Planet, Diana Kelley writes that it’s just not enough to pay what amounts to lip service to disaster planning and recovery when you produce a plan for it but never actually execute, even in a test environment, to ensure that it will truly work as expected. As Kelly contends the Gulf Coast oil spill was a convergence of the failure to put into place adequate controls for preventing a catastrophic event and a poor to non-existent business continuity and disaster (BC/DR) recovery plan.

Although the symmetry between the two may not be readily apparent, there are similarities. For example, we’re all familiar with backups until the point they become just another checked box at the end of the day. But how many of us actually validate the results on a regular basis to ensure the data is not only present, but also properly restored? It’s easy to make the rudimentary routine –until the data is required (for compliance purposes, for examples), and you discover not only is it not there but worse yet, you also have no idea where it went.

In taking BP to task Kelly’s observations fall along the same fault lines that are easily attributable to any IT professional finding themselves in a potentially problematic situation.

1.    Get the Consequence Cost Right

The cost of implementing BC/DR controls should be directly proportional to the loss of business risked by their absence. In other words, if you don’t have adequate controls in place and you suffer a devastating loss there is almost nothing to gain by downplaying the potential consequences. As an organization be nimble and perceptive enough to assess the impact of your loss at benchmarks along the way that make sense to your organization. Evaluate your organization and the practical cost of consequence scenarios and then deploy a level of BC/DR controls consistent with the results of that evaluation.

2.    Go for value, not volume

The BP response plan comes in at a “hefty” 583 pages and while that appears to be consistent with the level of response required given the devastation, Kelly believes that any BC/DR plan also needs to be able to articulate key decision points quickly so responders can act accordingly (e.g. a corporate policy that states shutting down the e-mail server if a virus has found its way in and is re-transmitting itself company-wide). And while Kelly concedes that even the most thorough BC/DR plan can’t anticipate unexpected circumstances, taking the steps to document what you can control in the face of a crisis is certainly preferable to being caught completely unawares.

3.    Practice makes (almost) perfect.

As media reports surface about the level of readiness those on the oil rig had in place for just such a disaster, most especially the crew’s weekly evacuation drills, it’s clear that many lives were saved by practicing for the least likely but most dramatic outcome. Kelly likens this readiness to validating data backups, where practice not only confirms the data has been backed up correctly, but also enables an administrator to easily find specific data called up for business reasons.

The lesson in all this, and one I agree with conclusively, is to never be complacent. By bringing your BC/DR plan to life ― in other words not taking it for granted ― when a serious attack on the network does occur you won’t be scrambling to implement basic response activities, and too late after the devastation has already incapacitated your business.

Case in point: Just this week the Boston Globe reported computer files from South Shore Hospital that contain personal information for about 800,000 people may have been lost when they were shipped to a contractor to be destroyed, hospital officials announced.

The information was on back-up files headed for destruction because they were in a format the hospital said it no longer used and contained information on patients, employees, physicians, volunteers, donors, and other business partners associated with South Shore between Jan. 1, 1996, and Jan. 6 of this year.

According to the Globe, the files may have included names, addresses, phone numbers, dates of birth, Social Security numbers, driver’s license numbers, medical record numbers, patient numbers, health plan information, dates of service, diagnoses, treatments relating to hospital and home health care visits, and other personal information.  Moreover, the data was NOT encrypted.

South Shore said its backup computer files were shipped to a contractor for destruction on Feb. 26, and when the hospital failed to receive their certificates, (evidencing the job had been completed), the hospital contacted the company for answers. On June 17, it was informed that only a portion of the shipped material had been received and destroyed.

Foresight being 20-20, of course, none of this would have happened if South Shore Hospital had elected to use an online backup and recovery solution, like Venyu, to transmit, secure and ultimately perform data destruction remotely. In fact, encrypting data upon ingestion and transmitting it onto a secure server located in a best-of-class Tier IV secure facility ensures your data is not only never lost, but also able to be (if that’s what you need, that is), rapidly recovered. (For additional benefits revisit our March 30 blog posting here.)

The take-away from this announcement? Whether you’re a hospital serving patients or a small business helping customers, taking a proactive, common sense approach to potential data breaches trumps having to respond reactively to them every day of the week.

As revealed just this week by the Massachusetts Secretary of State’s Office, the data breach in question occurred when an employee accidentally released confidential information of 139,000 state-registered investment advisors, including their social security numbers, to an investment industry publication, IA Week, via a CD-ROM. While the publication’s request was above board – it was merely seeking the names of Massachusetts registered investment advisors – what returned to the pub was probably far more that it had expected. Recorded on the CD-ROM were not only the aforementioned social security numbers, but also each advisor’s date and location of birth, height, weight, hair and yes, even eye color.

Ironically, and perhaps even more disturbing is that none of the information contained on the CD-ROM was encrypted – a core requirement of the MASS 201 CMR 17 law. On March 1, 2010 the groundbreaking law became the first in the nation to require encryption to protect personal information contained in both paper and electronic records. In fact, the law spells out that if you license or own any personal data of a Massachusetts resident, regardless of the size of your business or where you’re located, you must comply with this law.

While the publication claims it has not copied the data and therefore never placed the investment advisors’ identities in jeopardy, David Berman, a security expert interviewed for the story argues otherwise. “If gotten into the wrong hands, the exposed data could be used to obtain a fake ID, which can subsequently be used by hackers to infiltrate or open personal accounts using the victim’s personal information.” Berman goes on to state that those affected by the breach should consider their identity at risk.

In exercising damage control the Massachusetts Securities Division is weighing whether this all qualifies as a data breach, given that the data was recovered and no apparent abuse resulted.

That’s all well and good of course, however, when it comes to MASS 201 CMR 17 Massachusetts state government must lead by example and frankly, with this latest announcement of a data breach within its own Beacon Hill corridors, it’s falling far short of what the public law requires and private individuals expect. Read the full story here.

According to this article in Health Data Management Magazine, a federal advisory board is recommending mandated data encryption for one-to-one exchanges of patient data between providers. As an aside, the federal advisory board in question, the HIT Committee (shorthand for health IT committee) makes recommendations to the National Coordinator for Health IT on a policy framework for the development and adoption of a nationwide health information infrastructure, including standards for the exchange of patient medical information in association with The American Recovery and Reinvestment Act of 2009.

Encryption would be mandated from one provider to another for treatment purposes when there is potential for transmitted data to be exposed.

Additionally, the recommendations propose that given the one-to-one exchange under which the encryption scenario would be required, the mandate would need no “additional individual consent beyond what is already required by current law.” In other words, as a patient the feds will not need your permission when exchanging sensitive information with another entity, in this case, a provider. Sounds like a law that could get out of hand pretty quickly if the same process is mirrored in non doctor-patient scenarios. Is state-sponsored identity management the real outcome of universal healthcare? I welcome your thoughts.

According to a report published by IDC that purports to be the first of its kind to examine the economics of cloud deployment, the combination of an improving economy and aging hardware has the IT market “ripe” for a move to Cloud-based infrastructure. In fact, IDC found that 44 percent of the enterprises it surveyed are considering a move to the Cloud, with projected server revenue for public Cloud computing growing from $7.3 billion in 2009 to $11.8 billion in 2014. In addition, IDC estimates that, for public clouds, 318,121 servers were deployed in 2009 and that figure will grow to 875,954 units in 2014.

In the minds of those surveyed when it comes to the pros and cons of “clouds,” public and private Clouds have almost total overlap. The top four reasons for moving to a both a private and public Cloud, according to those surveyed by IDC, are improved availability, aid in disaster recovery, improved asset utilization and lower total cost of ownership (TCO), and they were all of nearly equal value. Unsurprisingly, at the bottom of the list was saving on IT headcount.

One interesting factoid gleaned from IDC’s research is that early attempts at virtualization solved one problem but created another with physical server sprawl replaced by virtual machine server sprawl. As IDC research analyst Kate Broderick points out, “Companies were deploying virtual machines all over their environment and not removing them, so VMs used for a short-term project would still be up and running years later — a state that showed that virtualized environments were not yet fully mature.”

While it may indeed be a stretch to invest business migration to the Cloud as a genuine bellwether of an improving economy, it does suggest that unlike other highly touted but ultimately overhyped concepts, cloud storage is no longer a solution in search of a problem.

In its wake, which has already cost the insurer at least $7 million, the Tennessee plan has just published its “lessons learned” which it wants to share with other organizations, especially those sensitized to these data breaches by HITECH data breach notification requirements.

 These include:

• Adding a layer of physical security to protect servers is a prudent step.
• Encryption should be applied widely, including on servers.
• Appointing a chief security officer helps to ensure coordination of all security efforts.
• Organizations should carefully assess how long to store information.
• In preparing a breach notification plan, be sure to prepare a pre-selected list of vendors that can help with various tasks.
• Train customer service representatives to deal with breach-related questions from the public.
• Communicate frequent updates on breach investigations through the media and a Web site.

These aren’t just take-aways for BlueCross BlueShield. They’re also meaningful outcomes for any business where securing customer data is job one.

According to the article published in SC Magazine, the amendment requires organizations to notify individuals that are placed at risk by a security breach, outlining the circumstances of the breach, the time period during which it occurred, and the personal information that was lost. The notification must give this information to the Alberta Privacy Commissioner, along with an assessment of the risk of harm to individuals, and quantify how many are likely to be affected. Companies must outline what they have done to reduce the risk of harm and notify the victims.

Erika Ringseis, an associate in the Calgary Labour and Employment Group at legal firm McCarthy Tétrault, said that the Alberta amendment is likely to have a significant impact on data breach notification practice across the country.

“This is now going to be the standard, the way things are done,” she said, arguing that companies were already accepting data breach best practice guidelines in Alberta anyway. If a national business operates in Alberta at all, the amended legislation will effectively set the baseline for that organization’s activities across the country. “What has been slowly happening in any regard is now going to be done on a larger scale.”

All I have to say is “what took them so long, eh?”

In this Q&A, David Navetta, founding partner of the Information Law Group, discusses the specifics of the proposed law and key similarities and differences with existing state data breach laws. Key topics include the legal standard for “risk of harm” as well as the cost implications relating to penalties and free, credit monitoring and call centers. Enterprises will also get brief guidance on what to do now to prepare for the likelihood of a national data privacy law.  Watch the video

Among the survey findings, published in this article by CentreDaily.com:

• 41.5% of hospitals have ten or more data breaches each year – a 120.7% increase over last year’s survey. Currently, over 20% percent of hospitals have twenty or more breaches annually.
• 56.3% of hospital compliance officers believe that the new health care reform law will either have no change or will increase medical identity theft at their institutions.
• Only 15.7% of hospitals feel they are in compliance with the HITECH Act, which went into effect in February 2010
• 48.3% of hospitals do not know if their vendors and business associates are in compliance with the HITECH Act.

As the CEO for the company that sponsored the survey remarked, “It turns out that addressing the problems of data breaches and medical identity theft is proving more complex and time-consuming than hospitals counted on. We are simply copying, digitizing and disseminating personal information faster than we can control it.”

Given that perspective I’m reminded of the Lion in the Wizard of Oz when, upon receiving his medal for courage, tersely summed up the occasion with the declaration: “Ain’t It The Truth.”