Developers are pressed for producing more secure code, but do not receive support from stakeholders, management and even from the very manufacturers who produce the tools used to write applications. What can go wrong when even the official documentation for a product is wrong regarding security aspects?

1. © 2012
Presented by:
Software Development:
You Better Do What They Told Ya
Ulisses Albuquerque
ualbuquerque@trustwave.com

2. © 2012
$ whois urma
• Ulisses Albuquerque
– App Security Consultant for Trustwave SpiderLabs
• Penetration testing
• Code reviews
• Secure development training
– Passionate and opinionated developer
• Ruby and C FTW
– Long time F/LOSS advocate
• It’s all about the community

3. © 2012
Who is SpiderLabs?
SpiderLabs is the elite security team at Trustwave, offering clients the most advanced
information security expertise and intelligence available today.
The SpiderLabs team has performed more than 1,500 computer incident response and
forensic investigations globally, as well as over 15,000 penetration and application security
tests for Trustwave’s clients.
The global team actively provides threat intelligence to both Trustwave and growing
numbers of organizations from Fortune 50 to enterprises and start-ups.
Companies and organizations in more than 50 countries rely on the SpiderLabs team’s
technical expertise to identify and anticipate cyber security attacks before they happen.
Featured Speakers at:
Featured Media:

4. © 2012
Agenda
• Motivation
• Non-Functional Requirements
• Who You Gonna Call?
• Official Documentation
• What Can We Do About It?
• Conclusion

5. © 2012© 2012
Motivation

6. © 2012
Motivation
Really, b*tch?
http://seclists.org/fulldisclosure/2013/Apr/173
Meanwhile, on [full-disclosure]…

7. © 2012
Motivation
http://memegenerator.net/instance/37406597

8. © 2012
Motivation
• Are developers really at fault?
• Do we (ahem, them) really suck this much?
• Do we have an attitude problem between
developers and security people in the software
industry?
• Obviously not, developers SUCK, right?

9. © 2012© 2012
Non-Functional Requirements

10. © 2012
Non-Functional Requirements
• Implicit expectations about the software
• It should be fast
• It should not crash
• It should be user-friendly
• It should be secure

11. © 2012
Non-Functional Requirements
http://memegenerator.net/instance/37522060

12. © 2012© 2012
Who You Gonna Call?

13. © 2012
Who You Gonna Call?
Software
Concepts
Business
Needs
Constraints
Craftmanship

14. © 2012
Who You Gonna Call?
• How to fill the concept-to-code knowledge gap?
• Google can help
• Stack Overflow can help a lot
• But…
There’s more than
one way to do it™
http://www.spidereyeballs.com/os5/perl/small_os5_r23_1542.html

15. © 2012
Who You Gonna Call?

16. © 2012
Who You Gonna Call?

17. © 2012
Who You Gonna Call?

18. © 2012
Who You Gonna Call?
• Official documentation should be the most
trustworthy source of information
• We don’t want to know just any “how to do it”
• We want to know “how to do it in a secure way”
http://www.themahoganyblog.com/2012/04/attention-music-imposter/laptop-thief/
<3 Stack Overflow!

19. © 2012© 2012
How are vendors providing information on
the security aspects of their tools, APIs
and frameworks?

20. © 2012© 2012
Official Documentation

21. © 2012
Official Documentation - Java
http://docs.oracle.com/javase/7/docs/api/java/io/File.html#toURL()

22. © 2012
Official Documentation - Java
• Pros
• Use of annotations to indicate deprecated APIs
• Compiler warnings
• Clear indication of reason for deprecation
• Security aspects mixed with functional description
• Cons
• Deprecation is not a security-oriented feature

23. © 2012
Official Documentation - .NET
http://msdn.microsoft.com/en-us/library/system.collections.caseinsensitivehashcodeprovider.aspx

24. © 2012
Official Documentation - .NET
• Pros
• Use of annotations to indicate deprecated APIs
• Compiler warnings
• Cons
• No indication of reason for deprecation
• Deprecation is not a security-oriented feature

25. © 2012
Official Documentation
• What about code samples?
http://msdn.microsoft.com/en-us/library/system.io.file.aspx
Race condition
in sample code?

26. © 2012
Official Documentation
• It’s not only about documentation in web pages
• manpages are very inconsistent in their presentation of
security-relevant information
• Shame on us, F/LOSS developers

27. © 2012
Official Documentation

28. © 2012
Official Documentation

29. © 2012
Official Documentation

30. © 2012
Official Documentation

31. © 2012
Official Documentation
http://memegenerator.net/instance/37529225

32. © 2012© 2012
Sometimes it’s not just incompetence or
laziness, but intentionally harmful
documentation

33. © 2012
Official Documentation
http://docs.oracle.com/cd/E13222_01/wls/docs81b/secintro/archtect.html#1033713
Are you f*cking
kidding me,
Oracle?

34. © 2012© 2012
What Can We Do About It?

35. © 2012
What Can We Do About It?
• We = security professionals
– Ignorance != incompetence
– Assume developers are unaware of their mistakes
– Avoid confrontation
• Do proper secure SDLC and be involved in ALL
stages of development
– Help developers make the right choices instead of just
vetoing them
– Easier said than done, unfortunately

36. © 2012
What Can We Do About It?
• We = developers
– Developers write tools for developers
– Add consistent and comprehensive security
information to documentation
– Help fellow developers make the right choices
• Deprecate what needs deprecation
• Remove what is too dangerous

37. © 2012© 2012
Conclusion

38. © 2012
Conclusion
• Developers need training
– Obviously
• Vendor documentation MUST improve
– Even trained developers need context to guide their
choices
• Developers are easy targets after a breach
– Their work takes months or years, breaches happen in
the blink of an eye

39. © 2012
Conclusion
• MOAR ACCOUNTABILITY! MOAR RESOURCES!
– Train your teams
– Assess your results and ACT on them
• Security people need to position themselves as
facilitators rather than opponents
– Who enjoys having their work vetoed after months
working on it?

40. © 2012© 2012
Questions?

41. © 2012
Trustwave SpiderLabs
SpiderLabs is an elite team of ethical hackers at
Trustwave advancing the security capabilities of
leading businesses and organizations throughout
the world.
More Information:
Web: https://www.trustwave.com/spiderlabs
Blog: http://blog.spiderlabs.com
Twitter: @SpiderLabs