Sunday, 18 March 2012

Software Security Debt - The Value in Measuring Security Debt

We published a free / paid for (your choice) eBooklet on software security debt earlier this month. What follows is an extract (2 of 20 pages) introducing some of the concepts of software security debt and the value of measurement....

Software Security Debt
All software no matter how simple, is likely to carry a degree of security debt. As software complexity increases the likelihood of incurring security debt also increases. This relationship between development and security debt is analogous to development and bugs. The reason the two are analogous is due to the simple fact that some security defects are a type of software bug. 

Debt should not necessarily be considered negatively, as an artefact of an economic development processes, the accrual of debt, security or otherwise is normal and good business. It is not likely that software will ever reach a debt free utopia. The knowledge of security debt is an important input into the risk profile and overall understanding of a product’s or organisation’s exposure.

The objective of having a security debt management process should be a business and development goal for software organisations. If the development and testing teams of an organisation say there isn't any debt; yet cannot demonstrate the steps taken to control it, then it’s likely that a significant amount exists. If proactive steps are not taken, then the accrued security debt can in time become toxic. Debt that has become toxic can then require far greater level of investment to resolve, under externally dictated time-lines and typically under forced repayment conditions.

The Value in Measuring Security Debt
No organisation can avoid the presence of security debt. On this basis, no responsible security and risk aware organisation can reasonably ignore its presence. As security debt cannot be avoided, it should be seen as another input to the risk management processes. Any attempt to avoid understanding or measuring the level of debt, is akin to not wishing to understand the risk exposure. This lack of visibility and understanding will result in a lack of an effective approach to mitigate or remediate the identified risks.

The value in measuring the level of software security debt is in the broader understanding of risk exposure it provides. This broader risk picture can then facilitate the understanding of:
  • The business exposure to the risk from a security incident (forced repayment event).
  • The speed and rate of payback of issues of differing severity.


Once the level of debt is understood it also facilitates strategic planning and metrics.
For example:
  • The potential for future expenditure to address known defects over the short to medium term.
  • Debt trends and the gauging of the return-on-investment from the SDLC process.
  • Understanding the percentage of the debt that is compromised of the OWASP top 10 or similar, facilitating additional prioritisation.
  • Identification of those security issues that can be linked together to achieve a higher level of impact.

Secure Development Life Cycles Identify Debt
It’s important to understand the relationship between an SDLC and security debt. The precursor to an SDLC is security mindfulness. Security mindfulness is where a formal SDLC may not be deployed throughout the organisation, but assurance processes or security related activities do occur at the different phases of development or testing. These activities will then likely mature into a full SDLC.

When adopting an SDLC the benefits of identifying vulnerabilities earlier in the lifecycle will be seen for new development. However, when SDLC or security mindfulness activities are applied to both new and old development there will be prolonged periods of implementation debt discovery.

As these activities increase, the likelihood is that the volume of issues found in software will quickly start to out pace the resources available to resolve them on a per release or per product basis. The reason for the acceleration in the discovery of security issues can be numerous, however, likely drivers include:
  • Increased manual code coverage.
  • Increased use of static code analysis.
  • Increased use of automated security testing (fuzzing).
  • Development and testing team knowledge and awareness of security issues enabling identification.
  • Root cause analysis and variation identification based on publicly disclosed flaws.

As a result of this increase in the volume of issues and the associated resource constraints, organisations tend to focus only on the most severe issues. Over time, a mountain of security debt starts to grow fuelled by the volume of lower impact issues. However, while individual issues may be rated at a certain severity level, the same is not true for combinations of issues. That is to say, a number of distinct lower impact issues when combined or chained together, can carry equal impact to a single higher rated issue. While the complexity related to discovery and exploitation is greater, the ultimate impact can be the same. SDLCs today do not adequately deal with this scenario of aggregating lower severity issues to understand impact.

If you're interested in reading more feel free to download the paper.

No comments:

Post a Comment