Partilhar via

Appendix B: Security Definitions for Vulnerability Work Item Tracking

  • Artigo

It is critical for project teams to specify and maintain a work item tracking system – that allows for creation, triage, assignment, tracking, remediation and reporting of software vulnerabilities.  Optimally, work item tracking should also include the ability to track security and privacy issues by cause and effect of the security bugs.  The work item tracking system should have access controls in place to ensure that changes to information in the system (whether malicious or accidental) can be tracked appropriately.

Ensure that the vulnerability/work item tracking system used includes fields with the following values (at a minimum):

On This Page

Security Bug Cause
Security Bug Effect

Security Bug Cause

The following fields describe causes of vulnerabilities:

  • Not a Security Bug. This field is self-explanatory.

  • Buffer Overflow/Underflow. A failure to check or to limit input data buffer sizes before data is manipulated or processed.

  • Arithmetic Error. A failure to check bounds conditions for integer math, in which results of calculations might overflow or underflow data type. An example is integer overflow.

  • SQL/Script Injection. Allows attackers to alter intended behavior by altering script.

  • Directory Traversal. Allows attackers access to navigate host directory structure.

  • Race Condition. A security vulnerability caused by code timing or synchronization issues.

  • Cross-Site Scripting. This cause involves website weaknesses that allow attackers to have inappropriate access to information or resources. Although a subset of script injection, it is listed separately.

  • Cryptographic Weakness. Insufficient or incorrect use of cryptography to protect data.

  • Weak Authentication. Insufficient checks or tests to validate that the user or process is who or what it claims to be.

  • Weak Authorization/Inappropriate Permission or ACL. Access to resources or data for an authenticated user that are not appropriate for users of that type. For example, allowing anonymous or guest users access to sensitive information.

  • Ineffective Secret Hiding. Insufficient or incorrect protection of cryptographic keys or passwords. For example, storing passwords in plain text in registry or not zeroing out password buffers.

  • Unlimited Resource Consumption (DoS). A failure to check or limit resource allocations that might allow an attacker to deny service by depleting available resources.

  • Incorrect/No Error Messages. Insufficient or incorrect reporting of error checking.

  • Incorrect/No Pathname Canonicalization. An incorrect trust decision based on a resource name, or allowing access to a resource because an attacker bypassed location or name restrictions.

  • Other. None of the above.

Security Bug Effect

The following definitions are from Writing Secure Code , Second Edition.

  • Not a Security Bug. This field is self-explanatory.

  • Spoofing. Spoofing threats allow an attacker to pose as another user, allow a rogue server to pose as a valid server or rogue code to pose as valid code

  • Tampering. Data tampering means malicious modification of data.

Repudiation. Repudiation threats are associated with users who deny having performed an action without other parties having any way to prove otherwise. For example, a user with malicious intent performs an illegal operation on a computer that is unable to trace the prohibited operation.

  • Information Disclosure. Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it. For example, such a threat might be a user’s ability to read a file to which they did not have access, or an intruder’s ability to read data in transit between two computers.

  • Denial of Service. Denial of Service (DoS) attacks deny or restrict services to valid users.

  • Elevation of Privilege. In this type of threat, a user increases their permissions level and therefore can perform actions they should not be allowed to perform. Any unprivileged user who gains unauthorized access might have sufficient access to compromise or even destroy the system.

  • Attack Surface Reduction. This type of threat is not a security bug in the same sense as the other items listed. However, when you attempt to reduce the attack surface, it is valuable to track bugs that describe services and functionality that affect the attack surface. It is important to identify attack surface, even though interfaces that are exposed on the attack surface are technically not vulnerabilities. Such bugs are assigned the Attack Surface Reduction designation.

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.

This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft Corporation. All rights reserved.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported