In today’s ever-connected technological landscape, cyber security is operating in an environment of unpredictability, accelerated technology change, and threat complexity. All too often, cyber responses are based on cumbersome, slower methodologies that miss critical elements to successfully respond to cyber security threats. Cybersecurity programs are driven primarily by a “Castle Model” of defense – focused on building walls (firewalls) and raising the drawbridge (limiting any access in). Many organizations build vast compliance checklists that itemize obvious “doors that must be locked.” Though useful, these checklists can produce some level of security and some illusion of completeness of security, particularly when small changes are made to the application or system that aren’t covered. The focus of cyber security culture is reporting on the checklist, not looking ahead to emerging threats or truly understanding what the security profile of the application is. The cyber security culture must be resilient enough to work with a flexible, intelligent strategy to counter the inevitably turbulent environment. To respond to these new cyber threats, our cyber security programs must begin to adopt agile in the same way many of our software development organizations have already done. They can start by:
1) Adopt more rapid feedback and delivery cycles
One of the most obvious benefits of agile for product owners and developers alike is more rapid feedback and delivery cycles. This allows product owners to change and adapt to user needs more rapidly. Spending months on a security assessment that gets completed once every two years does not allow our organizations to adapt to our threats. Cybersecurity teams need to change their process from waterfall to agile. Break down your tasks into more manageable stories, then adopt a scrum or kanban approach to managing your backlog.
2) Continuously evolve your threat/risk models
Threat models can’t be a one-and-done deal. Our threats and attackers are currently learning and evolving. When we build our threat models in a waterfall model we often complete a threat model and rarely ever return to it. That kind of process ensures we only think about security when we initially start the project and rarely think about it ever again. By evolving the threat model every sprint (when we talk about new functionality), our model will adapt to our changing application and new threats while staying constantly on the mind of our development team.
3) Rapidly reassess the organization’s cyber security infrastructure for effectiveness and ability to adapt
It’s not enough to just change our process, we have to change how we monitor and respond to findings in an agile world. As developers deliver more frequently, we have to be able to assess the changes faster. Integrating security into our DevOps pipelines is the quick answer, but we may also have to look at how we change staff capacity to adapt to our changing world and task orders.
4) Break down barriers between security and software development
It’s time to end the “us and them” mentality of security v. software development. Agile encourages open communication and for teams to work together with stakeholders. Security engineers should be a part of the agile planning process so that they can suggest changes that make the application more secure and so they have a greater idea of how things are being implemented and can build trust in the development teams.
5) Continually address security threats through cyber policy changes and upgrades of strategies, staff, processes and technology using a risk-based security model
Being able to adapt to change is critical. Creating working policies, strategies, processes and technologies is only successful if they’re adopted. Many organizations spend months creating massive policies, but once the business or technologies change they become resistant in order to avoid large rework. Address things in a risk-based model and don’t try to over-engineer your security initiatives.
