Security is a Journey

Having so many conversations with engineering security teams across the globe from companies of all shapes and sizes, patterns and similarities begin to emerge and there is one particular trend that threads through most of these companies.

They are all looking to go through what I term the “security transition”.

Put simply, this is a move away from the traditional methodology of ‘doing security’ in an organization, which is typically an exercise conducted at the end of the development process, just before systems or applications go live into production (reactive). Another feature of the traditional method is that it tends to be human labour intensive, which is notoriously difficult to scale and do at speed.

This approach has become untenable. The motivations precipitating the call to Continuum are very often expressed to me in this manner. Security teams are creaking under the weight of the ‘industrialization’ of development and operational departments. The move towards tooling to speed up the process of these endeavors, continuous integration, continuous deployment, and infrastructure-as-a-service, has accelerated to the point at which security can no longer keep up.

This is a painful place for security teams to find themselves and invariably they look for solutions. Security practitioners are wary – or more accurately weary – of hearing of the next silver-bullet that will solve these woes and shun buzz-words, but are more often than not perceptive and driven enough to know a potential solution when they see one.

And it’s in this spirit I often get to speak with them as they are in their quest exploring what “shift Left” and “continuous security” actually means in a practical, realistic sense. I too detest “silver-bullet” marketing and the use of ‘buzz’ to create the impression the effortless elixir to soothe all that ails you is no further away than another security tool purchase.

And I too was on this same quest not so long ago. The silver-bullet bubble had burst long ago for me and the desire for the ‘next great thing’ was pierced by the realization that something more fundamental was needed to address these problems in security.

I realized that for security to integrate with modern development and operational teams we needed to follow suit and also industrialize with continuous security through automation.

That emphasis on continuous security rather than an end-of-development activity is at the heart of the “shift-left” movement which has become for me – and many of those I talk with – more than a buzz-word, but a real, tangible solution to a very hard problem.

The underlying premise of “shift-left” may be encapsulated as defining security requirements at the same time planners are designing functional requirements, and from there continuing to gather security requirements at various points during the development phase. These same security requirements need to be implemented and tested in the same fashion – continuously (Proactive).

And one of the most powerful mechanisms at our disposal to walk this path is by leveraging threat modeling beginning at the planning and design phase and updating the model throughout the design phase. But I’m not talking about manual threat modeling, I’m talking about automated. Manual threat modeling will give us those security requirements but fails with the problem of being labour intensive and slow and rapid release cycles leave little room for this. Also, this activity may not aid us to implement and test the security requirements we discover.

In Continuous security as in DevOps, manual approaches should be the exception, not the rule, and the same goes for threat modeling. I’m fortunate. I found the tooling I needed to automate threat modeling and bake it into pipeline. And I get to demonstrate the same to other security professionals and it is wonderful to see the ‘light bulb’ go off in their minds as it did for me when I show them IriusRisk. Although this blog post is about the wider journey to continuous security and not about IriusRisk specifically, I’ll not talk further about it here, but will paste an image at the bottom showing the threat modeling tooling integration I speak of.

Continuous security has been described as a three phase approach: defining, implementing and testing security controls, and I think this is the nub. This has been coined as “Test Driven Security”(¹) which is apt. And the key to this is tooling.

I want to be clear, I am not suggesting manual security approaches are void, but as stated above, it should be the exception rather than the rule as we automate and industrialize as much as possible. There will always be a place for the manual approach, but this must be reserved for those types of problems for which the human mind can really bring value and not on those repetitive baseline security tasks that automation through technology can handle in a superior way.

However, tooling alone is not enough, there needs to be a concurrent culture change in security, operations and development to make this work as effectively as possible. Exploring fundamental culture change is for another day, but it is almost as important as getting the right tooling in my opinion.

And none of this happens overnight. It is a long haul and sometimes a painful and frustrating journey, but security practitioners are robust folk and many of us know this has the potential to bring security into the heart of the product strategy of the organization, rather than as an appendage.

Sign up to our community version and start threat modeling today! If you would like to see a full demo of IriusRisk you can download our Secure Design Webinar for free, or alternatively, if you would like to talk to our team for a custom demo of IriusRisk get in touch.

‍