Scribd Logo
Upload

Welcome to Scribd!

  • 144 views

    Security Testing: How Security Testing Is Different Types of Security Attacks Threat Modelling

    Uploaded by

    anil
    Security testing focuses on ensuring defensive mechanisms like authentication work properly rather than just functionality, involving identifying threats, vulnerabilities, and assets then designing tests to evaluate spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation attacks; common techniques include threat modeling using STRIDE to categorize risks and create attack trees, as well as specific tests for identity, data, logging, access controls, and crashes.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd

    Security Testing: How Security Testing Is Different Types of Security Attacks Threat Modelling

    Uploaded by

    anil
    144 views18 pages
    Security testing focuses on ensuring defensive mechanisms like authentication work properly rather than just functionality, involving identifying threats, vulnerabilities, and assets then designing tests to evaluate spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation attacks; common techniques include threat modeling using STRIDE to categorize risks and create attack trees, as well as specific tests for identity, data, logging, access controls, and crashes.

    Original Title

    SecurityTesting

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Security testing focuses on ensuring defensive mechanisms like authentication work properly rather than just functionality, involving identifying threats, vulnerabilities, and assets then designing tests to evaluate spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation attacks; common techniques include threat modeling using STRIDE to categorize risks and create attack trees, as well as specific tests for identity, data, logging, access controls, and crashes.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    144 views18 pages

    Security Testing: How Security Testing Is Different Types of Security Attacks Threat Modelling

    Uploaded by

    anil
    Security testing focuses on ensuring defensive mechanisms like authentication work properly rather than just functionality, involving identifying threats, vulnerabilities, and assets then designing tests to evaluate spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation attacks; common techniques include threat modeling using STRIDE to categorize risks and create attack trees, as well as specific tests for identity, data, logging, access controls, and crashes.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 18
    At a glance
    Powered by AI
    The key takeaways are that security testing ensures defensive mechanisms work correctly and prevent spoofing or other attacks, and that it is important to build security in during development rather than just testing for it later.

    The document discusses four general classes of security attacks: dependencies that can introduce vulnerabilities, unanticipated user input like special characters or long strings, design vulnerabilities like open ports or default values, and implementation vulnerabilities where developers only understand their own code.

    The document describes threat modeling techniques like threat trees and attack trees to identify potential threats and vulnerabilities in a system.

    Security Testing

    ¾ How security testing is different


    ¾ Types of security attacks
    ¾ Threat modelling

    ¾ Note: focus is on security of applications (not networks,


    operating systems)
    ¾ Security testing is about making sure the defensive
    mechanisms work correctly (e.g. you cannot spoof another
    user’s identify), rather than that the functionality works
    correctly
    Concepts
    ¾ Threat: a potential event that will have an unwelcome
    consequence if it becomes an attack.
    ¾ Vulnerability: a weakness in a system, such as a
    coding bug or a design flaw.
    ¾ Attack: occurs when an attacker has a motive and
    takes advantage of a vulnerability to threaten an asset.
    ¾ Asset: also referred to as threat target.

    ¾ Analogy:
    – A fault may remain latent, or may be surfaced as a failure when the
    code is executed
    – A vulnerability may remain latent, or may be exploited by an attacker,
    enabling an attack

    Howard, M. and Leblanc, D. Writing Secure Code, Microsoft Press, 2003.


    Test Driven Development
    General Good Practices
    1. The best defense is building security IN, not testing it in. [security
    is an emergent property; having a test-centric methodology helps]
    2. Decide how much security is needed.
    3. Perform automated testing.
    4. Test at every stage.
    5. Make a test plan.
    6. Test all system components.
    z Consider business impact of failure, compromise or unavailability
    z What about third-party software? Should it be trusted?
    7. Follow a specific software development methodology.
    8. [Also, use a layered approach to building in and testing for security
    Î Defense in Depth]
    9. [Practice Role-based Access Control (RBAC). Minimize the
    capability given to each “role” Î use least privilege]

    Based on: Graff, Mark G. and van Wyk, Kenneth R., Secure Coding: Principles and Practices, O’Reilly, 2003.
    Beware of Side Effects

    Unreachable code?
    Look at code
    coverage.

    Thompson, Herbert, Why Security Testing is Hard, IEEE Security and Privacy, July/Aug 2003, pp. 83-86.
    Four general classes of security attacks

    ¾ Dependencies
    – Application may inherit vulnerabilities from components its
    dependant upon
    – Libraries that contain security service may fail (so application must
    respond securely – defense in depth!)
    ¾ Unanticipated user input
    – Reserved words, escape characters, long strings, boundary values
    ¾ Expose design vulnerabilities
    – Esp. Ports open, insecure default values, test instrumentation
    interwoven with implementation code [that can explicitly bypass
    security for ease of testing]
    ¾ Expose implementation vulnerabilities
    – Developers only understand their piece, may expose data

    Whittaker & Thompson “How to Break Software: Security”


    Example Security Testing Techniques
    ¾ Spoofing Identity
    – Attempt to force the application to use no authentication; is there an
    option to allows this, which a non-administrator can use?
    – Can you view a valid user’s credentials on the wire or in persistent
    storage?
    – Can “security tokens” (e.g. a cookie) be replayed to bypass an
    authentication stage?
    ¾ Tampering with the data
    – Is it possible to tamper with than rehash the data?
    – Create invalid hashes and digital signatures to verify they are checked
    correctly.
    ¾ Repudiation
    – Do conditions exist that prevent logging or auditing?
    – Is it possible to create requests that create incorrect data in an event
    log?

    Howard, M. and Leblanc, D. Writing Secure Code, Microsoft Press, 2003.


    Example Security Testing Techniques II
    ¾ Information Disclosure
    – Attempt to access data that can be accessed only by more privileged
    users.
    – Make the application fail in a way that discloses useful information to
    an attacker (for example, error messages)
    – Kill the process and then perform disk scavenging, looking for
    sensitive data written to disk.
    ¾ Denial of Service (Dos)
    – Flood a process with so much data it stops responding to valid
    requests.
    – Does malformed data crash the process?
    ¾ Elevation of Privilege
    – Can you execute data as code
    – Can an elevated process be forced to load a command shell, which in
    turn will execute with elevated privileges?

    Howard, M. and Leblanc, D. Writing Secure Code, Microsoft Press, 2003.


    Consider your project
    ¾ Think about your types of users and your database
    project. What rights (read, write, update) do each
    type of user have for each table?

    ¾ Think about your project and possible “misuse


    cases” – write two security scenario tests.
    – A misuse case is a use case from the point of view of an actor
    hostile to the system; the actor is a hacker deliberately
    threatening the security of the system and/or the privacy of the
    users of the system [Alexander]. Done in requirements phase.
    – Every misuse case must have one or more tests.

    Login Obtain Password


    «threatens»
    «include» Hacker

    I. Alexander, "Misuse Cases: Use Cases with Hostile Intent," IEEE Software, vol. 20, no. 1, pp. 58-66, January/February
    2003.
    Threat modeling
    ¾ Security-based analysis that helps people determine the
    highest level risks posed to the product and how threats
    manifest themselves
    ¾ Decompose the application (data flow diagram, DFD) to
    investigate the components, or assets or threat targets,
    of the application and how data flows between them.
    – Treat targets are: every data source, process, data flow, and interactor
    ¾ Using STRIDE, identify threats for each treat target.
    These serve as the roots for the threat trees; there is one
    tree per threat goal.
    – Threats should have at least one test case in the test plan [realistically,
    the higher-risk threats]
    ¾ Build one or more threat trees for each threat target, as
    appropriate (risk-based choice).
    ¾ Using DREAD (or some other threat ranking method,
    determine the security risk for each threat tree.
    Howard, M. and Leblanc, D. Writing Secure Code, Microsoft Press, 2003.
    Data Flow Diagram (DFD): Symbols
    A process. Transforms or manipulates data.

    Interactor. Input into the system.

    Data Flow. Depicts data flow from data stores,


    processes or interactors.

    Data Store. A location that stores temporary or


    permanent data.

    Boundary. A machine, physical address space or


    trust boundary.

    http://www.microsoft.com/whdc/driver/security/threatmodel.mspx
    Data Flow Diagram (DFD): Sample

    (modified)

    http://www.microsoft.com/whdc/driver/security/threatmodel.mspx
    Simple rules for DFD entities:
    ¾ A process must have at least one data flow entering
    and one data flow exiting.
    ¾ All data flows start or stop at a process.
    ¾ Data stores cannot connect together, they must pass
    through a process.
    ¾ Process names are verbs and nouns or verb phrases
    (e.g. Process stock symbol, evaluate exam grade)
    ¾ Data flow names are nouns or noun phrases (e.g. Stock
    price, Exam score)
    ¾ Interactor names are nouns (e.g. Stock broker)
    ¾ Data store names are nouns (e.g. Realtime stock data,
    Exam result data)

    Howard, M. and Leblanc, D. Writing Secure Code, Microsoft Press, 2003.


    Microsoft STRIDE (six) threat categories

    ¾ Spoofing identity – pose as another user


    ¾ Tampering with data – malicious modification of data
    ¾ Repudiation – can the action (prohibited action) be
    traced?
    ¾ Information disclosure – disclose of information to
    individuals who aren’t supposed to have it
    ¾ Denial of service – deny access to valid users (e.g.
    consume all the CPU time)
    ¾ Elevation of privilege – unprivileged user gains
    privileged access (becomes part of the trusted system)

    Howard, M. and Leblanc, D. Writing Secure Code, Microsoft Press, 2003.


    Attack Tree
    Describes the decision-making process an attacker would go
    through to compromise the component.

    The ultimate
    threat; the goal of
    the attacker.

    Conditions
    and/or steps to
    carry out the
    attack.

    http://msdn.microsoft.com/security/securecode/threatmodeling
    Microsoft Security Risk
    Management: DREAD

    http://msdn.microsoft.com/security/securecode/threatmodeling
    Consider your project
    ¾ Draw a DFD diagram.
    ¾ Draw 2-3 attack trees, maybe based upon your scenario
    (misuse case).
    ¾ Create test cases for those attack trees.

    ¾ Resource:
    http://www.microsoft.com/whdc/driver/security/threatmodel.mspx
    References
    ¾ Graff, Mark G. and van Wyk, Kenneth R., Secure
    Coding: Principles and Practices, O’Reilly, 2003.
    ¾ Howard, M. and LeBlanc, D., Writing Secure Code,
    Microsoft Press, 2003.
    ¾ Thompson, H., Why Security Testing is Hard, IEEE
    Security and Privacy, July/Aug 2003, pp. 83-86.
    ¾ Whittaker, J., How to Break Software Security,
    Addison Wesley, 2004.

    You might also like