We’ve moved our critical apps to a mix of AWS and Azure. My old KRIs—like "number of missing patches"—don't seem to capture the dynamic nature of cloud misconfigurations. What "Key Risk Indicators" are you all using to report to the Board about our cloud security posture without overwhelming them with technical logs?
3 answers
For the Board, you need to shift from "Technical Vulnerabilities" to "Compliance Gaps" and "Exposure Time." In mid-2024, I implemented a KRI called "Mean Time to Remediate (MTTR) High-Severity Misconfigurations." If this number goes up, it indicates a lack of automation or staff expertise. Another good one is "Percentage of Cloud Assets with Inactive Logging." These KRIs are easy for non-technical leaders to understand—they show how long a "door" was left open rather than describing the "lock" in detail.
How are you differentiating between "Risk Indicators" and "Performance Indicators" (KPIs)? Sometimes teams report on "Uptime" as a KRI, but that’s really a KPI. A KRI should be a "leading" indicator that predicts a future problem.
Focus on "Identity." In the cloud, "Identity" is the new perimeter. Tracking the "Percentage of Users with Over-Privileged Access" is a high-value KRI for any modern GRC report.
Absolutely, Dorothy. Least Privilege is the ultimate risk mitigation in Domain 4. If the KRI for over-privileged accounts is high, the risk of a lateral movement attack is also high.
Michael, that's a classic CRISC trap! I was reporting on "number of security alerts," but that’s a lagging indicator of an event that already happened. Nancy, I love the "Exposure Time" idea. It’s a perfect leading indicator because it shows the opportunity for a threat to be realized. I’m going to start tracking the time between a new S3 bucket creation and its first automated security scan. That tells the Board exactly how well our "Governance" controls are actually functioning in real-time.