4.security assessment and testing

Click here to load reader

Post on 12-Nov-2014

725 views

Category:

Technology

1 download

Embed Size (px)

DESCRIPTION

 

TRANSCRIPT

  • 1. Course 1: Overview ofSecure Programming, Section 4
    • Pascal Meunier, Ph.D., M.Sc., CISSP
  • May 2004; updated August 12, 2004
  • Developed thanks to support and contributions from Symantec Corporation, support from the NSF SFS Capacity Building Program (Award Number 0113725) and the Purdue e-Enterprise Center
  • Copyright (2004) Purdue Research Foundation. All rights reserved.

2. Course 1 Learning Plan

  • Security overview and patching
  • Public vulnerability databases and resources
  • Secure software engineering
  • Security assessment and testing
  • Shell and environment
  • Resource management
  • Trust management

3. Learning objectives

  • Understand the challenges and methods for assessing software security.

4. Security Assessment and Testing: Outline

  • Security Assessment
    • Architecture and Assurance
    • Code analysis
      • Definitions
      • Reviews
      • Automated checkers
    • Code complexity
    • Style
    • History of vulnerabilities and patches
  • Testing

5. Architecture

  • If there happened to be a vulnerability in a given part of the code, what would be the consequences?
  • Design and architecture can mitigate the consequences of a vulnerability
    • e.g., correct application of compartmentalization and principle of least privilege
    • Example: chroot in UNIX limits the resources (files and libraries) accessible by a process, so that even if a vulnerability is exploited, damage can be limited
    • Use of stored procedures in SQL databases, instead of generating all SQL code dynamically, may limit how the database can be attacked (see code injection vulnerabilities in another unit)

6. Question

  • One of the roles of architecture insecuresoftware engineering is to structure the application or system so it :
  • a) Is easier to implement, test and maintain
  • b) Gives the best performance and code reuse
  • c) Mitigates exploits

7. Question

  • One of the roles of architecture insecuresoftware engineering is to structure the application or system so it :
  • a) Is easier to implement, test and maintain
  • b) Gives the best performance and code reuse
  • c) Mitigates exploits
  • (Answer "a" can also help security inasmuch as complexity makes security issues more likely)

8. Discussion

  • Give an example of something else architecture can do to improve the security of applications and systems.

(Instructor: Limit this discussion to less than 10 minutes) 9. Discussion examples

  • Organize the code into layers and units (libraries, kernels, headers, objects, etc...) whose security properties are more understandable, systematically guaranteed, or can even be proven
  • Choose languages that support declarative security restrictions (Java security manager;mechanism external to the code) instead of programmatic restrictions (C/C++)
    • That is, if you will actually use those features!
  • Does the application you are assessing do that?

10. Assurance

  • Correcting security problems after implementation has known security limitations
    • Cost and time
      • Some corrections would require rewriting everything
      • Superficial patch is usually applied instead
    • "Products claiming security that are created from previous versions without security cannot achieve high trust because they lack the fundamental and structural concepts required for high assurance" (Sullivan 2003)

11. Other Assurance Considerations

  • Has security been hacked into the artifact being evaluated, or was it part of the original design and architecture?
  • Has the artifact been certified with the Common Criteria?
  • Was it architected and designed using a valid threat model?

12. Security Assessment and Testing: Outline

  • Security Assessment
    • Architecture and Assurance
    • Code analysis
      • Definitions
      • Reviews
      • Automated checkers
    • Code complexity
    • Style
    • History of vulnerabilities and patches
  • Testing

13. Code Analysis

  • Static: examining the code without executing it
    • Examples:
      • Design and code reviews
      • Syntax and style checkers
      • Most automated security auditors
        • finds "stupid" coding mistakes
  • Model Checking: run code within model checker
    • check if rules and invariants ("properties") are obeyed
      • e.g., all allocated memory must be freed
  • Security auditors using static analysis or model checking tend to find different types of bugs

Reference: Engler and Musuvathi 2003 14. Code Analysis: Definitions

  • A false positive occurs when an alert is given in the absence of what we want to detect.
    • false positives incur the cost of activating response processes
  • A false negative occurs when no alert is given in the presence of what we want to detect.
    • false negatives allow a threat to become real

15. Question

  • Given busy locations where the great majority of people are honest citizens, what makes computerized face-recognition systems unusable?
  • a) False negatives, because criminals can get past them
  • b) False positives, because the number of alerts (and their cost) is unmanageable
  • c) They work well enough

16. Question

  • Given busy locations where the great majority of people are honest citizens, what makes computerized face-recognition systems unusable?
  • a) False negatives, because criminals can get past them
  • b) False positives, because the number of alerts (and their cost) is unmanageable
  • c) They work well enough

17. Code Analysis: Code and Design Reviews

  • Dependent on skills of reviewers
    • Best to have critical, unintimidated reviewers with different skills and perspective than the authors
  • With current technology they produce
    • Least false positives
    • Least false negatives
  • Can transfer skills (learning opportunity)
    • Starting code reviews early may be cheaper than later
  • Most effective... (according to Microsoft)
    • In 90 minute sessions
    • With no more than three people

18. Costs of Reviews

  • Can be hard on developer morale and self-esteem
  • Expensive
    • Time consuming
      • Focusing on risky code, as determined by a threat analysis, can yield a higher return
    • Need setup and followup
    • Reviewers may need training
  • Risks of
    • Group-think (reviewers become "yes-men")
    • Same-skills reviews ("inbred" code reviews)
    • Stale reviews (loss of lateral thinking capability)

19. Question

  • What can you do to avoid the dangers of "inbred" code or design reviews?
  • a) Invite an external participant with different skills
  • b) Study the genealogy of the code
  • c) Provide a constructive atmosphere during the review that welcomes and rewards criticism

20. Question

  • What can you do to avoid the dangers of "inbred" code or design reviews?
  • a) Invite an external participant with different skills
  • b) Study the genealogy of the code
  • c) Provide a constructive atmosphere during the review that welcomes and rewards criticism

21. Code Analysis: Automated Code Checkers

  • What targets?