Redspin Security Blog

Service driven innovation in healthcare

John Reno — Wed, 01 Sep 2010 03:59:41 +0000

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

John Reno — Fri, 27 Aug 2010 14:43:14 +0000

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.

How Social Media Can Compromise Your Company’s Security Posture

Jenn Miller — Tue, 24 Aug 2010 23:29:35 +0000

The unbridled use of social media in the workplace represents a growing area of risk to an organization’s information security posture. Social media networks present two distinct attack vectors: information leakage and false trust.

Hackers, red teams and experienced penetration testers have used OSINT (open source intelligence style information gathering) for years. But now that social media use has reached critical mass, it is relatively simple to garner information about your company’s employees, your organization and even your IT infrastructure. Using social profiles, information parsed from tweets, business directories, job postings, etc., cybercriminals can put together a complete dossier on employees of a target company without any ‘real’ hacking.

Employees most often use social media both at home and at the workplace without differentiating between the two. On social media networks, users create profiles, manage privacy settings, and grant permission to who can and can’t view their profiles. This creates a false sense of trust, where an individual feels comfortable disclosing detailed personal information about their life whether it be regarding relationships, issues at work, contact info, travels plans, likes and dislikes.

In addition, because they believe they are within a “walled garden,” they are more apt to click on unknown links (because they are recommended by a “friend.”) Link shorteners can heighten the risk as a full executable string can hide behind what appears to be an innocuous link. Clicking on an unverified link is a risk that could lead to a full system compromise if a malicious website is behind it and there is potential for the introduction of viruses and malware to the organization’s network.

The complete list of threats and vulnerabilities from social media in the workplace is long. Other examples include: phishing attacks, disclosure of private company info, brand/reputational damage, harassment and privacy violations.

Social media is not going away. More likely, the number of users and time spent on social networks will continue to rise exponentially, and your security risk will rise with it. Here’s what you can do about it.

Redspin’s 5 Tips to Improve Security Against Social Media Threats

Determine if social media use is necessary for your business. The security risk that social media presents for a company is significant. Whether or not to allow its use in the workplace is really a question of risk vs. benefit. If banning it outright seems too Draconina, consider limiting use to only the people that need it to perform their job function.
Provide training and security awareness to employees. This should include policies and procedures such as personal use in/out of the workplace, business use, nondisclosure of business content, and disallowed activities (installing apps, playing games, etc).
Use content monitoring technologies
Encourage URL lengthening tools like TinyURL to decode and verify shortened links.
Keep your hardware, software, anti-virus, and critical security patches up to date.

Thoughts on Intel’s acquisition of McAfee

John Reno — Fri, 20 Aug 2010 16:56:46 +0000

Yesterday Intel took most of the security industry by surprise by announcing a $7.68 billion acquisition of McAfee. The party line justification from Intel was that security will become the third major element of differentiation in Intel’s processor franchise, along with energy-efficient performance and connectivity. The near term beneficiaries seem to be McAfee shareholders as the market reacted by driving McAfee up some 60%.

I think the most significant implication of this deal is that it another example of the fact that security is viewed by enterprise customers as part of a broader IT stack. Over time security technology will find its way into the broader computing and communications ecosystem. Certainly, Intel has current IT system management initiatives such as vPro that will benefit from security technology integration but that’s hardly enough reason to spend nearly $8M on a $2M revenue stream.

Intel’s mindset is and for many years now has been about protecting and growing the market opportunity for the x86 franchise. While the server business is doing well, the major growth business over the next several years is in mobile devices (or more specifically phones). The problem for Intel is that the dominant processor architecture in that market is not x86, but ARM. ARM has recently aligned with Microsoft thus creating a schism in the partnership that worked so well in building the PC ecosystem. So now, with the McAfee acquisition, Intel has a brand that is strongly associated with security and mechanism to use security as means to disrupt the next great target market.

Will it work? That’s hard to say. The phone market is different in that the dominant players such as Apple and RIM control the OS. One could argue that this is the right place for security capability to live and that the horizontal view of the market that makes Intel comfortable just isn’t reality.

Was McAfee a good choice? I would argue that there really wasn’t much of a choice once Intel convinced itself that security could become a differentiating element for the x86 architecture. Intel is a big McAfee customer for desktop protection, but I can assure you this move had little to do with technical merits. In this case brand was as important as technical merit.

What does it mean for enterprise customers? Probably not that much in the near term other than that as the deal goes through the approval process over the next few quarters McAfee will have to continue to make its numbers, so it’s a great time to negotiate favorable licensing terms with them.

Defcon: Advanced Format String Attacks

The Shell Shakespear — Tue, 10 Aug 2010 00:15:18 +0000

Congratulations to those that survived the giant hangover that was Defcon 18, my presentation on Advanced Format String Attacks and especially the post Q&A and Mario Kart. My presentation was a continuation of my previous Automatic Format String Exploitation research, and I have updated the materials from the presentation here: defcon-18-paul_haas-advanced_format_string_attacks_final.pdf. I have also uploaded the demos from my talk, sans voice:

Demo 1: Attacking a program vulnerable (Makefile) to a format string attack, we dump the stack of the program until we find our passed format string using the following code:
for i in {001..200}; do echo -n "offset $i (%$i\$08x) = "; ./printf "%$i\$08x" | python -c "import sys, struct; s=int(sys.stdin.read(),16); print '0x%08x: %s' % (s,repr(struct.pack('L',s)))"; done

Demo 2: Finding the address of our format string. This combined with the stack offset found in the previous step lets us associate any data on the stack with its address using the following code:
or i in {1..100}; do ./printf "offset $i = %$i\$p:%$i\$s"; echo; done | grep -v ^$

Demo 3: Video of our technique demonstrated in our previous POC tool automatically exploiting a program vulnerable to a format string attack by locating the stack offset and address of our exploit and overwriting a known return location.

Demo 4: Automatically exploiting a program vulnerable to a format string attack by locating the stack offset and address of our exploit and brute forcing address on the stack for a valid return location. This includes both a Python and Ruby implementation.

Demo 5: Metasploit demonstration of a remote server vulnerable to a format string attack exploited automatically by locating the stack offset and address of our exploit and brute forcing address on the stack for a valid return location. The Metasploit module and vulnerable server are available for download.

All of the above plus additional documentation can be downloaded in a single archive here: DEFCON-18-Haas-Adv-Format-String-Attacks.tar.bz2

Getting things done – building and improving an application security program

John Reno — Thu, 29 Jul 2010 02:58:22 +0000

It seems that the realization that applications provide the most dangerous attack vector and the most common area of exposure for enterprise data has begun to take hold with the healthcare and financial services organizations that I have been talking to recently. The natural question that results is what should be done. What is the best approach to building or improving an application security program?

Often security teams look to industry analysts for their views on trends and developments with respect to security, compliance, privacy and cyber crime in hope of educating executive staff and gaining funds. Such an approach can be useful. In fact, the Ponemon Institute released last week a study of the cost of cyber crime over the last nine months in 45 U.S. companies. The median annualized cost of cyber crime in these organizations was $3.8M and companies reported more than one successful attack per week. While such facts can help make the case for investment in security, I would recommend a more thoughtful, structured approach that has immediate impact but builds for the long term.

In terms of building a new application security program or improving an existing one, I am partial to focusing on two key areas: creating leverage with the organization and replicating what has been successful in other enterprises. Ultimately both these activities help gain executive support and form the foundation for a well structured and effective program.
Let’s look at the first area which seeks to maximize leverage with other organizations within the enterprise. In previous posts I have referenced the diagram below to illustrate the point of how information security interacts with other groups within an organization.

An effective application security program requires alignment with the lines of business as well as sponsorship and coordination between development, QA and operations. Ultimately, all the organizations need to be brought on board with the process and support of the application security program whose goals should include:

• Risk management driven decisions

• Clear direction on how to achieve application security

• Cost reduction through standard, repeatable process

• Increased code quality

The second area of focus is to evaluate what has been successful in other enterprises. An excellent resource for this is the Building Security in Maturity Model or BSIMM. This initiative is a descriptive look at application security programs across thirty companies in sectors such as financial services, healthcare, technology and independent software vendors. Participating companies include organizations such as Bank of America, Capital One, EMC, Intel, Google, Microsoft, Nokia, Thomson Reuters and VMWare.

BSIMM lays out a software security framework consisting of twelve practices organized into four domains. The domains consist of the following:

• Governance – the practices that enable management, organization and measurement of an application security program.

• Intelligence – the collection of knowledge used in carrying out the program.

• Secure software development lifecycle touchpoints – activities supporting the analysis and assurance of applications.

• Deployment – practices that interface with operations, security and support organizations.

The domains, practices and associated business goals are shown in the table below.

The BSIMM initiative further lays out a maturity model for each of these areas identifying three levels of maturity with various practices that reflect program development. Perhaps most interesting is to look at the practices that the companies participating in the program have in common. These may not be a direct fit for every program, but you can conclude that they are found in many highly successful application security programs. The objectives and activities associated with the common practices are outlined below.

Hopefully these ideas will help to refine and develop your application security programs. I would encourage a close look at the BSIMM document.

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

John Reno — Sat, 17 Jul 2010 20:35:22 +0000

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.

Hard work – The ONC privacy and security tiger team

John Reno — Thu, 08 Jul 2010 15:53:22 +0000

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 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

John Reno — Sun, 27 Jun 2010 20:16:06 +0000

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.

Healthcare Web Applications – The Security Achilles Heel

mmarshall — Thu, 24 Jun 2010 21:10:01 +0000

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.