What does a “Security Leader” actually mean beyond the STIG?

When it comes to product security and compliance, there appear to be plenty of leaders. However, the definition of “leadership” can vary depending on the person, organization, or industry. In practical terms, what characteristics should an IT security leader possess? What actions should they take, and what should they avoid doing? And, most importantly, why are these actions significant?

Similar to the concept of leadership, there is no clear-cut answer to this question. Red Hat, with its extensive experience in software and system security, is well-suited to share our perspective on what it means to be a security leader. As an open-source organization, they believe that true security leadership requires active participation. Therefore, it should come as no surprise that we believe participation is an essential starting point for any claim of security leadership.

A security leader helps raise the tide

The saying “a rising tide lifts all ships” holds particular relevance in the realm of software security, particularly in open source. When a foundational technology, such as the Linux kernel, experiences a bug or exploit, or there is a change in compliance requirements, like STIG, it is unlikely to impact only a handful of vendors. Therefore, it is crucial for security leaders to engage in finding, addressing, and analyzing these problems actively. In other words, getting directly involved is essential.

Just as it is not appropriate to label oneself as a leader in an open-source community without having contributed to it, the same applies to security. If an organization only discusses how to address a particular challenge or the need for a specific standard but does not take any action to accomplish the work, it cannot be considered leadership. While discussions are a good starting point, the next step is to document the ideas and convert them into a standard that includes codes, rules, and guidance (e.g., CSAF or CVSS). Leaders take charge of this process and do not wait for others to take the initiative to write it down.

However, leaders are willing to share their knowledge and experience with others. For example, Red Hat recently made its Product Security Incident Response Team (PSIRT) plan, or IRP, open source, making it one of the first organizations to do so. While improving the security of their products is a priority for them, they recognize that the model has even more significant value to the wider security community. RedHat helps to demonstrate its framework to more IT security organizations, as they believe it can contribute to improving the overall security posture of the industry.

By engaging in active participation, security leaders demonstrate another essential trait they must possess – a dedication to establishing common ground.

Security leaders break silos

Customized processes and tools hinder modern IT, creating divisions among operational teams and breaking systems into disconnected parts instead of integrated entities. This applies to product security as well – excessive fragmentation and a lack of commonality can result in an excess of white noise and, potentially, a higher risk of security vulnerabilities being exploited.

Red Hat has been significantly engaged in numerous industry-wide initiatives aimed at developing common standards that provide valuable information, rather than simply generating “more data.” We have actively contributed to the development, maintenance, and evolution of standards such as CSAF, CVE, CVSS, and FIRST, which function effectively across various industries and at scale. To sustain a robust security posture at scale, standardized approaches are necessary. This means that when a bug or exploit is identified, organizations must be able to communicate with all of their vendors using the same terminology.

End-user organizations seldom rely on a single vendor. When a vulnerability is discovered, customers expect all of their vendors to provide them with information. Since the technology and threat landscapes are constantly evolving, these standards cannot remain static. Therefore, security leaders cannot afford to be complacent.

Security leaders don’t idle

Even when security leaders are not in a formal leadership position, they should work behind the scenes. They may provide informal guidance to specific working groups or assist an organization in leading a project to achieve its objectives. Additionally, they monitor emerging trends in IT security, identifying the source of future customer needs or pain points.

At present, the software supply chain is at the forefront of efforts to enhance security, validation, and provenance for the code that ultimately supports systems in production. In response to this need, several industry groups have rallied around the software bill of materials (SBOM), which seeks to provide assurance about the code’s origins, who accessed it, and whether it was altered.

The IT security leaders involved in the SBOM effort, including Red Hat, are exploring how existing work can be adapted to the needs of SBOMs or Vulnerability Exploitability eXchange (VEX). They are examining how the work being done on CSAF, vulnerability exchanges, and other areas can be applied to this emerging field. This is a prime example of IT security leadership in action, addressing emerging challenges that are just beginning to surface.

In this opinion, this is a prime example of security leadership – participating across different industries and functions to develop common standards while continuously moving forward. Red Hat has been implementing this approach in the realm of open source for a while now and has extended it to include open-source security.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com