Health Information Privacy and Security

TMHG 529
Health Information
Privacy & Security
Nawanan Theera‐Ampornpunt, M.D., Ph.D.
Faculty of Medicine Ramathibodi Hospital
Mahidol University
December 16, 2014
http://www.SlideShare.net/Nawanan

Outline
 Introduction to Information Privacy & Security
 Protecting Information Privacy & Security
 User Security
 Software Security
 Cryptography
 Malware
 Security Standards
 Privacy & Security Laws will be in next topic

Introduction to
Information Privacy &
Security

Threats to Information Security
Malware

Sources of the Threats
 Hackers
 Viruses & Malware
 Poorly‐designed systems
 Insiders (Employees)
 People’s ignorance & lack of knowledge
 Disasters & other incidents affecting
information systems

Consequences of Security Attacks
 Information risks
 Unauthorized access & disclosure of confidential information
 Unauthorized addition, deletion, or modification of information
 Operational risks
 System not functional (Denial of Service ‐ DoS)
 System wrongly operated
 Personal risks
 Identity thefts
 Financial losses
 Disclosure of information that may affect employment or other
personal aspects (e.g. health information)
 Physical/psychological harms
 Organizational risks
 Financial losses
 Damage to reputation & trust
 Etc.

Privacy & Security
 Privacy: “The ability of an individual or group
to seclude themselves or information about
themselves and thereby reveal themselves
selectively.” (Wikipedia)
 Security: “The degree of protection to safeguard
... person against danger, damage, loss, and
crime.” (Wikipedia)
 Information Security: “Protecting information
and information systems from unauthorized
access, use, disclosure, disruption, modification,
perusal, inspection, recording or destruction”
(Wikipedia)

Information Security
 Confidentiality
 Integrity
 Availability

Examples of Confidentiality Risks
http://usatoday30.usatoday.com/life/people/2007‐10‐10‐clooney_N.htm

Examples of Integrity Risks
“Operation Aurora”
Alleged Targets: Google, Adobe, Juniper Networks,
Yahoo!, Symantec, Northrop Grumman, Morgan Stanley,
Dow Chemical
Goal: To gain access to and potentially modify source
code repositories at high tech, security & defense
contractor companies
http://www.wired.com/threatlevel/2010/03/source‐code‐hacks/
http://en.wikipedia.org/wiki/Operation_Aurora

Examples of Integrity Risks
Web Defacements
http://news.softpedia.com/news/700‐000‐InMotion‐Websites‐Hacked‐by‐TiGER‐M‐TE‐223607.shtml

Examples of Availability Risks
Viruses/worms that led to instability &
system restart (e.g. Blaster worm)
http://en.wikipedia.org/wiki/Blaster_worm

Examples of Availability Risks
Ariane 5 Flight 501 Rocket Launch Failure
Cause: Software bug on rocket acceleration due to data conversion
from a 64‐bit floating point number to a 16‐bit signed integer without
proper checks, leading to arithmatic overflow
http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Interesting Resources
 http://en.wikipedia.org/wiki/List_of_software_bugs
 http://en.wikipedia.org/wiki/Notable_computer_viruses_a
nd_worms
 http://en.wikipedia.org/wiki/Hacktivism
 http://en.wikipedia.org/wiki/Website_defacement
 http://en.wikipedia.org/wiki/Hacker_(computer_security)
 http://en.wikipedia.org/wiki/List_of_hackers

Protecting Information
Privacy & Security

Common Security Terms
 Attack
 An attempt to breach system security
 Threat
 A scenario that can harm a system
 Vulnerability
 The “hole” that is used in the attack

Class Exercise
 Identify some possible means an
attacker could use to conduct a
security attack

Simplified Attack Scenarios
Alice
Server Bob
Eve/Mallory

Alice
Server Bob
‐ Physical access to client computer
‐ Electronic access (password)
‐ Tricking user into doing something
(malware, phishing & social
engineering)
Eve/Mallory

Alice
Server Bob
‐ Intercepting (eavesdropping or
“sniffing”) data in transit
‐ Modifying data (“Man‐in‐the‐middle”
attacks)
‐ “Replay” attacks
Eve/Mallory

Alice
Server Bob
‐ Unauthorized access to servers through
‐ Physical means
‐ User accounts & privileges
‐ Attacks through software vulnerabilities
‐ Attacks using protocol weaknesses
‐ DoS / DDoS attacks Eve/Mallory

Alice
Server Bob
Other & newer forms of
attacks possible
Eve/Mallory

Safeguarding Against Attacks
Alice
Server Bob
Administrative Security
‐ Security & privacy policy
‐ Governance of security risk management & response
‐ Uniform enforcement of policy & monitoring
‐ Disaster recovery planning (DRP) & Business continuity
planning/management (BCP/BCM)
‐ Legal obligations, requirements & disclaimers

Alice
Server Bob
Physical Security
‐ Protecting physical access of clients & servers
‐ Locks & chains, locked rooms, security cameras
‐ Mobile device security
‐ Secure storage & secure disposition of storage devices

Alice
Server Bob
User Security
‐ User account management
‐ Strong p/w policy (length, complexity, expiry, no meaning)
‐ Principle of Least Privilege
‐ “Clear desk, clear screen policy”
‐ Audit trails
‐ Education, awareness building & policy enforcement
‐ Alerts & education about phishing & social engineering

Alice
Server Bob
System Security
‐ Antivirus, antispyware, personal firewall, intrusion
detection/prevention system (IDS/IPS), log files, monitoring
‐ Updates, patches, fixes of operating system vulnerabilities &
application vulnerabilities
‐ Redundancy (avoid “Single Point of Failure”)
‐ Honeypots

Alice
Server Bob
Software Security
‐ Software (clients & servers) that is secure by design
‐ Software testing against failures, bugs, invalid inputs,
performance issues & attacks
‐ Updates to patch vulnerabilities

Alice
Server Bob
Network Security
‐ Access control (physical & electronic) to network devices
‐ Use of secure network protocols if possible
‐ Data encryption during transit if possible
‐ Bandwidth monitoring & control

Alice
Server Bob
Database Security
‐ Access control to databases & storage devices
‐ Encryption of data stored in databases if necessary
‐ Secure destruction of data after use
‐ Access control to queries/reports
‐ Security features of database management systems (DBMS)

Privacy Safeguards
 Security safeguards
 Informed consent
 Privacy culture
 User awareness building & education
 Organizational policy & regulations
 Enforcement
 Ongoing privacy & security assessments, monitoring,
and protection
Image: http://www.nurseweek.com/news/images/privacy.jpg

User Security
 Access control
 Selective restriction of access to the system
 Role‐based access control
 Access control based on the person’s role
(rather than identity)
 Audit trails
 Logs/records that provide evidence of
sequence of activities

User Security
 Identification
 Identifying who you are
 Usually done by user IDs or some other unique codes
 Authentication
 Confirming that you truly are who you identify
 Usually done by keys, PIN, passwords or biometrics
 Authorization
 Specifying/verifying how much you have access
 Determined based on system owner’s policy & system
configurations
 “Principle of Least Privilege”

User Security
 Nonrepudiation
 Proving integrity, origin, & performer of an
activity without the person’s ability to refute
his actions
 Most common form: signatures
 Electronic signatures offer varying degrees of
nonrepudiation
 PIN/password vs. biometrics
 Digital certificates (in public key
infrastructure ‐ PKI) often used to ascertain
nonrepudiation

User Security
 Multiple‐Factor Authentication
 Two‐Factor Authentication
 Use of multiple means (“factors”) for authentication
 Types of Authentication Factors
 Something you know
 Password, PIN, etc.
 Something you have
 Keys, cards, tokens, devices (e.g. mobile phones)
 Something you are
 Biometrics

Need for Strong Password Policy
So, two informaticians
walk into a bar...
The bouncer says,
ʺWhatʹs the password.ʺ
One says, ʺPassword?ʺ
The bouncer lets them
in.
Credits: @RossMartin & AMIA (2012)

Recommended Password Policy
 Length
 8 characters or more (to slow down brute‐force attacks)
 Complexity (to slow down brute‐force attacks)
 Consists of 3 of 4 categories of characters
 Uppercase letters
 Lowercase letters
 Numbers
 Symbols (except symbols that have special uses by the
system or that can be used to hack system, e.g. SQL Injection)
 No meaning (“Dictionary Attacks”)
 Not simple patterns (12345678, 11111111) (to slow down brute‐force
attacks & prevent dictionary attacks)
 Not easy to guess (birthday, family names, etc.) (to prevent
unknown & known persons from guessing)
Personal opinion. No legal responsibility assumed.

Recommended Password Policy
 Expiration (to make brute‐force attacks not possible)
 6‐8 months
 Decreasing over time because of increasing computer’s
speed
 But be careful! Too short duration will force users to write
passwords down
 Secure password storage in database or system
(encrypted or store only password hashes)
 Secure password confirmation
 Secure “forget password” policy
 Different password for each account. Create variations
to help remember. If not possible, have different sets of
accounts for differing security needs (e.g., bank
accounts vs. social media sites) Personal opinion. No legal responsibility assumed.

Techniques to Remember Passwords
 http://www.wikihow.com/Create‐a‐Password‐You‐Can‐
Remember
 Note that some of the techniques are less secure!
 One easy & secure way: password mnemonic
 Think of a full sentence that you can remember
 Ideally the sentence should have 8 or more words, with
numbers and symbols
 Use first character of each word as password
 Sentence: I love reading all 7 Harry Potter books!
 Password: Ilra7HPb!
 Voila!
Personal opinion. No legal responsibility assumed.

Social Engineering Examples
Dear mail.mahidol.ac.th Email Account User,
We wrote to you on 11th January 2010 advising that you change the password on
your account in order to prevent any unauthorised account access following
the network instruction we previously communicated.
all Mailhub systems will undergo regularly scheduled maintenance. Access
to your e‐mail via the Webmail client will be unavailable for some time
during this maintenance period. We are currently upgrading our data base
and e‐mail account center i.e homepage view. We shall be deleting old
[https://mail.mahidol.ac.th/l accounts which are no longer active to create
more space for new accountsusers. we have also investigated a system wide
security audit to improve and enhance
our current security.
In order to continue using our services you are require to update and
re‐comfirmed your email account details as requested below. To complete
your account re‐comfirmation,you must reply to this email immediately and
enter your account
details as requested below.
Username :
Password :
Date of Birth:
Future Password :
Real social‐engineering e‐mail received by Speaker

Phishing
Real phishing e‐mail received by Speaker

Signs of a Phishing Attack
 Poor grammar
 Lots of typos
 Trying very hard to convince you to open
attachment, click on link, or reply without
enough detail
 May appear to be from known person (rely on
trust & innocence)

Ways to Protect against Phishing
 Don’t be too trusting of people
 Always be suspicious & alert
 An e‐mail with your friend’s name & info doesn’t have
to come from him/her
 Look for signs of phishing attacks
 Don’t open attachments unless you expect them
 Scan for viruses before opening attachments
 Don’t click links in e‐mail. Directly type in browser
using known & trusted URLs
 Especially cautioned if ask for passwords, bank
accounts, credit card numbers, social security numbers,
etc.

Software Security
 Most common reason for security bugs is
invalid programming assumptions that
attackers will look for
 Weak input checking
 Buffer overflow
 Integer overflow
 Race condition (Time of Check / Time of
Use vulnerabilities)
 Running programs in new environments
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

Software Security
 Feeping creaturism (Creeping featurism)
 Log files that contain sensitive
information
 Configuration bugs
 Unnecessary privileges
 Monoculture
 Security bypass

Example of Weak Input Checking:
SQL Injection
 Consider a log‐in form on a web page
 Source code would look
something like this:
statement = ʺSELECT * FROM users
WHERE name = ʹʺ + userName + ʺʹ;ʺ
 Attacker would enter as username:
ʹ or ʹ1ʹ=ʹ1
 Which leads to this always‐true query:
 statement = ʺSELECT * FROM users
WHERE name = ʹʺ + ʺʹ or ʹ1ʹ=ʹ1ʺ + ʺʹ;ʺ
statement = ʺSELECT * FROM users WHERE name = ʹʹ or ʹ1ʹ=ʹ1ʹ;ʺ
http://en.wikipedia.org/wiki/SQL_injection

Secure Software Design Principles
 Economy of Mechanism
 Design should be small & simple
 Fail‐safe default
 Complete mediation
 Check every access to every object
 Open design
 Separation of privilege / Least Privilege
Saltzer & Schroeder (1975), Viega & McGraw (2000)

 Least common mechanism
 Minimize complexity of shared
components
 Psychological acceptability
 If users don’t buy in to security
mechanism or don’t understand how to
use it, system is insecure
 Work factor
 Cost of attack should exceed resources
attacker will spend

 Compromise recording
 If too expensive to prevent a compromise,
record it
 Tamper evident vs. tamperproof
 Log files
Image source: http://www.flickr.com/photos/goobelyga/2340650133/

 Defense in Depth
 Multiple layers of security defense are placed
throughout a system to provide redundancy
in the event a security control fails
 Secure the weakest link
 Promote privacy
 Trust no one
http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

Secure Software Best Practices
 Modular design
 Check error conditions on return values
 Validate inputs (whitelist vs. blacklist)
 Avoid infinite loops, memory leaks
 Check for integer overflows
 Language/library choices
 Development processes

Cryptography
Eve
Alice Bob
 Goal: provide a secure channel between Alice & Bob
 A secure channel
 Leaks no information about its contents
 Delivers only messages from Alice & Bob
 Delivers messages in order or not at all

Cryptography
 Use of keys to convert plaintext into
ciphertext
 Secret keys only Alice & Bob know
 History: Caesar’s cipher, substitution
cipher, polyalphabetic rotation
 Use of keys and some generator function to
create random‐looking strings (e.g. stream
ciphers, block ciphers)

Encryption Using Secret Key
(Symmetric Cryptography)
Alice Eve Bob
1. Encrypt message using secret key
2. Send encrypted message to Bob
3. Decrypt message
using same secret
key
Eve doesn’t know secret key
(but there are various ways to discover the key)

Cryptography
 What if no shared secret exists?
 Public‐key cryptography
 Each publishes public key publicly
 Each keep secret key secret
 Use arithmetic to encrypt & decrypt
message

Public‐Key Cryptography
(Asymmetric Cryptography)
Alice Eve Bob
1. Obtains Bob’s public key from public server
2. Use Bob’s public key to encrypt message
3. Send encrypted message to Bob
4. Decrypt message using
own private key
Even if Eve knows public key, can’t discover
message (unless weakness in algorithm)

Digital Signatures
Alice Bob
1. Sign message using own private key
2. Send plaintext and random‐looking string
(digital signature) to Bob
Provides nonrepudiation
3. Use Alice’s public key
against plaintext received
to get digital signature
4. Compare to match
Alice’s digital signature
received against
signature obtained in #3

Malware
 Malicious software ‐ Any code with intentional,
undesirable side effects
 Virus
 Worm
 Trojan
 Spyware
 Logic Bomb/Time Bomb
 Backdoor/Trapdoor
 Rootkit
 Botnet

Malware
 Virus
 Propagating malware that requires user action
to propagate
 Infects executable files, data files with
executable contents (e.g. Macro), boot sectors
 Worm
 Self‐propagating malware
 Trojan
 A legitimate program with additional, hidden
functionality

Malware
 Spyware
 Trojan that spies for & steals personal
information
 Logic Bomb/Time Bomb
 Malware that triggers under certain conditions
 Backdoor/Trapdoor
 A hole left behind by malware for future access

Malware
 Rogue Antispyware (Ransomware)
 Software that tricks or forces users to pay before fixing
(real or hoax) spyware detected
 Rootkit
 A stealth program designed to hide existence of
certain processes or programs from detection
 Botnet
 A collection of Internet‐connected computers that have
been compromised (bots) which controller of the
botnet can use to do something (e.g. do DDoS attacks)

Defense Against Malware
 Installed & updated antivirus, antispyware, &
personal firewall
 Check for known signatures
 Check for improper file changes (integrity failures)
 Check for generic patterns of malware (for unknown
malware): “Heuristics scan”
 Firewall: Block certain network traffic in and out
 Sandboxing
 Network monitoring & containment
 User education
 Software patches, more secure protocols

Newer Threats
 Social media spams/scams/clickjacking
 Social media privacy issues
 User privacy settings
 Location services
 Mobile device malware & other privacy risks
 Stuxnet (advanced malware targeting certain
countries)
 Advanced persistent threats (APT) by
governments & corporations against specific
targets

Some Information Security Standards
• ISO/IEC 27000—Information security management systems —Overview and
vocabulary
• ISO/IEC 27001—Information security management systems —Requirements
• ISO/IEC 27002—Code of practice for information security management
• ISO/IEC 27003—Information security management system implementation guidance
• ISO/IEC 27004—Information security management —Measurement
• ISO/IEC 27005—Information security risk management
• ISO/IEC 27031—Guidelines for information and communications technology readiness
for business continuity
• ISO/IEC 27032—Guideline for cybersecurity (essentially, ʹbeing a good neighborʹ on
the Internet)
• ISO/IEC 27033‐1 —Network security overview and concepts
• ISO/IEC 27033‐2 —Guidelines for the design and implementation of network security
• ISO/IEC 27033‐3:2010—Reference networking scenarios ‐ Threats, design techniques
and control issues
• ISO/IEC 27034—Guideline for application security
• ISO/IEC 27035—Security incident management
• ISO 27799—Information security management in health using ISO/IEC 27002

More Information
 US‐CERT
 U.S. Computer Emergency Readiness Team
 http://www.us‐cert.gov/
 Subscribe to alerts & news
 Microsoft Security Resources
 http://technet.microsoft.com/en‐us/security
 http://technet.microsoft.com/en‐us/
security/bulletin
 Common Vulnerabilities & Exposures
 http://cve.mitre.org/

Health Information Privacy and Security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Health Information Privacy and Security

Similar to Health Information Privacy and Security (20)

More from Nawanan Theera-Ampornpunt

More from Nawanan Theera-Ampornpunt (20)

Recently uploaded

Recently uploaded (20)

Health Information Privacy and Security