Security, Solution Architecture, Design Fundamentals - tying it together.

There are some things that need to be said about IT architecture - and by extension, security. There are some things I see are misplaced or otherwise forgotten, time and time again in IT architecture.

What I'd like to see in more solution architecture documents - and moreover, security attempting to bridge the gap and assisting solution architects out there:

1. Business problem - definition & solution: What problem does the solution architecture solve? What are the security threats at that level. How does security meet the business objective?
2. Requirements: Any restrictions that must be imposed on the design? Any constraints? Categorise them - Mandatory/Desirable/Discretionary. Based on threat modelling above, what are the security requirements? Are there any derived from existing policy? Also, how many of these requirements are set in stone? Too often people accept requirements as gospel without evaluating their foundation - without questioning them at all. You must pay attention here, especially when there requirements which have had drastic impacts on the design and imposing severe constraints. I once reviewed a design that had a very limiting requirement but sadly, nobody had defined the requirement clearly, nobody had questioned it with senior management to determine the extent of that limitation. The net result was a design rife with security holes and actually cost them hundreds of thousands of dollars more to implement due to increased hardware costs and software licensing - to say nothing of the cost of staff labour having to follow manual processes for what was trivial to automate.
3. Architectural Principles: Only a handful of places I've seen really provide good principles that are worth jotting down. TOGAF, Zachman (and by extension SABSA) have some foundational ones that we should evaluate as part of any solution. Simplicity is one principle I rarely see applied (I will get to that). There is a lot on offer from IT architecture frameworks and security consultants need to pay more attention here.
   
4. References: These don't necessarily have to be included within a Solution Architecture Design Document (SADD) but it helps to have done your research. Has the solution been attempted before? If so, what hurdles did they face? What lessons learned? Can the solution be copied? Are there any best practise guides out there on what the solution attempts to solve? It is rare that business problems we encounter haven't been dealt with before. The constraints or requirements are often the largest variable but the problems, in my experience, are often the same across different organisations, even different industries.
5. Keep It Simple Stupid (KISS principle): I draw this out separate to 3 because it needs to be called out. Security should be simple. The solution should be elegant. It should address the problem in one clean stroke. If you cannot find a simple solution to the problem, chances are you're doing it wrong.

This last point is the most important IMHO. Complexity is the bane of good security and most solutions are far too complex or at best, introduce elements of unnecessary complexity.

By looking to reduce complexity where we can, find simple solutions, you not only enhance the overall security of the design, you can potentially reveal substantial cost savings as well as find new respect with architects by providing a different viewpoint that they might not have considered previously.

These are just some of my thoughts that run through my head as I'm reviewing solution architecture. Hope this gives you all a little more food for thought.

- J.