Agile security and risk management are possible. This post is the third of three covering agile security challenges, opportunities, and good practices. It also discusses the taxonomy and instrumentation required to operationalize an agile risk management framework down to the agile team level.
Security Architects Partners has built an agile risk management framework for a global technology company and instrumented it for their agile teams (or “squads”). We have advised a major financial services company on building security into their emerging agile, devops, and microservices environments. Along the way, we’ve captured many good practices and lessons learned in the slideshare embedded above, which we presented at the UNCC Cybersecurity Symposium just last week.
Agile Security Opportunities
In Is Agile Security an Oxymoron? we found that some developers may be using the agile methodology as an excuse to have no process at all. Per Crisp’s blog, there’s good agile and bad agile (slide 6). What Crisp missed is that good agile needs more than a “rough adaptive architecture”, it needs specifications up to date enough and detailed enough to support production code maintenance down the road. The industry is accumulating a huge technical debt from “bad agile” – but that’s another problem. Our main concern for this post is the disconnect between “waterfall security departments” and agile development teams or even (in some cases) non-development teams using agile for all corporate projects.
One way to close this disconnect is to change the way security works to engage more effectively with “good agile” projects. Fortunately, the solution is relatively obvious. One of the critical tenets of agile is to give small cross-functional teams end to end responsibility for the product. Therein lies a huge opportunity: The squads can assume more responsibility for security!
DevSecOps Also Spells Opportunity
DevOps teams are moving forward with continuous integration / continuous deployment or delivery (CICD) models enabling rapid release of capability or changes to production. When the “D” in CICD stands for “delivery,” there is a manual step before new workloads or microservices actually go live. But when the “D” stands for the “deployment”, orchestration is automatic. Completely automated deployment could eliminate the separation of duty (SOD) that once existed to provide a check on vulnerable applications or configurations getting into production. This too can give the security department fits.
But what if, in the automated CICD deployment model, we also included steps at each point in the process as shown in the figure below from slide 11?
SOD could still exist at a higher level by being built into how the CICD process works, how it is lifecycle-managed, and how it is monitored. DevOps also brings intrinsic advantages absent in conventional operations: Namely, privileged administrators don’t need to “remote in” frequently for production support. In the new model, most or all changes or fixes are orchestrated rather than manually applied. As an added bonus, frequent refreshing of production images reduces malware dwell time in the event of compromise.
Instrumentation is Key for Risk Management Too
Our Risk Management in the Agile Environment post describes a risk management (RM) framework we built for a client that uses the agile delivery method for most of its projects, including many far outside development. Key to operationalizing their framework was building instrumentation and tools to enable end-to-end-accountable squads to “do” at least part of the process all by themselves.
First, we created a tailored RM taxonomy for the client which describes exactly how squads should estimate asset risk, issue severity, and the likelihood or impact of risks materializing. We then designed the following instrumentation, procedures, and tools for trained risk advisers at the squad level:
- Risk profile (of assets)
- Issue-to-risk triage (of issues, such as vulnerabilities, third party deficiencies, and more)
- Lightweight risk assessment of issues that could not be fixed within the remediation window required for the asset risk profile / issue severity
The goal of risk profiling, triage, and lightweight assessments is to filter medium-to-high risks out of the noise and escalate them to security specialists. Will the squads always do a perfect filtering job? No. But with the right data capture and analytics, mistakes can be detected and risk advisers can be trained on the job to continuously improve.
For the medium-to-high risks, we also designed focused risk assessment tools for security specialists:
- Threat class heat map
- Threat actor library
- Control effectiveness assessment method
- Control library
- Risk advisory memos
- Strategic risk register
Conclusion
How’s this for a radical idea? Embrace agile security because the change is good. We should have had more integrated security, development, and operations processes all along! Also, contact us and learn just how to build risk-informed operational risk management into the agile process, while escalating strategic risk management to the pros.
The post How to Build Security and Risk Management into Agile Environments appeared first on Security Architects Partners.