dsf

Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Slide 1: 

Security Design Principles Except where otherwise noted all portions of this work are Copyright (c) 2007 Google and are licensed under the Creative Commons Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/

Security Design Principles : 

Security Design Principles Least Privilege Defense in Depth Secure Weakest Link Fail-safe Stance Secure By Default Simplicity Usability

Principle of Least Privilege : 

Principle of Least Privilege Just enough authority to get the job done. Common world example: Valet Keys A web server should only be given access to the set of HTML files that the web server is to serve.

SimpleWebServer and “Elevated Privileges” : 

SimpleWebServer and “Elevated Privileges” Suppose a system administrator were to run SimpleWebServer under the root account When clients access the web server, they can access all the files on the system! Maybe we can control this by not storing sensitive documents in the web server’s directory tree…

What about this? : 

What about this? GET ../../../../etc/shadow HTTP/1.0

Defense in Depth : 

Defense in Depth Also called redundancy / diversity Common world example: Banks Passwords: Require users to choose “strong” passwords Monitor web server logs for failed login attempts

Secure the Weakest Link : 

Secure the Weakest Link Common Weak Links: Unsecured Dial-In Hosts; War Dialers Weak Passwords; Crack People; Social Engineering Attacks Buffer Overflows

Fail-Safe Stance : 

Fail-Safe Stance Common world example: Elevators System failure should be expected(and planned for) If firewall fails, let no traffic in Deny access by default

SimpleWebServer and Fail-Safe : 

SimpleWebServer and Fail-Safe serveFile() /* if the requested file can be successfully opened and read, then return an OK response code and send the contents of the file */ osw.write ("HTTP/1.0 200 OK\n\n"); while (c != -1) { sb.append((char)c); c = fr.read(); } osw.write (sb.toString());

An “Infinite” File : 

An “Infinite” File The Linux /dev/random is a file that returns random bits (often used to generate cryptographic keys) It can be used as a source of infinite data.. What happens when the web server receives: GET //dev/random HTTP/1.0

How Can We Fix This? : 

How Can We Fix This? /* if the requested file can be successfully opened and read, then return an OK response code and send the contents of the file */ osw.write ("HTTP/1.0 200 OK\n\n"); while (c != -1) { sb.append((char)c); c = fr.read(); } osw.write (sb.toString());

Secure By Default : 

Secure By Default Only enable the 20% of the products features that are used by 80% of the user population. “Hardening” a system:All unnecessary services off by default More features enabled -> more potential exploits ->less security!

Simplicity : 

Simplicity Complex software is likely to have security holes (i.e. sendmail). Use choke points – keep security checks localized. Less functionality = Less security exposure

Usability : 

Usability Users typically do not read documentation(Therefore: Enable security by default) Users can be lazy(Assume: They ignore security dialogs) Secure by default features in software forces users and vendors to be secure.

Security Features Do Not Imply Security : 

Security Features Do Not Imply Security Using one or more security algorithms/protocols will not solve all your problems! Using encryption doesn’t protect against weak passwords. Using SSL in SimpleWebServer doesn’t protect against DoS attacks, access to /etc/shadow, etc.

Security Features Do Not Imply Security : 

Security Features Do Not Imply Security Security features may be able to protect against specific threats But if the software has bugs, is unreliable, does not cover all possible corner cases: The system may not be secure despite the security features it has

“Good Enough” Security : 

“Good Enough” Security The fraction of time you spend designing for security in your application should be proportional to the number and types of threats that your software and business face But remember: Customers expect privacy and security

“Good Enough” Security : 

“Good Enough” Security Design for security by incorporating “hooks” and other low-effort functionality from the beginning. This way, you can add more security as needed without having to resort to work-arounds.

And Don’t Reinvent the Wheel! : 

And Don’t Reinvent the Wheel! SimpleWebServer has many security vulnerabilities… Building a secure, high-performance web server is a very challenging task Apache: www.apache.org

Source : 

Source The content of these slides was adapted from: "Foundations of Security: What Every Programmer Needs To Know" (ISBN 1590597842) by Neil Daswani, Christoph Kern, and Anita Kesavan. http://www.learnsecurity.com/ntk

authorStream Live Help