The following are some notes I put together describing the concept of ‘security debt’ as a way of thinking about managing security in a real world business, its taken on some new meaning following the credit crunch….
I think there are extensions to be made to the concept but I am interested in any opinions on the idea as an approach.
Introduction
Debt is a useful tool for maintaining the ebb and flow of cash flow over the short term. Technical Debt is a metaphor coined by Ward Cunningham in 1992 to describe the short-cuts in software development that end up costing more in time to fix and reduced flexibility in the future.
“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. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.” Ward Cunningham, The Wycash Portfolio Management System, 1992.
The concept of Technical Debt has become a useful tool in software development, especially in recent Agile Development methodologies. The concept of debt, trading future cost against today’s benefit, can be usefully applied to the management of security in large organisations.
Security Debt as a concept describes the gap between the Security Target for an organisation and the security implementation that is delivered. This debt represents a risk above and beyond the Risk Appetite, as well as the savings of cost and/or time in the delivery of the business need.
The Risk Appetite is the amount of risk the organisation is content to accept in the normal operation of its business. The Risk Appetite for an organisation is set and owned by the management board. The Security Manager can ask a series of simple questions of the board that he can use to document the Risk Appetite in the security context. These questions include:
- Do you want full compliance or risk-based compliance?
- Do you want to meet independent standards?
- Do you want to certify to independent standards?
- Do you want to be more secure than your competitors?
- Do you want to be no less secure than your competitors?
- Do you want to take more risk than your competitors?
The Security Target is the standard of security in different environments that the organisation deems to meet the risk appetite. Using the answers to the Risk Appetite questions a competent Security Manager should be able to establish a security target that would meet the Risk Appetite identified by the board.
The Security Manager is responsible for ensuring the stated Risk Appetite is reflected in the operations of the business though the implementation of the Security Target. The Security Manager *OWNS* the job of interpreting the Risk Appetite into the Security Target. The Security Target is characterised by its maturity as follows:
- Level 0 – There is no clear view of security target.
- Level 1 – The description of the Security Target relies on opinion or experience of security team on a case by case basis.
- Level 2 – Some documented security standards that meet the requirements of the Security Target exist.
- Level 3 – The complete Security Target based in documented standards exists.
- Level 4 – The complete Security Target exists and the organisation has demonstrated processes to review and update the security target in line with changes to the Risk Appetite or changes to the environments on a regular basis.
The Security Manager is responsible for improving the maturity of the Security Target from level 0 to 5.
When a conflict occurs with the business over the level of security controls required by the security target in any particular implementation there are two possible outcomes:
Where the risk is deemed high enough by the Security Manager then it is escalated to the board for resolution. This is expected to be a very rare occurrence.
Where the business owner of a legacy asset or a business sponsor of a change project wishes to take increased risk it is documented as a “Security Debt”.
The Security Debt is documented in a standard format and contains a brief description of the issue at hand, a statement from the Security Manager on the perceived risk level and a quote from the business owner/sponsor of the cost and/or time taking the risk saves versus full treatment. It is signed by the business owner/sponsor.
The perceived risks are identified by the Security Manager roughly as one of the following based on the level of divergence from the Security Target in the particular environment in question (More trusted environments can diverge further for less debt):
- Critical (Black)
- High (Red)
- Medium (Orange)
- Low (Amber)
Critical or Black risks are escalated to the Board. There are no green risks in security 🙂
The Security Manager is responsible for reporting monthly to the board on a headline total security debt or Organisational Security Deficit and is responsible for reporting bi-annually on a detailed breakdown of the Organisational Security Deficit listing numbers of & levels of risks by business owner/sponsor and the total cost and time savings by business owner/sponsor.
Decommissioned systems or assets with outstanding debts have those debts cancelled. The Security Manager will provide business cases for large scale organisational security improvement programmes and the development of central security services that should focus on potential reduction of the Organisational Security Deficit or on future Security Debt prevention.