•

» HIE

Healthcare Web Applications – The Security Achilles Heel (Part 2)

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

Last June, one of my colleagues at Redspin blogged about his concern that security flaws in software applications that house ePHI (electronic protected health information) represent a big threat. We had just completed a security assessment for a client and had found it relatively easy to access their customer portal using a common SQL injection technique. ePHI  records represent tempting targets for cyber crime as they typically include a wealth of personal info (name and address, SSN’s, credit card numbers, DOB and more).

The healthcare industry is currently very motivated to deploy EHR systems, increase interconnectivity via HIE’s, and launch new web applications. As data is made more accessible to more audiences, the risk of a breach increases too. The scope of a HIPAA Risk Analysis should include software applications but be sure to hire a company with specific application penetration testing expertise. Make sure your provider is competent, has relevant experience and applies best practices, starting with the Top 10 Web Application Vulnerabilities list as outlined by the Open Web Application Security Project (OWASP).

Another area of focus should be your internal patch management process. Effective maintenance of your current day-to-day IT operating systems and applications is essential but be sure to conduct an inventory of older applications as well. They may have been developed by people who are no longer with your organization.  Some may perform tasks that are very mundane, highly specialized and/or are rarely used. At Redspin we often uncover these “out-of-sight, out-of-mind” applications in our HIPAA Risk Analysis process. Fortunately we have an application penetration testing methodology that is applicable to both web applications and non-web applications

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.

Hard work – The ONC privacy and security tiger team

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

Last week I attended the Healthcare IT Standards Committee meeting. The all day meeting covered a wide variety of topics ranging from the interoperability framework, NHIN governance as well as updates from several teams, including the security and privacy tiger team. The Office of the National Coordinator (ONC) who heads this effort has done a great deal of hard work in gaining the perspectives from a broad set of constituents and communicating progress. Many commercial products and services have working examples in healthcare information exchange on a broad level.

My focus for this discussion has to do with privacy and security. Much of the discussion last week involved transport layer security. Clearly the problem is broader than that. In working on past projects with this sort of scope, I have found that a common understand can be found through the adoption and use of a threat model. There are several strong approaches that can be considered for use. I have found the following to work well.

The general idea is to apply a threat model to a set of applications communicating over NHIN. The process recommends a step by step approach of identifying security objectives; reviewing the application in terms of components, data flows and trust boundaries; decomposing the application in terms of components to identify areas where security needs to be evaluated; creating a structured list of threats; and enumerating likely vulnerabilities associated with the class of application in development. Microsoft advocates a threat classification scheme known as STRIDE. This scheme aims to characterize the threats with respect to the exploit that may be employed. This acronym stands for:

• Spoofing Identity
• Tampering with data
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

These areas provide a helpful mechanism for enumerating threats to the application. Closely associated with this process is a scoring scheme to help evaluate risk to the application. Another acronym applies to this problem as well: DREAD.
DREAD attempts to quantify, compare and prioritize the amount of risk presented by a given threat. It stands for:

• Damage potential
• Reproducibility
• Exploitability
• Affected users
• Discoverability

Typically each of these areas is assessed on a scale of 1 to 10 with 10 referring to the most severe risk. As always risk needs to be evaluated in terms of both probability and impact.

Perhaps the application of these ideas will be helpful as NHIN takes shape.

Electronic prescriptions of controlled substances – a key area where information security is paramount

Posted on June 27, 2010 by John Reno in Main | 1 Comment

Earlier this month the Drug Enforcement Administration (DEA) revised their regulations surrounding the writing of prescriptions for controlled substances electronically. The rule had been published in March on the Federal Register and is now effective. Streamlining the process associated with the e-prescribing of controlled substances has many benefits including cost reduction and improvement in the quality of care. At a recent conference some of the challenges in this area were discussed by Leisa Jenkins, executive director of CareSpark. In the region that the CareSpark RHIO serves, fraud associated with the use of controlled substances is rampant. Patients routinely take advantage of the lack of consistent medical record and cross-state jurisdictional issues to gain fraudulent access to controlled substances. Solving this problem requires that provider organizations invest in information systems and processes that address the issue. Security, privacy and compliance requirements are significant.

This area is a clear example where information security is a business enabler, a topic that I have discussed in earlier posts. It is also an area where the provider organization must ensure that they have thought through the legal defensibility associated with their information security programs.

Let’s now look at some of the security guidelines and requirements necessary for a provider organization to take advantage of e-prescribing. These recommendations apply generally to e-prescribing overall, but look closely at the problem in the context of controlled substances.
One of the critical security issues in this area is authentication. In order to meet the requirements mandated by the DEA an e-prescribing application must comply with security needs on several levels. At the heart of these requirements is two factor authentication. This is necessary for creating a controlled substance prescription, signing the prescription and obtaining the necessary credential. As usual, the National Institute of Standards and Technology (NIST) have provided guidance in this area. Specifically, the guidelines put forward in NIST special publication 800-63-1 provide recommendations. The important take-away is that authentication in the area of e-prescribing for controlled substances requires two factor authentication at NIST assurance level 3. There are several ways to meet this requirement but some technical approaches are rather advanced. Product/service combinations that I would recommend are the solutions from Anakam. In evaluating an authentication solution for this area it is not only a matter of strong security, but also dealing efficiently with the ease of use and workflow considerations in a medical environment.

Beyond authentication there are many additional challenges to deploying and sustaining a secure environment for a mission critical application such as e-prescribing. A useful point of reference is provided by Center for International and Strategic Studies (CSIS). In this report they describe the 20 critical controls necessary for effective cyber defense. Much of the work has been drawn from the experience of blue team members inside the Department of Defense. A conclusion of this report is consistent with our own experience at Redspin that application security is an area where significant investment is required. Information security teams that are charged with supporting mission critical applications such as e-prescribing need to focus not only on perimeter controls, but also on additional areas such as log monitoring, vulnerability remediation process and malware defense.

In subsequent posts I will delve further into some of the application security specifics, as well as discuss the aspects of legal defensibility associated with an information security program in this area.

State HIE deployments – Some thoughts from the field

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

Health and Human Services Secretary Kathleen Sebelius is one busy government employee. From announcements regarding Regional Extension Center Awards and Job Training Grants to the State Health Information Exchange Cooperative Agreement Program, it’s a daunting task to keep up with the acronyms and initiatives.

For the healthcare provider on the front lines, these announcements are just part of several waves of carrot and stick techniques that will ideally drive the U.S. healthcare system toward competitiveness. The carrots have already started coming in terms of grants and incentive payments. State grants (through governor appointed State Designated Entities (SDEs) and state Medicaid agencies) help states improve the exchange of healthcare information which will in turn have many benefits ranging from quality of care to cost reduction.

This sweeping effort reminds me of a huge product development effort on the level of a complex computer system or microprocessor. Given that I have been through more than my fair share of these development efforts, I dug out some notes that I have seen put to very effective use when teams at Intel, IBM and Microsoft and others faced complex endeavors. You might think of these like Stephen Covey’s Seven Habits of Highly Effective People, but for geeks.

1. Focus on tactics, not strategy – Andy Grove, Intel
2. Learn from others – Steve Jobs, Apple
3. Plan to throw one away – Frederick Brooks, IBM
4. Pilot as quickly as possible – Bill Gates, Microsoft
5. Implement in the lab rather that the conference room – Andy Bechtolsheim, Sun
6. Let the most important use cases lead, others will follow – Bill Harris, Intuit
7. Focus on information and users, gain critical mass as quickly as possible – Jeff Bezos, Amazon

But rather than go on and write a book about complex system development process, I thought I would stick to information security and offer a few insights to those that must secure these healthcare information exchanges.

Here are a few things to keep in mind with respect to information security and healthcare information exchange.

• Things will go wrong eventually – have an incident response plan; practice it.
• Make sure you have a CISO. I haven’t met very many in this sector (unfortunately).
• Invest in an information security assessment (yes, I realize it is self-serving).
• Derive policy from security goals and make sure it’s enforceable.
• Develop and maintain a risk management program (the only way to make stakeholders happy).
• Practice business continuity like elementary school fire drills.
• Take a similar approach to security awareness training.
• Review and act on your logs – enough said.
• Develop a threat model – your adversaries are bad, bad.
• Maintain adequate business associate oversight – trust no one.
• Harden your systems, run a patch management program under change control, etc. – this is basic stuff.

There is so much more, but hopefully I have given you a few things to think about.

Attack Surface Reduction – An often overlooked element of web application security

Posted on May 30, 2010 by John Reno in Main | Leave a comment

In industry surveys ranging from the Symantec Threat Report to Gartner analyst reports, application security is constantly cited as the most significant area of risk for enterprises and the most prevalent threat vector for cyber crime. It certainly makes sense, why bother to spend time on reconnaissance when the front door is wide open?

Many organizations have begun to spend a great deal of energy and money to secure applications. Popular approaches include code review, threat modeling, source code analysis and black box testing. Often overlooked is the rather fundamental practice of reducing the attack surface of the application.

During development and configuration of a system and the associated application the software must typically expose both customer and business assets through network ports, database access, APIs, web services and the user interface. The entire collection of entry points in a product is called its Attack Surface. These form the ways in which an adversary can attack a system. A big attack surface generally means big security issues, or often more time and budget dollars dedicated to protecting the system. It’s also important to remember that channels to local resources are not the only vectors for attack, remote resources must also be kept in mind.

Generally, when a software system is architected, implemented and configured, the top of mind issue is about providing useful functionality that meets business goals. From a security point of view, however, the design and deployment teams must also think about turning things off as well as on. From a design standpoint this involves reducing the amount of code that is executing by default, running with user privileges rather system, reducing functionality and data accessible to unauthenticated users and limiting the damage if access points are exploited. From a system configuration point of view this involves turning off unnecessary services, providing access only to required authorized users on specific subnets, and using strong ACLs to control access to resources.

The security community has done a relatively good job with respect to understanding which attack vectors are more likely targeted by adversaries.  Given that perspective, keep the following in mind:

• Minimize the use of scripting engines and controls such as ActiveX, JavaScript or VBScript.
• Avoid symbolic links as these are likely targets.
• Restrict file permissions to the fullest extent possible.
• Minimize the number of services that must run as root.
• Keep up with vulnerability research and build an effective patch process.

A useful practice is to put together a design guideline for developers suitable to your design environment and the business and security requirements associated with your system. Further, at deployment time, a security configuration guide and checklist of security best practices is recommended. Interestingly, some in the industry such as SAP have invested even more heavily in this area. SAP Labs has developed and begun pilot deployment of an Eclipse extension that uses a more formal process to measure attack surfaces. Their method involves summing the damage and potential-effort ratios (DER) of relevant resources. The relevant resources of an application include its channels, such as TCP ports; methods, such as API calls; and data, whether persistent, in memory, or in transit. The DER of a resource is the ratio of potential damage to the effort required to breach the resource. The SAP tool discovers application resources and combines that data with DER numbers to generate attack surface metrics for software components. While the discovery of resources is fully automated, the tool requires context specific configuration based on experience, judgment, and a threat modeling process.

Given the complex nature of deploying SAP software securely it’s not surprising that they have invested in this area. However, all systems can benefit immediately from simply measuring the potential avenues of attack and understanding the impact. This practice can be particularly beneficial for complex systems with many configuration decisions. In the healthcare sector, where Redspin has done many information security assessment projects, a good example is healthcare information exchange systems. A further example with broad deployment across many sectors is CRM systems.

Whether through design reviews, deployment guides or development tools, the practice of reducing the attack surface associated with an application has the potential to quickly yield a high return on investment.

Economics, HIE’s, and Information Security

Posted on May 5, 2010 by John Reno in Main | Leave a comment

Do economics, HIE’s and information security seem like a strange set of words to find together? I’ve been spending a lot of time recently talking with folks at healthcare providers and healthcare IT vendors, and they have found the relationships among these words fascinating. What I have encountered is a quite different set of viewpoints, that form an interesting contrast with the stories related to ARRA funding, state HIE initiatives and breach notification penalties that have been filling the mainstream healthcare IT trade press.

My primary line of discussion with providers (mainly hospitals and integrated delivery networks or IDNs) and HIE vendors has been around the topic of what are the economic drivers associated with HIE deployment and use. It was interesting to find that while hospitals and IDNs see significant benefit in participating in state funded and operated HIE’s over the medium to long term, they are launching their own HIE programs to take advantage of economic benefits in several areas. Several organizations outlined the following elements of near term focus:

• Decrease costs through elimination of redundant tests, fewer lab orders and imaging procedures.

• Improve productivity through workflow optimization in areas such as finding patient records and overall throughput.

• Increase quality in areas such as e-prescribing and more accurate diagnosis.

Over the medium to long term, expected benefits included additional areas such as meeting meaningful use requirements, increased physician referrals and improved patient satisfaction.

Another significant development that has lowered the barriers to taking on an HIE initiative is the growing popularity of software-as-a-service (SaaS) based solutions from the HIE vendor community. These services from vendors such as Axolotl, eClinicalWorks, Initiate, Medicity and RelayHealth mean that the funding organization does not have a capital outlay.  The hospital or IDN needs to focus simply on the operating model to make the economics work.

So where does information security factor into the equation? Well for one, from the vendors and providers that I have talked with, the prospect of managing the security, compliance and privacy of all the sensitive data that an HIE program drives causes a great deal of lost sleep. But security must also be viewed as an economic enabler – if the patients, physicians and hospital staff can use the system effectively, with the assurance that sensitive data is protected and accessed properly, the benefits described earlier can generate the necessary top-line and bottom-line results. Often a common pitfall encountered in structuring security programs is a reliance on simply meeting compliance requirements. While necessary, such an approach by no means is a formula for ensuring security or reducing risk.

In working with both vendors and providers on security, privacy and compliance in the HIE space, we have found the most productive approach is to start with an assessment, break the problem down in to manageable areas, staff appropriately and manage risk on an ongoing basis. The table below outlines how we structure a security assessment for both vendors that are operating a SaaS-based HIE solution or healthcare providers that are using the system.

The information security program is fundamental to the success of an HIE initiative. Making the economic model work effectively requires a focus beyond obvious areas such as compliance and technical controls with careful attention to governance, risk management, and operational process. Draw on expert experience and the business benefits of an HIE program will yield near term and long term results.

Healthcare IT – Key Security Areas to Get Right

Posted on April 6, 2010 by John Reno in Main | Leave a comment

According to the datalossDB.org, over 110 healthcare organizations have reported the loss of sensitive PHI and/or PII data affecting 5,306,000 people since January 1998. Over 40 percent of the losses were related to theft of laptops, tapes or other media. Another 27 percent were the result of loss or negligence by staff or third parties. Malicious insiders were responsible for 20 percent and 9 percent were related to external attacks, with the remaining 2% unknown. Given that the problem is highly likely to grow with the advent of greater information sharing through systems such as healthcare information exchanges (HIE), it is critical to apply security resources effectively and efficiently.

While external attacks often get the headlines, clearly the data shows it is only a small part of the problem. Outlined below are a few recommendations associated with key security areas to get right. Focus on these areas will help prevent data loss, save money in terms of compliance violations and in the end create value through systems that securely support the mission of the organization.

• Policy – Invest up front in analysis of policy requirements. Ensure the policies support both security and business goals. Guard against policies that are not enforceable. Complete a review of the policies with a trusted security assessment firm. Budget for training and awareness when rolling out the policies.

• Encryption – Use it with all PII and PHI data. Do not “roll your own”. Build on the wisdom of others and the vendor community. Spend time to architect and review your key management scheme. Make sure it is supported across the entire lifecycle of the data.

• Authentication and authorization – This provides a critical defense layer against attackers and malicious insiders as well as provides a critical mechanism that drives ease of use (and thus productivity). As with encryption don’t to be tempted to roll your own because you have “special needs”. Use vendor solutions that have been well tested or open standards from organizations such as OWASP (ESAPI).

• Third party assessment of the overall system – Invest in an information security assessment from a trusted vendor with healthcare domain expertise. The investment will pay back in terms of reduced cost of compliance, data breach penalties avoided, and value delivered to the users of the system.

• Change management – Ensure the change management process is well understood. Functional testing is a given, but security controls and policies must be thoroughly checked with each release (whether major or minor).

Clearly, there are many additional security concerns, but focus on these areas should yield high return in terms of the value of your system and the protection of your data.

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.