Your SlideShare is downloading. ×
0
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
Secure Software Engineering
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

Secure Software Engineering

296

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
296
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
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. Secure Software Engineering Soumyalatha Jamadarkhana
  • 2. “Security Guru” Says
      • “We wouldn’t have to spend so much time and effort on network security if we didn’t have such bad software security” -Bruce Schneier
  • 3. Source of Security Problems
    • “Time and time again security problems that are encountered come from errors in software.” -Terry Stanley, VP Security, Master Card
  • 4. Hackers
    • “Malicious hackers don’t create security holes; they simply exploit them. Security holes and vulnerabilities – the real root cause of the problem – are the result of bad software design and implementation.”
  • 5. Industry Problem
    • Software development is often rushed due to market pressures
      • Being first to market
      • Get it done yesterday
    • Features, not security, sell software
  • 6. Complexity
    • Software products are growing in size
    • Windows XP has 40 million lines of code
    • 5-50 bugs per KLOC
    • 10% of bugs result in security faults
  • 7. Cost of Bad Software
    • Cost to customer
      • Loss of productivity
      • Cost to apply the fix
      • Theft of information
    • Cost to the Company
      • Harm to reputation
      • Loss of customers
  • 8. Implications
    • Every software system deployed today must defend itself from malicious adversaries
      • Financial Institutions
      • Internet aware client applications on PCs
      • Schools
      • Nuclear Power Plant Control System
  • 9. Secure Software Engineering
    • Integrating security into the software development process
    • Security reviews at each stage: requirement, design, implementation
    • Also have defect removal filters at every stage.
    • Much easier and cheaper than retrofitting a system for security
  • 10.  
  • 11. Principles of Secure Software Engineering by Saltzer and Schroeder
    • Least Privilege – Operate using fewest privileges
    • Economy of Mechanism/Simplicity – Simple design
    • Open Design-Mechanism should be public with secrecy of items like passwords.
    • Complete Mediation-Every access attempt must be checked.
  • 12. Principles (contd)
    • Fail-safe defaults – Default is denial of service.
    • Separation of privilege – Access to objects should depend on more than one condition
    • Least common Mechanism-Minimize the amount and use of shared mechanism
    • Psychological acceptability/Easy to use -The interface should be designed for ease of use
  • 13. What We Don’t Know
    • “Have you ever written a program section with a security hole? ”
  • 14. What You Can Do
    • Understand the causes of security vulnerabilities.
    • Common causes being buffer overflows, race conditions and any kind of defects in the software.
    • Learn the principles for building secure software
    • Secure the weakest link, not the easiest or most obvious one.
  • 15.
    • Assume your code will run in the most hostile environment. Design, write, and test your code accordingly
    • SDLC best practices include security risk analysis, secure design principles, threat modeling, static code analysis, testing methods such as Fuzz testing, ballista, penetration testing.
  • 16. References
    • Holger Peine, Rules of Thumb for Secure Software Engineering.
    • Processes to produce secure software-volume II
    • www.cyberpartnership.org/Software%20Pro.pdf

×