•

» Healthcare IT

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.

A “Reasonable” Approach to HIPAA Risk Analysis

Posted on March 17, 2011 by Dan Berger in Main | Leave a comment

The Office of Civil Rights (OCR) is responsible for issuing annual guidance on the provisions in the HIPAA Security Rule (45 C.F.R. §§ 164.302 – 318.). But with so much recent interest in IT security driven by the “meaningful use” incentive program, we want to share some our observations and perspectives from recent Redspin client engagements in the healthcare industry.

All electronic protected health information (ePHI) created, received, maintained or transmitted by an organization is subject to the Security Rule. The importance of safeguarding ePHI cannot be understated. Sure, publicized breach notifications and million dollar penalties damage a healthcare organization’s reputation and bottom line. But more than that, such incidents undermine professional and public trust of electronic health records (EHR). And make no mistake about it – the widespread adoption of EHR is fundamental to future improvements in efficiency, communications and patient care.

So if security is the cornerstone to health IT transformation, what can your organization do to not only comply with the regulations but also contribute to this important mission? First, all heathcare organizations are required to evaluate risks and vulnerabilities in their environments. Then they must “implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of e-PHI.” While “reasonability” is a quintessential element of modern judicial systems, it doesn’t provide a lot of guidance. At Redspin, we suspect there will be little sympathy for major ePHI security breaches no matter what any standard of reasonability might dictate. More simply put, it’s better to be safe than sorry.

Conducting a risk analysis that maps to the HIPAA Security Rule is the first step in protecting ePHI. Note, the Department of Health and Human Services (HHS) does not endorse or recommend any particular risk analysis or risk management model. At Redspin, we think this is wise. From our direct experience, no template or “one-size-fits-all” approach can meet the diverse needs of the healthcare industry. We treat each client individually and conduct a thorough review of their environment even before drafting a scope of work, including:

- size and complexity of the IT environment

- number of physical and logical locations where ePHI is stored

- number of IT staff; their knowledge and experience level

- types of EHR, CPOE and other new applications

- functional responsibilities of team members

- progress-to-date toward EHR completion

- company culture and information security awareness

While a HIPAA Risk Analysis is often project-based, we also consider it the start of a process that will lead to ongoing and durable improvements in information security. The Security Rule itself requires an entity to update and document its security measures “as needed” and specifically recommends conducting continuous risk analysis to identify when such updates are warranted. While the rule does not specify how frequently to do this, it’s a moot point for Redspin’s enterprise security assurance clients. By providing our services on a monthly or quarterly subscription basis, regularly-scheduled assessments, validation and re-testing simply become part of an overall operating environment. Our enterprise solution also tracks and documents all historical findings and remediation via our secure, online web portal. The portal’s dashboard view displays summary information via a compelling graphical user interface, making complex data easier to understand and better enabling you to communicate improvements in your overall security posture to all stakeholders.

In summary, Redspin empowers healthcare organizations to truly integrate their risk analysis and management process. This helps them to accommodate: (1) new technologies (2) evolving business operations, (3) new regulations and (4) personnel changes. And by addressing security risks in a proactive, timely manner rather than fixing problems after implementation, healthcare organizations gain greater value from their investment in IT. Sound reasonable?

Increased Penalties for Healthcare Privacy and Security Violations? Batten Down the Hatches!

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

The 2009 HITECH Act authorized the Health and Human Resources Office for Civil Rights (HHS OCR) to add teeth to existing security and privacy regulations, and they’ve obviously taken the responsibility seriously.

On the same day that HHS OCR imposed a whopping $4.3 million dollar fine on Maryland-based Cignet Health for violating a provision of the HIPAA Privacy Rule, we also learned that HHS OCR intends to tighten healthcare data breach regulations further and to increase financial penalties across the board for privacy and security violations.

The Cignet Health fine was the first civil fine issued specifically under the existing provision of the Privacy Rule which requires covered entities to provide copies of patients’ health records within 30 days of request. As you may know, as covered entities (CE) and eligible professionals (EP) move to electronic health records (EHR), the time limit for responding to a patient’s request for access will become even shorter. To qualify for meaningful use incentives, an EP must provide EHR access within 4 business days. More recently, OCR suggested that, if patients request copies of the protected health information (PHI) and it is not readily available in the format requested, they must be directed to their EHR.

A senior OCR health IT and privacy advisor spoke at HIMMS11 this week. In addition to confirming that the final privacy, security and breach notification rules will be issued simultaneously in 2011, he got everyone’s rapt attention by announcing increases in financial penalties for privacy and security violations. This raises the security stakes considerably. The penalty for a single violation will be increased to $50,000 with a maximum penalty per year of $1.5 million per each provision of the rules. Since many breach incidents can include multiple violations, the corresponding fines could be huge.

Further, OCR is expanding the requirements for business associates. They will now assume direct liability for adhering to privacy and security rules 240 days after the final rules are issued. Subcontractors will also be held to the same standard as business associates. Currently business associates can only be found directly liable under the breach notification rule.

While it’s been publicly reported that over 220 organizations have suffered large data breaches (each impacting >500 individuals), we also got the stunning details that the OCR has been notified of more than 14,000 smaller breaches of PHI (each affecting <500 individuals).

As we noted in Redspin’s 2010 Protected Health Information Breach Report, theft or loss of portable devices such as laptops caused >65% of large breaches. But portable media is here to stay. Instead of trying to restrict where sensitive data is taken, adopt a more data driven view and protect it where it is stored. Solutions like Imation’s Defender product line (encrypted storage: flash, external hard drive and optical) may be right for your organization.

Clearly OCR also understands that business associates are data rich targets and will likely encounter an increase in malicious activity. At present, covered entities must extend their oversight of their business associates IT environment and security posture. This should be included in the CE’s HIPAA Risk Analysis. And with the impending extensions of direct liability to business associates, those organizations should also start preparing to conduct security assessments of their own. And sooner not later.

Of course, at Redspin we think every organization that handles ePHI should have a process in place for external security testing, remediation, validation and retesting. As security consultants, you may think our view is self serving but we consider it an issue in the common interest. After all, even security consultants are healthcare patients at one time or another! We’re all in the same boat – when malevolent storms or hackers strike, we want to avoid data leakage and protect our privacy. So “batten down the hatches – quick men!” (Chambers Journal, 1883)

Unreal Repeal: Healthcare Reform and HITECH

Posted on January 24, 2011 by Dan Berger in Main | 2 Comments

Last Wednesday, Republicans in the House of Representatives (+3 Democrats) voted to repeal the health-care reforms signed into law by President Obama less than 1 year ago. Although the 245-189 vote made good on a GOP mid-term election promise, it was largely symbolic. The Senate is not likely to consider (much less pass) the bill, nor would it ever get past an Obama veto.

Yet, reform of reform is in the air. Spending cuts as the path to deficit reduction are mentioned in every news cycle. It’s possible that congressional budget maneuvering will decrease or delay funding for some of the provisions of Obama’s Health Plan (The Patient Protection and Affordable Care Act).

Thus, it’s not surprising that some healthcare IT professionals wonder if the potential $29 billion in EHR meaningful use incentive payments promised under the HITECH Act are secure. During our January 20th webinar “Assessing HIPAA/HITECH Risks:  What You Need to Know,” I was asked this question several times.

My response? I believe that the HITECH Act will proceed as planned with full funding. Here’s why:

1)      HITECH was passed as part of the American Recovery and Reinvestment Act (ARRA) and not part of Obama’s healthcare reform initiative. It had broad bi-partisan support. As Allscripts Healthcare Solutions CEO Glen Tullman told the Wall Street Journal Health Blog, “Healthcare IT is a nonpartisan issue.”

2)      The goal of HITECH was to create jobs and begin a massive overhaul of the US healthcare system. Right after the mid-terms, Politico healthcare reporter Jennifer Haberkorn addressed a HIMSS press briefing and said cutting back HITECH was “not on the radar. The attitude on [Capitol] Hill is that health IT funding is creating jobs.”

3)      In addition to creating jobs, HITECH provides the foundation for an even broader national economic goal: increasing the efficiency and competitiveness of the U.S. healthcare system in one of the worlds’ largest and fastest growth industries (over $2.2 trillion dollars in expenditures per year).

For these reasons and others, I think HITECH funding is safe for now. That said, I urge covered entities to make achieving Stage 1 “meaningful use” of electronic health records, including conducting a HIPAA Risk Analysis, among their highest priorities. The best guarantee for “staying the course” is the success of the program itself.

Perspectives on application security and risk management

Posted on September 16, 2010 by John Reno in Main | Leave a comment

In my last blog post I discussed information security risk management and why the financial services sector aggressively adopted the practice. My recommendation was that the healthcare industry segment needs to follow suit to increase the effectiveness and efficiency of their information security programs. It is refreshing to see evidence that this is taking place. Last week at OWASP’s AppSec USA conference some leaders from the healthcare sector shared their perspectives on information security risk management.

The panel session, entitled “Characterizing Software Security as a Mainstream Business Risk,” represented application security and risk management experts and executives from both the commercial and public sectors, including: Tom Brennan, CEO for Proactive Risk and OWASP Board Member; Ed Pagett, CISO for Lender Processing Services; Richard Greenberg, ISO for the Los Angeles County Department of Public Health; and John Sapp, Director of Security, Risk and Compliance for McKesson.

Rather than focusing on technical issues associated with application security, which you might expect at an OWASP conference, the panel focused on the discussion of risk and the build out of risk management programs. Much of the discussion centered on how the key drivers for risk management needed to be expressed in business terms such as patient care outcomes, customer satisfaction as well as revenue and profit.
Greenburg, from the public healthcare sector, said that for the Los Angeles County Department of Public Health, “It’s all about getting straight to patient care. The department doesn’t really care about IT nor understand what application security is. They can, however, understand risk in the context of their business; how an application security program can help or hinder them from providing the best care possible.”

Sapp from McKesson continued, “When working through the development of our risk management program, we looked at how our application security programs are helping us to achieve our business objectives. Of course, this doesn’t mean we turn a blind eye to technology and security such that we put the business in harm’s way; we certainly don’t want to facilitate a breach. But, a deep dive into the technology isn’t the discussion we were having during our risk management program planning; we left that discussion for the security operations team to engage in outside of the risk management program discussions.”

The panel offered some guidelines to help other organizations build their own application security and risk management programs:

* Speak in terms of the business. For example, focus on how to ensure secure banking transactions, how to guarantee private and highly resilient patient care, and how to deliver trusted services to employees, partners, and customers.

* The answer is never simply ‘buy a tool.’ Avoid blindly buying products in the hopes that they will solve your application security and risk management problems. It is important to first understand the objective of the risk management program and then select the right tool (s) for the job. As Sapp put it, “a fool with a tool is still a fool.”

* Gain a wide range of allies, both deep and wide — focus first on those that have revenue-generating responsibility, followed by those that have audit and compliance responsibility.

* Find in-field leaders and champions to establish some grassroots efforts. Leverage your project management team to achieve a quick win or two and then use them as case studies to progress the program further.

* Leverage frameworks such as ISO 27002 to establish a baseline level of guidance of how to build out your risk management program and your supporting application security program.

In terms of some guidance for those in the healthcare industry, Sapp from McKesson noted the some highlights from their risk management program.

The top four goals McKesson focused on were:

• Harmonizing processes and investments surrounding risk management

• Improving the overall risk management process

• Establishing application governance

• Delivering transparency and visibility through the risk management program

To achieve these goals, McKesson defined a complete set of risk management categories designed to help define, implement and measure progress. Some sample risk management categories include security, quality, privacy, legal and third-party components. Each of these categories play a role in managing risk, and by defining them up front, McKesson was able to establish a comprehensive, formalized risk management program for the entire enterprise. McKesson’s program is designed to encompass its own business risk as well as the risk associated with the products, services and solutions it offers to its clients.

Within each category, McKesson would look beyond the security risk and the business risk; it would do a deep dive into the risk/reward analysis and focus on how to gain the most reward while mitigating or avoiding the most risk. One example of this analysis would include how to lower the total cost of ownership of a system/application versus mitigating the risk to avoid increased operational cost. Another example would include how it could achieve high levels of application quality and resiliency as a reward while mitigating the risk associated with application failures and other critical errors. One final example would be how McKesson could increase the likelihood and close rate of its own sales efforts while reducing the cost of customer acquisition versus mitigating the risk of having competitive disadvantages (such as poor security or poor application quality).
With its program framework in place, leveraging the OCEG (Open Compliance & Ethics Group) framework as a baseline, McKesson began to focus on implementing an integrated application security program. The order with which the company performed the application security analysis was:

1. Applications that were seeking certification on HITECH (Health Information Technology for Economic and Clinical Health).

2. New applications that were in development or on the roadmap for development.

3. Legacy applications that possess the high revenue value for the company.

This analysis and prioritization enables McKesson to make clear, calculated decisions on how to proceed with IT security and application security in relation to its overall risk management program. One such decision revolves around which applications to update or end of life. Without this analysis, McKesson could be making decisions based on poor or limited data, investing potentially millions in systems and applications that should have otherwise been rebuilt or replaced.

With the program in place and the prioritized analysis performed, McKesson was able to select a set of application security products, code analysis tools and consulting services to perform routine risk assessments, prescribe risk mitigation tasks, implement secure application development best practices within its software development life cycle and provide management visibility into the status of an effective risk management program that is application security enabled.

Why information security risk management makes sense in the healthcare industry

Posted on September 11, 2010 by John Reno in Main | 1 Comment

Lately I have been thinking about risk in the context of information security and the healthcare industry. I have written an article that you can find here about using risk management to help healthcare organizations manage their information security, privacy and compliance programs more effectively and efficiently. For the most part using risk to manage information security is new territory for the healthcare industry. Yet it has been common practice in the financial services sector for more than ten years. Why it that the case?

In the late 90’s financial services companies in New York, London and Tokyo went through a dramatic change in the way they managed their information security programs. Risk management took over as (and remains today) the dominant paradigm for running an information security program and enabling business in the financial services sector.

Why did that happen? Well, the financial services world is about transactions. By the late 90’s the infrastructure of the internet had evolved to the point where financial transactions were realistic and could done reliably on a scalable basis. The requirements for enabling electronic transactions were (are) as follows:

• Non-reputable communications between two parties, each of whom can verify the time, value and content integrity of the message.

• Confidentiality

• Authorization

• Counterparty authenticity

• High availability

All of these requirements are information security issues. So information security became a competitive differentiator. A major element of winning in the financial service market was managing information security in the most effective and efficient manner. Risk management is the way to do that.

The financial services sector was a natural place for adoption. First, financial institutions are risk-intermediation businesses; as the most sophisticated of them came to realize, the ability to describe, price, and manage risk should be among their core competencies. Second, this sector is rich in data, and thus the raw fuel for risk analysis already exists. Third, and perhaps most important, they are typically highly leveraged and are monitored by regulators who, concerned about the potential impact of failures, pushed for improved risk management. So risk management was and is at the core of the business and the extension of processes and methods to information security was evolutionary rather than revolutionary.

I don’t think the same severe pressures on information security that exist in the financial services industry are present in healthcare. However, by making poor decisions around information security, privacy and compliance organizations can destroy patient trust, increase costs, damage brand and create major liability. I think healthcare IT leaders need to borrow the financial services information security playbook and aggressively adopt risk management.

Service driven innovation in healthcare

Posted on August 31, 2010 by John Reno in Main | Leave a comment

This month’s edition of Harvard Business Review features an article on service driven innovation at Kaiser Permanente. Kaiser is well known in the healthcare industry as a leader in applying IT to improve quality of care and producing better business results. The organization routinely outspends its peers on IT as a percent of revenue and has always rejected the fee for service model that is often blamed for excessive healthcare costs across the industry.


What struck me as interesting about this article is that innovation initiatives are typically associated with expensive, top down endeavors aimed at producing new product categories. The approach at Kaiser is different in that the focus on service driven processes means that innovation can be done rapidly and economically. One example that is cited examines the process that nurses follow to exchange information between shifts. The status quo process took 45 minutes or more and delayed the arriving nurses first contact with their patients. This not only wasted time, but also often resulted in inaccurate information exchange, as well as unhappy patients. After analyzing the process and engaging the nursing teams, a simple breakthrough was identified that called for information exchange to take place with the patient’s at bedside rather than at the nurse’s station. This new process, coupled with supporting software to compile information in standard format throughout the nursing shift, led to much improved quality, staff satisfaction and increased quality of care.


To ensure that the service innovation process takes hold throughout the KP organization every project includes a “change package”. The package consists of a concise set of guidebooks describing the innovation, the process by which it was developed, the benefits for staff and patients and the metrics used to evaluate performance over time. Several versions of the package are targeted at line of business leaders, project managers and frontline staff.


I think this process of service driven innovation can be applied successfully in the information security domain. Incident response is one area that comes to mind. The process calls for coordination with many groups within the organization and the quality of results are driven as much by the thoroughness of the process preparation as the technical methods employed. Another area calling for process innovation is application security. The risk to the organization is acute, but often IT and information security teams get bogged down in reacting to the latest vulnerabilities rather than following a process to reduce risk and liability to the business.


We are in the midst of putting together a white paper that will examine many of these issues as they relate to healthcare IT security and service process innovation.

Patient Consent Policy Guidelines to Support Meaningful Use of Stage 1 Data Exchange

Posted on August 27, 2010 by John Reno in Main | Leave a comment

Last week the ONC privacy and security tiger team for the healthcare IT committee provided guidance on patient consent policy. Summary slides of their recommendations can be found here and the full documentation can be found here. These guidelines are important because the recommendations apply to electronic exchange of patient identifiable health information among known entities to meet Stage I of meaningful use — the requirements by which health care providers and hospitals will be eligible for financial incentives for using health information technology. This includes the exchange of information for treatment and care coordination, certain quality reporting to the Centers for Medicare & Medicaid Services (CMS), and certain public health reporting.

The requirements for supporting meaningful use of stage 1 data exchange consist of both core set and menu set transactions as outlined below:

1. Provide patients an electronic copy of their ambulatory, ED or inpatient summary of care record.

2. Transmit prescriptions.

3. Exchange clinical information among care providers and patient authorized entities.

4. Report clinical quality measures.

Menu Set

5. Incorporate clinical lab tests results into EHRs as structured data.

6. Provide summary of care record for patients referred or transition to another provider or setting.

7. Capability to submit data to immunization registries, provide surveillance and lab data to public health agencies.

Hopefully these national guidelines will reduce duplication of work that has been occurring at the state and regional level and accelerate the meaningful use of HIT and most significantly ensure that patient privacy is protected.