software security austerity - 44con 2012

Software Security Austerity Security Debt in Modern Software Development Ollie Whitehouse, Associate Director, NCC Group

Presenter

Presentation Notes

Based on the paper written by Ollie Whitehouse and James Vaughan: http://www.amazon.co.uk/Software-Security-Austerity-development-ebook/dp/B007H76ABC/ref=sr_1_1?ie=UTF8&qid=1330955744&sr=8-1

Agenda

• Introduction •Software Security Debt •Debt Management •Conclusions

Before we begin…

metaphor abuse warning!

… before we begin part 2…

there is a white paper available

Security debt

Technical debt

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."

Security debt…

• Present in all software • Analogous to development and bugs

• security is just a type of bug • Analogous to development and tech debt • The trade off between

• fix everything and ship nothing -versus- • fix only the critical -versus- • real world business

Security debt…

• You get good… • .. you get a new problem • Too many vulnerabilities!

• You focus on just the critical / serious

• … the low / medium mountain grows

Security debt – types?

• Known – identified, but yet to be addressed

• Unknown – latent issues yet to be discovered

Security debt – source?

• Self my development

• Supply chain my outsourced development

• Dependency COTS component use without formal support

Security debt and SDLs

• SDL does not mean 0 debt • SDL means known security debt

• with a repayment plan • No SDL means latent security debt

• with no repayment plan • SDL means more bugs than resources

• quite quickly / in the short to medium term • SDL means accelerated discovery

• you get too good

Security debt and SDLs

• Why accelerated discovery? • requirements reviews • static code analysis • manual code analysis • automated testing (fuzzing) • increased awareness and knowledge • root cause analysis and variations

Accruing debt based on risk

• Financial cost versus • Revenue • Cost of a response incident • Brand impact • Liability

• Time cost versus • Resources • Time to market • Financial costs

Accruing debt based on risk

• Impact versus • Discovery • Mitigations • Complexity and

prerequisite conditions • Access requirements • Marker expectation

Latent debt resilience

• Latent debt will always exist • through own activities • through suppliers • through dependencies

• The need to feed upstream • The need to build resilient software

Debt Management

Why we care

• Client expectation • Regulatory requirements • Increasing cost of debt • Attacker capability evolution • Increased external focus

Why we care

Assigning interest rates to security debt

• Interest rate = Priority • Priority = risk • Risk = informed

Presenter

Presentation Notes

Impact: What is the impact of the issue if exploited? Distribution: How widespread is the products use, and into which markets? Disclosure: How was the issue reported or discovered, and how well known is it? Likelihood of discovery: What is the potential for the issue to be discovered outside of the organisation’s control? Presence of mitigations: Are their any effective mitigations to reduce the impact if exploited? Complexity of exploitation: What factors and knowledge are required for successful exploitation? Access requirements for exploitation: Are there certain circumstances or criteria that have to be met (outside of the product) before an attack can be brought to bear? Customer expectation of security: How security aware are users of the product, and what is their typical risk profile or appetite?


Threat = f (Motivation, Capability, Opportunity, Impact)

Presenter

Presentation Notes

Motivation: The degree to which a threat agent is prepared to implement a threat. Capability: The degree to which a threat agent is able to implement a threat. Opportunity: The requirements of access to be in a position to exploit. Threat Agents: Used to denote an individual or group that can manifest a threat.


DREAD

Presenter

Presentation Notes

Damage potential: How great is the damage if the vulnerability is exploited? Reproducibility: How easy is it to reproduce the attack? Exploitability: How easy is it to launch an attack? Affected users: As a rough percentage, how many users are affected? Discoverability: How easy is it to find the vulnerability?


CVSS

Presenter

Presentation Notes

Base: The intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments. Temporal: Characteristics of a vulnerability that change over time but not among user environments. Environmental: The characteristics of a vulnerability that are relevant and unique to a particulaire user ’s environnent.


• Impact • Distribution • Disclosure • Likelihood of discovery • Presence of mitigations • Complexity of exploitation • Access requirements • Customer expectation

Presenter

Presentation Notes

Impact: What is the impact of the issue if exploited? Distribution: How widespread is the products use, and into which markets? Disclosure: How was the issue reported or discovered, and how well known is it? Likelihood of discovery: What is the potential for the issue to be discovered outside of the organisation’s control? Presence of mitigations: Are their any effective mitigations to reduce the impact if exploited? Complexity of exploitation: What factors and knowledge are required for successful exploitation? Access requirements for exploitation: Are there certain circumstances or criteria that have to be met (outside of the product) before an attack can be brought to bear? Customer expectation of security: How security aware are users of the product, and what is their typical risk profile or appetite?

Repayment – New version requirements

Repayment – Severity prioritization

• Next release (any type) • Next release (major version) • Next release +1 (any type) • Next release +2 (any type) • Next release +3 (any type)

Repayment – Percentage reduction

Severity Percentage to be resolved

Critical 100%

Serious 50%

Moderate 30%

Low 20%

Other 0 to 5 %

Repayment – Forced

Debt Expiry

Debt Overhang

• Stuart Myers paper (1977)

‘Determinants of Corporate Borrowing’

• Debt mountain equals death by a thousand cuts

• Leading to inability to accrue more security debt

• Leading to slower innovation

Strategic Debt Restructuring

Bankruptcy

Non Repayment – Consequence Planning

"We may be at the point of diminishing returns by trying to buy down vulnerability," the general observed. Instead, he added, "maybe it’s time to place more emphasis on coping with the consequences of a successful attack, and trying to develop networks that can "self-heal" or "self-limit“ the damages inflicted upon them. "

Conclusions

• Zero debt is not good business practice • SDLs enable debt discovery and repayment • A pure risk approach allows the mountain to grow • Outsourcing carries risk of larger latent debt • A mature model is to understand and plan payment • … while educating upstream • … while paying down the mountain • … while still using risk

UK Offices Manchester - Head Office

Cheltenham

Edinburgh

Leatherhead

London

Thame

North American Offices San Francisco

Atlanta

New York

Seattle

Australian Offices Sydney

European Offices Amsterdam - Netherlands

Munich – Germany

Zurich - Switzerland

Thanks! Questions?

Ollie Whitehouse [email protected]

software security austerity - 44con 2012

Technology

assigning interest rates

accruing debt based

security debt

debt

repayment

development

versus

fix