When security architecture fails
Nov 16th, 2008 by Jesper Kråkhede
I often get one specific question when I am out work shopping, is doing a speech or in any other way get in the cross hair of the public: What is Security Architecture?. Still to this day I cannot give a good answer due to the following:
Security is only a quality property of any functional or non functional requirement.
So the answer always starts with: It depends… as any other architect most probably recognise as a default answer. It gets really interesting when I am approached with the question: Why did our security architecture fail?
The most common problem when a security architecture fails (the definition of fails is currently: cost to much, opens up vulnerabilities, inflexible, [insert possible flaw here]) is often due to the lack of a holistic view on security. You could have a great architecture with SOA, compliance, Identity and other components making you Buzzword-compliant but still lack a simple thing as making sure you have a secure coding process, patch management, internal audit process or stuff like that.
When doing a security architecture start out by doing the functional architecture and after that take into account the security aspects of all your components. Use ISO-2700X, PCI DSS or Jericho Style Security as a reference model to make sure you do not miss anything and do not forget to do a risk analysis. If you have no risk you have no need for security. Just relying on a best practise will get you into trouble sooner or later.
No! Do your security architecture _alongside_ the functional architecture (ok, you might mean that but the point is a crucial one). To succeed with “adding security” I believe you truly have to discuss the security requirements in the same sentences that you discuss the business functionality with your customer.
There will always be time to go back and over all the sec requirements later to create coherency and fill in the gaping holes.
cheers,
Peter.
You are correct that security architecture should be created along side with the functional architecture. Often though the functional architecture is somewhat crippled by perceived security requirements. Perceived in that sense that some kind of “Best Practice” or “Common Use” is used to handle security instead of actually looking into what has to be protected, what the risks are and what could be done if you think of security in another way. So in the best of worlds, handle security directly, and in this world bring in the security architect after the first iteration. In the end, security is there to protect and serve but in some cases it actually opens up new opportunities.