Information Security, some illustrated principles

2,122 views
1,622 views

Published on

Some principles of information security are mentioned and illustrated with some recent events in the Belgian Blogosphere and Facebook.

Published in: Education
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total views
2,122
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Information Security, some illustrated principles

  1. Information security some illustrated principles
  2. Waarom security?
  3. Geheimen “aan niemand doorvertellen he!”
  4. Controle “_Wie_ weet dat allemaal?”
  5. Information wants to be free
  6. Problemen?
  7. www.facebook.net phishing
  8. OMG pink poniezzz trojan horses
  9. Botnets
  10. crack!
  11. sniffers
  12. spam
  13. Concepten
  14. Data confidentiality
  15. Entity Authentication (Identification)
  16. Data authentication (integrity + who sent it)
  17. Non-repudiation (origin vs receipt)
  18. Denial of Service
  19. Terminology & definitions • Cryptographers and computer security people talk a different language (e.g. ‘authentication’ vs ‘authorisation’) • Integrity(Data authentication? Entity authentication?) • Availability (Denial of Service? Non-repudiation?) • Confidentiality • Trust
  20. Terminology & definitions • Cryptographers and computer security people talk a different language (e.g. ‘authentication’ vs ‘authorisation’) • Integrity(Data authentication? Entity authentication?) • Availability (Denial of Service? Non-repudiation?) • Confidentiality • Trust
  21. Terminology & definitions • Cryptographers and computer security people talk a different language (e.g. ‘authentication’ vs ‘authorisation’) • Integrity(Data authentication? Entity authentication?) • Availability (Denial of Service? Non-repudiation?) • Confidentiality • Trust
  22. Terminology & definitions • Cryptographers and computer security people talk a different language (e.g. ‘authentication’ vs ‘authorisation’) • Integrity(Data authentication? Entity authentication?) • Availability (Denial of Service? Non-repudiation?) • Confidentiality • Trust
  23. Terminology & definitions • Cryptographers and computer security people talk a different language (e.g. ‘authentication’ vs ‘authorisation’) • Integrity(Data authentication? Entity authentication?) • Availability (Denial of Service? Non-repudiation?) • Confidentiality • Trust
  24. Vertrouwen (trust) ➡ Dieter Gollman: “Trust is not the ➡ Based on concept that ➡ reputation unifies security, it ➡ control and is an absolute punishment mess.” ➡ policy enforcement ➡ “If it is trusted, it ➡ ... or blind can hurt you.”
  25. Vertrouwen (trust) ➡ Dieter Gollman: “Trust is not the ➡ Based on concept that ➡ reputation unifies security, it ➡ control and is an absolute punishment mess.” ➡ policy enforcement ➡ “If it is trusted, it ➡ ... or blind can hurt you.”
  26. Vertrouwen (trust) ➡ Dieter Gollman: “Trust is not the ➡ Based on concept that ➡ reputation unifies security, it ➡ control and is an absolute punishment mess.” ➡ policy enforcement ➡ “If it is trusted, it ➡ ... or blind can hurt you.”
  27. Vertrouwen Nieuws.be 27/11/’08 18u13: “A320 crasht in de Middellandse Zee.”
  28. Vertrouwen Luchtvaartnieuws.nl op 5/10/’07: “US Airways bestelt 92 Airbussen.”
  29. Nieuws.be: A320 Luchtvaartnieuws.nl: A350
  30. Vertrouwen Nieuws.be 27/11/’08 20u25: “A320 crasht in de Middellandse Zee.”
  31. Vertrouwen • In de praktijk: • cryptografische sleutel (bvb. encryptie) • toegangsrechten • digitale handtekeningen • “trusted computing”
  32. Vertrouwen • In de praktijk: • cryptografische sleutel (bvb. encryptie) • toegangsrechten • digitale handtekeningen • “trusted computing”
  33. Vertrouwen • In de praktijk: • cryptografische sleutel (bvb. encryptie) • toegangsrechten • digitale handtekeningen • “trusted computing”
  34. Vertrouwen • In de praktijk: • cryptografische sleutel (bvb. encryptie) • toegangsrechten • digitale handtekeningen • “trusted computing”
  35. Information Security Principles • Be clear about definitions
  36. Don’ts
  37. Don’ts • Security and complexity do not mix
  38. Don’ts • Security and complexity do not mix: • operating system • network architecture • applications • mobile code • services: XML, SOAP, VoIP (through the firewall!) • always on connections (botnets!)
  39. Don’ts • Security and complexity do not mix: • operating system • network architecture • applications • mobile code • services: XML, SOAP, VoIP (through the firewall!) • always on connections (botnets!)
  40. Don’ts • Security and complexity do not mix: • operating system • network architecture • applications • mobile code • services: XML, SOAP, VoIP (through the firewall!) • always on connections (botnets!)
  41. Don’ts • Security and complexity do not mix: • operating system • network architecture • applications • mobile code • services: XML, SOAP, VoIP (through the firewall!) • always on connections (botnets!)
  42. Don’ts • Security and complexity do not mix: • operating system • network architecture • applications • mobile code • services: XML, SOAP, VoIP (through the firewall!) • always on connections (botnets!)
  43. Don’ts • Security and complexity do not mix: • operating system • network architecture • applications • mobile code • services: XML, SOAP, VoIP (through the firewall!) • always on connections (botnets!)
  44. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  45. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  46. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  47. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  48. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  49. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  50. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  51. Don’ts • Security through obscurity: • mobile phone systems: GSM in US • DVD copyright protection (DVD Jon!) • Sony rootkit • Diebold voting machines • Microsoft • Cisco router OS • physical locks • blacking out text in PDF (hack: “read out loud”)
  52. Don’ts • Risk avoidance: • accept the risk • reduce risk with technology • reduce risk with procedures • reduce risk with insurance • reduce risk with disclaimers • transfer the risk (e.g.: from data to key)
  53. Don’ts • Risk avoidance: • accept the risk • reduce risk with technology • reduce risk with procedures • reduce risk with insurance • reduce risk with disclaimers • transfer the risk (e.g.: from data to key)
  54. Don’ts • Risk avoidance: • accept the risk • reduce risk with technology • reduce risk with procedures • reduce risk with insurance • reduce risk with disclaimers • transfer the risk (e.g.: from data to key)
  55. Don’ts • Risk avoidance: • accept the risk • reduce risk with technology • reduce risk with procedures • reduce risk with insurance • reduce risk with disclaimers • transfer the risk (e.g.: from data to key)
  56. Don’ts • Risk avoidance: • accept the risk • reduce risk with technology • reduce risk with procedures • reduce risk with insurance • reduce risk with disclaimers • transfer the risk (e.g.: from data to key)
  57. Don’ts • Risk avoidance: • accept the risk • reduce risk with technology • reduce risk with procedures • reduce risk with insurance • reduce risk with disclaimers • transfer the risk (e.g.: from data to key)
  58. Don’ts • Security is not forever: • Cryptography: • 1958 vs now : peanuts • now vs 2058 : ? • Advances in: • reverse engineering • side channel attacks
  59. Don’ts • Security is not forever: • Cryptography: • 1958 vs now : peanuts • now vs 2058 : ? • Advances in: • reverse engineering • side channel attacks
  60. Don’ts • Security and complexity don’t mix • Security through obscurity does not work • 100% security doesn’t exist • Security is not forever
  61. Do’s
  62. Assumptions • Clearly state the assumptions behind the system. • Code re-use can be dangerous: design assumptions might no longer be valid!
  63. Assumptions • GSM: • encryption until the base station • no need to authenticate the network (in Soviet mobile nation, network authenticates YOU!)
  64. Assumptions • e-ID: • PIN code is kept secret by the user
  65. Assumptions • RFID: • opponent cannot eavesdrop > 1 meter
  66. Do’s • Clearly state the assumptions behind the system. • Need for integrated approach
  67. Integrated approach
  68. Do’s • Clearly state the assumptions behind the system. • Need for integrated approach • Find the right mix of technology and law
  69. “Gentlemen don’t go in through the exit”
  70. Digital Rights Management
  71. Digital Millenium Copyright Act
  72. Spam
  73. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
  74. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
  75. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
  76. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
  77. Do’s • Clearly state the assumptions behind the system. • Need for integrated approach • Find the right mix of technology and law • Need for secure implementations
  78. Secure implementations • “Nothing is more practical than a good theory” • “Theory is important, at least in theory”
  79. Secure implementations • Consider: • Secure software/hardware (orlly?) • Side channel attacks • Buffer overflows • API errors • Random number generators • Model vs reality
  80. Model vs Reality
  81. Challenges
  82. Challenges • Always room at the bottom: • RFID • Sensor networks • Smartphones
  83. Challenges • Always room at the bottom • Human Factors: • usability (“This certificate is invalid.” - “OK”) • social engineering
  84. Challenges • Always room at the bottom • Human Factors • It’s the economy, stupid!
  85. Challenges • It’s the economy, stupid! • “No gain, no pain” • Examples: • Software (no liability) • Credit cards in France
  86. Questions to you
  87. 1. Did you _really_ implement secure software?
  88. 2. Do you trust your news service(s)?
  89. 3. Do you use Facebook’s privacy features?
  90. 4. Do you respect someone else’s privacy on Facebook?
  91. 5. Do you care?
  92. Questions?
  93. Disclaimer
  94. Credits • Introduction to security and course overview, prof. dr. ir. Bart Preneel, Intensive Program on Information and Communication Security, July 2006 • Google Images (most of the images) • Sigridschrijft.be / Sony (Terminator 4 poster)

×