Could not agree more with this tweet from Dino Dai Zovi
Finding the balance between productivity and security is very difficult. In the context of a rapid fire development project its even more so. Threat models are the best available option to establish an analytical framework and tradeoff scenarios. If I were stranded on a desert island and could only bring two AppSec tools I would bring a threat model and fuzzer (of course a machete and Swedish firesteel might be better). The infosec industry exists in enterprises that use agile methods and threat models work well - quick, dirty and cheap. Agile is a project by project world, but we face some risks that are not project specific.
Marinus van Aswegen sent me a message about a Security Architecture Blueprint that I worked on some years ago. Marinus said basically there's so many perspectives on this problem domain with so little progress on the ground. I have to agree on that.
When I put together the Security architecture blueprint, I thought it was addressing a vital missing link in Infosec (not my work per se but something, anything to fill that space). Namely, security is of strategic value, but infosec teams do not take a strategic approach to addressing it. This was written around ten years back and the first part has, for sure proved true, every corporate board and C level exec gets that security is an important issue. Unfortunately, the second issue persists, companies take a project by project approach to security.This mismatch of strategic problem to a patchwork of tactical solutions has led to predictable results.
When I put together the Security Architecture Blueprint, I had it reviewed by three of the best security archs that I know - Brian Snow and James McGovern. I thought - this will be great, I can do this work, which I really like and is super useful and every company needs it, I can do this for the next 5-10 years.
So then I put it out, people said some nice things, but nothing really happened, no projects at all. I kept doing security architecture work, but mainly project by project, and backing into strategy instead of building a strategy. It seemed crazy to me then that any big platform at Google, Amazon, or your favorite bank, has a CTO or someone with a technical vision and leadership that you use to build a platform toward, but security is in the business of incremental fixes. in addition, security's job is harder than building a platform.
My thought when I wrote it was that security is of strategic value, but most people do not take a strategic approach to security. The excuse used to be we didn't have money or authority, but that is not true any more. Instead we have the perils of incrementalism.
its true tat software is built using project by project, spike by spike, Agile methods, but infosec is not required to play these rules exclusively. We can and should do more with threat models in agile.
The goal of the threat model is not for security geeks to get our yee-has out. The output of the threat model is a set of controls - the what and the where. You build a range of options, but each control is not equal. Second and third level thinking is vital - the hard questions are which controls? Developers use agile and we must participate fully here, but security is not required to use agile exclusively, as the only option. This is a case where we can use security's separateness to our advantage. To think longer term,
Many security controls do not show value if used on a single project, think SSO, Federation, Virtual Directory, AM and on and on. They only show real value once scaled out. This is a really important point though since you won't uncover these solution in a strictly agile view. Instead you can get everyone writing their own access control frameworks. Double loss since they will likely do it poorly and on top of that you have way more to review and test. Thinking longer term, involves thinking more like Civil War General, Nathan Bedford Forrest (one of two authentic geniuses in that war) "Get there first with the most men."
The only way to deliver better security in agile is to be targeted and quick.Threat models help with the targeting and can be tuned to deliver quickly. But if what you want is a more cohesive approach, better access control protocols and more consistency, you can get there from here strictly with agile and threat models. The threat model output has to be oriented towards getting better integration with security frameworks, and those security frameworks have to exist so they can be plugged in in the two week spikes that agile teams operate on. You have to anticipate the needs a prior and build out the lego blocks to be snapped in. Security architecture blueprints help to frame up what these frameworks are, where they integrate, what users and platforms they serve, and how best to distribute and integrate them, Nothing fancy here, in short the same mantra any other product owner has, but that's the point we should think of our security capabiities not as individual, standalone capabilities but rather a security product where coverage, integration and adoption matter first and foremost. It does not matter a whit if we can "build" a trusted, standalone, tamperproof, compartmented workstation if it only ever exists on a blackboard. It mattes what we can ship and integrate.
We need to build the roadmaps to get us there.
Two postscripts, a few years after writing the Security Architecture Blueprint I got a call from someone I never heard of at a company I never worked for and they said "I need a Security Arch Blueprint, when can you start?" It ended up being one of my favorite people to work with and a long, successful and interesting project. So I am both optimistic and pessimistic. I have seen and wroked with a number of organizations taking more strategic approaches. There are some people out there that get it, but for the industry as a whole it feels like we're dragging it kicking and screaming into doing works that's valuable.
Lastly, I did do some work on the Open Group Enterprise Security architecture which is another attempt that may be useful for some organizations.