Gene Spafford, the eminent professor of computer science at Purdue University, once remarked, “The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards – and even then I have my doubts.”
Perhaps we can take some small comfort in knowing that Prof. Spafford, one of the world’s most prominent security experts, harbors many of the same doubts that most of us experience in our careers as security professionals.
That said, we cannot shirk or evade our responsibilities as security leaders, no matter how many doubts we have. The risks are real, and too much is at stake.
Despite our common purpose, our leadership goals are diverse. They vary by situation, and are defined by the operational context of our company’s industry sector, size, organizational structure, growth rate, security budget, technology stack, organizational culture, and other criteria. Each situation embodies unique characteristics and presents unique challenges. And yet each situation also presents unique opportunities that we can leverage to overcome the challenges we face.
For example, a company’s product development and software security postures are influenced by external and internal business drivers. Within each situation there are different maturity states of the security program, depending on what initiatives have been implemented, which ones are facing headwinds and which ones will garner organization-wide support both vertically and horizontally. For each leader, the starting point may be different.
In this chapter, we offer a framework of broad categories to describe the different situations and corresponding characteristics of people, processes and technology. We describe the unique challenges and opportunities that manifest under such situations. We then present durable security imperatives that can take the reader from a zero state to a practical solution.
Organizational Change Begins with You
We all wish to provide the best possible security. That is why we are here, on this page, reading the contents of The Purple Book. We want to prepare ourselves and our teams to achieve aspirational and audacious goals by learning new technologies and policy frameworks, acquiring training and certifications, expanding our project management skills, hiring and nurturing the best available talent, and continually elevating our leadership abilities.
Yet security is and has always been an organizational discipline. Hence, our ability to influence a strong security culture as a shared responsibility across the company is a critical aspect of our program. Ultimately, the success of the security strategy depends significantly on the cooperation of many players and multiple teams.
At the time of this writing, it is not unusual or uncommon for company leaders to feel a deep sense of uneasiness about the state of their security. As a security leader, your role is laying the foundation for a culture that embodies strong security practices and behaviors. That is a formidable task, as Professor Spafford’s quote implies. But it is a necessary and imperative task; it is a duty we must embrace.
Your Purpose is a Source of Power
You have experienced this elsewhere: teams or companies achieving remarkable results in response to a rallying cry by the leadership team. The magic formula for making progress on security goals is simple: connect security goals to business drivers.
External drivers (e.g., compliance certification or penetration testing required by a large potential customer) can be very effective for getting quick alignment both horizontally and vertically across the organization. Internal drivers must be created by working horizontally across functional boundaries and establishing rapport between critical organizations (e.g., engineering, infrastructure and security).
Compliance Certification Drives Shorter Sales Cycles
We all know that compliance is not equal to security and that security is not equal to compliance. But compliance can be a valuable tool for attaining your security goals. Common cyber security regulatory frameworks and compliance standards (e.g., ISO 27001, NIST CSF, FFIEC handbook, etc.) require an effective software development lifecycle and release management controls.
The Cloud Security Alliance [1] reports that most common attack vectors are rendered ineffective when product security and vulnerability management are undertaken during the DevOps lifecycle. In short, implementing compliance frameworks in concert with development efforts can lead to a better security posture.
Encouraging Shared Responsibility and Joint Goals
Quite often CEOs and product organizations are focused on reducing customer friction. But now, consumers are taking a stand on how their accounts and data are being secured and their data privacy protected. It does not have to be a choice.
Instead, leaders should foster customer centricity by enabling a shared vision, ownership and transparency across product, user experience, design, engineering, infrastructure and security organizations. In other words, everyone needs to know they’re playing for the same side and striving to achieve the same goals.
Developers should be empowered to experiment and to identify risks early in the development lifecycle. The organization should be set up to prioritize both security and product quality, linking both to customer satisfaction. Team members should be trained to balance user experience with risk mitigation.
Contribute Rather Than ‘Consult’
Compared to other functions within the organization, which are often fervently and actively engaged in moving the business to bigger and bolder milestones, security teams can seem like passive observers or gatekeepers of best practices.
At some organizations, the security team runs bootcamps and helps new employees learn best practices and avoid security risks. But for the most part, security teams are perceived as “fault finders.” Think of our security certifications, penetration tests and audits -- our goals are uncovering deviations from best practices, quantifying risks and prioritizing tasks for other teams to perform.
This is understandable. But security teams also should strive to be the champions of inclusion and collaboration. It is worth noting that inclusion and collaboration are two-way streets. If you wanted be included, you must first be inclusive. Go out of your way to include other teams and players (e.g., product, design, development, QA) in your processes and activities. The same holds true for collaboration: if you want people to collaborate with you, then you must demonstrate that you are open to collaboration and all that it entails.
It is time for security organizations to become more than consultative and to engage actively with the rest of the company through meaningful participation. The sections below describe how a security team can become more active and engaged across the company.
Participate
Many security leaders often argue that they are never “in the know” and that they are not informed of code changes, new features, new services or changes that would change the risk score for the product and the company. But a passive stance, combined with a negative attitude, can increase the sense of alienation. The best tack is leaning in and participating in everything that is happening around the company -- from sprint planning, road mapping, engineering incident responses and other product building rituals.
The goal of such participation is to develop a deeper understanding of why certain products exist, what kind of “build vs. buy” decisions are being made and how those decisions could impact the security posture. Most important, the goal is achieving a better understanding of customer perspectives and company goals.
Contribute
The next step in taking an active role in the company is to participate in building technology and workflow automations. Hire software developers on the security team, create shared libraries and integrate product workflows in a self-service manner. Instead of security developers just taking on the role of consultants or advisors to a black box product, have them check in code to the main branch. Collaboration will enhance the reputation of the security team, internally and externally!
Measure, Then Manage
How does your company go from 0 to 1? Where do you peg your 0 and what would 1 feel like? Figure out a capability maturity model that applies, and apply it to your company’s stage, given the several choices on what suits best: OWASP SAMM, BSIMM, Microsoft SDL and several tools to measure them, such as OWASP ASVS.
- Organization metrics vs. industry standards
- Security SLAs by application, by division
- Known risks by application, by division
- Vulnerabilities that resulted in security incidents
- Attacks (even if failed attempts) by application, by division
- Cost to business per security incident
- Mean time to remediate by application, by division
- Vulnerabilities by vulnerability type
- Security controls in place by application category and data classification
- SDLC phase that identifies most vulnerabilities
Managing Your Spheres of Influence
Large organizations commonly operate with many business units, merge with and acquire other organizations, have a variety of cultures interwoven into the fabric of their employees and operations, and commonly struggle with serving customers while continuing to scale. Small organizations, on the other hand, are laser-focused on survival and may have only a handful of folks dedicated to security.
Ideally, the head of security or the Chief Information Security Officer (CISO) should report to the CEO directly. Sometimes, however, large organizations choose to embed security capabilities into other functions that have the responsibility of ensuring security through a distributed model. In those cases, the CEO carries the ultimate responsibility of ensuring effective security across the entire entity.
With business units as part of the larger organization, the CISO may also need an extensive network of leaders and an extension staff to ensure that security is making its way into the business. In the business units, the leaders are likely to be peers of the CISO and their security staff are direct reports that serve the business unit first as an embedded Business Information Security Officer (BISO).
The BISO is responsible for understanding what the CISO requires and ensuring that they assess and work within their businesses to achieve a high-quality level of security, while the CISO is responsible across the larger organization. In this construction, the BISO solid line reports to the business unit, with a dotted-line report to the CISO.
In a well-run large organization, governance is a major responsibility for the CISO to ensure that the organization operates in compliance with regulations and standards that govern the level of security required by the industry. Governance is commonly established by a dedicated governance, risk and compliance group within the CISO’s organization. Further, the CISO must have a program management capability to run central standards and may choose to invest in a dedicated program management office to support multiple business unit engagements.
If enterprise architecture is a strong driver within the software organization, the CISO will also require a security architect to ensure that the appropriate representatives are available to work within the dedicated software groups. The CISO will also have other major capabilities such as security services, security incident management, security testing, threat intelligence and training. Within these service offerings and capabilities, the CISO is responsible for identifying and managing the larger organization’s adversaries and ensuring that its defenses are effective.
Head of Security Hierarchy
There is an age-old discussion among security practitioners that the ability of the security organization to achieve progress is proportional to the placement of the role of head of security. Does the head of security report directly to the CEO and the company Board, or to a director or vice president? In reality the hierarchy does not matter. Ensuring that the leadership in the company cares about security and takes actions that reflect their intent matters more than the position of the security leadership on the vertical chain of hierarchy.
In spite of all the efforts, there will be conflicts. The team charters and OKRs are all built using stretch goals to an extent that there is hardly any room left for cross-functional concerns.
Summary and Takeaways
We encourage security leaders to create expectations and demonstrate the purposeful behaviors driving towards a culture that embodies strong security technologies and processes.
Step 1: is to connect security goals to business drivers. External drivers (e.g., compliance certification, penetration testing required by a big potential customer, etc.) are very effective for quickly getting alignment both horizontally and vertically across the organization.
Step 2: is to effectuate a paradigm shift in how the security team takes an active role in the company. Instead of being merely an enabler or “guard rail,” it is far better to be an active participant in helping the company achieve its strategic goals and greater purpose. Consider the security team as an indispensable component of the company’s larger strategy. Resist the urge to become a passive observer when everyone else in the company is fervently and actively engaged in moving the business to bigger and bolder milestones.
Step 3: is to establish a baseline for creating achievable but challenging security ambitions for the company and making small but effective changes towards those goals.
Step 4: is to set up the security leadership and empower the team to exert cooperative influence, as opposed to authoritative influence in the company, with the goals being to build secure products and to protect data and privacy, all within an overarching business framework.
.svg)
.svg)
