Overview of Information Security & Privacy


Published on

Presented at Ramathibodi Hospital Administration School's 5th Healthcare CIO Certificate Program

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Overview of Information Security & Privacy

  1. 1. Overview of  Information Security  & Privacy Nawanan Theera‐Ampornpunt, M.D., Ph.D. Faculty of Medicine Ramathibodi Hospital Mahidol University August 7, 2014 http://www.SlideShare.net/Nawanan
  2. 2.  Introduction to Information Privacy & Security  Protecting Information Privacy & Security  User Security  Software Security  Cryptography  Malware  Security Standards Outline
  3. 3. Introduction to  Information Privacy &  Security
  4. 4. Malware Threats to Information Security
  5. 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. 6.  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. Consequences of Security Attacks
  7. 7.  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) Privacy & Security
  8. 8. Information Security  Confidentiality  Integrity  Availability
  9. 9. Examples of Confidentiality Risks http://usatoday30.usatoday.com/life/people/2007‐10‐10‐clooney_N.htm
  10. 10. Examples of Integrity Risks http://www.wired.com/threatlevel/2010/03/source‐code‐hacks/ http://en.wikipedia.org/wiki/Operation_Aurora “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
  11. 11. Examples of Integrity Risks http://news.softpedia.com/news/700‐000‐InMotion‐Websites‐Hacked‐by‐TiGER‐M‐TE‐223607.shtml Web Defacements
  12. 12. Examples of Availability Risks http://en.wikipedia.org/wiki/Blaster_worm Viruses/worms that led to instability &  system restart (e.g. Blaster worm)
  13. 13. Examples of Availability Risks http://en.wikipedia.org/wiki/Ariane_5_Flight_501 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
  14. 14. 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
  15. 15. Protecting Information  Privacy & Security
  16. 16. http://www.aclu.org/ordering‐pizza Privacy Protections: Why?
  17. 17.  Attack  An attempt to breach system security  Threat  A scenario that can harm a system  Vulnerability  The “hole” that is used in the attack Common Security Terms
  18. 18.  Identify some possible means an  attacker could use to conduct a  security attack Class Exercise
  19. 19. Alice Simplified Attack Scenarios Server Bob Eve/Mallory
  20. 20. Alice Simplified Attack Scenarios Server Bob ‐ Physical access to client computer ‐ Electronic access (password) ‐ Tricking user into doing something  (malware, phishing & social  engineering) Eve/Mallory
  21. 21. Alice Simplified Attack Scenarios Server Bob ‐ Intercepting (eavesdropping or  “sniffing”) data in transit ‐ Modifying data (“Man‐in‐the‐ middle” attacks) ‐ “Replay” attacks Eve/Mallory
  22. 22. Alice Simplified Attack Scenarios 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
  23. 23. Alice Simplified Attack Scenarios Server Bob Other & newer forms of  attacks possible Eve/Mallory
  24. 24. Alice Safeguarding Against Attacks 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
  25. 25. Alice Safeguarding Against Attacks 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
  26. 26. Alice Safeguarding Against Attacks 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
  27. 27. Alice Safeguarding Against Attacks 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
  28. 28. Alice Safeguarding Against Attacks 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
  29. 29. Alice Safeguarding Against Attacks 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
  30. 30. Alice Safeguarding Against Attacks 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)
  31. 31. Privacy Safeguards Image: http://www.nurseweek.com/news/images/privacy.jpg  Security safeguards  Informed consent  Privacy culture  User awareness building & education  Organizational policy & regulations  Enforcement  Ongoing privacy & security assessments, monitoring,  and protection
  32. 32. User Security
  33. 33.  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
  34. 34.  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
  35. 35.  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
  36. 36.  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 User Security
  37. 37. 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)
  38. 38. 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.
  39. 39. 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.
  40. 40. 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.
  41. 41. 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 : Social Engineering Examples Real social‐engineering e‐mail received by Speaker
  42. 42. Phishing Real phishing e‐mail received by Speaker
  43. 43.  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) Signs of a Phishing Attack
  44. 44.  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. Ways to Protect against Phishing
  45. 45. Software Security
  46. 46.  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 Software Security Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  47. 47.  Feeping creaturism (Creeping featurism)  Log files that contain sensitive  information  Configuration bugs  Unnecessary privileges  Monoculture  Security bypass Software Security Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  48. 48.  Consider a log‐in form on a web page Example of Weak Input Checking:  SQL Injection  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
  49. 49.  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 Secure Software Design Principles Saltzer & Schroeder (1975), Viega & McGraw (2000) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  50. 50.  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 Secure Software Design Principles Saltzer & Schroeder (1975), Viega & McGraw (2000) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  51. 51.  Compromise recording  If too expensive to prevent a compromise,  record it  Tamper evident vs. tamperproof  Log files Secure Software Design Principles Saltzer & Schroeder (1975), Viega & McGraw (2000) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271  Image source: http://www.flickr.com/photos/goobelyga/2340650133/
  52. 52.  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 Secure Software Design Principles 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)
  53. 53.  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 Secure Software Best Practices Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  54. 54. Cryptography
  55. 55.  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 Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271  Alice Bob Eve
  56. 56.  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) Cryptography Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  57. 57. Encryption Using Secret Key  (Symmetric Cryptography) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271  Alice BobEve 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)
  58. 58.  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 Cryptography Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  59. 59. Public‐Key Cryptography  (Asymmetric Cryptography) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271  Alice BobEve 1. Obtains Bob’s public key from public server 2. Use Bob’s public key to encrypt message 3. Send encrypted message to Bob Even if Eve knows public key, can’t discover  message (unless weakness in algorithm) 4. Decrypt message using  own private key
  60. 60. Digital Signatures Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271  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
  61. 61. Malware
  62. 62.  Malicious software ‐ Any code with intentional,  undesirable side effects  Virus  Worm  Trojan  Spyware  Logic Bomb/Time Bomb  Backdoor/Trapdoor  Rootkit  Botnet Malware
  63. 63.  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
  64. 64.  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
  65. 65.  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) Malware
  66. 66.  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 Defense Against Malware
  67. 67.  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 Newer Threats
  68. 68. Security Standards
  69. 69. • 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 Some Information Security Standards
  70. 70.  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/ More Information
  71. 71. Q & A