•

» Healthcare IT security

REDSPIN CHIMES IN ON MEANINGFUL USE

Posted on January 14, 2011 by Dan Berger in Main | Leave a comment

A few days ago, members of the College of Healthcare Information Management Executives (CHIME) testified before a federal panel in Washington, D.C. The hearing was entitled “Real World Experience Working with Meaningful Use.” The panel consisted of members of the Implementation Workgroup of the HIT Standards Committee, who in turn report to David Blumenthal, M.D., HIT’s national coordinator.

CHIME representatives shared their direct experiences mainly to convey the challenges hospitals are facing in meeting the HITECH requirements for achieving “meaningful use” of electronic health records. Not coincidentally, the meeting was assembled about a week after the January 3rd registration opening for the Medicare and Medicaid electronic health record (EHR) incentive programs. The money is now available and qualifying healthcare entities could start receiving payments as early as April or May.

Shortly after becoming HIT’s national coordinator Dr. Blumenthal reinforced that achieving the vision of “an interoperable, national health information system” will require unprecedented collaboration between the public and private sector. Last week’s CHIME meeting panel meeting was an attempt at doing just that.  Think of it as “Policy, meet real world. Real world, meet policy.”  CHIME is an executive organization that serves CIO’s and other senior healthcare IT leaders. In includes more than 1,400 CIO members and over 70 healthcare IT vendors and professional services firms. In meeting with HIT Workgroup, the CHIME delegation hoped that by bringing real word experience with EHR to the committee, they will have some impact on the final qualifying criteria for approving “early adopters” of meaningful use (translation: “please lower the bar, particularly for those organizations that have already spent significant time and resources to achieve the goal.”)

Summarizing CHIME’s input:

1.       Revamp meaningful use reporting: The current reporting requirements for achievement of objectives and quality measures are onerous, difficult and time-consuming.

2.       Create a different achievement-level criteria for smaller facilities who typically have smaller IT staffs and/or need to rely on outside vendors to provide services the incentive qualifications consider to be full time positions.

3.       Take into consideration the balance between autonomy and collaboration, particularly when it comes to the requirement to provide for “HIE use cases” showing EMR has been built into physicians workflow. At the individual physician office level, many want to choose their own technologies, but then also expect to be able to send and receive data at will. There is a definite IT knowledge gap here as many physicians don’t actually understanding what’s necessary to ensure all of these systems can “talk” to each other.

At Redspin, we were pleased to see that CHIME did not call the security provisions of meaningful use “onerous, difficult and time-consuming.” In fact, they did not mention security. We’ll take that as full support of its necessity or at least tacit acceptance. Thus, those early adopters should be moving urgently to perform a security risk analysis in accordance with the requirements of 45 CFR 164.308(a)(1). The rule also requires implementation of security updates as necessary and correcting identified security deficiencies as part of its risk management process. From Redspin’s experience with other regulatory compliance areas, we know there will be some lee-way regarding the corrective aspect of the requirement. But at a minimum, healthcare organizations who want to qualify for Stage 1 and start receiving incentive payments as early as possible must: a) identify security risks, b) have remediation efforts underway, and c) put in place an ongoing risk management process. A HIPAA Risk Analysis is the only way to start this process.

The final rule on meaningful use – an opportunity for healthcare process improvement and security program development

Posted on July 17, 2010 by John Reno in Main | Leave a comment

Earlier this week the CMS and ONC released the final Standards Rule for meaningful of electronic health records. This culminates a process in which the ONC received thousands of comments and struggled to reach a balance between specificity (presumed to make certification and implementation a simpler task) and generalization (which can enable more rapid innovation).

An analysis of the requirements can be daunting. For those who choose to go through the details of the requirements, key resources can be found at the Federal Register. Specifically, the Federal Register publication of the Meaningful Use regulation and the Federal Register publication of the Standards regulation. I have found the most useful summary in a recent article in the New England Journal of Medicine by David Blumenthal and Marilyn Tavenner. This reference includes a table with a summary overview of meaningful use objectives and their respective measures. This is a concise and useful description of the 15 core requirements for Eligible Professionals and the corresponding 14 core requirements for hospital organizations as well as the 10 discretionary requirements (of which 5 must be chosen). I have also put together a presentation regarding meaningful use that you may find helpful. Feel free to download it here.

From a security, privacy and compliance standpoint the implications of the final Standards Rule are quite significant. One of the core requirements sets a specific goal: implement systems to protect the security and privacy of patient data in the EHR. The corresponding measure calls for organizations to conduct a security risk analysis, implement security updates and correct identified security deficiencies.

A closer look at the security and privacy rules shows that the most prescriptive requirements involve transport layer security, message integrity and auditing/logging. Key highlights from the regulations are outlined below:

Encryption and decryption requirements for use of electronic health information

Usage guidelines – Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2.

Record actions related to electronic health information

The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded.

Verification that electronic health information has not been altered in transit

Standard – A hashing algorithm with a security strength equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1) as specified by the National Institute of Standards and Technology (NIST) in FIPS PUB 180-3 (October, 2008)) must be used to verify that electronic health information has not been altered.

Record treatment, payment, and health care operations disclosures

The date, time, patient identification, user identification, and a description of the disclosure must be recorded for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501.

Now, let’s look at what this will mean in the healthcare community with a focus primarily on security, privacy and compliance programs. By now, I think most vendors and providers in the healthcare industry segment realize that the transition to widespread adoption and meaningful use of electronic health records is an opportunity for a major overhaul and upgrade of their workflow processes and the IT systems that support those processes. Many people in the healthcare community that I have talked with view this as similar to the challenges faced in the 80’s and 90’s when businesses transitioned to ERP systems. The transition can be a source of major disruption and pain, but ultimately a source of competitive advantage and business agility.

The transition should also be viewed as an opportunity for major enhancements to security, privacy and compliance programs. Information security stakeholders at healthcare organizations need to look at the transition to meaningful use of electronic health records not simply as a set of requirements that call for risk analysis, encryption and auditing/logging, but an opportunity to modernize their information security programs, revitalize governance mechanisms and institute risk management as a core, ongoing process. Pragmatically, healthcare organizations must also realize that for the next 12 to 18 months EMR vendors will be focusing on certification as their number one priority. Certification is a necessity for meeting the requirements of the meaningful use rule and a business driver for the EMR vendor community. Realistically, this means that security will not be the priority that it should be. As a result, more of the burden of systems and application security will fall on the shoulders of deploying organizations.

In summary, the transition to meaningful use of electronic health records is a very ambitious program. The most successful organizations will look to set their own goals and invigorate their security, privacy and compliance programs.

Healthcare Web Applications – The Security Achilles Heel

Posted on June 24, 2010 by mmarshall in Main | 1 Comment

At Redspin we have a unique view of the security space, given that we are hired to perform security assessments of customer web applications all the time. Our clients want to know if a hacker can access their Electronically Protected Health Records. The answer, sadly, is often yes. Many times it is dreadfully easy. This week we accessed a customer portal chock full of EPHI using the classic ‘or 1=1;– trick (SQL injection). For those not technically inclined, this string is usually entered into the username field. It tricks the application so that instead of checking whether the username and password are valid, it checks to see if the username and password are valid or if 1=1. Since 1=1 is always true, a poorly coded application will log the nefarious hacker in (often as the global administrator or system user).

It’s unfortunate that the healthcare space is subject to these flaws, as most of these applications house thousands of EPHI records. These systems commonly have SSN’s, Credit Card Numbers, addresses, DOB’s, essentially everything a nefarious bad guy would need to steal many identities. In addition many people consider their medical information to be their most private data.

Another example is an advisory we just published on Cross-Site Scripting Vulnerabilities and database access in OpenEMR an open source healthcare records application.

It’s not just the small players either, Anthem Blue Cross recently disclosed that over 200,000 records were potentially breached on their website. Many security problems we see are obvious and with basic effort, an organization can be much more secure. According to the report attorneys looking for information for a class action lawsuit against Anthem were able to gain access to the EPHI. This implies that the breach and the flaw were not complicated and didn’t require world class hacking skills. Given that the California Department of Public Health is starting to dole out fines (Healthcare Breach Fines), it will be interesting to see if they hit Anthem with the maximum fine.

The bottom line: if you have EPHI accessible via your Internet facing web applications, perform your due diligence. At Redspin we always recommend starting with the best practices that the Open Web Application Security Project (OWASP) has outlined in their Top 10 Web Application Vulnerabilities list.

HIE’s – Now That the Funding is Complete, What Will the Operational Environment Look Like?

Posted on March 22, 2010 by John Reno in Main | 1 Comment

Last week the Department of Health and Human Services (HHS) announced an additional round of $162M in funding for Healthcare Information Exchanges. Combined with the state grants announced in February, this brings total funding to $547M. This means that all the states and state designated entities are on a path towards implementing the vision of the Office of the National Coordinator for Health Information Technology (ONC) laid out in their strategic plan.

The next step in the process calls for states to develop and align strategic and operational plans that cover what the ONC has termed as the five essential domains: governance, finance, technical infrastructure, business and technical operations and legal/policy. These plans are critical because strategic and operational plans must be approved by HHS before the states are free to begin to use HIE funds for implementation purposes. The plans are also critical to ensure coordination around standards and expand the use of HIE to a national level.

As one might expect this has created a great deal of activity in the healthcare IT sector as vendors position themselves for the operational phase associated with the state funding. As we enter this next phase in the evolution of HIE’s one of the major challenges to be overcome in driving HIE success is associated with ensuring security and privacy, as well as efficiently demonstrating compliance with HIPAA and HITECH requirements. With user requirements ranging from large hospitals to small physicians’ offices, answers to basic questions such as appropriate technical protection mechanisms and access controls present significant challenges. To a certain extent, forming the appropriate answers to questions of security and privacy requires definition of the compute and storage model that will be most prevalent in the environment.

In many respects, the leading model that is emerging in the HIE market is that of a cloud services based platform. In this model the cloud service provider is responsible for providing highly scalable services, authorization, access control, audit logging and data protection. Many vendors such as Axolotl, Covisint, IBM, Microsoft HealthVault/Amalga and Medicity have announced offerings in some form. These have included API’s that allow specialized applications to be developed rapidly while taking advantage of the core infrastructure services. Example applications range from clinical decision support to meaningful use reporting. An illustration of this framework is shown below.


The platform as a service model can be very powerful in the HIE environment because security and privacy services can be leveraged by the applications as well as the providers and consumers of the information. However, for rapid deployment and efficient ongoing operations it is critical that the providers of healthcare cloud services communicate security, privacy and compliance practices and procedures to customers in a transparent fashion. The hospitals, laboratories and physician practices that form the customer base of the HIE need to be able to understand this information and ensure that their security, privacy and compliance needs are met.

A further critical requirement in this model is for the API’s to support a secure ecosystem with common security controls that have been thoroughly tested. I think the emerging nature of the HIE market presents an excellent opportunity for platform vendors to coalesce around a common set of application security controls such as OWASP Enterprise Security API. Adoption of ESAPI would provide consistent application protection as well as leverage for both cloud platform providers and application developers.

As the HIE market evolves through this important phase of development it will be critical to continue to look for additional areas of leverage in the areas of privacy, security and compliance among the many stakeholders.

Healthcare IT Security Developments

Posted on March 17, 2010 by John Reno in Main | 1 Comment

Earlier this week the Office of the National Coordinator for Health Information Technology (ONC) released an initial draft of its healthcare IT framework and strategic plan. This is a high level outline of the themes, principles, strategies and objectives that the ONC will address and reflects an update to the Federal Health IT Strategic Plan published in June 2008. One of the four major strategic themes is privacy and security. As one might expect in the strategies and objectives associated with this theme, there is an emphasis developing, promoting and enforcing privacy and security policies consistently at a federal and state level. With this high level plan in mind, I thought it would be interesting to make some associations with what I have been hearing from healthcare IT leaders in meetings and at industry conferences over the last month or so.

One important aspect mentioned throughout the strategy document is the development, dissemination and promotion of specific IT security best practices. From talking with a significant number of healthcare providers, the top of mind IT security issue was the prevention of security breaches. In an even broader perspective, a recent HIMSS survey of 270 healthcare organizations and 700 hospitals throughout the United States showed that nearly one quarter (23 percent) had suffered a security breach in the last year. Now, there are many things that need to be done to prevent security breaches, but most healthcare providers that I’ve talked with seem to be looking for guidance on encrypting data.

Encryption is certainly a worthwhile starting point, but it is critical to keep in mind that without effective key management encryption will create more problems than it is worth. Given that most deployments occur within heterogeneous IT environments, one of the most common stumbling blocks is a lack of standards across encryption products. There are standards efforts underway through the IEEE and OASIS organizations and several vendors such as EMC/RSA and HP support interoperable key management products. Make sure you have carefully thought through the entire scope of your encryption programs and that interoperable key management is addressed properly. Another important best practice to keep in mind is to clearly map out your policies before starting any implementation. This requires a written policy (that will then be carried out through the administrative interfaces of encryption and key management products) that specifies access procedures, key lifetimes and other similar issues.

A further aspect of the strategy document was the emphasis on use of emerging technologies. In talking with healthcare providers I have been surprised by how many have existing cloud services deployments or are considering some form of public or private cloud deployment. But I have also noticed some degree of naiveté when it comes to understanding best practices associated with IT security in cloud deployments. Several organizations said a key reason for adopting cloud services was to gain the leverage associated with the IT security teams in place at the cloud providers. I completely agree with this argument when it comes to physical and infrastructure security. However, the cloud service provider security teams have no understanding of the application or for that matter the business context. In this case, the healthcare provider still needs to own the information security issues associated with application. From a threat perspective the application layer is where adversaries are focusing their resources, so it is worthwhile to concentrate security resources and protection mechanisms in this area.

I would emphasize that this is a rapidly evolving area with technical, business and legal challenges. In such an environment it important to seek cooperation from other organizations and leverage the work of others. In this regard the Cloud Security Alliance as well as NIST has done important work in framing some of the most important issues and driving consensus around IT security topics. While many are asking for a standard for cloud security, given the diverse business requirements, I don’t think that is possible. But I do think that standard practices and procedures will emerge, as well as standard legal definitions. In the meantime I would encourage healthcare IT professionals take advantage of the leverage that cloud services provide, but assess your risks and develop a plan to manage those risks appropriately.

ROI, NPV and a few other words about predicting the financial performance of information security projects

Posted on January 14, 2010 by John Reno in Main | Leave a comment

Over the course of many years in the information security profession, I have heard claims that the return on investment associated with security projects cannot be calculated. Most often the perspective is that security is a cost center and should be treated as such. I do not have that opinion. The following discussion summarizes Redspin’s work with one of its healthcare customers to calculate return on investment (ROI) and Net Present Value (NPV) in order to justify and manage an information security assessment project. This methodology has been applied with many of our customers in industry segments such as retail, media/entertainment, financial services and technology.
The approach we take is based on protecting data, after all that is a primary goal of information security. Because of this fundamental approach we can use the same methodology for a wide range of projects including internal assessments and web application security assessments. The methodology to calculate ROI and NPV consists of determining the reduced liability associated with identifying and fixing information security issues (thus providing the return side of the equation) and estimating the project costs (supplying the investment information).
In the scenario with our healthcare customer we began with a few questions regarding the characteristics of their security project. For the scope of the assessment project how many data records existed? In this case the assessment spanned two data centers containing a number of databases as well as data records stored in file systems and Microsoft SharePoint. Is the customer subject to regulatory requirements? In this case, yes, the customer was obligated to comply with HIPAA, the HITECH Act, PCI and Sarbanes-Oxley. Next, we asked if a breach occurred would it be high profile (in terms of media and industry visibility) or low profile. Our customer believed a potential breach would be high profile.
The project investment consisted of Redspin costs and customer costs. The Redspin costs included the price of the assessment combined with travel and expense costs. The customer costs were broken down into security and IT staff time to manage the project and staff time to fix the identified issues. These cost estimates were then summed to determine project investment.
The project return is associated with reducing the liability due to a security breach. Our methodology relies on customer surveys performed by Forrester Research to estimate and categorize the cost of a breach per data record. The categories are service availability opportunity cost (customer churn and difficulty in acquiring new customers due to breach), lost employee productivity (employees diverted from primary tasks), regulatory fines (fines imposed by the HITECH Act, FTC, SOX, PCI, etc.), incident response (discovery, notification and response) and increased audit requirements (the security and audit requirements levied as a result of a breach). The cost per record ranges from $10 to $60.
For our customer example we estimated that liability across the five major categories would be reduced in the first year by a total of $3,321,000. The total project investment included a $25,000 Redspin assessment and 18 man weeks of customer staff time for a total investment of $83,000. The project ROI was then calculated as 40.01. The same data was also used to calculate NPV (the present value in today’s dollars of cash flows associated with the project) as $2,573,374.
We have found this methodology to work well across a range of information security projects. It works most effectively when we are working closely with the customer and the customer team includes security, IT and business unit representation.

« Previous   1 2