Software developers are screwing up the digital world. Security is often an afterthought, or worse, the job of I.T., who is expected to sprinkle magic fairy dust on an app that magically makes it secure. That's an impossible ask and forces a perimeter-based security model that cannot succeed alone in a world of cloud apps, mobile devices, and distributed data. Developers must embrace security by design principles and fundamentally shift their attitude about who is responsible for security.

1. STOPEXPECTING
MAGIC
FAIRY DUSTMAKE APPS SECURE BY DESIGN

2. @zmre zmre
Patrick Walsh
15 Years of Security and Eng. Leadership
CEO IronCore Labs

3. Story is from the book: Secure by Design
Östgöta Bank Robbery of 1854
@zmre / #bsdc

4. ÖSTÖTA BANK
@zmre / #bsdc

5. PICK-PROOF LOCK == FEATURE != SECURE SYSTEM
@zmre / #bsdc

6. SECURE DESIGN SECURE APP
@zmre / #bsdc

7. PERFORMANCE
DEVELOPMENT CONCERNS
SCALABILITY
USABILITY
SECURITY
RELIABILITY
MAINTAINABILITY
@zmre / #bsdc

8. (CONFIDENTIALITY,
INTEGRITY,
AVAILABILITY)
SECURITY CONCERNS
==
@zmre / #bsdc

9. WHO IS RESPONSIBLE FOR YOUR
SECURITY BUDGET?
@zmre / #bsdc

10. I T
OWNS
SECURITY
BUDGET
IT’s toolkit: firewall,
anti-virus, intrusion
detection, VPN, etc.
(CISO or CIO)
@zmre / #bsdc

11. Bugs and security
flaws can’t be fixed
from outside.
A wall without a
gate is a prison. By
design, perimeters
have gates.
<
/>
App Code
@zmre / #bsdc

12. A perfectly secure
app doesn’t need
a perimeter.
<
/>
App Code
@zmre / #bsdc

13. But programmers
aren’t perfect.
And no code runs
in isolation. It’s
balanced atop a
fragile chain of
trust.
So we need both.
<
/>
App Code
@zmre / #bsdc

14. IT
ASSUME APP IS VULNERABLE
DEV
ASSUME NETWORK IS COMPROMISED
@zmre / #bsdc

15. /ˈprinsəpəl/
noun
1. a rule or belief governing one's
behavior
2. fundamental quality or attribute;
an essence
SECURE DESIGN PRINCIPLES
@zmre / #bsdc

16. Layers
Defense in Depth
Verify Everything
Complete Mediation
Play The What If Game
Weakest Link
Expect Transparency
Open Design
Distrust Users & Services
Least Privilege
Compartmentalize
Separation of Duties
KISS
Economy of Mechanism
Usability
Psychological Acceptability
Secure by Default
Fail Safe
Monitor
n/a
PATRICK’S SECURE DESIGN PRINCIPLES
OWASP EQUIVALENTS
@zmre / #bsdc

17. SYLVANIA LIGHTIFY BY OSRAM
@zmre / #bsdc

18. /smärt/
adjective
1. a quick-witted intelligence
2. clean, neat, and well-dressed
noun
1. intelligence; acumen
2. sharp stinging pain
DEFINITION OF SMART
@zmre / #bsdc

19. /smärt/
adjective
1. a quick-witted intelligence
2. clean, neat, and well-dressed
noun
1. intelligence; acumen
2. sharp stinging pain
DEFINITION OF SMART
@zmre / #bsdc

20. SYLVANIA LIGHTIFY BY OSRAM
XSS on username field.
No SSL cert verification.
Malicious wi-fi network name
hack.
Trivial bullshit pre-shared key:
0123456789abcdef.
6 other serious issues.
Research credit: Rapid7@zmre / #bsdc

21. VERIFY EVERYTHING
COMPLETE MEDIATION
Assume the worst. Check all
inputs. Verify all SSL connections.
Check permissions at each data
access.
Should have verified (or pinned)
SSL cert. Should have a RegEx
validation on username field.
More code.
OVERVIEW CASE STUDY HARD PART

22. NO EXCUSE
Not to use HTTPS in dev/staging/QA.
@zmre / #bsdc

23. EXPECT TRANSPARENCY
OPEN DESIGN
Never rely on obscurity to
keep something secure.
Assume all details are public.
Magic pre-shared keys
are bad. Especially weak
and unprotected ones.
Security is easy if obscurity
works. Have to think harder to
make it robust if transparent.
OVERVIEW HARD PARTCASE STUDY

24. AWS key stolen, server accessed, all customers’ data decrypted and stolen.
@zmre / #bsdc

25. “customer data was compromised, including
the ability to decrypt encrypted data.”
@zmre / #bsdc

26. Every user’s secret tokens, passwords, and notes are encrypted
with that user’s unique AES key.
Every user’s AES key is stored on the server and encrypted with
the server’s master AES key.
An attacker with access to the server can trivially decrypt all
secrets. And did.
OneLogin ARCHITECTURE
@zmre / #bsdc

27. LAYERS
DEFENSE IN DEPTH
Use multiple access
methods, protections
and technologies.
Access to their server (via
AWS keys or otherwise)
gave access to all data.
Can reduce usability,
reusability, and increase
complexity.
OVERVIEW HARD PARTCASE STUDY

28. PLAY THE WHAT IF GAME
WEAKEST LINK
When designing systems,
always seek the weakest
link and ask, “what if…”
What if a hacker gets
onto a server?
Can be hard to identify
and fix the weakest link.
OVERVIEW HARD PARTCASE STUDY

29. Who has their router at home?
@zmre / #bsdc

30. http://a.b.c.d/cgi-bin/;COMMAND
@zmre / #bsdc

31. http://a.b.c.d/cgi-bin/;killall$IFS'httpd'
“Users who have the option of doing so should strongly
consider discontinuing use of affected devices.”
@zmre / #bsdc

32. NO AUTOMATIC UPDATES
@zmre / #bsdc

33. DISTRUST USERS & SERVICES
LEAST PRIVILEGE
Limit permissions and keep
things “need-to-know.” Define
the minimum required
permissions and use those.
Services (especially httpd)
should never run as root.
Giving all services and users
admin privileges makes life
easy, but is a terrible mistake.
OVERVIEW HARD PARTCASE STUDY

34. MIRAI BOTNET
THE “FUTURE”
@zmre / #bsdc

35. 60 factory default usernames and passwords
Weaponized IoT: IP cameras, home routers, universal
remotes, DVRs, and more.
Used for DDoS attacks.
Took down DynDNS and Brian Krebs.
MIRAI BOTNET
@zmre / #bsdc

36. SECURE BY DEFAULT
FAIL SAFE
Even fresh out of the box, software
should be secure. That goes
double for failure states. “Fail open”
only when no security implications.
Should have forced a setup
step to set a password before
product would work.
Hard to make secure defaults a
good user experience.
OVERVIEW HARD PARTCASE STUDY

37. MongoDB
@zmre / #bsdc

38. Default config: listens on public port
Default config: no access control or authentication
Expectation: users RTFM and set up security.
MongoDB
@zmre / #bsdc

39. 680
MongoDB CONSEQUENCES
TERABYTES
of data
UNSECURED
@zmre / #bsdc

40. 30,000
MongoDB CONSEQUENCES
DATABASES
COMPROMISED & RANSOMED
@zmre / #bsdc

41. USABILITY
PSYCHOLOGICAL ACCEPTABILITY
Users find ways around
security if it gets in their way.
Like propping open doors.
Mongo used insecure defaults
to make it easy to get started,
but they made it hard to secure
and ultimately failed at usability.
Highly secure systems often
come at the expense of
usability so striking this balance
is difficult.
OVERVIEW HARD PARTCASE STUDY

42. JEEP
@zmre / #bsdc

43. COMPARTMENTALIZE
SEPARATION OF DUTIES
Isolate access to data and gate it.
Different systems have their own
gates. Modular and no trust or master
auth. One system, one purpose.
Extreme example where
networked A/V system should
be completely isolated from
driving controls.
More complexity, harder
troubleshooting, dev, QA.
OVERVIEW HARD PARTCASE STUDY

44. Many crypto algorithms: going back to the nineties.
Support about a dozen different versions
Across architectures and operating systems
Combinatorics of code paths is insanely high
OpenSSL
@zmre / #bsdc

45. 2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
0 10 20 30 40
Low
Moderate
High
FREAK, Logjam
HeartBleed, Poodle, Goto Fail
DROWN
OCSP Stapling
ASN1 Bio
Plaintext Recovery
OpenSSL CONSEQUENCES
@zmre / #bsdc

46. KISS
ECONOMY OF MECHANISM
You must be able to reason about
and understand a system or it can’t
be secure. Legacy is the enemy
when no one understands it and is
afraid to remove it.
OpenSSL is the living example
of this and it’s just getting
worse.
Removing old functionality is
hard to do to customers and
systems. But better for security
and maintainability.
OVERVIEW HARD PARTCASE STUDY

47. MONITOR
Audit and log everything, and
monitor those logs. Use off-
prem or tamper resistant
mechanisms.
Be ready to detect if your app
is hacked and to have data to
tell you how.
Acting on info and getting to
people who understand it.
OVERVIEW HARD PARTCASE STUDY

48. Layers
Defense in Depth
Verify Everything
Complete Mediation
Play The What If Game
Weakest Link
Expect Transparency
Open Design
Distrust Users & Services
Least Privilege
Compartmentalize
Separation of Duties
KISS
Economy of Mechanism
Usability
Psychological Acceptability
Secure by Default
Fail Safe
Monitor
n/a
PATRICK’S SECURE DESIGN PRINCIPLES
OWASP EQUIVALENTS
@zmre / #bsdc

49. Thank You
@zmre
zmre
@ironcorelabs
ironcorelabs.com
Patrick Walsh