Developing Software with Security in Mind
Upcoming SlideShare
Loading in...5
×
 

Developing Software with Security in Mind

on

  • 483 views

 

Statistics

Views

Total Views
483
Views on SlideShare
479
Embed Views
4

Actions

Likes
0
Downloads
4
Comments
0

2 Embeds 4

http://www.linkedin.com 2
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Developing Software with Security in Mind Developing Software with Security in Mind Presentation Transcript

  • Developing Software with Security in Mind Scott Blomquist CTO, Vidoop
  • Format
    • This session is:
      • 10 useful rules for developing with security in mind
      • Not just mine: feel free to interrupt at any time
    • This session isn't:
      • A talk about specific security pitfalls, development techniques, etc.
  • Rule #1
      • Learn about security or it will teach you.
  • How my security education began
    • July 2001: Code Red slows corporate networks to a crawl
    •  
    • September 2001: Nimda does it again
    •  
    • February/March 2002: Windows Security Push
    •  
    • January 2003: This time it's Slammer
    •  
    • Summer 2003: Work begins on "Springboard"
    •  
    • August 2003: Blaster terrorizes the world
  • Rule #2
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
  • Security trends
    • Tools, languages, development practices get better
      • Static analysis tools
      • Safer versions of C run-time functions
      • Input fuzzing tools
      • Stack attack detection
    •  
    • So do the badguys
      • Tools advances may help them, too
      • New techniques are discovered all the time
    •  
    • ALL: favorite examples of either of these?
  • Rule #3
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
  • Passions get the best attention
      • Security geek doesn't have to be a full-time job.
      • You might already work with one (or might be one).
      • To get started, you just have to make it a point to read about and talk about security.
      • With luck, it will just "fit" for someone.
  • Rule #4
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
      • Befriend the security researchers in your field.
  • Security researchers: symbiotic parasites
      • We have great local resources here in Tulsa.
      • Spend time poking holes in your project over coffee or beer.
      • Suggest exciting research projects.
      • Make sure they know how to reach you if they have an interesting thought. 
      • Despite how bad it feels when a flaw in your project gets published, you want them to find the flaw.
  • Rule #5
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
      • Befriend the security researchers in your field.
      • Despite knowledge, you  will ship security bugs.
  • Software is never defect-free
      • No one would claim to be unbreakable (okay, except Oracle)
      • But many projects sure act like they are.
  • Rule #6
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
      • Befriend the security researchers in your field.
      • Despite knowledge, you  will ship security bugs.
      • Have security response plans in place.
  • Emergency response plans
      • How to know when to respond
        • Web products and boxed products are different.
      • How to disseminate the response
        • Everyone needs an update process.
        • Sometimes you need damage control levers, too.
  • Rue #7
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
      • Befriend the security researchers in your field.
      • Despite knowledge, you  will ship security bugs.
      • Have security response plans in place.
      • Security and usability will always be in tension.
  • Secrity vs. Usability
    • "The most secure computer in the world is in a concrete and steel vault, protected by armed guards, and not plugged in to the network or even power. But it's not very useful, either."
    • --Various
  • Rule #8
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
      • Befriend the security researchers in your field.
      • Despite knowledge, you  will ship security bugs.
      • Have security response plans in place.
      • Security and usability will always be in tension.
      • The perfect is the enemy of the good.
  • A case study: OpenID
    • First, what is OpenID: OpenID According to Dave
    •  
      • Many OpenID objections center around how it doesn't solve as many problems as pick-your-favorite-heavy-crypto-based-auth-protocol.
      • Despite those strong objections, OpenID is poised to be an Internet phenomenon.
  • Rule #9
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
      • Befriend the security researchers in your field.
      • Despite knowledge, you  will ship security bugs.
      • Have security response plans in place.
      • Security and usability will always be in tension.
      • The perfect is the enemy of the good.
      • Have open conversations about security.
  • Open conversation
      • You want to know at least as much about your security as everyone else. 
      • Sometimes conversations will be uncomfortable, but you have to learn and your users have to be reassured about their future with your software.
      • Who to talk to:
        • Users
        • Researchers
  • Rule #10
      • Learn about security or it will teach you.
      • Security knowledge goes obsolete quickly.
      • Your team should have a security geek (or more).
      • Befriend the security researchers in your field.
      • Despite knowledge, you  will ship security bugs.
      • Have security response plans in place.
      • Security and usability will always be in tension.
      • The perfect is the enemy of the good.
      • Have open conversations about security.
      • Sometimes there is no rule #10.
  • No rule #10
      • Security is unpredictable.
      • Be ready for anything.
  • Additional Resources
    • More information about Microsoft's security turning point
      • Inside Windows XP SP2
      • Inside the Windows Security Push
  • Questions?
    • Slides available at http://Scott.Blomqui.st