Why Adaptive Security Orchestration Is the Best Strategy for CISOs

Sep 01 2016

Why Adaptive Security Orchestration Is the Best Strategy for CISOs

In our continuing quest at CYBRIC to make the “DevSecOps” culture a reality, and, more importantly, start enabling companies to first understand their true risk posture and then greatly increase their security resiliency, I’m going to outline how we think about Adaptive Security Orchestration as part of our Continuous Security Delivery Fabric.

Adaptive vs. Rigid

With the increased adoption of Public, Private and Hybrid Clouds, security solutions now need to be adaptive to the environment, elastic for scale and API-first for automation. Existing tools and processes are typically standalone and manual, requiring security engineers to utilize them and then attempt to correlate the disparate results, which is often an error-prone exercise. These manual efforts also tend to add a fair amount of latency to an organization’s CI/CD pipeline, slowing down the feature release cycle and often creating a contentious relationship between the DevOps and Security teams. Many of the existing security testing processes are extremely rigid and must be performed in a static environment with a pre-defined schedule. That approach is analogous to the Waterfall approach in software development versus the Agile methodology that Enterprises are now adopting — security practices need to catch up to this adaptive, agile flow.

Mythical Man Month

CISOs often try to take a “scale-out” approach by attempting to hire more Security Engineers to resolve this problem, but that really isn’t feasible given either budget constraints or the severe workforce shortage. It has also been shown, and documented, that adding engineers does not typically help. Team Productivity ChartThe other historical problem is that security reviews, tests, and scans have always been performed at the end of the software development lifecycle and often times after code updates have been deployed to the Production environment.

Shift Left

Shift-Left Testing is an approach to software testing where tests are performed earlier in the process pipeline (i.e. further to the “left”). We need to take this same approach with respect to code and application security. W. Edwards Deming also makes some applicable points in his “The Fourteen Points for the Transformation of Management,” including “Break down barriers between departments,” which is part of the cultural transformation to bring the Security team into the DevOps workflow. Security testing such as static code analysis, application vulnerability scanning and penetration tests need to be shifted left inline with the CI/CD process. Security should be a fluid, functional participant, not an “after-the-fact outsider.”

MTTR meet IRD/IRR

Security Posture/Resiliency is often measured by the MTTR (Mean Time To Recover) metric, but we at CYBRIC are thinking about this in different terms — IRD (Internal Rate of Detection) and IRR (Internal Rate of Remediation).We don’t want DevSecOps teams spending time on recovering from incidents, but instead automating the vulnerability detection and remediation processes before an issue is deployed to production. By enabling CISOs with these quantifiable metrics, they can now articulate the company’s true risk profile and level of resiliency. Board Members now have a fiduciary responsibility for cyber risk and CISOs need to be able to present them with factual metrics and supporting data.

Going Forward

Arrow going through wallIt is still early days with respect to DevOps adoption and the transformation of software development and delivery processes to Agile and Continuous methodologies. We believe that now is the time for CISOs to implement a strategy around Adaptive Security Orchestration and Automation. This is why we are developing our Continuous Security Delivery Fabric and leading the charge in Gartner’s SOAR Magic Quadrant.




  • Share: