More Related Content
Similar to Information Security, some illustrated principles
Similar to Information Security, some illustrated principles (20)
Recently uploaded
Recently uploaded (20)
Information Security, some illustrated principles
- 1. Information security some illustrated principles
- 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
- 11. Botnets
- 12. crack!
- 13. sniffers
- 14. spam
- 15. Concepten
- 17. Entity Authentication (Identification)
- 18. Data authentication (integrity + who sent it)
- 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. 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
- 25. 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
- 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 (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.”
- 28. 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.”
- 29. Vertrouwen Nieuws.be 27/11/’08 18u13: “A320 crasht in de Middellandse Zee.”
- 30. Vertrouwen Luchtvaartnieuws.nl op 5/10/’07: “US Airways bestelt 92 Airbussen.”
- 31. Nieuws.be: A320 Luchtvaartnieuws.nl: A350
- 32. Vertrouwen Nieuws.be 27/11/’08 20u25: “A320 crasht in de Middellandse Zee.”
- 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. Vertrouwen • In de praktijk: • cryptografische sleutel (bvb. encryptie) • toegangsrechten • digitale handtekeningen • “trusted computing”
- 36. Vertrouwen • In de praktijk: • cryptografische sleutel (bvb. encryptie) • toegangsrechten • digitale handtekeningen • “trusted computing”
- 37. Information Security Principles • Be clear about definitions
- 38. Don’ts
- 39. Don’ts • Security and complexity do not mix
- 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 and complexity do not mix: • operating system • network architecture • applications • mobile code • services: XML, SOAP, VoIP (through the firewall!) • always on connections (botnets!)
- 45. 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!)
- 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 • 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”)
- 53. 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”)
- 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 • 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)
- 59. 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)
- 60. Don’ts • Security is not forever: • Cryptography: • 1958 vs now : peanuts • now vs 2058 : ? • Advances in: • reverse engineering • side channel attacks
- 61. Don’ts • Security is not forever: • Cryptography: • 1958 vs now : peanuts • now vs 2058 : ? • Advances in: • reverse engineering • side channel attacks
- 62. Don’ts • Security and complexity don’t mix • Security through obscurity does not work • 100% security doesn’t exist • Security is not forever
- 63. Do’s
- 64. Assumptions • Clearly state the assumptions behind the system. • Code re-use can be dangerous: design assumptions might no longer be valid!
- 65. Assumptions • GSM: • encryption until the base station • no need to authenticate the network (in Soviet mobile nation, network authenticates YOU!)
- 66. Assumptions • e-ID: • PIN code is kept secret by the user
- 67. Assumptions • RFID: • opponent cannot eavesdrop > 1 meter
- 68. Do’s • Clearly state the assumptions behind the system. • Need for integrated approach
- 70. Do’s • Clearly state the assumptions behind the system. • Need for integrated approach • Find the right mix of technology and law
- 71. “Gentlemen don’t go in through the exit”
- 73. Digital Millenium Copyright Act
- 74. Spam
- 75. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
- 76. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
- 77. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
- 78. Legislation • Electronic Signatures • Data retention • Eavesdropping • Computer Crime
- 79. 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
- 80. Secure implementations • “Nothing is more practical than a good theory” • “Theory is important, at least in theory”
- 81. Secure implementations • Consider: • Secure software/hardware (orlly?) • Side channel attacks • Buffer overflows • API errors • Random number generators • Model vs reality
- 82. Model vs Reality
- 83. Challenges
- 84. Challenges • Always room at the bottom: • RFID • Sensor networks • Smartphones
- 85. Challenges • Always room at the bottom • Human Factors: • usability (“This certificate is invalid.” - “OK”) • social engineering
- 86. Challenges • Always room at the bottom • Human Factors • It’s the economy, stupid!
- 87. Challenges • It’s the economy, stupid! • “No gain, no pain” • Examples: • Software (no liability) • Credit cards in France
- 88. Questions to you
- 89. 1. Did you _really_ implement secure software?
- 90. 2. Do you trust your news service(s)?
- 91. 3. Do you use Facebook’s privacy features?
- 92. 4. Do you respect someone else’s privacy on Facebook?
- 93. 5. Do you care?
- 94. Questions?
- 95. Disclaimer
- 96. 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)