Archive for the ‘Architecture’ Category

Security defect triage in delivery projects

The guys at Recx asked me to look at a draft of their recent blog post The Business v Security Bugs – Risk Management of Software Security Vulnerabilities by ISVs where they describe some of the business constraints and influences on security defect triage for Independent Software Vendors and make the case that ultimately the triage decision is a business decision not a technical security decision.

I was happy to do it as I’ve known the guys at Recx for a long time and they are a great little British security company with some seriously deep technical security skills. They have a lot of experience working through ISV security defect triage processes both as external security researchers and as internal product security managers.

Zones of Trust

The key security design decision is the balance to be taken at every step of a system design between trust and inconvenience.

For every system to system, subsystem to subsystem and component to component connection a decision must be made as to whether either side of the connection will trust the other, and to what degree. Trust is in some ways analogous to coupling. The higher the level of trust, the more likely that a compromise of one side of the connection will lead to the compromise of the other.

User-Sourced Security Monitoring

One of the constant challenges I face delivering big systems is meeting the protective monitoring requirements.

A lot of the requirement to spot technical events (low level network probing, back door installation, beaconing and command and control channels) can be covered with a bundle of vendor products integrated into a correlation engine that is tuned by an analyst and watched by expensive security operations staff. That isn’t easy, and getting the buy-in for the capital and operational investment definitely isn’t easy. However it is significantly easier than building a protective monitoring capability that understands the business transactions flowing through a system, significantly easier than finding an analyst who has the skills and time to understand the business rules for those transactions and what the indicators that those business rules have been breached are.

It occurs to me that we have a ready supply of staff on our internal or B2B transactional systems who understand the business context of the transactions intimately….the users!

We have staff in open plan offices, we give them ID badges to wear and ask them to challenge people they don’t recognise for ID. When these staff see something suspicious happening in their work areas they tell us. We put guards on the front door to limit the flow of unknown people into the office, we build secure physical perimeters and monitor them with guard patrols and CCTV. Generally we don’t do this in the offices themselves, we rely on the staff themselves to monitor the inside of our offices for security. This works because they can see what is going on, they can identify co-workers and they know from experience how their business processes work around them. Why not add this visibility and reporting capability to our big transactional systems?

If you’re in a particular team and you could see what your colleagues are doing on the system while you are working on it there is a good chance you would spot something unusual. Such as working a task assigned to a different team member, such as being logged on while home ill, such as making transactions at a much higher rate than the business process usually allows for, such as a user performing a transaction that the rest of the team have never heard of before or is usually working in a different team.

I suggest that for each transaction a short (A familiar 140 character limit perhaps) description is shown in a river of events at the side  of the screen, including a user photo, a user name, what transaction type is being performed, on what data, when it was performed and where the connection to the system came from. Next to each transaction put a ‘Looks suspicious’ button that when pressed sends an alert to the security operations staff to investigate.

The alert can be automatically enriched by the protective monitoring software to include more details about the suspicious transaction, the user that initiated it and the user that indicated it was suspcisious. Such alerts could be weighted by the analyst on the criticality of the transaction and on the relative histories of both the transaction user and the alert initiator. Do either of those users have risk indicators visible in their past behaviour?

This outsources the task of identifying what might be interesting to review out to the users who have the knowledge of what normal looks like.

As long as the private data in the transaction is protected then there is no real privacy difference between this and working in an open plan office.


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