Can Healthcare Leaders Learn

Information Security Lessons from

the Financial Services Industry?

We compare the
healthcare regulatory
environment to that
of financial services
regarding the handling
of customer confidential
information.

6450 Via Real, Suite3

Carpinteria, CA 93013

WHITE PAPER
800-721-9177
805-684-6858
 TABLE OF CONTENTS
1 Executive Summary
2 Regulatory Parallels
3 A Very Brief Regulatory History and Comparison
4 Lessons Learned and Pitfalls to Avoid
5 A Framework for Improvement
6 Conclusion

Page 1 | www.redspin.com 2009 | White Paper

 Executive Summary
This paper provides forward looking
guidance to health IT managers and
healthcare executives who could
significantly reduce business risks
associated with the confidentiality
requirements of electronic health
information (EHI). We compare the
healthcare regulatory environment to
that of financial services regarding
the handling of customer confidential
information. Because each industry
segment has followed very similar paths,
and because critical milestones of the
financial services legislation were passed
years before, the healthcare industry has
the opportunity to learn from financial
service provider’s mistakes. We discuss
some of the lessons that can be learned
from the financial services industry, how
to avoid the pitfalls they have uncovered,
as well as how to create an effective and
efficient information security program.

Regulatory Parallels
The lessons learned by the financial
The healthcare services industry are important because
their compliance requirements are on
industry has the similar paths regarding data security
issues. Roughly, the experience has
opportunity to evolved as follows: IT becomes more
integrated with business operations (for
learn from financial both healthcare and financial services)
due to regulatory reaction with breach
notification laws after the inevitable data
security breaches have occurred. This
is something to have been expected
given the vast data stores of customer/
patient confidential data. Once these
laws go into effect, the rate of breach
notifications grows significantly.

service provider’s
mistakes.
A Very Brief Regulatory History and Comparison
In financial services a big regulatory milestone occurred in 2001 with section 501(b)
of the Gramm-Leach-Bliley Act (GLBA) which required financial service firms, amongst
others, to establish standards for protecting the security and confidentiality of customers’
non-public personal information. This got the financial services industry really thinking
about their information security program. In healthcare, The Health Insurance Portability
and Accountability Act (HIPAA) (specifically the Security Rule) was the significant
regulatory event that put information security on the industry’s radar.

However, what really got financial services acting on their security and taking their
information security programs seriously was the State of California breach notification
requirements that became effective July 1, 2003 with SB 1386. In that California
State Senate Bill any disclosure of a customer’s unencrypted confidential information
required the entity that lost the information to notify the customers whose data was
compromised. Knowing that sending out the “oops we lost your data” letters to a big list
of customers inevitably winds up in the news, this bill essentially shamed institutions into
taking their information security programs seriously. This was a California state based
law, but because most large customer databases (no matter where those companies
were headquartered) contained some California residents, the legislation affected most
companies nationwide. It also prompted most other states to follow suit with similar laws
– currently most states have similar breach notification laws.

The number of reported data breaches and lost records has grown significantly since
the enactment of SB 1386 and the similar laws enacted since then in most other states.
Now Governor Schwarzenegger has expanded California’s Breach notification law
with the passage of AB 1298, which became effective January 1, 2008. It expands the
definition of personal information in SB 1386 to include medical information and health
insurance information. In addition, the Health Information Technology for Economic and
Clinical Health Act (HITECH Act) of 2009 is meant to improve the quality and efficiency

Page 2 | www.redspin.com 2009 | White Paper

 of healthcare with $19.2 billion in funding to promote electronic health records (EHRs)
via health IT. It was signed into law on February 17, 2009 by President Obama as part
of the stimulus package – the American Recovery and Reinvestment Act of 2009 (ARRA).
The HITECH Act extends the security and privacy provisions of HIPAA and expands
the definition of a covered entity. It requires that covered entities provide notification to
individuals whose information was compromised as well as the Secretary of Health,
Human Services, and media outlets for breaches of 500 or more records. It also extends
the HIPAA Privacy and Security Rule to include business associates. ARRA also provides
cash incentives for compliance, as well as penalties for non-compliance.

Expect additional security breach incident news in the healthcare industry due to this
kind of legislation.

Of course it is not the number of breaches that grow due to breach notification
requirements, just our awareness of them, because security incidents that were otherwise
undisclosed are publicized. However, the business impact of a breach is magnified
when an incident hits the news. There have been hundreds of breaches disclosed due
to the notification requirements and a review of some of the high profile cases make it
clear the extent of the business impact.

• Choicepoint has paid out $25,000,000 in civil penalties, including the

There have been settlement of a class action lawsuit after its February 5, 2005 incident. In this
case thieves set up bogus accounts to steal the confidential data of 163,000
people. The Choicepoint settlement with the Federal Trade Commission
hundreds of breaches required them “to establish and maintain a comprehensive information
security program, and to obtain audits by an independent third-party security
disclosed due to professional every other year until 2026” among other things.

the notification • CardSystems of Tucson, Arizona, June 16, 2005. 40,000,000 credit card
records were compromised when hackers broke into the credit card processor
and accessed unencrypted cardholder data. Visa and American Express
requirements... stopped processing transactions through them.
• Circuit City and Chase Card Services, a division of JP Morgan Chase
& Co. lost data on 2,600,000 customers as it mistakenly discarded backup
tapes on September 7, 2006.
• TJ stores (TJX) on January 17, 2007 reported that around 50,000,000
accounts were compromised in a security breach involving insecure wireless
data protocols. SQL injection was used to extract data from the application.
Breach costs are estimated to exceed $200,000,000 and 19 lawsuits have
been filed.
• Hannaford Bros. Supermarket chain (Portland, ME) reported on March 17,
2008 that credit and debit card information for 4,200,000 customers was
compromised. Class action lawsuits have been filed.
• Heartland Payment Systems (Princeton, NJ) on January 20, 2009
reported that hundreds of millions of debit and credit card numbers may have
been stolen in a data breach. 656 banks have reported associated card
compromises due to the breach. Thirty-one lawsuits have been filed to date.

Clearly, the healthcare industry would benefit from taking note of these incidents
and reacting by improving and placing strategic value in their information security
programs.

Page 3 | www.redspin.com 2009 | White Paper

 Lessons Learned and Pitfalls to Avoid
Specifically, there are some categorical areas of security risk which encapsulate a
significant portion of business impact. By avoiding these pitfalls healthcare IT can
significantly reduce the risk associated with patient confidential information. Here are
some of the pitfalls to avoid.

Confusing Regulatory Compliance with Security and

Risk Management
Security compliance initiatives are put in place, often by a government or industry,
in an attempt to enforce operational discipline and security controls upon an industry
that lacks incentives, resources, awareness or other motivation to do it themselves.
Because regulatory compliance standards are generalized to minimize risk across an
entire industry, they don’t adequately address specific areas of risk for each individual
organization and thus cannot be replicated universally with adequate results. While
it is important to audit for “compliance” with specific regulations, solely focusing on
compliance can miss critical security risks.

Heartland Payment Systems, Inc., CEO, Robert Carr highlights the risk very concisely in
a interview with CSO Magazine regarding their recent data breach involving over 100
million credit/debit card records: “The audits done by our QSAs (Qualified Security
Assessors – the auditors hired to verify compliance with the Payment Card Industry Data
Security Standard – PCI DSS) were of no value whatsoever. To the extent that they were
telling us we were secure beforehand, that we were PCI compliant...”

A risk-based security assessment should be utilized to identify risk, and while these efforts
may look and feel like a compliance audit, their scope may differ significantly – they
might be lighter in some areas, while requiring significantly more depth in others to
address potential risk.

Unfortunately for Heartland, they were not aware of the gap between compliance and
security risk until it was too late. Similarly, it would be foolish to assume that general
HIPAA Security Rule guidance applies equally across the board within healthcare
organizations. An appropriate security program involves a more holistic information
security process including: management leadership commitment and oversight, risk
assessment, technical controls, controls review, security assessment to evaluate risk and
also regulatory compliance. Compliance is a component of an information security
program – not an entire strategy.

We Outsource Some Technology Services to a Big National

Vendor, Thus We’ve Eliminated Our Security Risk in Those Areas
The financial services industry has had a long-standing strategy of outsourcing both
Compliance is a back-end data processing as well as customer facing services. Sometimes these
implementations, in effect, make the outsource company and the financial services firm
component of an look like partner companies as they need to connect their networks together to implement
the service. One benefit of this strategy is that an organization outsources not only the
information security technology, but also (in theory) the security risk and security program. However, while the
latter should be reasonably expected as part of the service being outsourced, it rarely is.
program – not an The FDIC recently reported that the majority of the security incidents in organizations that
they regulate were from outsourcing vendors as opposed to the companies themselves.
entire strategy. In response to outsourcing vendor risk, financial services regulation includes vendor
management requirements in which organizations must assess the security of vendors
and are held accountable for security breaches of their vendors. It is no longer possible
to say: “Its not our fault, the breach was due to a security flaw with the outsourcing
vendor.”

Healthcare organizations should expect a similar evolution, and indeed this is evident in
the regulatory environment. The recent Health Information Technology for Economic and
Clinical Health (HITECH) Act of 2009, among other things, expanded the definition
of a HIPAA covered entity such that any vendor that transmits or has routine access to
protected health information (PHI) is subject to HIPAA Security Rule requirements.

Page 4 | www.redspin.com 2009 | White Paper

 Clearly the regulators understand outsourcing vendor security risk. Healthcare executives
should do the same. With the additional customer and media notification requirements
of the HITECH Act, security breaches, even by an outsourcing vendor, can do substantial
brand and revenue damage. Don’t assume your outsourcing vendors are secure – even
if they are a national brand.

Thinking That More Technology Will Mitigate Security Risk

Technology alone will not protect data from security breaches or system downtime, so
deploying more security technology often gives little more than a false sense of security.
One problem is that the more technology that is deployed, the already overburdened
IT staff is given an additional management and configuration load. Another problem
is that technological controls are often deployed based on news-of-the-day driven fear
rather than a process-driven approach in which the information security program, and its
prioritized characterization of risk guides actions. Another challenge with technology is
that the existence of a security control is often equated with effectiveness. This problem
is as prevalent in healthcare IT as it is with financial services. These controls often will
not be effective in mitigating the risk – not due to technological flaws, but rather a lack
of operational discipline. In other words, the problem is not technology, but the way it is
deployed. In our work, assessing security for our clients, we see countless examples of
this. Firewalls are one example of technology that illustrates this risk.

Firewalls are common network devices used to monitor, control and block network
traffic between two networks, for example, the Internet and an organization’s corporate
headquarters, or one company and a vendor that have connected their networks as part
of a data processing arrangement. While these controls are often a critical component
of network security, more than half of the firewalls we have reviewed are deployed
with flawed configurations. While many of these flaws do not necessarily represent
critical vulnerabilities, it is frustrating to see the extent to which this critical first line (and
sometimes only line) of defense, is not configured properly.

Recently, one of our clients had us test the firewall that controls their access to a vendor –
a Fortune 500 company that hosts back-office services to many clients. We discovered
that from the client network we could access much of the Fortune 500 company’s data
center which stored confidential data for many other clients. Unfortunately, the firewall
was managed by the vendor and when we confronted them with this problem stating
that they only needed to allow each client with access to the few applications needed
for their service (and not hundreds of other ones!). The vendor disagreed, claiming that
it was not a security risk because they had a network security team, ran periodic scans
(which generated hundreds of pages of vulnerabilities) and... had a firewall in place.
Believe it or not, the vendor had to be convinced through communication with higher
levels of management that a firewall with no security rules configured, has no security
value. The vendor has since fixed the problem.

Clearly, the existence of security technology/control does not imply security – it is not
the existence of a control, it is the effectiveness of the control that matters. A key lesson
is that security is not about high technology equipment as much as attention to detail,
capable IT staff and operational integrity. For a security program to meet the needs
of the business, technology must be deployed carefully, peer reviewed, managed
with a process in an organization run by executives who are aware that the small
things matter.

Our Web Application Has Been in Production for Years, if We

Haven’t Been Hacked Yet, it Must be Secure
On a recent audit of a web application for a global financial institution, we identified
a flaw in their application. The flaw was seemingly minor – on certain form fill pages,
when we entered invalid information, an un-trapped error occurred. What this means
is that rather than the web application recognizing that a user had submitted invalid
information and presenting the user with a helpful message such as “please re-enter
your email address and resubmit the form,” it generated an internal system error which
was sent directly to the user. While this is indicative of one of the most common form
of web attack called SQL Injection, in this case the output was very cryptic, just a few
characters.

Page 5 | www.redspin.com 2009 | White Paper

 The flaw existed in the system for a long time (years) and the application was difficult
to update because the application pre-existed the web front-end and would require
a recompile of the core application as well as an update to the web front-end, the
institution opted to leave the application with the flaw.

However, in this case, there was little management motivation to fix the SQL Injection
issue due to the cost and operational challenges to upgrade the production site, we
were commissioned to do additional research on the bug. With some ingenuity and
programming we were able to prove that the SQL Injection flaw on the site would
yield confidential customer information. In this case, the odd characters on the screen
represented binary system memory. Our security engineer on the project noticed that the
error message would change each time the error occurred. We were able to automate
our attack, reverse characters in the cryptic error message, convert it to hex and after
thousands of requests over a period of about a week, we were able to download their
entire application and all of its data in an unencrypted format. As a result, this seemingly
innocuous error provided access to anyone on the Internet with the full contents of the
financial institution’s customer database.

Why had they not yet been hacked? This particular error was not easy to exploit and
required a focused effort by a talented hacker. However, as the industry as a whole
gets more sophisticated with its security defenses, there is less low-hanging fruit and
these types of flaws start to get targeted by hackers whose skills improve over time.
The good news of this story: this company was able to learn from a web application
security assessment that the flaw on their system was serious, as opposed to learning
from an incident.

While virtually all organizations have elements of an adequate information security

program, many of them lack a cohesive information security approach that continually
addresses the state of security risks. A first step to ensure that the full security life-cycle
is reflected in an information security program requires that the executive management
appoint strong leadership to own the information security program. It’s a top-down
executive management problem – so asking, “is executive management on-board?”,
is critical.

A Framework for Improvement

A framework for improvement is just that, a framework, as opposed to a set of ad hoc
Well this particular actions intended to address security as an afterthought. A framework is intended to be
built into the organization in terms of both documented standards as well as a culture
error was not easy of decision making. Here we address the two related high-level activities healthcare
organizations can leverage to minimize security risk and avoid the costly mistakes made
to exploit and by their counterparts in financial services.

Create a Cohesive Information Security Program

required a focused Industries such as financial services that have evolved from the early stages of dealing
with incidents to mature models based on risk have behind them, multiple iterations of
effort by a talented refinement built into their information security programs and capture the entire ongoing
life cycle of security management.
hacker to exploit.
Healthcare leaders should continue to refine their information security programs to
ensure that they are evolving to address the dynamic nature of business risk and the
threat landscape. An effective program should include:

Strong buy-in, leadership and commitment from executive management that

extends beyond check-the-box compliance and addresses true business risk.

Periodic risk assessments in which the business environment is characterized

to define levels of sensitivity/criticality for data and systems. For all assets
(for example: a server, a particular type of data, a business unit network
segment, or a web application), the threats, vulnerabilities and probability of an
attack should be defined along with the impact to the organization, should an
incident occur.

Page 6 | www.redspin.com 2009 | White Paper

 A practical security policy should be developed which addresses overall risk
as defined in the risk assessment. Development of a practical policy requires
commitment from executive management, buy-in from departmental heads, and
education and communication throughout the organization.

Select, implement, assess and monitor controls. Controls should be implemented

in a risk-based prioritized fashion as opposed to being driven by technology,
fear, or the latest incident.

Continually cycling through this process with a feedback loop that ensures the program
is relevant to the business operations and addresses the dynamic nature of the threat
environment will minimize the risk of a major security incident.

Integrate Security into the Web Application Development Life Cycle

Just as operational business security is a function of a well integrated information security
program, developing and operating secure web applications is a function of similar
holistic processes. Many leaders in the financial services sector have discovered that
web applications are not necessarily secure (and probably insecure) by default. The
impact to their organizations in the form of monetary damage and bad publicity is
significant. This is indicative of an environment where it is no longer acceptable to
deploy insecure web applications – security is now expected. The lesson to learn from
this is: without careful thought and consideration into the security of web applications,
No one can assume no one can assume they are secure and need to be dealt with systematically and
methodically.
they are secure and
While there are a variety of documented frameworks used to guide a secure development
need to be dealt with life cycle, the OWASP CLASP (Comprehensive, Lightweight Application Security Process)
project provides a practical starting point. It provides a structured approach to building
systematically and security into an application, rather than to consider it as an afterthought.

methodically. CLASP Defines Seven Best Practices:

1 Institute Awareness Programs
2 Perform Application Assessments
3 Capture Security Requirements
4 Implement Secure Development Practices
5 Build Vulnerability Remediation Procedures
6 Define and Monitor Metrics
7 Publish Operational Security Guidelines

Essentially, these processes define a structured framework for building organizational

support including management commitment for security, documenting security policies to
address standards for software releases and considering security from the early stages
of system requirements and design.

Conclusion
We hope that these observations of the parallel paths taken through the regulatory and
risk environment for healthcare and financial services, clarifies the need to learn from
the costly mistakes of the financial services industry. By taking a holistic view of security
and building it into an organization with an adequate information security program, and
concurrently integrating security into the application development life cycle, healthcare
leaders can significantly reduce the business risk associated with the mass storage of
EHI.

Page 7 | www.redspin.com 2009 | White Paper

 About Redspin www.redspin.com

Redspin delivers the highest quality information security assessments through technical
expertise, business acumen and objectivity. Redspin customers include leading companies
in areas such as healthcare, financial services and hotels, casinos and resorts as well as
retailers and technology providers. Some of the largest communications providers and
commercial banks rely upon Redspin to provide an effective technical solution tailored to
their business context, allowing them to reduce risk, maintain compliance and increase
the value of their business unit and IT portfolios.

Page 8 | www.redspin.com 2009 | White Paper