Threat Level: green Handler on Duty: Guy Bruneau

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Architecture, security and assurance

Published: 2007-11-17
Last Updated: 2007-11-17 09:48:28 UTC
by Mark Hofman (Version: 1)
0 comment(s)

Kind of following on from Swa's post from yesterday.   When we go to a banking website we check for the little padlock, when we send a confidential communication we encrypt it.  Much of the internet now is dependent on strong encryption.  Ecommerce relies on solid encryption, as do governments, businesses, etc.  So what if encryption goes bad?  Well, at best people laugh at you (remember CSS) at worst national security is compromised, or your company’s reputation is shot to pieces.

Craig (thanks) wrote in with an observation that set me thinking. 

I don’t think there is a single place in a computing system where the architecture and implementation have more critical impact then in implementation of cryptographic systems.

We all know that if the key is compromised, the game is over.   We also tend to think “I’m using AES-256, so everything should be sweet”, but not all of us think about the rest of the system.  For example the pseudo-random number generator (PRNG) on Windows issue swa talked about yesterday, shows that if thing aren’t quite as random as you’d hoped, or access can be gained then things go awry and using a strong algorithm means nothing. 

As Craig writes

just because your pieces fit and operate as a cryptographic system, doesn’t mean that you put them together in a way that makes the cryptographic system secure

Now governments typically have recognised this issue.  Many will state that unless the cryptographic product has been fully examined by them, as a government agency, you are not permitted to use it to transmit anything sensitive.   

If the architecture to deliver cryptographic services has not been evaluated, then if a recognised strong algorithm it may still be used albeit for limited use.   To me it shows that there are governments that have recognised that the way something is put together is very important.   This is one area where business needs to catch up.  You often hear the words “but it uses insert favourite algorithm here”.  In the world today we may need something more.

Common Criteria

So how do you get some of this assurance that a product is put together in a secure manner?  Many organisations and government look at products that have been evaluated.   Typically this is now under a scheme called Common Criteria (CC)  (old timers will remember the orange book as well).  One of the things to look out for is the security target of the device/software being evaluated.   For example there are some firewalls on the list whose security target does not include the VPN or encrypting capabilities.  So the firewalling capabilities have been verified, but the encryption functions have not.   If you are a business, then this may still be OK to use, but if you are a government agency, it may mean that you will have to purchase a separate product to provide VPN connectivity for remote users.

The devices also need to be configured in line with the Security Target and the Certification report in order to be able to comply.  Over time there have been examples where a product is rated as a secure product, but only if you don’t connect it to a network (yes it was a product that provides network functionality).   Again government bodies typically have to pay attention to this, business less so, but it is always good to know what has been evaluated and what has not.  Also don’t forget that not all versions of the same product will be evaluated.  It can be an expensive process so vendors may only have major new versions evaluated.

So next time when a vendor (sorry guys) tells you "this product is rated EAL something", you may want to ask for the relevant certification report and Security Target and have a good read, but still better than nothing.


Mark H - Shearwater



0 comment(s)
Diary Archives