1. Health Information
Privacy & Security
Nawanan Theera‐Ampornpunt, M.D., Ph.D.
Faculty of Medicine Ramathibodi Hospital
Mahidol University
For the Faculty of Pharmacy, Silpakorn University
February 4, 2014
http://www.SlideShare.net/Nawanan

2. Outline








Introduction to Information Privacy & Security
Protecting Information Privacy & Security
User Security
Software Security
Cryptography
Malware
Security Standards
Privacy & Security Laws

3. Introduction to
Information Privacy &
Security

4. Threats to Information Security
Malware

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

6. Consequences of Security Attacks

Information risks



Operational 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



System not functional (Denial of Service ‐ DoS)
System wrongly operated
Personal risks


Unauthorized access & disclosure of confidential information
Unauthorized addition, deletion, or modification of information
Financial losses
Damage to reputation & trust
Etc.

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

8. Information Security



Confidentiality
Integrity
Availability

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

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

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

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

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

14. Interesting Resources






http://en.wikipedia.org/wiki/List_of_software_bugs
http://en.wikipedia.org/wiki/Notable_computer_viruses_
and_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

15. Protecting Information
Privacy & Security

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

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

18. Simplified Attack Scenarios
Alice
Server
Bob
Eve/Mallory

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

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

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

22. Simplified Attack Scenarios
Alice
Server
Bob
Other & newer forms of
attacks possible
Eve/Mallory

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

24. Safeguarding Against Attacks
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

25. Safeguarding Against Attacks
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

26. Safeguarding Against Attacks
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

27. Safeguarding Against Attacks
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

28. Safeguarding Against Attacks
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

29. Safeguarding Against Attacks
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)

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

31. User Security

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

33. 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”

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

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

36. 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)

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

38. Recommended Password Policy

Expiration (to make brute‐force attacks not possible)





Decreasing over time because of increasing computer’s
speed


6‐8 months
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.

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

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

41. Phishing
Real phishing e‐mail received by Speaker

42. 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)

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

44. Software Security

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

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

47. Some Security Principles

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
Saltzer & Schroeder (1975), Viega & McGraw (2000)
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271
http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

48. 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
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

49. Cryptography

50. 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
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

51. 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)
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

52. Encryption Using Secret Key
(Symmetric Cryptography)
Alice
Bob
Eve
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)
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

53. 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
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

54. Public‐Key Cryptography
(Asymmetric Cryptography)
Eve
Alice
1. Obtains Bob’s public key from public server
2. Use Bob’s public key to encrypt message
Bob
4. Decrypt message using
own private key
3. Send encrypted message to Bob
Even if Eve knows public key, can’t discover
message (unless weakness in algorithm)
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

55. Digital Signatures
Bob
Alice
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
Adapted from Nicholas Hopper’s teaching slides for UMN Computer Security Class Fall 2006 CSCI 5271

56. Malware

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

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

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

60. Malware

Rogue Antispyware (Ransomware)


Rootkit


Software that tricks or forces users to pay before fixing
(real or hoax) spyware detected
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)

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

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

63. Security Standards

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

65. 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/

66. Privacy & Security
Laws

67. 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)

68. Privacy Protections: Why?
http://www.aclu.org/ordering‐pizza

69. Ethical Principles in Bioethics
Respect for Persons (Autonomy)
 Beneficence
 Justice
 Non‐maleficence


70. Hippocratic Oath
...
What I may see or hear in the course of
treatment or even outside of the
treatment in regard to the life of men,
which on no account one must spread
abroad, I will keep myself holding such
things shameful to be spoken about.
...
http://en.wikipedia.org/wiki/Hippocratic_Oath

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

72. HIPAA

73. U.S. Health Information Privacy Law



Health Insurance Portability and Accountability Act of
1996
http://www.gpo.gov/fdsys/pkg/PLAW‐
104publ191/pdf/PLAW‐104publ191.pdf
More stringent state privacy laws apply
HIPAA Goals
 To protect health insurance coverage for workers &
families when they change or lose jobs (Title I)
 To require establishment of national standards for
electronic health care transactions and national
identifiers for providers, health insurance plans, and
employers (Title II: “Administrative Simplification”
provisions)
 Administrative Simplification provisions also address
security & privacy of health data
http://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act

74. HIPAA (U.S.)


Title I: Health Care Access, Portability, and
Renewability
Title II: Preventing Health Care Fraud and
Abuse; Administrative Simplification;
Medical Liability Reform

Requires Department of Health & Human
Services (HHS) to draft rules aimed at increasing
efficiency of health care system by creating
standards for use and dissemination of health
care information

75. HIPAA (U.S.)
Title III: Tax‐Related Health Provisions
 Title IV: Application and Enforcement
of Group Health Plan Requirements
 Title V: Revenue Offsets


76. HIPAA (U.S.)

HHS promulgated 5 Administrative
Simplification rules





Privacy Rule
Transactions and Code Sets Rule
Security Rule
Unique Identifiers Rule
Enforcement Rule

77. Some HIPAA Definitions

Covered Entities




A health plan
A health care clearinghouse
A healthcare provider who transmits any health
information in electronic form in connection with a
transaction to enable health information to be exchanged
electronically
Business Associates

78. Some HIPAA Definitions

Protected Health Information (PHI)


Individually identifiable health information transmitted or
maintained in electronic media or other form or medium
Individually Identifiable Health Information

Any information, including demographic information collected from
an individual, that—

(A) is created or received by a CE; and

(B) relates to the past, present, or future physical

or mental health or condition of an individual, the provision of
health care to an individual, or the past, present, or future payment
for the provision of health care to an individual, and—

(i) identifies the individual; or

(ii) with respect to which there is a reasonable basis to believe that
the information can be used to identify the individual.

79. Protected Health Information –
Personal Identifiers in PHI










Name
Address
Phone number
Fax number
E‐mail address
SSN
Birthdate
Medical Record No.
Health Plan ID
Treatment date









Account No.
Certificate/License No.
Device ID No.
Vehicle ID No.
Drivers license No.
URL
IP Address
Biometric identifier
including fingerprints
Full face photo

80. HIPAA Privacy Rule

Establishes national standards to protect PHI; applies to CE &
business associates

Requires appropriate safeguards to protect privacy of PHI

Sets limits & conditions on uses & disclosures that may be made
without patient authorization

Gives patients rights over their health information, including
rights to examine & obtain copy of health records & to request
corrections
http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html

81. HIPAA Privacy Rule

Timeline





November 3, 1999
December 28, 2000
August 14, 2002
April 14, 2003
Proposed Privacy Rule
Final Privacy Rule
Modifications to Privacy Rule
Compliance Date for most CE
Full text (as amended)
http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/
adminsimpregtext.pdf
http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html

82. HIPAA Privacy Rule


Some permitted uses and disclosures
Use of PHI


Sharing, application, use, examination or
analysis within the entity that maintains the
PHI
Disclosure of PHI

Release or divulgence of information by an
entity to persons or organizations outside of
that entity.

83. HIPAA Privacy Rule

A covered entity may not use or disclose
PHI, except
 with individual consent for treatment,
payment or healthcare operations (TPO)
 with individual authorization for other
purposes
 without consent or authorization for
governmental and other specified
purposes

84. HIPAA Privacy Rule

Treatment, payment, health care operations
(TPO)






Quality improvement
Competency assurance
Medical reviews & audits
Insurance functions
Business planning & administration
General administrative activities

85. HIPAA Privacy Rule

Uses & disclosures without the need for patient
authorization permitted in some circumstances
 Required by law
 For public health activities
 About victims of abuse, neglect, or domestic
violence
 For health oversight activities
 For judicial & administrative proceedings
 For law enforcement purposes
 About decedents

86. HIPAA Privacy Rule

Uses & disclosures without the need for patient
authorization permitted in some circumstances
 For cadaveric organ, eye, or tissue donation purposes
 For research purposes
 To avert a serious threat to health or safety
 For workers’ compensation
 For specialized government functions






Military & veterans activities
National security & intelligence activities
Protective services for President & others
Medical suitability determinants
Correctional institutions
CE that are government programs providing public benefits

87. Responsibilities of a CE


Control use and disclosure of PHI
Notify patients of information practices (NPP, Notice of Privacy
Practices)






Provide means for patients to access their own record
Obtain authorization for non‐TPO uses and disclosures
Log disclosures
Restrict use or disclosures





Specifies how CE can use and share PHI
Specifies patient’s rights regarding their PHI
Minimum necessary
Privacy policy and practices
Business Associate agreements
Other applicable statutes
Provide management oversight and response to minimize threats and
breaches of privacy
From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz

88. HIPAA & Research






Individually identifiable health information
collected and used solely for research IS NOT PHI
Researchers obtaining PHI from a CE must obtain
the subject’s authorization or must justify an
exception:
Waiver of authorization (obtain from the IRB)
Limited Data Set (with data use agreement)
De‐identified Data Set
HIPAA Privacy supplements the Common Rule
and the FDA’s existing protection for human
subjects
From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz

89. Research Data Sets

De‐identified Data Set



Remove all 18 personal identifiers of subjects,
relatives, employers, or household members
OR biostatistician confirms that individual cannot be
identified with the available information
Limited Data Set



May include Zip, Birthdate, Date of death, date of
service, geographic subdivision
Remove all other personal identifiers of subject, etc.
Data Use Agreement signed by data recipient that
there will be no attempt to re‐identify the subject
From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz

90. IRB’s New Responsibility





Assure the CE that all research‐initiated HIPAA
requirements have been met
Provide letter of approval to the researcher to
conduct research using PHI
OR, Certify and document that waiver of
authorization criteria have been met
Review and approve all authorizations and data
use agreements
Retain records documenting HIPAA actions for 6
years
From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz

91. HIPAA Security Rule


Establishes national standards to protect
individuals’ electronic PHI that is created,
received, used, or maintained by a CE.
Requires appropriate safeguards to ensure
confidentiality, integrity & security of
electronic PHI



Administrative safeguards
Physical safeguards
Technical safeguards
http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html

92. HIPAA Security Rule

Timeline




August 12, 1998
February 20, 2003
April 21, 2005
Proposed Security Rule
Final Security Rule
Compliance Date for most CE
Full Text
http://www.hhs.gov/ocr/privacy/hipaa/
administrative/securityrule/securityrulepdf.pdf
http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/index.html

93. HIPAA Security Rule: Meaning

The HIPAA Security Rule is:




A set of information security “best practices”
A minimum baseline for security
An outline of what to do, and what procedures
should be in place
The HIPAA Security Rule is not:



A set of specific instructions
A set of rules for universal, unconditional
implementation
A document outlining specific implementations
(vendors, equipment, software, etc.)
From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz

94. HIPAA Security Rule: Meaning


Many rules are either Required or Addressable
Required:


Compliance is mandatory
Addressable:


If a specification in the Rule is reasonable and
appropriate for the CE, then the CE must implement
Otherwise, documentation must be made of the
reasons the policy cannot/will not be implemented,
and when necessary, offer an alternative
From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz

95. New in HITECH Act of 2009



Breach notification
Extension of complete Privacy & Security
HIPAA provisions to business associates of
covered entities
New rules for accounting of disclosures of a
patient’s health information

96. Health Information Privacy Law:
U.S. Challenges




Conflicts between federal vs. state laws
Variations among state laws of different
states
HIPAA only covers “covered entities”
No general privacy laws in place, only a few
sectoral privacy laws e.g. HIPAA

97. Health Information Privacy Law:
Other Western Countries






Canada ‐ The Privacy Act (1983), Personal
Information Protection and Electronic Data
Act of 2000
EU Countries ‐ EU Data Protection Directive
UK ‐ Data Protection Act 1998
Austria ‐ Data Protection Act 2000
Australia ‐ Privacy Act of 1988
Germany ‐ Federal Data Protection Act of
2001

98. Thailand’s Health
Information Privacy
Law

99. Thai Privacy Laws
The Sanatorium Acts, B.E. 2541 &
2547
 พรบ.สถานพยาบาล พ.ศ. 2541 และ พรบ.สถานพยาบาล
(ฉบับที่ 2) พ.ศ. 2547
 ประกาศกระทรวงสาธารณสุข ฉบับที่ 3 (พ.ศ. 2542) เรือง
่
ชนิดหรือประเภทของการรักษาพยาบาล การบริการอื่นของ
สถานพยาบาลและสิทธิของผูปวยซึงผูรบอนุญาตจะต้องแสดง
้ ่ ่ ้ั
ตามมาตรา 32 (3)


100. Thai Privacy Laws
คําประกาศสิทธิของผูป่วย
้
“...
7. ผูปวยมีสทธิทจะได้รบการปกปิดข้อมูลเกียวกับตนเอง จากผู้
้ ่
ิ ่ี
ั
่
ประกอบวิชาชีพโดยเคร่งครัด เว้นแต่จะได้รบความยินยอมจากผูปวย
ั
้ ่
หรือการปฏิบตหน้าทีตามกฎหมาย
ั ิ
่
...
ั
่
9. ผูปวยมีสทธิทจะได้รบทราบข้อมูลเกียวกับรักษาพยาบาลเฉพาะ
้ ่
ิ ่ี
ของตนทีปรากฏในเวชระเบียนเมือร้องขอ ทังนี้ ข้อมูลดังกล่าวต้องไม่
่
่
้
เป็ นการละเมิดสิทธิสวนตัวของบุคคลอืน
่
่
...”

101. Thai Privacy Laws
The Official Information Act, B.E. 2540
 พรบ.ข้อมูลข่าวสารของราชการ พ.ศ. 2540
 “เปิ ดเผยเป็ นหลัก ปกปิ ดเป็ นข้อยกเว้น”
“มาตรา 15 ข้อมูลข่าวสารของราชการทีมลกษณะอย่างหนึ่งอย่างใดดังต่อไปนี้
่ ีั
หน่วยงานของรัฐหรือเจ้าหน้าทีของรัฐอาจมีคาสังมิให้เปิดเผยก็ได้ โดยคํานึงถึง
่
ํ ่
การปฏิบตหน้าทีตามกฎหมาย...ประกอบกัน
ั ิ
่
...
(5) รายงานการแพทย์หรือข้อมูลข่าวสารส่วนบุคคลซึงการเปิดเผยจะเป็ นการรุก
่
ลํ้าสิทธิสวนบุคคลโดยไม่สมควร
่
(6) ข้อมูลข่าวสารของราชการทีมกฎหมายคุมครองมิให้เปิดเผย...
่ ี
้
...”


102. Thai Privacy Laws

No universal personal data privacy law
(Draft law has been proposed)

National Health Act, B.E. 2550
พรบ.สุขภาพแห่งชาติ พ.ศ. 2550
“มาตรา 7 ข้อมูลด้านสุขภาพของบุคคล เป็ นความลับส่วนบุคคล
ผูใดจะนําไปเปิดเผยในประการทีน่าจะทําให้บุคคลนันเสียหายไม่ได้
้
่
้
เว้นแต่การเปิดเผยนันเป็ นไปตามความประสงค์ของบุคคลนัน
้
้
โดยตรง หรือมีกฎหมายเฉพาะบัญญัตให้ตองเปิดเผย แต่ไม่วาใน
ิ ้
่
กรณีใด ๆ ผูใดจะอาศัยอํานาจหรือสิทธิตามกฎหมายว่าด้วยข้อมูล
้
ข่าวสารของราชการหรือกฎหมายอืนเพือขอเอกสารเกียวกับข้อมูล
่ ่
่
ด้านสุขภาพของบุคคลทีไม่ใช่ของตนไม่ได้”
่



103. Thai ICT Laws


Computer‐Related Crimes Act, B.E. 2550
พรบ.การกระทําความผิดเกียวกับคอมพิวเตอร์ พ.ศ. 2550
่
 กําหนดการกระทําที่ถือเป็นความผิด และหน้าที่ของผู้
ให้บริการ


Focuses on prosecuting computer
crimes & computer‐related crimes
Responsibility of organizations as IT
service provider: Logging &
provision of access data to authorities

104. Thai ICT Laws


Electronic Transactions Acts, B.E. 2544 & 2551
พรบ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 และ พรบ.ว่าด้วยธุรกรรมทาง
อิเล็กทรอนิกส์ (ฉบับที่ 2) พ.ศ. 2551




รองรับสถานะทางกฎหมายของข้อมูลทางอิเล็กทรอนิกส์
รับรองวิธการส่งและรับข้อมูลอิเล็กทรอนิกส์ การใช้ลายมือชืออิเล็กทรอนิกส์ (electronic
ี
่
ั
signature) และการรับฟงพยานหลักฐานทีเป็ นข้อมูลอิเล็กทรอนิกส์ เพือส่งเสริมการทํา e‐
่
่
transactions ให้น่าเชือถือ
่
กําหนดให้มคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ และอํานาจหน้าที่
ี
Security & privacy requirements for
 Determining legal validity & integrity of electronic
transactions and documents, print‐outs, & paper‐to‐
electronic conversions
 Governmental & public organizations
 Critical infrastructures
 Financial sectors
 Electronic certificate authorities

105. ผลทางกฎหมายของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์




ห้ามมิให้ปฏิเสธความมีผลผูกพันและการบังคับใช้ทางกฎหมายของ
ข้อความใด เพียงเพราะเหตุทขอความนันอยูในรูปของข้อมูล
่ี ้
้ ่
อิเล็กทรอนิกส์ (มาตรา 7)
ให้ถอว่าข้อมูลอิเล็กทรอนิกส์ มีการลงลายมือชือแล้ว ถ้า (1) ใช้วธการที่
ื
่
ิี
ระบุตวเจ้าของลายมือชือ และ (2) เป็ นวิธการทีเชือถือได้ (มาตรา 9)
ั
่
ี
่ ่
ธุรกรรมทางอิเล็กทรอนิกส์ทได้กระทําตามวิธการแบบปลอดภัยทีกาหนด
่ี
ี
่ ํ
ใน พรฎ. ให้สนนิษฐานว่าเป็ นวิธการทีเชือถือได้ (มาตรา 25)
ั
ี
่ ่
คําขอ การอนุญาต การจดทะเบียน คําสังทางปกครอง การชําระเงิน การ
่
ประกาศ หรือการดําเนินการใดๆ ตามกฎหมายกับหน่วยงานของรัฐหรือ
โดยหน่วยงานของรัฐ ถ้าได้กระทําในรูปของข้อมูลอิเล็กทรอนิกส์ตาม
หลักเกณฑ์และวิธการทีกาหนดโดย พรฎ. ให้ถอว่ามีผลโดยชอบด้วย
ี
่ ํ
ื
กฎหมาย (มาตรา 35)

106. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์


พรฎ.กําหนดประเภทธุรกรรมในทางแพ่งและพาณิชย์ทยกเว้นมิหนํากฎหมายว่าด้วย
่ี
ธุรกรรมทางอิเล็กทรอนิกส์มาใช้บงคับ พ.ศ. 2549
ั
ประกาศคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์



เรือง การรับรองสิงพิมพ์ออก พ.ศ. 2555
่
่
 กําหนดหลักเกณฑ์และวิธการรับรองสิงพิมพ์ออก (Print‐Out) ของข้อมูล
ี
่
อิเล็กทรอนิกส์ เพือให้สามารถใช้อางอิงแทนข้อมูลอิเล็กทรอนิกส์ และมีผลใช้แทนต้นฉบับ
่
้
ได้
เรือง หลักเกณฑ์และวิธการในการจัดทําหรือแปลงเอกสารและข้อความให้อยูในรูปของ
่
ี
่
ข้อมูลอิเล็กทรอนิกส์ พ.ศ. 2553
 กําหนดหลักเกณฑ์และวิธการในการจัดทําหรือแปลงเอกสารและข้อความทีได้มการจัดทํา
ี
่ ี
หรือแปลงให้อยูในรูปของข้อมูลอิเล็กทรอนิกส์ในภายหลัง
่
เรือง แนวทางการจัดทําแนวนโยบาย (Certificate Policy) และแนวปฏิบติ
่
ั
(Certification Practice Statement) ของผูให้บริการออกใบรับรอง
้
อิเล็กทรอนิกส์ (Certificate Authority) พ.ศ. 2552
 ว่าด้วยการให้บริการออกใบรับรองอิเล็กทรอนิกส์ (Certificate)

107. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์

พรฎ.กําหนดหลักเกณฑ์และวิธการในการทําธุรกรรมทาง
ี
อิเล็กทรอนิกส์ภาครัฐ พ.ศ. 2549

ประกาศ เรือง แนวนโยบายและแนวปฏิบตในการรักษาความมันคง
่
ั ิ
่
ปลอดภัยด้านสารสนเทศของหน่วยงานของรัฐ พ.ศ. 2553


กําหนดมาตรฐาน Security Policy ของหน่วยงานของรัฐทีม ี
่
การทําธุรกรรมทางอิเล็กทรอนิกส์ภาครัฐ
ประกาศ เรือง แนวนโยบายและแนวปฏิบตในการคุมครองข้อมูลส่วน
่
ั ิ
้
บุคคลของหน่วยงานของรัฐ พ.ศ. 2553

กําหนดมาตรฐาน Privacy Policy ของหน่วยงานของรัฐทีมการ
่ ี
ทําธุรกรรมทางอิเล็กทรอนิกส์ภาครัฐ

108. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์




พรฎ.ว่าด้วยการควบคุมดูแลธุรกิจบริการการชําระเงินทาง
อิเล็กทรอนิกส์ พ.ศ. 2551
ประกาศ เรือง หลักเกณฑ์การพิจารณาลงโทษปรับทางปกครอง
่
สําหรับผูประกอบธุรกิจให้บริการการชําระเงินทางอิเล็กทรอนิกส์
้
พ.ศ. 2554
ประกาศ เรือง หลักเกณฑ์ วิธการ และเงือนไขในการประกอบธุรกิจ
่
ี
่
บริการการชําระเงินทางอิเล็กทรอนิกส์ พ.ศ. 2552
ประกาศ ธปท. ทีเกียวข้อง
่ ่

109. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์

พรฎ.ว่าด้วยวิธการแบบปลอดภัยในการทําธุรกรรมทาง
ี
อิเล็กทรอนิกส์ พ.ศ. 2553

ประกาศ เรือง ประเภทของธุรกรรมทางอิเล็กทรอนิกส์ และหลักเกณฑ์
่
การประเมินระดับผลกระทบของธุรกรรมทางอิเล็กทรอนิกส์ตามวิธการ
ี
แบบปลอดภัย พ.ศ. 2555


หลักเกณฑ์การประเมินเพือกําหนดระดับวิธการแบบปลอดภัยขันตํ่า
่
ี
้
ประกาศ เรือง มาตรฐานการรักษาความมันคงปลอดภัยของระบบ
่
่
สารสนเทศตามวิธการแบบปลอดภัย พ.ศ. 2555
ี

กําหนดมาตรฐานความปลอดภัยตามวิธการแบบปลอดภัยแต่ละระดับ
ี

110. สรุปความเชื่อมโยงของกฎหมาย พรบ.ธุรกรรมทางอิเล็กทรอนิกส์
•
•
พรบ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์
พรฎ.ว่าด้วยวิธการแบบปลอดภัยในการทํา
ี
ธุรกรรมทางอิเล็กทรอนิกส์ (+ ประกาศ
2 ฉบับ)
ประกาศ เรื่อง หลักเกณฑ์และวิธีการในการ
จัดทําหรือแปลงเอกสารและข้อความให้อยู่
ในรูปของข้อมูลอิเล็กทรอนิกส์
•
•
•
พรฎ.กําหนดหลักเกณฑ์และวิธีการในการทําธุรกรรม
ทางอิเล็กทรอนิกส์ภาครัฐ
ประกาศ เรื่อง แนวนโยบายและแนวปฏิบัติในการ
รักษาความมันคงปลอดภัยด้านสารสนเทศของ
่
หน่วยงานของรัฐ
หน่วยงานของรัฐ
ประกาศ เรื่อง แนวนโยบายและแนวปฏิบัติในการ
คุ้มครองข้อมูลส่วนบุคคลของหน่วยงานของรัฐ

111. หน่วยงานที่เกี่ยวข้องกับ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์



คณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์
สํานักงานคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ สํานักงาน
ปลัดกระทรวง กระทรวงเทคโนโลยีสารสนเทศและการสือสาร
่
สํานักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (องค์การมหาชน) หรือ
สพธอ. (Electronic Transactions Development
Agency (Public Organization) ‐ ETDA)

112. “วิธีการแบบปลอดภัย”

มาตรา 25 ของ พรบ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์


“ธุรกรรมทางอิเล็กทรอนิกส์ใดทีได้กระทําตามวิธการแบบปลอดภัยที่
่
ี
กําหนดในพระราชกฤษฎีกา ให้สนนิษฐานว่าเป็ นวิธการทีเชือถือได้
ั
ี
่ ่
พรฎ.ว่าด้วยวิธการแบบปลอดภัยในการทําธุรกรรมทางอิเล็กทรอนิกส์
ี
พ.ศ. 2553


วิธการแบบปลอดภัย มี 3 ระดับ (พืนฐาน, กลาง, เคร่งครัด)
ี
้
จําแนกตามประเภทของธุรกรรมทางอิเล็กทรอนิกส์ (ธุรกรรมทีมผลกระทบ
่ ี
ต่อความมันคงหรือความสงบเรียบร้อยของประเทศ หรือต่อสาธารณชน)
่
หรือจําแนกตามหน่วยงาน (ธุรกรรมของหน่วยงานหรือองค์กรทีถอเป็ น
่ ื
โครงสร้างพืนฐานสําคัญของประเทศ หรือ Critical
้
Infrastructure)

113. วิธีการแบบปลอดภัยในระดับเคร่งครัด

ธุรกรรมทางอิเล็กทรอนิกส์ ประเภทต่อไปนี้






ด้านการชําระเงินทางอิเล็กทรอนิกส์
ด้านการเงินของธนาคารพาณิชย์
ด้านประกันภัย
ด้านหลักทรัพย์ของผูประกอบธุรกิจหลักทรัพย์
้
ธุรกรรมทีจดเก็บ รวบรวม และให้บริการข้อมูลของบุคคลหรือ
่ั
ทรัพย์สนหรือทะเบียนต่างๆ ทีเป็ นเอกสารมหาชนหรือทีเป็ นข้อมูล
ิ
่
่
สาธารณะ
ธุรกรรมในการให้บริการด้านสาธารณูปโภคและบริการสาธารณะทีตอง
่ ้
ดําเนินการอย่างต่อเนื่องตลอดเวลา

114. ระดับผลกระทบกับวิธีการแบบปลอดภัย

ให้หน่วยงานยึดถือหลักการประเมินความเสียงของระบบเทคโนโลยี
่
สารสนเทศซึงเป็ นทียอมรับเป็ นการทัวไป เป็ นแนวทางในการ
่
่
่
ประเมินระดับผลกระทบ ซึงต้องประเมินผลกระทบในด้านต่อไปนี้
่
ด้วย (ผลกระทบจาก Worst Case Scenario ใน 1 วัน)

ผลกระทบด้านมูลค่าความเสียหายทางการเงิน



ตํ่า: ≤ 1 ล้านบาท
ปานกลาง: 1 ล้านบาท < มูลค่า ≤ 100 ล้านบาท
สูง: > 100 ล้านบาท

115. ระดับผลกระทบกับวิธีการแบบปลอดภัย

ให้หน่วยงานยึดถือหลักการประเมินความเสียงของระบบเทคโนโลยี
่
สารสนเทศซึงเป็ นทียอมรับเป็ นการทัวไป เป็ นแนวทางในการ
่
่
่
ประเมินระดับผลกระทบ ซึงต้องประเมินผลกระทบในด้านต่อไปนี้
่
ด้วย (ผลกระทบจาก Worst Case Scenario ใน 1 วัน)

ผลกระทบต่อจํานวนผูใช้บริการหรือผูมสวนได้เสียทีอาจได้รบอันตราย
้
้ ี่
่
ั
ต่อชีวต ร่างกาย หรืออนามัย
ิ



ตํ่า: ไม่ม ี
ปานกลาง: ผลกระทบต่อร่างกายหรืออนามัย 1-1,000 คน
สูง: ผลกระทบต่อร่างกายหรืออนามัย > 1,000 คน หรือต่อชีวตตังแต่ 1
ิ ้
คน

116. ระดับผลกระทบกับวิธีการแบบปลอดภัย

ให้หน่วยงานยึดถือหลักการประเมินความเสียงของระบบเทคโนโลยี
่
สารสนเทศซึงเป็ นทียอมรับเป็ นการทัวไป เป็ นแนวทางในการประเมิน
่
่
่
ระดับผลกระทบ ซึงต้องประเมินผลกระทบในด้านต่อไปนี้ดวย (ผลกระทบ
่
้
จาก Worst Case Scenario ใน 1 วัน)
 ผลกระทบต่อจํานวนผูใช้บริการหรือผูมีสวนได้เสียทีอาจได้รับความ
้
้ ่
่
เสียหายอืนใด
่




ตํ่า: ≤ 10,000 คน
ปานกลาง: 10,000 < จํานวนผูได้รบผลกระทบ ≤ 100,000 คน
้ ั
สูง: > 100,000 คน
ผลกระทบด้านความมันคงของรัฐ
่


ตํ่า: ไม่มผลกระทบต่อความมันคงของรัฐ
ี
่
สูง: มีผลกระทบต่อความมันคงของรัฐ
่

117. สรุปวิธีการประเมินระดับวิธีการแบบปลอดภัย


พิจารณาตามประเภทของธุรกรรมทางอิเล็กทรอนิกส์
พิจารณาตามระดับผลกระทบ



ถ้ามีผลประเมินทีเป็ นผลกระทบในระดับสูง 1 ด้าน ให้ใช้วธการแบบ
่
ิี
ปลอดภัยระดับเคร่งครัด
ระดับกลางอย่างน้อย 2 ด้าน ให้ใช้วธการแบบปลอดภัยระดับกลาง
ิี
นอกจากนี้ ให้ใช้วธการแบบปลอดภัยในระดับพืนฐาน
ิี
้

118. ประกาศ เรื่อง มาตรฐาน Security ตามวิธีการแบบปลอดภัย




อ้างอิงมาตรฐาน ISO/IEC 27001:2005 ‐ Information
technology ‐ Security techniques ‐ Information
security management systems ‐ Requirements
มีผลใช้บงคับเมือพ้น 360 วัน นับแต่วนประกาศในราชกิจจานุเบกษา (19 ธ.ค.
ั
่
ั
2555) คือ 14 ธ.ค. 2556
ไม่มบทกําหนดโทษ เป็ นเพียงมาตรฐานสําหรับ “วิธการทีเชือถือได้” ในการ
ี
ี
่ ่
พิจารณาความน่าเชือถือในทางกฎหมายของธุรกรรมทางอิเล็กทรอนิกส์ แต่มผล
่
ี
ในเชิงภาพลักษณ์และนํ้าหนักการนําข้อมูลอิเล็กทรอนิกส์ไปเป็ นพยานหลักฐานใน
การต่อสูคดีในศาลหรือการดําเนินการทางกฎหมาย
้
คณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์อาจพิจารณาประกาศเผยแพร่รายชือ
่
หน่วยงานทีมการจัดทํานโยบายและแนวปฏิบตโดยสอดคล้องกับวิธการแบบ
่ ี
ั ิ
ี
ปลอดภัย เพือให้สาธารณชนทราบเป็ นการทัวไปก็ได้
่
่

119. มาตรฐาน Security ตามวิธีการแบบปลอดภัย












แบ่งเป็ น 11 หมวด (Domains)
Security policy
Organization of information security
Asset management
Human resources security
Physical and environmental security
Communications and operations management
Access control
Information systems acquisition, development and
maintenance
Information security incident management
Business continuity management
Regulatory compliance

120. มาตรฐาน Security ตามวิธีการแบบปลอดภัย แต่ละระดับ
หมวด (Domain)
ระดับพืนฐาน
้
ระดับกลาง
(เพิ่มเติมจากระดับพืนฐาน)
้
ระดับสูง
(เพิ่มเติมจากระดับกลาง)
Security policy
1 ข้อ
1 ข้อ
-
Organization of information security
5 ข้อ
3 ข้อ
3 ข้อ
Asset management
1 ข้อ
4 ข้อ
-
Human resources security
6 ข้อ
1 ข้อ
2 ข้อ
Physical and environmental security
5 ข้อ
2 ข้อ
6 ข้อ
Communications & operations management
18 ข้อ
5 ข้อ
9 ข้อ
Access control
9 ข้อ
8 ข้อ
8 ข้อ
Information systems acquisition,
development and maintenance
2 ข้อ
6 ข้อ
8 ข้อ
Information security incident management
1 ข้อ
-
3 ข้อ
Business continuity management
1 ข้อ
3 ข้อ
1 ข้อ
Regulatory compliance
3 ข้อ
5 ข้อ
2 ข้อ
รวม
52 ข้อ
38 ข้อ (รวม 90 ข้อ)
42 ข้อ (รวม 132 ข้อ)

121. Health Information Privacy Law:
Thailand’s Challenges



Official Information Act only covers
governmental organizations
“Disclose as a rule, protect as an exception”
not appropriate mindset for health
information
National Health Act: One blanket provision
with minimal exceptions: raising concerns
about enforceability (in exceptional
circumstances, e.g. disasters)

122. Health Information Privacy Law:
Thailand’s Challenges




No general data privacy law in place
ICT laws (e.g. Electronic Transactions Act)
focus on security & privacy in general (no
specific health‐related provisions)
Governance: No governmental authority
responsible for oversight, enforcement &
regulation of health information privacy
protections
Policy: No systematic national policy to
promote privacy protections

123. Health Information Privacy Law:
Summary



Each country has its unique context,
including legal systems, national priorities,
public mindset, and infrastructure
A comprehensive & systematic approach to
data privacy and health information privacy
is still lacking in some countries such as
Thailand
Key issues include enforceable regulations,
governance, and national policy

124. Q & A