Beyond the STIG: What does “security leadership” really mean?

In the world of product security and compliance, there’s no shortage of leadership, at least on the surface. But “leadership” doesn’t necessarily mean the same thing across individuals, companies or industries. Practically, what traits should a leader in IT security exhibit? What should they be doing…or not doing? And why do these specific actions matter?

Just like the nature of leadership itself, there isn’t an objective answer here. Red Hat (and I personally) have been deeply involved with software and systems security for decades, which puts us in a good position to explain what security leadership means in our eyes. Unsurprisingly, given the open source nature of Red Hat, I feel that you can’t be confident in a claim of security leadership without participation as a starting point.

A security leader helps raise the tide

“A rising tide lifts all ships” is how the saying goes, and this couldn’t be more true in the world of software security, especially in open source. It’s rare that a bug or exploit in a foundational technology, like the Linux kernel, or a change in compliance (i.e. STIG) requirements will only affect a small set of vendors. This makes it vital that security leaders actually get their hands dirty and participate in finding, fixing and analyzing these issues.

Just like you can’t call yourself a leader in an open source community that you’ve never actually contributed to, the same can be said for security. If an organization simply talks academically about how to fix a challenge or the need for a specific standard, but does little to actually get the work done, that’s not leadership. Talking is great to start, but then things have to make it to paper and eventually to a standard with, where necessary, accompany code, rules and guidance (i.e. CSAF or CVSS) - leaders make this happen and don’t wait for others to pick up the pen or the keyboard first.

Leaders are also open to sharing their expertise. Red Hat recently open sourced its product security’s incident response team (PSIRT) plan (IRP), being one of the first organizations to do so. Enhancing the security of our products is a critical need for us, but the model itself has even greater value to the broader security community. We wanted to show our framework to more organizations involved in IT security, as we believe it can only help improve the overall stance of the industry at large.

This participation showcases another characteristic that I feel security leaders need to bring to the table - a commitment to commonality.

Security leaders break silos

Bespoke processes and tooling are the enemies of modern IT, causing divides in operational teams and fragmenting systems into tiers rather than holistic entities. The same is true on the product security front - too much fragmentation and not enough commonality leads to white noise and, potentially, greater risk of vulnerabilities being exploited.

Red Hat has been heavily involved with many industry-wide efforts aimed at delivering common standards that provide actual information, not just “more data.” From CSAF and CVE to CVSS and FIRST, we’ve actively helped to create, maintain and evolve standards that function at scale and across industries. The only way to maintain a strong security posture at scale is with standardized approaches - this means that whenever a bug or exploit is discovered, organizations should be able to talk with all of their vendors in the same language.

No end user organization is ever using a single vendor but when a vulnerability lands, customers want all of their vendors to reach out to them with answers. Because the technology and threat landscapes are dynamic, this means that these standards cannot remain static.

It also means that security leaders cannot settle.

Security leaders don’t idle

Even when security leaders aren’t leading, they should be working behind the scenes. This could be informal leadership within specific working groups or helping an organization leading a project to actually get things done. They also keep an eye on emerging trends in IT security, including from where the next set of customer needs or pain-points may emerge.

For example, right now, the software supply chain has taken center stage in how we as an industry deliver greater security, validation and provenance to the code that eventually underpins systems in production. To address this need, various industry groups have coalesced around the software bill of materials (SBOM), which aims to provide assurance on where code is derived, who accessed it and if it has been modified. 

The various product and IT security leaders involved in this effort, of which Red Hat is one, are exploring how existing work can fit the needs of SBOMs or Vulnerability Exploitability eXchange (VEX). Essentially, these leaders are looking into how what’s being done on CSAF, vulnerability exchanges and more can apply to an emerging area. This is IT security leadership in practice in the real world, solving challenges that have only begun to emerge.

In my eyes, this is what security leadership looks like - it’s cross-industry and cross-functional participation, finding ways to create common standards and never standing still. This is what Red Hat has long done in the open source world and what we’ve expanded to encompass in open source security.

In our next post in this series, we’ll talk about the value of security data and how to use it.