Your SlideShare is downloading. ×
0
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
The Thing That Should Not Be
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Thing That Should Not Be

456

Published on

Presentation delivered @ OWASP's IBWAS 2010

Presentation delivered @ OWASP's IBWAS 2010

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
456
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The Thing That Should Not Be A glimpse into the dark future of web application securityBruno Morisson <bm@integrity.pt> IBWAS’10
  • 2. About me•  Consultant & Partner - INTEGRITY, Consulting & Advisory•  ~12 years in Information Security•  CISSP-ISSMP/CISA/ISO27001 Lead Auditor•  Background as a Linux/Unix sysadmin•  Background as a C developer 2
  • 3. Warning!This is all rather unscientific! Really. Consider yourself warned. 3
  • 4. If wishes were ponies……security would be inherent to the applications.…there would be no (security) bugs.…we would all get along just fine. 4
  • 5. This is how they see us 5
  • 6. This is how we see them 6
  • 7. We’re all skewed!Security practitioners have a skewed vision of reality.We’re usually what regular people would call paranoid.Developers have a skewed vision of reality.They usually don’t care about (or understand) security issues. 7
  • 8. We’re all skewed!We believe everyone should care about security at least as much as we do. WE’RE WRONG! 8
  • 9. We’re all skewed! 9
  • 10. Security Mindset“Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail.” Bruce Schneier 10
  • 11. “We have a firewall on our internets” 11
  • 12. “We use usernames and passwords to access our webapplication” 12
  • 13. SSL 13
  • 14. ProofSource: Cenzic Web Application Security Trends Report – Q1-Q2, 2010, Cenzic Inc. 14
  • 15. More ProofSource: Cenzic Web Application Security Trends Report – Q1-Q2, 2010, Cenzic Inc. 15
  • 16. Even more proofSource: Verizon Data Breach Report 2010 16
  • 17. OWASP Top Ten•  Injection•  XSS•  Broken Authentication and Session Management•  Insecure Direct Object Reference•  CSRF•  Security Misconfiguration•  Insecure Cryptographic Storage•  Failure to Restrict URL Access•  Insufficient Transport Layer Protection•  Unvalidated Redirects and Forwards 17
  • 18. How are we solving this ?The typical approach is forcing developers to solve all of these problems.But the question is: Who are the developers ? Do they understand the problem ?Most of them know nothing about security.Some of them know little about web development. 18
  • 19. 19
  • 20. Render Unto Caesar…Security practitioners are not web developersWhy should web developers be security practitioners ? 20
  • 21. Flashback 21
  • 22. Let’s party like it’s 1999Most security vulnerabilities had to do with services:•  HTTP (IIS, apache)•  FTP (wu-ftpd, IIS)•  POP3 (Qpopper)•  SMTP (Sendmail)•  DNS (Bind)•  Telnet•  SSH•  …Buffer Overflows, Format Strings, Integer Overflows were the flavor of the decade… 22
  • 23. What happened ?Security vulnerabilities had global impact.Few companies/groups produced that software: Microsoft, Apache, SUN, Sendmail, Linux community/vendors.Some built security into the process (Secure SDL), mainly Microsoft.Tools started having security features (from bounds checking, to static and dynamic code analysis)Operating Systems security was improved (no ASLR or DEP back then) 23
  • 24. Back to the future 24
  • 25. And now ?Impact of vulnerabilities is limited to that company (or set of companies that use that particular software)Anyone develops a Web Application.Myriad of development languages.Point & Click frameworks that automagically create code… 25
  • 26. Looking into the future…Let’s break this down into 4 areas:•  Compliance•  Processes•  People•  Tools 26
  • 27. ComplianceUnless there’s a business requirement, don’t expect anyone to implement security.Ex: PCI-DSS, Data Privacy Laws, … 27
  • 28. ProcessesIf security is done ad-hoc, it will most surely fail.•  Embed security in the SDL•  Create internal processes for dealing specifically with security (e.g. risk assessment, engineering, testing, etc) 28
  • 29. 29
  • 30. PeopleDevelopers won’t build security into the apps, unless it’s a requirement…They need to:understand the security impact.know how to solve the problem.know how to use the tools…Developers won’t become security gurus. 30
  • 31. ToolsPeople fail. Tools/frameworks should become more idiot- proof.Have security built in by default. Force insecurity to be explicit. 31
  • 32. 32
  • 33. Thank You!" Q&A?Bruno MorissonCISSP-ISSMP, CISA, ISO27001LA[email]: bm@integrity.pt[work]: http://www.integrity.pt/[fun]: http://genhex.org/~mori/ 33

×