Document Sample
SecureDesignPrinciples Powered By Docstoc
					CSC 382: Computer Security

  Secure Design Principles

    CSC 382: Computer Security   Slide #1
• Can you login to Sun account (zappa)?
• How much C/C++ experience do you have?

        CSC 382: Computer Security   Slide #2
• Categories of Security Flaws
    – Architecture/Design
    – Implementation
    – Operational
•   Software Security: More than Just Coding
•   Secure Design Principles
•   Design Issues in Legacy Code
•   Case Study: Sendmail vs Postfix

           CSC 382: Computer Security     Slide #3
   Categories of Security Flaws
1. Architectural/design-level flaws:
   security issues that original design did not
   consider or solve correctly.
2. Implementation flaws: errors made in
   coding the design.
3. Operational flaws: problems arising from
   how software is installed or configured.

         CSC 382: Computer Security        Slide #4
     Architecture/Design Flaws
• Race Condition
   – Application checks access control, then accesses a file
     as two separate steps, permitting an attacker to race
     program and substitute the accessible file for one that’s
     not allowed.
• Replay Attack
   – If an attacker can record a transaction between a client
     and server at one time, then replay part of the
     conversation without the application detecting it, a
     replay attack is possible.
• Sniffing
   – Since only authorized users could directly access
     network in original Internet, protocols like telnet send
     passwords in the clear.
             CSC 382: Computer Security                   Slide #5
         Implementation Flaws
• Buffer overflow
   – Application with fixed-size buffer accepts unlimited
     length input, writing data into memory beyond buffer in
     languages w/o bounds checking like C/C++.
• Input validation
   – Application doesn’t check that input has valid format,
     such as not checking for “../” sequences in pathnames,
     allowing attackers to traverse up the directory tree to
     access any file.
• Back door
   – Programmer writes special code to bypass access
     control system, often for debugging or maintenance

           CSC 382: Computer Security                    Slide #6
           Operational Flaws
• Denial of service
  – System does not have enough resources or
    ability to monitor resources to sustain
    availability under large number of requests.
• Default accounts
  – Default username/password pairs allow access
    to anyone who knows default configuration.
• Password cracking
  – Poor passwords can be guessed by software
    using dictionaries and permutation algorithms.

         CSC 382: Computer Security                Slide #7
             Software Security
• More than just coding!
• Security in every phase of development:
  –   Requirements
  –   Design
  –   Implementation
  –   Testing

          CSC 382: Computer Security        Slide #8
 Why is Software Security poor?
1. Security is seen as something that gets in
   the way of software functionality.
2. Security is difficult to assess and quantify.
3. Security is often not a primary skill or
   interest of software developers.
4. Time spent on security is time not spent
   on adding new and interesting

         CSC 382: Computer Security         Slide #9
     How can design securely?
What about using checklists?
  – Learn from our and others’ mistakes.
  – Avoid known errors: buffer overflow, code
    injection, race conditions, etc.
  – Too many known problems.
  – What about unknown problems?

         CSC 382: Computer Security             Slide #10
     How can design securely?
• Think about security from the beginning.
  – Evaluate threats and risks in requirements.
  – Once we understand our threat model, then we
    can begin designing an appropriate solution.
• Apply Secure Design Principles
  – Guidelines for security design.
  – Not a guarantee of security.
  – Tradeoffs between different principles

         CSC 382: Computer Security          Slide #11
               Meta Principles
1. Simplicity
  –   Fewer components and cases to fail.
  –   Fewer possible inconsistencies.
  –   Easy to understand.
2. Restriction
  –   Minimize access.
  –   Inhibit communication.

         CSC 382: Computer Security         Slide #12
      Security Design Principles
1.   Least Privilege
2.   Fail-Safe Defaults
3.   Economy of Mechanism
4.   Complete Mediation
5.   Open Design
6.   Separation of Privilege
7.   Least Common Mechanism
8.   Psychological Acceptability

           CSC 382: Computer Security   Slide #13
                Least Privilege
• A subject should be given only those
  privileges necessary to complete its task.
  – Function, not identity, controls.
  – Rights added as needed, discarded after use.
  – Minimal protection domain.
• Most common violation:
  – Running as administrator or root.
  – Use runas or sudo instead.

         CSC 382: Computer Security            Slide #14
        Least Privilege Example
• Problem: A web server.
  –   Serves files under /usr/local/http.
  –   Logs connections under /usr/local/http/log.
  –   HTTP uses port 80 by default.
  –   Only root can open ports < 1024.
• Solution:
  – Web server runs as root user.
  – How does this solution violate the Principle of
    Least Privilege and how could we fix it?
           CSC 382: Computer Security          Slide #15
How do we run with least privilege?
• List required resources and special tasks
  –   Files
  –   Network connections
  –   Change user account
  –   Backup data
• Determine what access you need to resources
  – Access Control model
  – Do you need create, read, write, append, etc.?

          CSC 382: Computer Security           Slide #16
            Fail-Safe Defaults
• Default action is to deny access.
• When an action fails, system must be
  restored to a state as secure as the state it
  was in when it started the action.

          CSC 382: Computer Security          Slide #17
    Fail Safe Defaults Example
• Problem: Retail credit card transaction.
  – Card looked up in vendor database to check for
    stolen cards or suspicious transaction pattern.
  – What happens if system cannot contact vendor?
• Solution
  – No authentication, but transaction is logged.
  – How does this system violate the Principle of
    Fail-Safe Defaults?

         CSC 382: Computer Security            Slide #18
    Fail Safe Defaults Example
• Problem: MS Office Macro Viruses.
  – MS office files can contain Visual Basic code (macros.)
  – MS Office automatically executes certain macros when
    opening a MS Office file.
  – Users can turn off automatic execution.
  – Don’t mix code and data!
• Solution
  – MS Office XP has automatic execution of macros
    turned off by default.
  – While the solution is a fail-safe default, does it follow
    least privilege too?
           CSC 382: Computer Security                    Slide #19
      Economy of Mechanism
• Keep it as simple as possible (KISS).
  – Use the simplest solution that works.
  – Fewer cases and components to fail.
• Reuse known secure solutions
  – i.e., don’t write your own cryptography.

         CSC 382: Computer Security            Slide #20
 Economy of Mechanism Example
• Problem: SMB File Sharing Protocol.
  – Used since late 1980s.
  – Newer protocol version protects data integrity
    by employing packet signing technique.
  – What do you do about computers with older
    versions of protocol?
• Solution:
  – Let client negotiate which SMB version to use.
  – How does this solution violate economy of

         CSC 382: Computer Security            Slide #21
         Complete Mediation
• Check every access.
• Usually checked once, on first access:
  – UNIX: File ACL checked on open(), but not on
    subsequent accesses to file.
• If permissions change after initial access,
  unauthorized access may be permitted.
• bad example: DNS cache poisoning

         CSC 382: Computer Security         Slide #22
                Open Design
Security should not depend on secrecy of
design or implementation.
– Popularly misunderstood to mean that source
  code should be public.
– “Security through obscurity”
– Refers to security policy and mechanism, not
  simple user secrets like passwords and
  cryptographic keys.

       CSC 382: Computer Security           Slide #23
       Open Design Example:
• Problem: MPAA wants control over DVDs.
  – Region coding, unskippable commercials.
• Solution: CSS (Content Scrambling System)
  – CSS algorithm kept secret.
  – DVD Players need player key to decrypt disk key on
    DVD to descript movie for playing.
     • Encryption uses 40-bit keys.
     • People w/o keys can copy but not play DVDs.
• What happened next?
  – CSS algorithm reverse engineered.
  – Weakness in algorithm allows disk key to be recovered
    in an attack of complexity 225, which takes only a few

          CSC 382: Computer Security                 Slide #24
                  Closed Source
• Security through obscurity.
• Assumes code in binary can’t be read
  –   what about disassemblers?
  –   what about decompilers?
  –   what about debuggers?
  –   what about strings, lsof, truss, /proc?
• Reverse engineering.

           CSC 382: Computer Security           Slide #25
                   Open Source
• Linus’ Law: Given enough eyeballs, all
  bugs are shallow.
• Not so effective for security
  – More incentives to add features than security.
  – Few people have skills to find security holes.
• Having source eliminates a barrier to entry
  for crackers.

         CSC 382: Computer Security            Slide #26
       Separation of Privilege
Require multiple conditions to grant access.
  – Separation of duty.
  – Compartmentalization.
  – Defence in depth.

         CSC 382: Computer Security       Slide #27
          Separation of Duty
• Functions are divided so that one entity
  does not have control over all parts of a
• Example:
  – Different persons must initiate a purchase and
    authorize a purchase.
  – Two different people may be required to arm
    and fire a nuclear missile.

         CSC 382: Computer Security            Slide #28
• Problem: A security violation in one
  process should not affect others.
• Solution: Virtual Memory
  – Each process gets its own address space.
  – In what ways is this solution flawed?
     • i.e., how can the compartments communicate?
  – How could we improve compartmentalization
    of processes?

         CSC 382: Computer Security                  Slide #29
            Defence in Depth
• Diverse defensive strategies
  – Different types of defences.
     • Protection
     • Detection
     • Reaction
  – Different implementations of defences.
  – If one layer pierced, next layer may stop.
  – Avoid “crunchy on the outside, chewy on the
    inside” network security.
• Contradicts “Economy of Mechanism”
  – Think hard about more than 2 layers.
         CSC 382: Computer Security          Slide #30
      Defence in Depth Example
• Problem: Bank.
  – How to secure the money?
• Solution: Defence in depth.
  –   Guards inside bank.
  –   Closed-circuit cameras monitor activity.
  –   Tellers do not have access to vault.
  –   Vault has multiple defences:
       • Time-release.
       • Walls and lock complexity.
       • Multiple compartments.

           CSC 382: Computer Security            Slide #31
    Least Common Mechanism
• Mechanisms used to access resources
  should not be shared.
  – Information can flow along shared channels.
  – Covert channels.
• Contradicts Economy of Mechanism?

         CSC 382: Computer Security          Slide #32
    Least Common Mechanism
• Problem:
  – Compromising web server allows attacker
    access to entire machine.
• Solution
  – Run web server as non-root user.
  – Attacker still gains “other” access to filesystem.
  – Run web server in chroot jail.

         CSC 382: Computer Security              Slide #33
 Psychological Acceptability
Security mechanisms should not add to the
difficulty of accessing a resource.
– Hide complexity introduced by security
– Ease of installation, configuration, and use.
– Human factors critical here.

       CSC 382: Computer Security                 Slide #34
   Psychological Acceptability
• Users will not read documentation.
  – Make system secure in default configuration.
• Users will not read dialog boxes.
  – Don’t offer complex choices.
  – example: Mozilla/IE certificate dialogs.
• Privacy vs Usability
  – example: one-click shopping

         CSC 382: Computer Security            Slide #35
     Psychological Acceptability
• Problem: Your workstation is myws, but you
  log into green every day to do other tasks
  and don’t want to type your password.
• Solution: Let green trust myws.
  – Create ~/.rhosts file on green that lists myws as
    trusted host, then rlogin green will allow
    access without a password.
  – Does this solution violate other principles?
  – Is there a more secure alternative solution?

         CSC 382: Computer Security              Slide #36
                 Legacy Issues
• How can you design security into legacy
  applications without source code?
  – Wrappers
  – Interposition
• What is the best way to fix security flaws in
  an existing application?
  – Code Maintenance Techniques

         CSC 382: Computer Security        Slide #37
         Retrofitting: Wrappers
• Move existing application to special location.
• Replace old application with wrapper that:
   – Performs access control check.
   – Performs input checks.
   – Secures environment.
   – Logs invocation of application.
   – Invokes legacy application from new location.
• Example: AusCERT overflow_wrapper

           CSC 382: Computer Security                Slide #38
     Retrofitting: Interposition
• Interpose software between two programs we
  cannot control.
  – Add access control.
  – Filter communication.
• Example: Network proxy
  – Router blocks all direct client/server connections.
  – Client connects to proxy server, who makes
    connection to remote server on behalf of client.
     • Access Control: disallow certain clients and/or servers.
     • Filtering: scan for viruses, worms, etc.
     • Auditing: all connections can be logged.
          CSC 382: Computer Security                   Slide #39
     Maintenance: Sun tar flaw
• 1993: Every tar file produced under Solaris 2.0
  contained fragments of /etc/passwd file.
• Tar reads and writes fixed size blocks.
• Last block written has contents of memory block
  that were not overwritten by disk read.
• Tar reads /etc/passwd to obtain user info.
• Immediately before it allocates the block read
• Heap allocation doesn’t zero out memory.
• In earlier versions, other memory allocations were
  between reading passwd and block read alloc.
          CSC 382: Computer Security           Slide #40
   Legacy Issues: Maintenance
• How can you avoid adding new security
  flaws when performing code maintenance?

• Before looking at a code maintenace
  procedure, what design principles could
  have prevented the Sun tar flaw?

         CSC 382: Computer Security         Slide #41
   Legacy Issues: Maintenance
1. Understand security model and
   mechanisms already in place.
2. Learn how the program actually works.
   Read design docs, code, and profile the
3. When designing and coding the fix:
  1. Don’t violate the spirit of the design.
  2. Don’t introduce new trust relationships.

         CSC 382: Computer Security             Slide #42
Case Study: Postfix vs Sendmail
• Sendmail
  – monolithic program with root privileges
• Postfix
  –   separate programs with different privileges
  –   smptd: listens to network (port 25)
  –   sendmail: accepts local mail
  –   postdrop: setgid drops in maildrop directory
  –   pickup: retrieves mail from maildrop

            CSC 382: Computer Security           Slide #43
                     Key Points
• Categories of Security Flaws
  – Architecture/design
  – Implementation
  – Operational
• Secure Design Principles
• Retrofitting and Maintaining Secure Design

         CSC 382: Computer Security     Slide #44
1.   Bishop, Matt, Introduction to Computer Security,
     Addison-Wesley, 2005.
2.   Graff, Mark and van Wyk, Kenneth, Secure Coding:
     Principles & Practices, O’Reilly, 2003.
3.   Howard, Michael and LeBlanc, David, Writing Secure
     Code, 2nd edition, Micorosft Press, 2003.
4.   Viega, John, and McGraw, Gary, Building Secure
     Software, Addison-Wesley, 2002.
5.   Wheeler, David, Secure Programming for UNIX and
     Linux HOWTO,
     programs/Secure-Programs-HOWTO/index.html, 2003.

           CSC 382: Computer Security              Slide #45

Shared By:
fanzhongqing fanzhongqing http://