Speaking about how to go about taking security seriously in a digital company. Be it from scratch, or fixing a legacy codebase, learn from Canada Revenue Agency's Heartbleed mess-up and advice from a white-hat hacker.

1. Security for Digital Companies
Observations, lessons, and advice from a hacker
Presented by Justin Bull!
September 9th, 2014

2. Who am I

3. Who am I
• Justin Bull
• Software developer at
• Security nutbar
• Ethically curious
• @f3ndot on Twitter

4. Outline
• Canada Revenue Agency: A Case Study
• Responsible disclosure
• Security 101 for a digital company
• Q & A, time permitting

5. “Everything is broken.”
–Quinn Norton, 2014

6. “Everything is broken.”
–Quinn Norton, 2014
It's all about risk management & incident response

7. Canada Revenue Agency:
A case study

8. Canada Revenue Agency:
A tale of woe

9. Think of the word
“Government”

10. Think of the word
“Government”
What comes to mind?

11. Think of the word
“Government”
• Slow
What comes to mind?

12. Think of the word
“Government”
• Slow
• Inefficient
What comes to mind?

13. Think of the word
“Government”
• Slow
• Inefficient
What comes to mind?
• Lots of red tape

14. Think of the word
“Government”
• Slow
• Inefficient
• Lots of red tape
• Bureaucratic
What comes to mind?

15. Yeah…
We have a problem

16. The heartbleed bug
affected 17.5% of all
website servers.
–Netcraft, 2014

17. That’s around half a
million websites
–Netcraft, 2014

18. Who was affected

19. Who was affected
• My personal servers

20. Who was affected
• My personal servers
• Banks

21. Who was affected
• My personal servers
• Banks
• Almost every, single digital company

22. Who was affected
• My personal servers
• Banks
• Almost every, single digital company
• …and the Government of Canada

23. Was CRA self aware?

24. Was CRA self aware?
Nope.

25. FAIL
Was CRA self aware?
Nope.

26. Could CRA be notified?

27. Could CRA be notified?
Nope, nope, nope!

29. Could CRA be notified?
Nope, nope, nope!

30. Could FAIL
CRA be notified? Nope, nope, nope!

31. Was CRA at least quick
when they did know?

32. Was CRA at least quick
when they did know?
Sorta, not really

38. Was CRA at least quick
when they did know?
Sorta, not really

39. Sorta, not really FAIL
Was CRA at least quick
when they did know?

40. We all know about the 900 SIN’s
!
But were there other attacks?
!

41. We all know about the 900 SIN’s
!
But were there other attacks?
!
We will never know

42. What could CRA have
done?

43. What could CRA have
done?
• Have a competent security officer or sysadmin

44. What could CRA have
done?
• Have a competent security officer or sysadmin
• Inter-department cooperation with CSEC
(they knew 1 day before Heartbleed went public)

45. What could CRA have
done?
• Have a competent security officer or sysadmin
• Inter-department cooperation with CSEC
(they knew 1 day before Heartbleed went public)
• A way for people to tell them security issues

46. What could CRA have
done?
• Have a competent security officer or sysadmin
• Inter-department cooperation with CSEC
(they knew 1 day before Heartbleed went public)
• A way for people to tell them security issues
• Be quick!

47. “We don’t have time or money to think about
security right now.”
–Almost any company

48. Responsible Disclosure
The bare minimum for security

49. Responsible Disclosure
• Officially allows users/hackers/researchers to
contact you about security issues
• Basically just a webpage
• Cheapest security investment you can make*
*depending who you talk you

50. Who has a RD policy?
•
• Microsoft
• GitHub
• Apple
• Tesla Motors… Yes, really

51. Danger, Will Robinson!
It’s surprisingly hard to get right

52. Danger, Will Robinson!
It’s surprisingly hard to get right
You need to set up proper encryption and
decide on how to communicate with
researchers.

53. Lessons learned

54. Lessons learned
• It’s pesky and time consuming if you have security
debt

55. Lessons learned
• It’s pesky and time consuming if you have security
debt
• Expect a lot of bullshit, entitlement, and comedy
(See @CluelessSec)

56. Lessons learned
• It’s pesky and time consuming if you have security
debt
• Expect a lot of bullshit, entitlement, and comedy
(See @CluelessSec)
• Expect to be humbled

57. Responsible Disclosure:
you should have it
The bare minimum:

58. Responsible Disclosure:
you should have it
The bare minimum:
• Offer no reward or swag

59. Responsible Disclosure:
you should have it
The bare minimum:
• Offer no reward or swag
• Tell people what’s acceptable, what’s not

60. Responsible Disclosure:
you should have it
The bare minimum:
• Offer no reward or swag
• Tell people what’s acceptable, what’s not
• Provide a special email or a direct phone number

61. Security 101 for Digital Companies
aka “How to not get hacked within a year”*

62. * no promises 

63. Encrypt your passwords!

64. Encrypt your passwords!
No excuses.

65. Encrypt your passwords!
No excuses.
None.

66. Encrypt your passwords!
The consequences

67. Encrypt your passwords!
The consequences
• Domino effect with other customer’s accounts

68. Encrypt your passwords!
The consequences
• Domino effect with other customer’s accounts
• Permanent black mark on your company record

69. Encrypt your passwords!
The consequences
• Domino effect with other customer’s accounts
• Permanent black mark on your company record
• You could be sued. Maybe even class-action

70. Encrypt your passwords!
The consequences
• Domino effect with other customer’s accounts
• Permanent black mark on your company record
• You could be sued. Maybe even class-action
• It’s so cheap and easy to do now. Why not?

71. Encrypt your passwords!
But, don’t roll your own crypto

72. Encrypt your passwords!
But, don’t roll your own crypto
• MD5, SHA1, etc. were not designed for passwords

73. Encrypt your passwords!
But, don’t roll your own crypto
• MD5, SHA1, etc. were not designed for passwords
• Use a password hashing library for your language

74. Encrypt your passwords!
But, don’t roll your own crypto
• MD5, SHA1, etc. were not designed for passwords
• Use a password hashing library for your language
• It should use bcrypt, scrypt, PBKDF2, or an
algorithm designed for passwords

75. Encrypt your passwords!
But, don’t roll your own crypto
• MD5, SHA1, etc. were not designed for passwords
• Use a password hashing library for your language
• It should use bcrypt, scrypt, PBKDF2, or an
algorithm designed for passwords
• You want it to be slow to hash, maybe 1 second

76. Wat.

77. Wat.
You want something to run slowly?
!
Why on earth…?

78. It’s a numbers game
Make it expensive for attackers to brute force your
passwords
–Colin Percival (scrypt), 2009

79. Password Specifics

80. Password Specifics
• You’re gonna encrypt ‘em, right?

81. Password Specifics
• You’re gonna encrypt ‘em, right?
• Enforce password minimums (min. 8 chars, etc.)

82. Password Specifics
• You’re gonna encrypt ‘em, right?
• Enforce password minimums (min. 8 chars, etc.)
• Expire a login after 8 hours? a day? 2 months?

83. Password Specifics
• You’re gonna encrypt ‘em, right?
• Enforce password minimums (min. 8 chars, etc.)
• Expire a login after 8 hours? a day? 2 months?
• Changing/resetting password patterns

84. Password Specifics
• You’re gonna encrypt ‘em, right?
• Enforce password minimums (min. 8 chars, etc.)
• Expire a login after 8 hours? a day? 2 months?
• Changing/resetting password patterns
• Beware of bad security questions!
See goodsecurityquestions.com

85. Lock ‘em out.
Guessed wrong too many times?
Wait 5 minutes, or longer.

86. SSL/TLS
aka
HTTPS
aka

87. SSL/TLS
aka
HTTPS
aka

88. Why SSL/TLS,
!
no matter what?

90. • Foreign & domestic governments

91. • Foreign & domestic governments
• Them nasty hackers

92. • Foreign & domestic governments
• Them nasty hackers
• Even that “innocent” person at the café

93. • Foreign & domestic governments
• Them nasty hackers
• Even that “innocent” person at the café
• Your competitor?

94. • Foreign & domestic governments
• Them nasty hackers
• Even that “innocent” person at the café
• Your competitor?
• Users find comfort in green padlocks…

95. Get Auth & Auth Right!

96. Get Auth & Auth Right!
• Research latest Authorization & Authentication
practices or libraries

97. Get Auth & Auth Right!
• Research latest Authorization & Authentication
practices or libraries
• The most common languages or frameworks
already have libraries available

98. Get Auth & Auth Right!
• Research latest Authorization & Authentication
practices or libraries
• The most common languages or frameworks
already have libraries available
• A rock solid login mechanism is your foundation

99. Have multi-level
access?

100. Have multi-level
access?
Guest, User, Moderator, Admin?

101. Have multi-level
access?
Guest, User, Moderator, Admin?
Research or build ACL into foundations
of your code.

102. Got money, but no time?
!
Don’t know how screwed you are?

103. Got money, but no time?
!
Don’t know how screwed you are?
Hire a pen tester!

104. Got money, but no time?
!
Don’t know how screwed you are?
Hire a pen tester!
Beware the snakeoil.

106. Top 10

107. Top 10
• Get every dev into it, until they dream about it

108. Top 10
• Get every dev into it, until they dream about it
• Covers most common & most dangerous web app
security issues
(XSS, CSRF, SQLi, etc.)

109. Top 10
• Get every dev into it, until they dream about it
• Covers most common & most dangerous web app
security issues
(XSS, CSRF, SQLi, etc.)
• Print out OWASP’s guide books too.
(They’re tomes, but good desk references)

110. Operational Security

111. Operational Security
• Don’t email passwords

112. Operational Security
• Don’t email passwords
• Don’t email passwords

113. Operational Security
• Don’t email passwords
• Don’t email passwords
• Use a password management application
✦ 1Password
✦ KeePass
✦ LastPass

114. Operational Security
• Don’t email passwords
• Don’t email passwords
• Use a password management application
✦ 1Password
✦ KeePass
✦ LastPass
Hell, even use sticky notes
Just don’t email passwords.

115. Some security is about
good PR…

116. Public Relations
• Got social? Use it."
• Got blog? Use it."
• Got email base? Use it."
• Got media attention? Use it.

117. Public Relations
• Got social? Use it."
• Got blog? Use it."
• Got email base? Use it."
• Got media attention? Use it.
See a pattern?

118. Public Relations
• Give the facts & truth
• Try not to spin too much
• Transparency & honesty is key

119. Do it right,
!
and you might escape unscathed

120. That’s all folks!
This presentation has been a
C
Attribution–ShareAlike 4.0 International licensed work.

121. Questions?

122. C Credits
• “Anonymous Hacker” by Brian Klug (CC BY-NC 2.0) (Slide 1, 43)
• “Heartbleed” by Leena Snidate/Codenomicon (CC0 1.0) (Slide 9)
• “The Secret” by Cedward Brice (CC BY-NC 2.0) (Slide 24)
• “Pure Mathematics” by Ed Brambley (CC BY-SA 2.0) (Slide 31)
• “Widget, confused as ever” by Anna Pickard (CC BY-NC-SA 2.0) (Slide 36, 37)
• “The Big E Day 2 2011” by RustyClark (CC BY 2.0) (Slide 40)
• “EFF version of NSA logo” by EFF (CC BY 2.0) (Slide 43)
• “Bryant Park, Nov 2009 - 52” by Ed Yourdon (CC BY 2.0) (Slide 43)
• “Owasp logo” by OWASP (CC BY-SA 3.0) (Slide 47, 48)
• “Day 342 - Hacker” by Christophe Verdier (CC BY-NC 2.0) (Slide 54)
• “Question Box” by Raymond Bryson (CC BY 2.0) (Slide 55)