Shifting Security More Left
The idea of DevSecOps has existed for some time, where engineers are expected to incorporate security concerns at the time of development so it is not a concern layered in after the fact. We called this “shifting left,” and I don’t think we’re shifting left far enough.
Security is a product-level concern. It should be discussed in product ideation, and included in product epics and user stories as a first class citizen. We should not have epics that say “Redeem Airline Miles,” and assume that everyone knows that the user experience should implicitly be secure. Instead, our epics should be named “Securely Redeem Airline Miles.”
From there security should flow through every element of the product design and implementation. Conceptual architecture should include security concerns, such as identity. Physical architecture should include security concerns, such as encryption and certificate management. Deployment architecture should include container scanning in registries and while running in production. And, of course, our software should be written with security in mind.
A few years ago, I had the good fortune of working with a security expert as we built out a “DevSecOps” approach to software and cloud platform. As part of “shifting left,” we had our developers take OWASP training and study the specifications of PCI DSS and SOC2. That worked to some extent, but we still felt that there was more we could be doing to shift this left. They suggested that we have our engineers perform a CAIQ on our software.
The CAIQ (Consensus Assessment Initiative Questionnaire) identifies what security controls have been implemented in a platform or ISV product. The security expert suggested that we treat our application the way a vendor should, by performing it on ourselves. They noted that any IaaS/PaaS/SaaS ISV who wanted to sell us a product should have filled out a CAIQ, and that it was a sign of a good one if they even knew what it was and had answers ready to provide to us. By doing this to ourselves, we could self-identify what controls we had met and hold ourselves to a similar standard.
I have been thinking about this ever since. It’s not only a good idea for software teams to perform the CAIQ, but for everyone involved in the SDLC to be aware of the concepts of the questionnaire, and as a product exercise, identify which controls are in scope for your implementation. Doing this at the outset of software development shifts security all the way to the left and makes it a core concept of what you build. The current version (v4) has 261 yes/no questions, but there is also a “Lite” version with only 71 questions, covering areas such as Business Continuity, Change Control, GRC, Infra and Virtualization Security, Supply Chain, and more. The CAIQ maps to the following security standards: ISO/IEC 27001/27002/27017/27018, CCM V3.0.1, AICPA TSC (2017), CIS Controls V8, NIST 800–53r5, PCI DSSv3.2.1, and ISF SOGP 2022. You can freely download the Lite version after you create an account.
We need to shift more left. Use tools like the CAIQ to enable your team and help you do so throughout your SDLC. Review the LITE version with your team, including product owners, business analysts, architects, engineers, testers, DevOps, SREs, everyone. Discuss product specifications and architectural artifacts and see where gaps may exist. Shift more left by making this review part of the earlier phases of product development from there.
