Trusted security

How do you know that you are your mother’s child?

How can you be sure that the chef in that restaurant did not spit in your lasagna after you complained that the service was too slow?

For the former question, you know that she is your mother, she fed, clothed and looked after you.  You may even have some of her features.  But did you have a DNA test at the hospital to prove it? For the latter, you saw the food hygiene certificate and surely the chef would not do such a thing?

It all comes down to trust

The answer for both is something more fundamental and perhaps somewhat philosophical.  It boils down to trust. You trusted that the staff at the hospital put you in the right crib with the right labels. You may be the only person with ginger hair in your family, but hey, it’s never bothered you before.

And…the lasagna looked ok, but then again…

Trust is not a fixed entity.

The reason for this is that your level of trust in something can vary.   The more important the decision or subject, the more trust you are likely to require…simple…?

Trusted Security

The world of security raises the same fundamental questions;

• That new firewall you just bought, where was it manufactured?
• Are the people managing said firewall suitably qualified?
• Who developed that online banking application?

Most decisions are based upon this concept of trust, and it is derived from a number of places.  Take the example of a service provider; the level of trust may come from the origin, location or perhaps the type of people working for the provider.

Is it down to price?

Trust also comes at a price, because to have a service provider closer to home with staff that you can have greater trust in, is naturally more expensive.

There is a sliding scale in play, with a complete lack of trust often associated with less cost and more risk.  Whereas attaining a greater level of trust is likely to cost more while reducing the level of risk exposure.

So how do you know how much trust you need to have?

Well this is simple risk management really, in that you look at the criticality of the subject, service or system and seek more trust where more critical assets are concerned and similarly, for less critical assets, you may be content with a lesser level of trust.

How do we build trusted security into an architectural pattern?

If you are deploying a service, this concept of trust also applies. You need to know that the software and hardware components you have deployed and the architecture used is sound.  There are many product certification schemes for security enforcing controls out there, for instance Common Criteria and some of the (UK) CESG owned schemes such as CPA.  The use of these certified products builds trust in your environment.  Following well established architectural principles such as Defence in Depth for the deployment of trusted products also enhances the overall security of the subject environment.

For software you ensure that you follow tried-and-tested models for secure development such as those prescribed by OWASP and Safecode.

Multi-layered security

It is important that in any design you do not place too much trust in any single component, be it software or hardware, in your environment.  You need to add sufficient challenge and depth for a potential attacker/hacker to overcome, such that if your first line of defence is attacked or breached, you will have sufficient time to contain or react to the same.  As stated earlier, the level of trust you require, will be driven by the value of your data or service.

Trusted Security

The next time you are deploying a service or considering whether you have done enough to protect your data or service, think about how much you can trust the different elements that comprise the environment, particularly the security enforcing controls..

Oh… and never complain about something in a restaurant before you have had your food…unless you want some extra sauce that is.