+I-DM-A Stream A: Defect Tracking
---+I-DM-1-A Track security defects centrally
---+I-DM-2-A Rate and track security defects
---+I-DM-3-A Enforce an SLA for defect management

I-DM-A Stream A: Defect Tracking

Defect tracking manages the collection and follow-up of all potential issues in a piece of software, from architectural flaws to coding issues and run-time vulnerabilities.

1. Visão geral

I-DM-1-A Track security defects centrally

Maturity level 1 objective of the practice: All defects are tracked within each project.

Benefit: Transparency of known security defects impacting particular applications

Short description: Introduce a structured tracking of security defects and make knowledgeable decisions based on this information.

Introduce a common definition / understanding of a security defect and define the most common ways of identifying these. These typically include, but are not limited to:

  • Threat assessments
  • Penetration tests
  • Output from static and dynamic analysis scanning tools
  • Responsible disclosure processes or bug bounties

Foster a culture of transparency and avoid blaming any teams for introducing or identifying security defects. Record and track all security defects in a defined location. This location doesn't necessarily have to be centralized for the whole organization, however ensure that you're able to get an overview of all defects affecting a particular application at any single point in time. Define and apply access rules for the tracked security defects to mitigate the risk of leakage and abuse of this information.

Introduce at least rudimentary qualitative classification of security defects so that you are able to prioritize fixing efforts accordingly. Strive for limiting duplication of information and presence of false positives to increase the trustworthiness of the process.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Security Engineer
  • Security Officer
I-DM-2-A Rate and track security defects

Maturity level 2 objective of the practice: Defect tracking is used to influence the deployment process.

Benefit: Consistent classification of security defects with clear expectations of their handling

Short description: Rate all security defects over the whole organization consistently and define SLAs for particular severity classes.

Introduce and apply a well defined rating methodology for your security defects consistently across the whole organization, based on the probability and expected impact of the defect being exploited. This will allow you to identify applications which need higher attention and investments. In case you don't store the information about security defects centrally, ensure that you're still able to easily pull the information from all sources and get an overview about "hot spots" needing your attention.

Introduce SLAs for timely fixing of security defects according to their criticality rating and centrally monitor and regularly report on SLA breaches. Define a process for cases where it's not feasible or economical to fix a defect within the time defined by the SLAs. This should at least ensure that all relevant stakeholders have a solid understanding of the imposed risk. If suitable, employ compensating controls for these cases.

Even if you don't have any formal SLAs for fixing low severity defects, ensure that responsible teams still get a regular overview about issues affecting their applications and understand how particular issues affect or amplify each other.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Security Engineer
  • Security Officer
I-DM-3-A Enforce an SLA for defect management

Maturity level 3 objective of the practice: Defect tracking across multiple components is used to help reduce the number of new defects.

Benefit: Assurance that security defects are handled within predefined SLAs

Short description: Enforce the predefined SLAs and integrate your defect management system with other relevant tooling.

Implement an automated alerting on security defects if the fix time breaches the defined SLAs. Ensure that these defects are automatically transferred into the risk management process and rated by a consistent quantitative methodology. Evaluate how particular defects influence or amplify each other not only on the level of separate teams, but on the level of the whole organization. Use the knowledge of the full kill chain to prioritize, introduce and track compensating controls mitigating the respective business risks.

Integrate your defect management system with the automated tooling introduced by other practices, e.g.:

  • Build and Deployment: Fail the build / deployment process if security defects above certain severity affect the final artifact, unless someone explicitly signs off the exception.
  • Monitoring: If possible, ensure that abuse of the security defect in production environment is recognized and alerted.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Administrator
  • Security Engineer
  • Security Officer
  • Product Owner
  • Manager

1.1 Referências

1.2 Requisitos identificados

1.3 Regulamentos relacionados

2. Requisitos identificados

Requisitos

3. Regulamentos relacionados

Regulamentos
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.