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.