Some field notes based on a conversation with Adam Shostack. There are a lot of things that make security architecture a tough business. One of the ones that comes up regularly is that security is a system level property, but yet we live in a project based world. Its not really the mandate of any one project to overhaul IDM or software security tooling. I like bottom up approaches, most of the time they are the right way to go, however they do not work for everything and incremental improvement is hard when it comes to delivering security services.
So what to do? One approach is to do a mix of bottom up and top down. First build a simple top down basic security profile for security services that lists the capabilities like authentication, authorization, defensive programming, and the like. Then grade the different ways your organization delivers the capabilities, according to strength, good better best, crawl walk run, and establish some sort of progression.
So for example if we take authentication:
w/ Soft token
w/ hard token
The set of capabilities is really around formalizing the services that your security architecture delivers to the developers and operational team. It takes a little time to build up your profile of what good-better-best crawl-walk-run means, and then a fair amount of time to go bottom up through all the teams, alligator wrestle your inventory down to all the categories, authN, authZ and so on.
But then once you have it, its like having your investment portfolio all in one place. You look across your investments and say, hey I need less bonds as a percent or I need more dividends or I need more international exposure.
With the security portfolio, you can look across your profiles and see what would it take to get to better or best or walk or run in app scanning or IDM or SIEM or what have you and find good opportunities.
Its pretty helpful to lay out the systems side by side in an objective way and then figure out where to dial things up or not. Like assessing your own portfolio, there is no one right answer, but having a basic framework in place let's you rationally manage your decision set.
Finance has some good simple rules. One that comes to mind is Jack Bogle's rule for retirees, you should own your age as a percent in bonds, 70 year old should be 70% in bonds (good luck with that today's interest rates, btw, but moving on...), its not perfect, you can argue about the details but its directionally correct. (Note - I will withhold the identity of the person who suggested - oh yeah 50% firewalls, 50% SSL)
Building out the security profiles helps you see things in a different light. You might, for example, see that "hey my web exposed transactional system that does 50% of my business really has almost the same security capability set as most everything else", maybe that is where to spend time and security resources. The framework is qualitative, but once the profiles are set, objective rules can fill in the matrix and give you useful objective information for how to manage the set of security capabilities in the enterprise.