Software Security: Design

Software Engineering
1.0x

Software Security: Design

Created 3 years ago

Duration 0:07:32
lesson view count 423
Select the file type you wish to download
Slide Content
  1. Software Security: Design

    Slide 1 - Software Security: Design

    • Emerson Murphy-Hill
  2. Design Flaws

    Slide 2 - Design Flaws

    • … account for 50% of security problems.
    • … can’t find these by staring at the code or running static analysis
    • … have to have a higher-level view by examining architecture and design
    • ... versus established security architecture and design principles
    • Some principles: defense in depth, least privilege, role-based access control, server-side checks, open design, and psychological acceptability
  3. Defense in Depth

    Slide 3 - Defense in Depth

    • A system should have multiple defensive countermeasures to discourage potential attackers.
    • Each component in a path that leads to a critical component implement proper security measures in its own context (as if it was the “last man standing”).
    • Firewall + encryption + Hibernate + white list server side + Javascript checks …
    • http://www.techi.com/2011/09/the-technology-behind-fort-knox-the-most-secure-vault-in-the-world/
  4. Least Privilege

    Slide 4 - Least Privilege

    • “Need to know” rule; role-based access
    • A subject (user/other system) should be given only those privileges it needs to complete its task.
    • The function (or role) of a user (as opposed its identity) should control the assignment of rights.
  5. Role-Based Access Control

    Slide 5 - Role-Based Access Control

    • A user has access to an object based on the assigned role.
    • Roles are defined based on job functions.
    • Permissions are defined based on job authority and responsibilities within a job function. (“need to know”)
    • Operations on an object are invoked based on the permissions.
    • The object is concerned with the user’s role and not the user.
    • From: csrc.nist.gov/rbac/alvarez.ppt
  6. Role-Based Access Control

    Slide 6 - Role-Based Access Control

    • Individuals
    • Roles
    • Resources/Processes
    • Role 1
    • Role 2
    • Role 3
    • User’s change frequently, roles don’t
    • From: csrc.nist.gov/rbac/alvarez.ppt
  7. Server-Side Checks

    Slide 7 - Server-Side Checks

    • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page.
    • Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
    • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
    • http://cwe.mitre.org/data/definitions/285.html
  8. Never Assume Your Secrets are Safe(Principle of Open Design)

    Slide 8 - Never Assume Your Secrets are Safe(Principle of Open Design)

    • Security of a mechanism should not depend upon the secrecy of its design or implementation. No “security through obscurity.”
    • Inevitably information about the internals of a system will be discovered by malicious users.
    • Insider threat
    • Reverse engineering
  9. Psychological Acceptability

    Slide 9 - Psychological Acceptability

    • Security mechanisms should not make the resource more difficult to access for legitimate users.
    • Pain required to use system should be congruent with importance of security.
    • Otherwise, users will either attempt to bypass security mechanisms or will use them incorrectly.
    • http://cms.skidmore.edu/campus_safety/programs/index.cfm