Cyber Security is often framed in terms of ‘Risk’- the possibility of suffering harm or loss – and the ‘Management’ of Risk to reduce uncertainty. This is familiar territory for businesses. Cyber Security falls in neatly under Risk Management, is assigned a suitable place on the organigramme, tossed some spare budget and granted a few paragraphs in the board report. NIST defines Risk as a ‘function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organisation’.
Key theme:
This presentation explores the idea that making cyber security analogous to risk is holding us back. How about we talk about security ‘debt’ instead? Technical Debt is already a well understood concept in software development – the cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer or cost more. Changing our language changes how we think and how we behave. This presentation argues that such a change could have a significant impact on software security.
In this presentation we will comment on the power of ‘analogies’ and how they’ve shaped our industry. We’ll then consider the difference between the ‘security as risk’ and the ‘security as debt’ paradigms and explore how changing paradigms may change the way we think about, talk about and measure software security. We believe this could have a very empowering effect on development managers and other security professionals who are struggling to articulate the relative benefits of security (or a lack of security) to a software product.
11. 9/14/2018 11
A probability or threat of damage,
injury, liability, loss, or any other
negative occurrence that is caused
by external or internal
vulnerabilities, and that may be
avoided through preemptive action
12. 9/14/2018 12
Risk is the language we use to
communicate with business,
society and government
14. 9/14/2018 14
BOTTOM LINE, IT RISK IS SOMETHING CREATED WITHOUT
BEING UNDERSTOOD. IT IS THE MOST IMPORTANT CONCEPT
IN INFORMATION SECURITY, AND THE MOST ABUSED.
Alex Hutton
15. 9/14/2018 15
AT OUR PRESENT SKILL IN MEASUREMENT OF SECURITY, WE
GENERALLY HAVE AN ORDINAL SCALE AT BEST, NOT AN
INTERVAL SCALE AND CERTAINLY NOT A RATIO SCALE. IN
PLAIN TERMS, THIS MEANS WE CAN SAY WHETHER X IS
BETTER THAN Y BUT HOW MUCH BETTER AND COMPARED TO
WHAT IS NOT SO EASY.
Dan Geer
21. 9/14/2018 21
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.
TECHNICAL DEBT CAN BE COMPARED TO MONETARY DEBT. IF
TECHNICAL DEBT IS NOT REPAID, IT CAN ACCUMULATE 'INTEREST',
MAKING IT HARDER TO IMPLEMENT CHANGES LATER ON.
UNADDRESSED TECHNICAL DEBT INCREASES SOFTWARE
ENTROPY. Ward Cunningham
23. 9/14/2018 23
WE CAN THINK OF ALL THE LATENT VULNERABILITIES IN A PIECE OF
SOFTWARE AS APPLICATION SECURITY DEBT.
Chris Wysopal
24. 9/14/2018 24
Debt and credit are two
sides of the same coin.
Debt is something owed
and credit is something
given, usually in the form
of money.
Debt vs
Credit
An entity who receives
credit
Debtor /
Borrower
The entity who gives
credit is the creditor
Creditor
The debtor must enter
into a contract with the
creditor specifying the
terms by which the debt
will be repaid
Loan
The principal is the
amount of money
borrowed, minus any
payments that have
already been made
Principal
Interest is a fee charged
by the creditor,
calculated monthly or
annually, and expressed
as an interest rate
Interest
Percentage of
the principal
Interest
Rate
Debt classifications
are secured and unsecur
ed debt. A secured debt
is backed by collateral
Secured vs
Unsecured
A secured debt is backed
by collateral, or
something of real value
Collateral
25. 9/14/2018 25
Home Mortgage Asset Backed Debt Security Debt
The borrower… An individual A business A business
Borrows from… A bank A bank RISK Mitigation
Using collateral…
The home
Potentially all assets
• The asset
• Potentially all assets
• Future utility value
• Potentially all assets
Which is leveraged to… Buy a home
Create some utility by
providing Opex or Capex
Create some utility by
providing Opex or Capex
That must be repaid… Regularly Regularly
• For regulation
• For evaluation
• When an asset goes toxic
From…
• Rent; or
• Personal income
• Capital; or
• Revenue generated
• Revenue; or
• Capital
To the lender… The bank The bank Security Debt
26. 9/14/2018 26
Leverage: It’s like borrowing a cow and
selling the milk!
betterexplained.com
Debt multiplies our risk and reward.
28. 9/14/2018 28
WHAT I LIKE ABOUT DEBT
• Concrete
o Shows on the balance sheet
o Impacts on business viability
o It can't be 'accepted' away
• Links directly into fiduciary responsibility
• Transferable
o Buying a technology product with debt is
like buying a financial product with debt
o Everywhere that technology is used carries
that debt onto its balance sheet
• Accrues 'interest'
• Can be 'paid off’
• Can be extrapolated - to groups,
industries, even countries
…a number, a number that has the
personality of a brick; it does not
change much, it is not subject to
interpretation. To us, that’s beautiful.
It’s also limited.
Dan Geer & Gunnar Peterson
38. 9/14/2018 38
Debt: Must always be repaid
betterexplained.com
1. Client Expectation
2. Increasing Cost of Debt
3. External Capability Evolution
4. Increased External Focus
5. During careful evaluation
6. Regulatory Requirements
7. When the asset goes toxic
39. 9/14/2018 39
businessinsider.com
Toxic assets are assets that are now worth considerably less
than they used to be, will likely continue falling in value, and for
which the market has frozen…
52. 9/14/2018 52
“Systemically Important Technology Enterprises”
(SITEs) are technology enterprises crucial to
international corporate productivity.
We want to understand better the risk of cyber
inflicted harm on the global economy and financial
markets.
What is worrying is the potential for a global system-
wide IT failure occurring across many organizations –
a “correlated loss” event that ultimately erodes value
in a vast number of companies across multiple
industries.
53. 9/14/2018 53
But the root causes, as usual,
were mania, leverage and
runnable short-term financing
The resulting global macro-economic impact portends
an economic downturn driven by a reduced trust in
IT by business leaders, investors and consumers,
which we call an ‘information malaise’.
54. 9/14/2018 54
The damage caused by
the more extreme
variants of Sybil Logic
Bomb is almost as severe
as the Great Financial
Crisis of 2007-2012.
The most extreme
scenario variant, X1,
shows a GDP@Risk of $15
trillion.
By comparison, the Great
Financial Crisis of 2007-
2008 measures $20
trillion.
59. 9/14/2018 59
• Assigning Interest Rates to Security Debt:
• Experience prioritisation of security debt is based on a number of
typical technical and business factors, many of which can increase or
decrease the interest rate.
• An organisation should ideally look to continually repay debt, whilst
actively looking for ways to reduce the interest rate associated with
it.
• The overall cost of an issue becomes the development cost plus
the costs associated with the response e.g triaging
• It is possible for software security debt to expire without
needing to get ones creditors to agree
• Debt Overhang: If a large volume of security debt has been
accrued then there is the danger that once external individuals
become aware of the debt mountain and start to actively exploit
then no more can be accumulated at a reasonable rate of
interest.
60. 9/14/2018 60
• There are three sets of information we need to gather:
• Information about the vulnerabilities in the application
• Information about the vulnerabilities that are being exploited
• The cost of an application security breach
• Take the numbers from above and multiply it by the number of
records to get the average expected loss (for an individual
vulnerability category).
• E.g. take a financial organization with 100,000 records in a
critical app. What is their expected loss from SQL Injection this
year:
15.5% X $248 * 100,000 = $3,844,000
• To tie it all together we need a way of relating the vulnerabilities
in your application to the vulnerabilities in the average
application that ended up getting breached
• This is still a work in progress…
61. 9/14/2018 61
• Propose using a Margin of Safety calculation to compare the
book value of a company’s IT assets to book value of the
security controls and services used to defend those assets
• Book value is the asset’s dollar value carried on your balance
sheet - what cost did you incur to develop, deploy, and operate
your system
• The difference between the two numbers above assesses the
level of safety for assets in your enterprise.
• The amount you extend beyond your security spending is your
company’s leverage. Leverage is risky and amplifies any risk
that you already have on your books
• Advantages:
• The Margin of Safety can be compared across projects.
• Gives you a way to see where you are more exposed and some idea
where to allocate resources.
• Uncontroversial and simple to understand.
62. 9/14/2018 62
melv1n.com
• Create a dedicated (SCRUM) epic for debt
• Spike first, then story.
They look like stories but without story points. Instead of that, they have a
time-frame (ex. 5 hours to investigate X) allocated and their main purpose
is to investigate to clarify what needs to be done. The result of a Spike is a
story.
• Adjust your roadmap
• Communicate to stakeholders
• How this will affect the organization and more importantly, your
customers.
• How this will impact the speed of product development.
• Grade your debt:
• Severity
• Occurrence
• Dependency
Add up the numbers of all three levels. Put all issues in a list
for yourself with those total grades. Now you’ll have a base of
prioritization of technical debt issues
63. 9/14/2018 63
• Maintain your own internal Debt Register
• Establish a locus of control for security ‘best practice’
• Every time a security trade-off is made, add it to the list
• Coding short-cut
• Pentest or audit finding
• Technology procurement compromise
• Project or process compromise
• Human resource compromise
• Calculate what the recommended path would have cost and
what was actually spent
• Deduct one from the other to derive the debt and add it to the
register
• Calculate interest monthly at prime and add it also
• You can add a risk weighting to each item and increase or
decrease the interest rate accordingly
• Communicate your Debt Register to your leadership and slowly
crank up the rhetoric.
• Ask key vendors to do the same
67. 9/14/2018 67
THE BUCK STOPS HERE
• We’re facing real threats that require
real change
• Maybe Alex has a point with a medical
risk model
• Clearly more work would need to be
done on quantifying security debt
• Let’s start by changing how we
talk
73. 9/14/2018 73
• In the model economic
consequence was estimated
to be in the range of $60
billion to $200 billion
• The model is considered
possible but not probable
• But it depends largely on the
success rate of attackers in
compromising graphs
• Defender skill and effort play
a highly significant role
74. 9/14/2018 74
Home Mortgage Asset Backed Debt Security Debt
The borrower… An individual A business A business
Borrows from… A bank A bank RISK Mitigation
Using collateral…
The home
Potentially all assets
• The asset
• Potentially all assets
• Future utility value
• Potentially all assets
Which is leveraged to… Buy a home
Create some utility by
providing Opex or Capex
Create some utility by
providing Opex or Capex
That must be repaid… Regularly Regularly
• For regulation
• For evaluation
• When an asset goes toxic
From…
• Rent; or
• Personal income
• Capital; or
• Revenue generated
• Revenue; or
• Capital
To the lender… The bank The bank Security Debt
What happens if this Asset goes toxic?
75. 9/14/2018 75
The sand pile is a great example of a nonlinear
system that does not produce the same result
every time even though the inputs and
conditions are the same. You never know which
grain of sand is going to cause an avalanche or
how big the eventual avalanche will be because
each grain of sand uniquely interacts with other
grains to create a pile that is slightly different
each time.
We may be dealing with a complex, adaptive
system.
- Alex
76. 9/14/2018 76
THREAT: Any circumstance or event with the potential to adversely impact
organizational operations (including mission, functions, image, or reputation),
organizational assets, or individuals through an information system via
unauthorized access, destruction, disclosure, modification of information,
and/or denial of service.
VULNERABILITY: A weakness which can be exploited by a Threat Actor,
such as an attacker, to perform unauthorized actions within a computer
system.
RISK: A probability or threat of damage, injury, liability, loss, or any other
negative occurrence that is caused by external or internal vulnerabilities, and
that may be avoided through preemptive action.
82. 9/14/2018 82
Insufficient up-front definition, where requirements are still being defined during development, development starts before
any design takes place. This is done to save time but often has to be reworked later.
Business pressures, where the business considers getting something released sooner before all of the necessary changes are
complete, builds up technical debt comprising those uncompleted changes.
Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without
considering the implications.
Tightly-coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in
business needs.
Lack of a test suite, which encourages quick and risky band-aids to fix bugs.
Lack of documentation, where code is created without necessary supporting documentation. The work to create any
supporting documentation represents a debt that must be paid.
Lack of collaboration, where knowledge isn't shared around the organization and business efficiency suffers, or junior
developers are not properly mentored.
Parallel development on two or more branches accrues technical debt because of the work required to merge the changes into
a single source base. The more changes that are done in isolation, the more debt is piled up.
Delayed refactoring – As the requirements for a project evolve, it may become clear that parts of the code have become
inefficient or difficult to edit and must be refactored in order to support future requirements. The longer that refactoring is
delayed, and the more code is added, the bigger the debt.
Lack of alignment to standards, where industry standard features, frameworks, technologies are ignored. Eventually,
integration with standards will come, doing sooner will cost less (similar to 'delayed refactoring').
Lack of knowledge, when the developer simply doesn't know how to write elegant code.
Lack of ownership, when outsourced software efforts result in in-house engineering being required to refactor or rewrite
outsourced code.
Poor technological leadership, where poorly thought out commands handed down the chain of command increase the
technical debt rather than reduce it.
Last minute specification changes, these have potential to percolate throughout a project but no time or budget to see them
through with documentation and checks.