By Jarrod Loidl.

At present, I am reading “Enterprise Security Architecture: A Business-Driven Approach“, in anticipation of sitting the SABSA Foundation course. Based on the title and many people’s view the content, it isn’t the most thrilling read. While this book is certainly not perfect, I actually am enjoying it at the moment, but I think that’s because I have begun to appreciate the beauty of good architecture. To explain;

In my previous role, (and to a lesser extent current role), I reviewed a lot of solution architecture designs. I really got a buzz reviewing and helping to build a given solution and make it as secure and robust as possible.

In was during this time I really developed an appreciation for architecture as a distinct discipline in its own right. I got to work alongside many IT architects of various backgrounds and capabilities. I attended Architecture Forums where the roadmaps were presented to the CIO. What was interesting was seeing how many of the technical decisions either directly benefited through cost saving, business enablement or supported future company growth and expansion. Growing up in IT, I had often heard how IT exists to support the business. This was truly my first experience seeing the truest extent in which IT could enable the enterprise.

It is also what made me truly realise that many security professionals lack an architectural focus in what we do. Now this is not something limited to our profession is alone. There are plenty of people passing themselves off as “architects” when in fact they are really “designers”. This happens in construction all the time.

It seems intuitive to both “designers” and “architects” that “form follows function”. But what is the distinction between the two? There are application security architectures, infrastructure security architectures, heck once you start getting into SABSA, there is a model for policy security architecture! So what are all these different architectures? What do they mean? Are they just ‘fluff’? Or is there something more?

It is these questions which have lead me to exploring security architecture and design frameworks in an effort to broaden my own horizons and try and find the answers to these questions. When I first begun reviewing solution architecture, what I found was that there was not a lot of methodology to make sure that each review was consistent – with the exception being the application security space. This was incredibly frustrating to me.

Threat modelling helps but as Dr. Peter Gutman pointed out at KiwiCon in 2009, (and I learned on my own long before then), it didn’t fulfil my needs: http://www.cs.auckland.ac.nz/%7Epgut001/pubs/threat_modelling.pdf. I am convinced that security architecture is an area of very low maturity. However it is evolving and evolving fast. What follows is my own opinion, and likewise, this too is evolving.

Simply put, security architecture involves looking at all of the functions – from a business and IT perspective – how they inter-relate and define controls to directly support/enable those functions while preventing or reducing risks. To my thinking, the difference between architecture and design is that many practitioners focus solely on technical controls without regard for the supporting business functions. While the necessity in understanding technical constraints is imperative, such controls cannot exist in isolation. Such an approach can inhibit key business goals.

A security “designer” will nearly push for the purest technical solution, often with blatant disregard for cost, business drivers or needs. They have tunnel vision. They can only see the singular technical solution which directly prevents the problem. This view is systemic throughout IT mind you, but more common in security I find, because many of us (myself included) come from the perspective of a penetration tester. As any pen tester will tell you, when a control gap exists, the solution is obvious. However the context from a business viewpoint is not. And sometimes that ‘obvious’ solution may have unintended consequences. However, that is the difference in form that an “architect” sees and a “designer” does not.

For example, two-factor authentication might sound great for an authentication process to an Internet banking website and sure, it arguably aligns in a ‘best practice’ sense. However, if you raise the technical barrier to entry on your clients, (e.g. technical ability to remember their pin, own a mobile phone, not lose their token) or even the system, (e.g. SMS server to be fully redundant and not available), then this can inhibit key business drivers, (e.g. clients find the whole thing “too difficult”) – by directly impacting the end user experience. Instead, an approach you might take might be to enable some form of “step-up” authorisation which requires two factor authentication prior to accessing key functions (view/update personal information, payment details, etc). In fact, this same approach is already in use by some of these sites.

Taking the above example, an architect might readily determine that using two factor authentication for at logon could be highly annoying to end users. If someone wants to just quickly check their balance, having to fumble with a token is most decidedly a barrier to entry. But if a compromised account cannot change or view personal information, alter payee information, direct debits, etc, then precisely what is the risk beyond the risk of information leakage in determining an account holder’s balance? Is this a risk the business is willing to carry in order to lower the barrier to entry? That’s an easy enough question to put to the business.

While there is a purity that cannot be denied in the pursuit of technical knowledge, that knowledge is only useful to an architect that is able to possess agile, (no pun intended) thinking, which allows them to look at all the business requirements as a whole and view their technical knowledge as a toolbox in which they can reach in to find the right tool for the right job.

Architecture frameworks are simply methods by which you can help you to build and develop your deliverables and ask yourself at each phase “did I cover everything?” These frameworks certainly are not technical because the creators assume you are already carrying the toolbox! By definition, an architect must be a designer, but the reverse doesn’t hold true. In many cases, an architect will draw upon the skill of a designer who might be considered a domain specialists to help brainstorm ideas to some of these problems. But a designer may have an architectural spark within them that just simply hasn’t been cultivated.

Mark Curphey once said “we need more builders http://securitybuddha.com/2008/09/10/are-you-a-builder-or-a-breaker“. This really resonated with me. Not enough people appreciate the beauty that exists in good architecture or the skills required in using their security skills to solve business challenges. Now if you read the above example and were already thinking of different ways you could secure the business transactions, (with or without two factor authentication), then maybe there is more of an architect in you than you think?

If so, maybe it is time for you to step up? After all, the world needs more people like you.

- J.

Jarrod Loidl has recently made the jump to consulting as a Technical Security Consultant for Dimension Data. Prior to that, he worked at Sensis as the security lead within the Trading Post brand. He has an strong background working within enterprise environments, having worked with University of Melbourne and Monash University as a security analyst and before that at various Internet Service Providers both within Australia and the United States. He has a particular interest is security architecture both at the solution and enterpise level. More from Jarrod Loidl at his blog: http://jarrodloidl.blogspot.com/

———————————————————————————————-
Securus Global: IT Security, Penetration Testing, Security Assessments, PCI Compliance, Product Assurance, QualysGuard, Security Strategy, Vulnerability Assessment.