Data Security in the Pharmaceutical Industry

Download Report

Transcript Data Security in the Pharmaceutical Industry

Data Security in the Pharmaceutical Industry
July 31 - August 1, 2003, Sheraton Society Hill, Philadelphia, PA
Strategies for Overall Data Security, HIPAA, and
21 CFR Part 11 Compliance
Practical Strategies for Risk Assessment,
Authentication, Encryption, and Other
Mandated Security Measures
Stephen Cobb, CISSP
Senior VP, Research and Education, ePrivacy Group
Author: Privacy for Business—Web Sites and Email
Copyright, 2003, Stephen Cobb
cobbassociates.com
Agenda (9AM to 12 Noon)





Practical strategies for matching risk to
authentication, encryption and other security
measures
Perform an acceptable risk assessment as a
precursor to a practical security program
Determine appropriate levels and technologies for
authentication and access controls
Implement workable encryption strategies or avoid
encryption requirements
Put in place other required security measures such
as backup and disaster recovery plans
Page 2 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
General Observations

Security technology has focused on defending corporate
secrets and government networks, but health care and
research also have serious security requirements:
–
Care and research require data sharing
–
Privacy requires data protection and data sharing
–
Privacy and security standards require compliance

Security arsenal—includes authentication, encryption,
VPNs, filtering, firewalls biometrics—can serve these ends

But without proper implementation, training, and support,
security technology is wasteful and doubly insecure

And it all begins with understanding the risks
Page 3 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Why Would Hackers Do This?


Hackers broke into the computer systems belonging to a
clinic in the UK, altered medical records of 6 patients
who had just been screened for cancer—switched test
results from negative to positive—those patients spent
several days thinking that they had cancer
The night before a patient was due to have a brain tumor
removed, hackers broke into the computer where the
tests were stored and corrupted the database. Surgery
had to be postponed while the tests were redone
Why? Because We Can
Source: Richard Pethia,
Software Engineering Institute (SEI)
Pittsburgh
Slogan from DEF CON III
Las Vegas, 1995
Page 4 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Make No Mistake, Your Data Are At Risk
Hackers
Former
Employees
Virus
Writers
Script
Kiddies
Unethical
Employees
Sensitive
Medical
Data
Competitors
Accidents
Unintended
Consequences
Page 5 of 30
Unethical
Partners
Disgruntled
Employees
©Stephen Cobb, 2003
www.cobbassociates.com
How to Assess Risk

Threats
–
–
–

Enumerate threats and threat agents
Assign relative probability
Consensus or forum model
Impacts
–
–
–
Evaluate impact of threats materializing
Rank in terms of impact on mission
Not always $$$ issue
Page 6 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Consult All Parties + Experts

Don’t discount threats not understood
–

Try to anticipate threat trends
–


E.g. wireless, worms, spam
Consider macro factors
–

Expert opinion can help
E.g. bad economics mean more crime
Be realistic with cost figures
See worksheet
Page 7 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Do Not Under Estimate Costs
- Forester Research, Feb 2001 Report (www.forrester.com)
- Forester Research, Feb 2001 Report (www.forrester.com)
Page 8 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Implications of HIPPA Final Security Rule

Federally mandated standard for security practices
–
–
–

For organizations involved in health or handling health-related
information, including much research data
Defines practices necessary to conduct business
electronically in the health care industry today
Requires organizations to document risk assessment with
respect to all security decisions
Some processed are required, but many implementation
specifics are merely “addressable” based on risk
assessment
–
There is no “Thou shalt encrypt X data in Y circumstance”
Page 9 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Implications of HIPPA Final Security Rule

Leaves organizations exposed to court rulings
when cases are brought by persons claiming harm
from exposure of their health data
–

Requires organizations to know what an expert
would determine acceptable risk to be
Standards in other areas can be applied
–
–
–
–
E.g. FTC has created standards that apply to all
companies, including pharmas, healthcare
Specify expert = CISSP or equivalent
Require risk assessment
Reasonableness test applies
Page 10 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
164.306 Security Standards: General Rules
Covered entities must do the following:
(1) Ensure the confidentiality, integrity, and availability of all
electronic protected health information the covered entity
creates, receives, maintains, or transmits.
(2) Protect against any reasonably anticipated threats or
hazards to the security or integrity of such information.
(3) Protect against any reasonably anticipated uses or
disclosures of such information that are not permitted or
required under subpart E of this part.
(4) Ensure compliance with this subpart by its workforce.
Page 11 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Security Rule Sets Standards in 5 Areas
1.
2.
3.
4.
5.
Administrative safeguards
Physical safeguards
Technical safeguards
Organizational requirements
Policies and procedures & documentation
requirements
Technically, compliance with Security Rule is April, 2005
(with one more year for smaller orgs).
But Privacy Rule requires appropriate protections by April,
2003 and the Security Rule defines appropriate protections.
Regulators may not audit until 2005+ but litigators will
probably not hesitate to bring suit this year.
Page 12 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
1. Administrative Safeguards
1.
2.
3.
4.
5.
6.
7.
8.

Security management
process
Assigned security

responsibility
Workforce security
Information access
management

Security awareness and
training
Security incident procedures
Contingency plan
Evaluation
Page 13 of 30
These are “Standards” that
specify steps which must be
taken or addressed.
E.g. a security management
process is required to be in
place and someone must be
assigned responsibility for
security, but management of
passwords is addressable.
Data backup plan and a disaster
plan are required, but testing of
contingency plan is
addressable.
©Stephen Cobb, 2003
www.cobbassociates.com
2. Physical Safeguards 3. Technical Safeguards
1.
2.
3.
4.
Facility access controls
Workstation use
Workstation security.
Device and media controls
4. Organizational
Requirements
1.
2.
Business associate
contracts or other
arrangements.
Requirements for group
health plans
Page 14 of 30
1.
2.
3.
4.
Access control.
Integrity
Person or entity
authentication
Transmission security
5. Policies/Procedures/
Documentation
1.
2.
Policies and procedures.
Documentation
©Stephen Cobb, 2003
www.cobbassociates.com
Final Rule’s “Flexible” Approach
(1) Covered entities may use any security measures that allow the
covered entity to reasonably and appropriately implement the
standards and implementation specifications as specified in this
subpart.
(2) In deciding which security measures to use, a covered entity
must take into account the following factors:
(i) The size, complexity, and capabilities of the covered entity.
(ii) The covered entity's technical infrastructure, hardware, and
software security capabilities.
(iii) The costs of security measures.
Are you qualified to
(iv) The probability and criticality of
determine probability and
potential risks to electronic
criticality of potential risks?
protected health information.
Page 15 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
“Addressable” Implementation Specifications
Some implementation specifications are required and must be
implemented as specified.
Others are “addressable” which means you must: assess whether
the implementation specification is a reasonable and appropriate
safeguard in its environment, when analyzed with reference to
the likely contribution to protecting the entity's electronic
protected health information; and, as applicable to the entity-(A) Implement the implementation specification if reasonable and
appropriate; or
(B) If implementing the implementation specification is not
reasonable and appropriate-(1) Document why it would not be reasonable and appropriate to
implement the implementation specification; and
(2) Implement an equivalent alternative measure if reasonable
and appropriate.
Page 16 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
The Security Toolset

Basic tools are well-established:
–
–

Firewalls now practical for wide range of systems
–

Preventing system abuse as well as malicious code
Intrusion detection and systems surveillance
–

Easier,cheaper, allow DMZ architecture, VPN functions
Anti-virus expanding to include content filtering
–

Firewalls, AV, IDS, encryption, VPN, authentication
But standards are still evolving to meet new
challenges, like Web services and wireless
Used against internal and external activity
Encryption being more widely used
Page 17 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Encryption Basics: Private or Public Key







Two types of encryption: private key or public key
Private key = same password for scrambling and
unscrambling
Plaintext + Password = Ciphertext
Ciphertext + Password = Plaintext
Also called symmetric because same key is used
at both ends of the process
Works well on bulk data, relatively fast
Key management problem: How do you get the
key/password to the recipient?
Page 18 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Encryption Basics: Public Key

Public key encryption uses a pair of keys
–



My Private Key + Your Public Key + Plaintext = Ciphertext
Ciphertext + Your Private Key + My Public Key = Plaintext
The keys are mathematically linked so that:
–



One you can share (public) and one you keep secret (private)
If I use my private key and your public key to encipher a
message then only you can decipher, using your private key,
my public key
Because public key can be public, key exchange is easier
than with symmetric private key, but processing is slow
So only encrypt a key to symmetrically encrypted bulk data
Public key also used in digital signatures for message
authenticity—proving from whom and as sent
Page 19 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Digital Signature Defined




It is an actual transformation of the message itself
that incorporates a "secret" known only to the
signer, and is therefore tied to both the signer and
the message being signed
A signer's digital signature will be different for each
different document he or she signs
All digital signatures can be consider electronic
signatures (21 CFR Part 11)
But not all electronic signatures are digital
signatures
Page 20 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Digital signatures use
public key encryption
So making public key
encryption available
serves several
purposes:
Message auth
Bulk encryption
Electronic signing
Page 21 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Digital Certificates Serve Up Trusted Keys


Need people’s public keys in order to communicate
either with authentication and/or encryption
Digital certificates are issued by a Certificate
Authority (CA) and they store:
–
–
–
–
–
The name of the entity (person or organization)
The entity's public key
The digital signature of issuing CA
The issuing CA public key
Other pertinent information about the entity, such as
authority to conduct certain transactions, etc.
Page 22 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
This the Public Key Infrastructure (PKI)




Required to enable use of public key encryption
Employs directories to serve up public keys of
parties to transactions, stored in digital certificates
Being deployed for 21 CFR Part 11
But PKI, digital certificates and electronic
signatures are NOT secure without proper support
Design
Deploy
Darn well train people how to use it
Page 23 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
In Some Cases Some Data Require Encryption

Encrypted storage
–

Encrypted transfer
–
–

Where access controls are not enough, or to enforce
granularity in access controls
When communication channel is not secure
E.g. Internet, phone lines at home, on road
HIPAA does not say that data traveling
on the Internet has to be encrypted, but
–
–
–
Judge will not be asking “Was it PHI?”
Will be asking “Why wasn’t it encrypted?”
You won’t find be able to a credible witness to say there was
no need to encrypt it
Page 24 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Encryption Needs Protection

PKI, digital certificates, electronic signatures, and
VPNs are NOT secure without proper support
–
–
–

Access controls, training and awareness are required
The more heavily you rely on credentials
The more heavily they must be defended
They are at risk from:
–
–
–
weak passwords, lost laptops, loose PDAs
careless wireless, lazy dial-ins
thoughtless road users, worm and virus victims
Page 25 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
None of it Works Without Authentication
Page 26 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Trouble Ahead?

Wireless is rapidly expanding
–
–
–
–

Out-of-the-office access is a major headache
–


Local networks on 802.11
Wide area via GPRS
Wireless today is relatively insecure, even when default settings are
changed and encryption is on
Standards for better protection are emerging
Notebooks, PDAs and cell phones all have potential to be
stolen/hacked and used to access network/data
More and more people will sue over privacy
Compliance with laws like HIPAA will not be a slam dunk
defense because HIPAA does not specify exactly what
kinds of protection are acceptable
Page 27 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Your Best Weapon? Training & Awareness



Security technology without security training is a waste of
money (e.g. anti-virus software v. email attachments)
The single best defense is a security-savvy workforce
Documented training also creates strong defense for the
organization in the event of privacy or security breach
–



“We trained this person not to do that, so we were not
negligent”
Training required by regulations but more importantly by
due diligence
Eli Lilly case was not HIPAA, was costly to the company,
and better training could have prevented
Training can be accomplished at reasonable cost per
person through technology (web, intranet, video, etc)
Page 28 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Trained Employees are Safer Employees
Page 29 of 30
©Stephen Cobb, 2003
www.cobbassociates.com
Thank You! — For More Information

Email Stephen Cobb, CISSP
–

sc @ cobbassociates.com
Notes:
–
–
CISSP = Certified Information
System Security Professional
(ISC)2 International Information
System Certification Consortium
–
www.isc2.org
Page 30 of 30
©Stephen Cobb, 2003
www.cobbassociates.com