Infosec metrics that your bosses will love

The speakers begin with why security needs quantified metrics. Without numbers, security is often seen as a cost center, while trends over time can justify headcount and budget. They list measures a security organization can report, including vulnerability age and remediation rates, patch currency, cloud exposure, endpoint agent coverage, incident timelines and phishing results. Their starting point was a manual monthly process: someone gathered data from several tools and Jira, aggregated it in a spreadsheet and answered follow-up questions. The result was stale, hard to scale and not tailored to different audiences.

The middle of the talk covers requirements gathered from executives, engineering managers and product managers, who each needed different detail and did not want another tool to log into. The team added standard Jira fields for vulnerability source, category and business unit, since label-based queries were inconsistent. A Python job collected and normalized ticket data, calculated SLA status and wrote it to a Google Sheet that fed Google Data Studio. Three dashboards followed: a leadership overview, a view for the security team by source and category, and a detailed team view. These were embedded in the internal wiki, with edit rights limited to the security team.

The speakers say executives found the dashboards useful for identifying which business units needed attention, and some engineering teams built their own views from the data. They note limitations, such as a sync problem that sometimes required a manual refresh. Next steps include bringing in data from other security teams and building a risk scorecard per product. The talk closes with sample templates and dummy data shared publicly.