Posts Tagged ‘security’

6 Questions about security the board care about

Another short post to break up the big essays I tend to write.

These are the questions any Security Manager worth his salt needs to have prepared answers for anytime he attends the board of the company or socialises with board members:

  1. Are we safe ?
  2. Can I take responsibility for the actions of the company ?
  3. Who handles our data ?
  4. Who are we doing business with ?
  5. Are they accountable ?
  6. What is everyone else in our sector doing ?

If you focus your metrics away from the numbers of technical security events and away from the numbers of deployed security controls and towards answering those questions you’ll get a much more engaged board who will be happier to hear you speak.

Top 10 Points – Security Elevator Advice

These are my top 10 key points to give to the top man when he asks you “what should we be doing in security?” and you only have a minute or two or you need a single slide on security for the CTO:

  1. Identify and understand your threats
  2. Reduce your attack surface
  3. Compartmentalise your important services
  4. Track assets and fix known vulnerabilities
  5. Teach people to write secure code
  6. Teach people to behave responsibly
  7. Audit these processes regularly
  8. Monitor for & detect intrusions
  9. Prepare for incident response
  10. Choose and measure security outcomes

The challenge  is, there is a large volume of material needed to understand what they mean and why they matter and years of experience needed to truly understand how to deliver them.

Security Debt

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.


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.

Risk Appetite

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?

Security Target

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.

Security Debts

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 🙂

Security Debt Management

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.

Paying Down the Debt

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.


Security Principles & Maxims

When discussing security architecture with my clients I find it useful to have a handy canned definition of what architecture means when I use the term. This is the definition I use and I think it most accurately represents my concept of architecture in day to day use:

An architecture is a set of principles or maxims used to guide design decisions AND the collection of design decisions taken (or constraints adopted) during the design process.”

I have a list of security principles and maxims that I keep up to date with my current experience of building large systems that I recycle quite a lot, I’ve listed these principles below.

The overall list of principles and maxims is more of an aide memoir to the architectural decision process. It’s a combination of mostly other peoples previously published material (some going back to Saltzer & Schroeder in 1975) and my personal experience which generally goes to show this isn’t rocket science and isn’t actually anything new under the sun.

The benefit of writing these down and sharing them amongst client teams and supplier teams is that sometimes architects in other functional areas apply them to their architectural decision-making before they are reviewed by security. This can make the subsequent discussions regarding security more valuable if the low-hanging fruit is picked off before it gets to me.

Similarly sometimes the process of explaining some of the concepts below can start designers and developers in other functional areas consider security in new ways which when combined with their deep domain knowledge results in very interesting discussions.

Principle 1: Economy of mechanism

There is a positive relationship between the level of complexity of a system or component and the numbers of vulnerabilities that exist. In a related matter highly complex systems or components can contain subtle flaws that very difficult to identify. As a result is it recommended that wherever possible architects and developers should design the simplest possible systems and components.

Principle 2: Fail safe defaults

When a system fails it should do so securely, this generally entails denying access and functionality as a default configuration. This relies on systems rigorously checking return values for failure codes and reverting to a default configuration and undoing changes to revert to a reliable trusted state.

Note: Generally the confidentiality and integrity of a system takes precedence over the availability of the system although there are exceptional cases where this does not apply.

Principle 3: Complete mediation

Implicit trust relationships between components and systems should be eliminated. It is key that security privileges are checked and enforced at all trust boundaries and that subsequent requests for access do not rely on the assigned privileges of previous requests for access without some mechanism for maintaining the trusted state.

Principle 4: Orthogonal security mechanisms

Wherever possible security controls should be orthogonal to the systems they protect. This provides a higher level fo assurance in the correct operation f the security control as it is less likely to be affected by a compromise of the system or component itself and also tends to allow for a more flexible and layered approach to controls.

Principle 5: Semantically consistent defence in depth

Defence in depth provides a higher assurance of security as attackers are required to compromise multiple security controls to compromise the system. When building defence in depth, especially at the application or business logic layer it is important to ensure semantic consistency between security controls so that the depth is maintained throughout a transaction flow.

A lack of semantic consistency can mean that a single security control compromise can lead to a successful attack on the system as a whole as subsequent security controls don’t recognise the same bad events and as a result the level of assurance provided by the multiple controls is reduced.

Principle 6: Separation of privilege

A user or transactions should require multiple conditions to apply before the privilege to perform actions is granted and where possible those conditions should be set by separate components.

Conditions can include authentication, authorisation, location and time among many others.

This prevents the compromise of a single component leading to a successful compromise of the system as a whole.

Principle 7: Least privilege

Users, or components acting on behalf of users, should only be granted the minimum necessary privileges required to perform the requested action or access to a resource. Those privileges should only be granted for minimal length of time and privileges should be explicitly revoked when no longer required.

Extensive privileges granted to users or components beyond the minimum necessary can allow an attacker to significantly extend a local compromise into a wider attack on the system as a whole.

Principle 8: Least common mechanism

Sharing ‘mechanisms’ between users or components for different purposes potentially allows a compromise of that mechanism to result in a significant security breach. This is especially true when the mechanism is shared between high trust and low or medium trust users or components.

Sharing mechanisms, such as reusing the same web server to serve private intranet and public internet content, combines the threat model and the attack surface of both compromise vectors increasing the possibility that the shared mechanism will be compromised.

Where possible and where the threat models are significant enough to merit it separate instances of mechanisms should be used. Actively avoid single points of failure for security controls.

Principle 9: Psychological acceptability

Users have to accept the security mechanisms used or else they will either not use the system or will actively attempt to subvert the security of the system in order to do their jobs rather than for malicious purposes.

Where possible security controls should be transparent to users and technical security risk must be weighed against the risk of human subversion of the planned controls.

Principle 10: Threats change

Security is a competition between the designers and managers of a system and the malicious human attackers that threaten to attack a system. In contrast to environmental risks such as natural disasters human attackers adapt to the security controls and change their methods of attack. New attack vectors and vulnerabilities are identified overtime and groups that previously would have no interest in attacking a system may become a threat due to changing political or social factors.

The threat model considered during the design of a system should not be relied upon to be static for the lifetime of the system and should be regularly reviewed during the operational lifetime of the system and during extended design and build processes.

Principle 11: Design for failure

No security control has ever been shown to be a perfect response to a threat, extensive experience of the implementation of systems shows that failures of systems and failures of security mechanisms are commonplace.

Always consider the impact of a failure of a security mechanism and plan to mitigate for those failures before they occur.

Principle 12: Use configuration control

Change is a constant of design, development build and operations. Many security architectures build a tree of dependencies between a variety of security controls that can be easily disrupted when change to the system occurs and the impact on security is not considered.

The ability of security controls to enforce security constraints on a system is dependent on the understanding of the system and the assets being protected. When these change an entirely effective security architecture may be rendered redundant.

Strong configuration control throughout the lifecycle of a system from requirements through design, development, build, operations and eventually decommissioning ensures an opportunity to review the appropriateness of the security of the system

Principle 13: Product certifications are of little utility

The fact that a COTS component has had some form of independent and reliable scrutiny does increase confidence in the claims made by that component.

However, many certifications are based on very limited configurations of a component. The testing is likely to have been completed in an environment that that is very different to that of the system in design. The testing is unlikely to consider a threat model that is the same as system in design. The testing is also done at a particular point in time, the knowledge of potential vulnerabilities and attack vectors will very probably changed since the testing was completed.

Do not rely on security certifications alone; supplement this with other assurance activities to the veracity of the security claims made by the product.

Principle 14: Design security in from the start

Experience has shown that retrofitting increased security to an extant system is a difficult, expensive and usually unsuccessful exercise.

Where possible include security in the earliest stages of a design and where a likely future change to the security posture is known design for that future posture as soon as possible.

Building a platform for security that isn’t utilised in the early lifecycle of a system is usually cheaper than attempting to refresh the security platform in later stages of the lifecycle and will usually mitigate higher levels of risk.

Principle 15: Include the flexibility to change security controls in the future

Attacks change, new vulnerabilities are discovered, system requirements change, risk appetites change, new threats are identified and the operating environment of the system changes.

It is useful to only loosely-couple the security controls to the system to allow them to be replaced or supplemented with additional components in the future. Tightly coupled security controls are not only expensive to replace or supplement but may constraint he flexibility of the system itself.

Principle 16: Don’t virtualise across security boundaries

Virtualisation is not a security technology, it is a technology designed for performance, efficiency and scalability purposes and in order to meet those goals the security aspects have a lower priority in the design decisions taken by the vendors of virtualisation products.


Twitter RSS