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

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

11. Botnets

12. crack!

13. sniffers

14. spam

15. Concepten

16. Data confidentiality

17. Entity Authentication
(Identification)

18. Data authentication
(integrity + who sent it)

19. Non-repudiation
(origin vs receipt)

20. Denial of Service

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

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

72. Digital Rights
Management

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)