What should you do with the SaaS products that your organization had to purchase without Single Sign-On (SSO)? And to get this out of the way: Vendors that lock SSO behind enterprise-only plans do a disservice to their customers. No wonder the US government’s Secure by Design Pledge expects vendors to offer SSO in baseline product versions.

But this article isn’t complaining about SSO-taxing vendors–it’s more pragmatic than that. Let’s start with the role that SSO plays in modern defense architecture, and then cover how to implement similar security measures without such a centralized mechanism.

Controlled Entry Points as Defense Tactics

First, why is SSO so important to security and IT professionals? It acts as a chokepoint. Defenders have historically used choke points to control attackers. Numerous examples include:

• Battle of Thermopylae (480 BCE): A small Greek force defended the narrow Thermopylae pass against the much larger Persian army. The location allowed the Greeks to inflict significant losses.
• Battle of Stirling Bridge (1297): The Scots positioned themselves near the narrow Stirling Bridge, which allowed them to overwhelm the English forces as they crossed the bridge in small groups.
• Battle of Morgarten (1315): The Swiss Confederates ambushed the Austrian forces in a narrow pass between a lake and the mountains. The advantageous terrain allowed the Swiss to achieve a decisive victory.

Just as historical defenders leveraged choke points to concentrate their resources and control the flow of attackers, SSO centralizes authentication, creating a single, controlled entry point for accessing multiple systems.

SSO as a Control Funnel

Centralizing authentication through an SSO provider allows efficient enforcement of security measures, account management, access monitoring, and attack surface reduction:

• Enforce security measures: Enable multi-factor authentication (MFA) to help prevent attacks such as those that affected Snowflake customers in May 2024. Control which authentication factors are available, enforce password complexity, configure session duration, and manage credential resets.
• Manage user accounts: Automate user provisioning and deprovisioning via SSO-provided SCIM capabilities. Automatically assign roles according to personnel needs. Gain visibility into product utilization for licensing requirements.
• Monitor access: Use the SSO provider’s anomaly detection to flag suspicious login attempts, such as those that occur from unexpected locations or malicious infrastructure. Direct logs to a centralized location (SIEM) for analysis, correlation, and forensics.
• Reduce the attack surface: Expose a single, fortified login mechanism provided by the SSO vendor, reducing reliance on individual SaaS vendors' security practices.

These benefits don’t apply to the SaaS products onboarded without standards-based SSO, putting defenders at a significant disadvantage.

Compensating for the Lack of SSO

To define baseline SSO expectations organizations should:

1. Formally require SSO (and SCIM) for all SaaS purchases.
2. Communicate that policy to internal purchasers and vendors.
3. Educate purchasers to negotiate SSO capabilities when buying and renewing products.
4. Create a process for approving exceptions when SSO is unavailable. 

When granting an exception to buy an SaaS product without SSO support, organizations must compensate for the loss of security measures by assigning responsibilities may be assigned to IT, cybersecurity teams, or business units. Define expectations for:

• User account settings: Acceptable 2FA factors, password requirements, session duration expectations, etc.
• Provisioning and Deprovisioning: Steps for creating user accounts with the right privileges and disabling the accounts when employees leave or no longer need the product.
• Security Monitoring: Detecting attacks and configuration weaknesses, reviewing in-app security logs, or directing events to the organization’s SIEM.
• Centralized Oversight: Determining whether the appropriate security responsibilities for securing the product are being followed.

Organizations should recognize that they take on these burdens when purchasing SaaS products without SSO. If they cannot commit to these security measures, they accept the increased risk that the SaaS product will be compromised or look for an alternative product that offers SSO.

The absence of SSO in SaaS products poses significant security challenges. Organizations can tackle them by enforcing SSO policies, negotiating for SSO capabilities, and implementing compensating security measures. By taking these steps, you can maintain robust security even without centralized access control, ensuring your SaaS environment remains secure and manageable.

The notion that cybersecurity defenders are at an inherent disadvantage—the so-called defender's dilemma—is incorrect and counterproductive. Instead of focusing solely on how we respond to attackers’ tactics, we can identify and use the advantages inherent in our position as defenders. This article explains what a defender-oriented mindset entails and how it can help you strengthen your security program.

What’s the Defender’s Dilemma?

For many years, security professionals have used the “defender’s dilemma” to claim that we are at a disadvantage when protecting enterprises from cyberattacks. It goes something like this:

“The defenders are at a disadvantage because we must be right all the time, but the attacker needs to be right just once.”

According to this perspective, defenders need to spread our attention across all possible attack paths and protect against all of them. We must make difficult choices regarding which attack paths to focus on (this is the dilemma), which puts us at a disadvantage. Our disadvantage is also, presumably, due to the need to respond to every attack on all fronts, which means we will sometimes miss an attack.

The notion of the defender’s dilemma is not only demoralizing but also incorrect. Defenders can gain an advantage over the attackers. Let’s explore this.

The Folly of the Defender’s Dilemma

The defender’s dilemma is folly in part because it oversimplifies the complexity of cyberattacks. Consider the MITRE ATT&CK framework, which illustrates the multi-step process attackers must follow to achieve their objectives. According to ATT&CK, attackers typically start with Reconnaissance, progress to Resource Development, then Initial Access, and from there must still push past several additional stages to achieve their objective.

The attacker must complete each stage successfully to fulfill their mission. It’s sufficient for the defender to interfere with just one step in that chain to foil the attack, requiring the attacker to adjust tactics. Industry veteran Richard Bejtlich observed this back in 2009 in the context of intrusion detection, coining the term “the intruder’s dilemma.” He pointed out:

“Defender only needs to detect one of the indicators of the intruder’s presence in order to initiate incident response within the enterprise.”

David J. Bianco, another respected cybersecurity professional, expanded on this idea in 2023 and proposed the term “the attacker’s dilemma.” In addition to pointing out that “attackers have to get everything right throughout the entire attack lifecycle,” he noted that:

“Attackers usually operate with imperfect knowledge of their environment.”

Our inherent strength–the defender’s advantage–is our ability to develop a better understanding of our environment than the attackers. With some foresight and planning, we can create a security architecture that changes how we engage with attackers. 

Gaining the Defender’s Advantage

The defender’s dilemma assumes that defenders are waiting for attacks to happen and then respond. This reactive stance allows attackers to define the terms of engagement and puts the defenders in the position of always playing catchup. Seeking to change such dynamics, industry analysts are highlighting the need for defenders to practice “proactive security.” Eric Parizo from Omdia uses this term to encourage enterprises to:

“Seek out and mitigate likely threats and threat conditions before they pose a danger to the extended IT environment.”

According to Forrester’s Erik Nost, practicing proactive security means controlling security posture and reducing breaches through strong visibility, prioritization, and remediation. This process begins with a solid understanding of our environment so we know the resources to protect and the security weaknesses to address.

Knowledge of the terrain is not exclusive to cybersecurity; the concept applies to attackers and defenders on a variety of fields, including the battlefield itself throughout history. For example, during the Battle of Agincourt in 1450, the English positioned themselves in a narrow field flanked by woods, funneling the French knights into a confined space. By narrowing the front, the English army defeated a much larger French force.

Much like the Battle of Agincourt, creating a choke point in cybersecurity defenses, as historical defenders have done, is one way to establish the defender’s advantage. For instance, funneling SaaS logins through a Single Sign-On (SSO) provider allows organizations to apply reliable security measures such as 2FA and anomaly detection. SSO forces attackers to pursue SaaS targets through a choke point controlled by the defenders, putting them at a disadvantage.

More broadly, to gain the defender’s advantage, we should:

1. Understand our environment: Maintain a continuously updated inventory of all assets, including hardware, software, SaaS platforms, and user accounts. Understand the business purpose of each resource. This foundational step allows us to know exactly what needs protection and where potential security improvements might be.
2. Minimize the attack surface: Regularly patch vulnerable software, turn off unneeded systems, disable or decommission unneeded services, and enforce SSO to reduce entry points. These actions collectively reduce the number of potential attack vectors.
3. Prioritize remediation by considering the context: Assess the risk of each vulnerability based on system criticality, business processes, and sensitivity. Focus on addressing the most significant risks first. This targeted approach ensures that resources are allocated effectively to address the highest priority areas.
4. Remediate in a measured way: Develop and execute a remediation plan, making changes in a controlled and practical way. Monitor the progress and effectiveness of remediation efforts, using metrics to track improvements and intervene if needed. This ensures that the security improvement projects achieve the expected outcomes.

To gain the defender’s advantage, start by thoroughly knowing your environment, which allows you to identify and mitigate weaknesses, deploy automated response measures, and design an architecture that funnels attacks to well-fortified aspects of your environment. Minimize attack path opportunities by reducing the attack surface and prioritizing security improvement opportunities. Oversee remediation efforts to ensure progress. Turn the attacker’s advantage on its head by shifting from a reactive to a proactive mindset.

Organizing events that gather cybersecurity leaders requires significant effort and sponsorships. Unfortunately, some events and communities exclude CISOs who work for security vendors. This stance, though well-meaning, harms the industry and allows hidden conflicts of interest to go unchecked. Here's why and how we can address this issue to improve such events and the community at large.

CISOs of All Types

Industry veteran Andrew Hay once posted a tongue-in-cheek "CISO hierarchy of industry respect." At the top were security leaders of Fortune 500 companies. Further down were CISOs at financial services or insurance firms. Lower, the CISOs at hardware vendors. Closer to the bottom were the CISOs working for a cybersecurity vendor; hi, that's me!

The respect hierarchy was meant as a joke, and CISOs took it as such. It was funny because there was something truthful about it. Some executives command more respect among their peers than others. CISOs who work at large organizations have to deal with more complexities and command larger budgets than those who work for smaller firms. Yet, no matter the type or size of the organization, CISOs are dealing with many challenges and have much to contribute to the community.

Sponsorship of CISO Events

Hosting events incurs costs for the venue, food, and organizer salaries. Typically, these costs are covered by vendor sponsorships, which allow vendors to present, advertise, and otherwise expand their brand equity.

Therefore, CISO gatherings sometimes include designated sessions where the sponsors discuss their commercial products. Sometimes, the organizers ask the sponsors to present "thought leadership" content that doesn't overtly pitch products. For such presentations, the organizers often require that the speaker not be in sales or marketing. If the vendor has a CISO, that person is often a good candidate.

When well-orchestrated, this approach to covering event costs benefits all stakeholders: the organizers, attendees, and vendors.

Excluding Security Vendors' CISOs from Events

Some events restrict CISOs from security vendors to only attend sessions sponsored by their employer. In doing this, the organizers aim to:

• Maintain a revenue source whereby the only way for security vendors to access attendees is through sponsorship.
• Allow open discussions about security vendors without their representatives.
• Ensure that the attendees are practicing CISOs, not sales or marketing people with "CISO" in their titles.

These are reasonable objectives; however, banning security vendors' CISOs from events is a poor way of achieving them.

This jackhammer, all-or-nothing approach creates the appearance of an environment that facilitates an unbridled exchange of ideas and opinions. Yet it doesn't address overt conflicts of interest and vendor relationships of attendees who might:

• Be affiliated with security vendors as investors or advisers, which is not unusual for CISOs.
• Work for non-security vendors that offer products or services to the event's attendees.
• Be non-practitioners even if they have "CISO" in the title without working for a security vendor.

When events ban CISOs of cybersecurity vendors but allow the possible issues above unchecked, they merely create the appearance of establishing an environment free of vendors' involvement or other undesirable interference.

Moreover, all of us who work for commercial companies are somebody's vendors. And we want our vendors to have strong security programs with knowledgeable leaders. We often want to meet these leaders, establish relationships with them, and perhaps even learn from them. By failing to create an environment that allows CISOs of all organizations, even security vendors, to participate, organizers get in the way of our industry's growth.

How to Organize Events for All CISOs

There is another way. Many CISO communities successfully include all types of security leaders. How do they facilitate fruitful discussions while allowing security vendors' CISOs, such as me, to participate? They enforce transparent rules of conduct, which require attendees to:

• Avoid selling or promoting their employer's products outside designated forums.
• Disclose conflicts of interest or abstain from related discussions.
• Exit discussions if their presence causes discomfort due to conflicts of interest.
• Engage respectfully and professionally, acknowledging diverse opinions and affiliations.

Establishing these rules requires intentionality, but it is possible and effective. I've seen it create thriving communities that benefit all stakeholders and advance our industry. If you're a CISO attending a security event, ask whether security vendors' CISOs are allowed to participate in the entire event. If not, encourage organizers to adopt these rules or refer them to this article.

Creating an informative and readable report is among the many challenges of responding to cybersecurity incidents. A good report not only answers its reader's questions but also instills confidence in the response and enables the organization to learn from the incident. This blog highlights my advice on writing such incident reports. It's based on the presentation I delivered at the RSA Conference, which offers more details and is available to you on YouTube.

What Do Incident Report Readers Want to Know

Though you probably have your own objective for the incident report, write it with your readers in mind, addressing the questions they want the report to answer in a way that's easy to absorb. In general, people want to know the following about a cybersecurity incident:

• What happened and when? Include the date, time, and affected resources.
• What was the root cause? Explain what caused the incident and how you know this.
• What was and remains to be done? Detail the steps taken and what remains to be done.
• What lessons can be learned? Highlight opportunities for improvement.

Each of these high-level questions conceals other questions--too many to list in this blog post. For more details, see the Report Template for Incident Response, which I created with input from colleagues. This template not only helps you capture the right information in the report but also provides a convenient way for structuring it so the readers can easily find the details they need.

To demonstrate how you can use the template, I created a simplistic report based on a fictional cybersecurity incident. Download it and take a look.

Sometimes, your reports might be as brief as this example. Sometimes, depending on the expectations of your readers, they'll be longer and offer more details.

Key Elements of Writing

Having the right information in the report is important, but that's not the only consideration for good writing. As I discuss in the short course I teach at SANS on this topic, good writing incorporates all five of the elements below:

• Information: Ensure your report contains all the necessary details your readers need to understand the incident.
• Tone: Maintain a professional yet approachable tone. Avoid blaming individuals or teams; focus on the situation and how it can be improved.
• Words: Use clear and concise language. Avoid jargon unless your audience is familiar with it.
• Structure: Organize your report to make it easy to read and navigate. Use headings, lists, and whitespace effectively.
• Look: Ensure your report looks inviting. A well-formatted report is more likely to be read and taken seriously.

When you combine these elements, your writing benefits your readers and lets you shine as the author of valuable content.

Additional Considerations for Good Reports

Watch the video of my presentation on this topic to discover additional details, including the following key considerations for good reports:

• Effective incident response reports require empathy with readers' needs and expectations.
• Succinct writing demands extra effort but significantly enhances communication effectiveness.
• Incident reports should balance technical details with business impact explanations.
• Templates and checklists are invaluable tools for maintaining clarity under stress.
• The tone of a report can influence cooperation and perception within an organization.
• Structuring reports with key takeaways first respects readers' time and attention.
• The visual appeal of reports affects reader engagement and willingness to read.
• Lessons learned sections should be actionable, assigning responsibilities and timelines.

Learning Resources for Better Cybersecurity Writing

Here are more free resources I created to help people improve their cybersecurity writing skills:

• How to Write a Strong Executive Summary (blog post)
• Security Assessment Report as a Critique (blog post)
• Tips for Creating a Strong Cybersecurity Assessment Report (cheat sheet)
• Writing Tips for IT Professionals (cheat sheet)
• Top 10 Cybersecurity Writing Mistakes (video)
• Writing Effective Threat Reports (video)

Wherever you are in your professional journey, it helps to peek into another's career story to learn from their approach, mistakes, and triumphs. In the following three videos, I reflect on my career so far to share my story, hoping that others in the industry will find it useful. Perhaps you'll glean from these short episodes the insights that will help you chart your own path in cybersecurity.

Episode 1: Foundation

In the first episode, I discuss the challenges and opportunities of starting as an outsider--an immigrant from the former Soviet Union. I pursued a degree in computer science and was inspired to enter the cybersecurity field after deploying my first firewall. Watch the video to learn how understanding and embracing your background can provide a solid foundation for your professional journey. Lean into your own strengths and don't worry as much about your weaknesses.

Some takeaways. They sound generic but make more sense in the context of the video:

• Identifying your strengths early offers a starting point for a career.
• A strong educational foundation offers flexibility for future career paths.
• Cybersecurity is an interdisciplinary field requiring diverse knowledge.
• To succeed, be curious about topics even outside of your direct interests.

Episode 2: Adaptation

In the second episode, I share the unusual path I followed to my current role as a CISO, having undertaken a variety of positions in cybersecurity. System administration, network security, penetration testing, professional services, product management... It's been quite a journey! Watch the video to understand the significance of flexibility in your professional path, the need to be open to opportunities, and the requirement to continue learning. I also discuss an approach to staying sane and energized in intense work environments and share a recipe for an unconventional ceviche.

Some takeaways. They sound generic but make more sense in the context of the video:

• Flexibility and openness to new opportunities are crucial in cybersecurity careers.
• Balancing work stress with personal hobbies is essential for mental well-being.
• Diverse career experiences can provide valuable skills for cybersecurity roles.
• Unconventional career paths can lead to rewarding professional destinations.

Episode 3: Growth

In the final episode, I explain how I started teaching at SANS Insitute and created REMnux as side projects to my primary professional pursuits. Watch the video to understand how to find yourself at the epicenter of the industry and maintain engagement over time. Interacting with others in the industry outside your professional bubble is one way to continue learning and finding growth opportunities. And sharing your knowledge with others offers a way to create meaningful human connections while giving you the mind space to move on to other topics worth conquering.

Some takeaways. They sound generic but make more sense in the context of the video:

• Continuous learning is crucial for staying engaged in cybersecurity.
• Sharing knowledge and tools helps you and others in the industry.
• Anticipating future needs helps you maintain professional relevance.
• Engaging with diverse professionals provides fresh perspectives.

Several years into your role as a security leader at a company, you’ll reach a point when you ask yourself, “What’s next for me?” This article discusses three ways to proceed if you choose to stay at your current organization. (It was co-authored by Yael Nagler and Lenny Zeltser.)

At this point in your CISO tenure, you know your way around the company, you’re familiar with the cadence and patterns of the organization, you know what’s expected, and you understand your trajectory.

Consider three paths available to you if you decide not to switch employers­­. Each path comes with the benefit of allowing you to pursue it in an environment where you already have the ‘map’ of how to navigate, execute, and succeed. You can:

1. Keep at it,
2. Slow it down, or
3. Accelerate.

There are different reasons and times to choose each of these options.  No matter which you choose, the most important thing is that you enter into it intentionally.

You Decide to Keep At It

Keeping at it means maintaining your current pace of execution and change. Since you’ve been doing this at the company for a while, you can do this with predictability and reduced cognitive load.

Why choose this:

Decide to keep at it if there’s more for you to get done. You’re excited about continuing to execute the existing plan, and your current approach is working and well received. You’re finding it fulfilling, and the company is supportive of the pace. You aren’t experiencing indicators that the company’s leadership is expecting or needing something more or different.

This is a good choice when the security team is past the forming and storming stages but could be in the norming and performing stages. On a personal level, you may be looking to reduce your work-cognitive load because of factors happening outside of work. Keeping on pace and on track with what you’ve already been doing provides that space.

What it looks like:

Well, more of the same. When you’ve chosen to keep at it, you don’t make big changes to the team structure, the scope of the department, or how it operates. You may find that you or your department are expanding into other company functions and interactions. Perhaps you’ll join another committee or be asked to participate in a cross-functional initiative.

Importantly, you’re doing it well. For example, as you think about your team, you may focus more energy on enabling your team. You’re doing this by increasing their learning opportunities and their cross-functional contribution and involvement.

A caution for CISOs who choose this route–be on the lookout for atrophy and stagnation. You may be at risk if it’s perceived that you or the program is not continuing to deliver the expected level of value.

You Decide to Slow It Down

Slowing it down means intentionally decreasing the pace and scale of security changes and throughput. Selecting this path should be intentional and appropriate for what the company needs at this stage. Importantly, the organization agrees. While slowing it down, shift your focus to succession planning or preventing change fatigue.

Why choose this:

A lot has happened already. Whether it’s a lot of change or other activity, you decide to slow it down. This can be a good option if your organization is experiencing change fatigue and needs time to absorb recent security program changes before you introduce more. Alternatively, you may consider this option for the health of the current team, for example, if the team needs a recovery period after a significant year-long project.

Another reason to consider slowing it down is if you think you’ll leave the company in the next 18 months. Slowing it down allows you to put effort into succession planning to set up your team and the organization for success.

What it looks like:

If you slow it down, you’ll make incremental rather than major changes to the security program. This frees up time for you to work on documentation, reflect on achievements, and focus on professional development or community engagement.

However, when you slow it down, avoid complacency and the perception of being checked out. Set goals and metrics so you remain valuable and continue to fulfill your responsibilities for the organization. Resist the gentle pull of mediocrity.

You Decide to Accelerate

Accelerating means increasing the pace or impact of security initiatives. This may include taking on higher-risk, higher-reward projects or perhaps revisiting previously failed or off-limits initiatives. Perhaps most excitingly, deciding to accelerate may include taking on things you’ve never done before but are now trusted to explore and pursue.

Why choose this:

With several years in the role, you likely have substantial influence and trust. This capital–which you wouldn’t have upon entering a new organization (if you decided to leave)–provides a safety net and permits taking on larger initiatives not feasible earlier.

Deciding to accelerate is exciting, but it’s also higher-risk (for you individually as well as for the company). Before pursuing this option, consider how much organizational support you already have. Timing is equally important as is determining whether this is the right thing for the company based on its business objectives. Don’t accelerate solely because you have the energy if your team or other stakeholders aren’t ready.

What it looks like:

If you’re accelerating, pursue complex, high-impact projects aligned to business goals. Expand into new areas. Pursue passion projects in the context of work projects. Encourage your team to have a growth mindset and share knowledge through conferences, open-source releases, or other community collaborations.

As a caution, when choosing to accelerate, beware of burnout in yourself and others. Define the timeframes, desired outcomes, and success metrics upfront. Accelerating exhilarates, but this mode of operating is unsustainable into perpetuity.

Where Do You Go From Here?

Now you know about the 3 options for security leaders who decide to stay at the organization when they reach an inflection point in their tenure. Recognize when you’ve reached an inflection point in your security leadership tenure. Then, assess your situation to decide how and where to direct your energy for the next phase of your professional journey.

Reflect on your program, leadership, and company (this reflection guide may help) before deciding to keep at it, slow it down, or accelerate your pace. Recognize the unique opportunities of your tenure if you decide not to switch employers and leverage these powers purposefully to maximize impact.

Congratulations on arriving at the inflection point. What you do next is going to be great. How you feel about it will be based on when you decide to lean into it. As you plan your next steps, consider how these decisions may impact your strategy and priorities.

To dig into this topic further, consider watching the recording of a talk that we delivered at the RSA Conference, titled Whoa, You’ve Been the CISO for 3 Years at Your Firm—Now What?

The notion that security is everyone’s responsibility in computer systems dates back to at least the early 1980s when it was included in a US Navy training manual and hearings in the US House of Representatives. Behind the pithy slogan is the idea that every person in the organization contributes to its security program. Even if the company has employees with “security” in their title, they cannot safeguard information assets on their own. After all, people outside the security team are the ones who deliver services, build products, or otherwise engage in business activities that require making security-related decisions.

Can Everyone be Responsible?

How might we distribute cybersecurity tasks and operationalize the perhaps utopian idea that "security is everyone's responsibility"? After all, the diffusion of responsibility principle suggests that people feel less responsible when they are part of a group, possibly because they think someone else will take action.

Saying that security is “everyone’s responsibility” might lead to it being “nobody’s responsibility.” To distribute security responsibilities among the stakeholders, we need to counteract the diffusion of responsibility. We should clarify expectations, hold people accountable, and establish a personal connection between the stakeholders and the affected items.

Clarify Expectations

Cybersecurity leaders generally design and manage the security program, which is the structure within which the organization can achieve its security objectives. Within that program, teams with “security” in their name have responsibilities such as:

• Identifying and tracking the remediation of security vulnerabilities
• Engineering systems for enforcing security measures
• Monitoring and investigating security events
• Documenting secure configuration guidelines, templates, and practices
• Providing security guidance to business stakeholders
• Noticing when security expectations aren't followed

Who should be fixing vulnerabilities, incorporating security principles into projects, and deploying technology in a security-appropriate way? In most cases, these tasks are distributed throughout the organization. 

Members of specific teams are typically  assigned security responsibilities in the company’s security policies and procedures, which communicate expectations such as:

• DevOps or IT teams patch systems according to risk-based, agreed-upon timelines.
• Procurement or Legal teams incorporate security reviews of vendors according to a defined process and include necessary security requirements in contracts.
• People or HR teams screen new hires according to specific background check requirements.

For capturing expectations in great detail, we can use some form of a responsibility matrix, such as RACI, to capture who should be responsible, accountable, consulted, and informed for specific security-related activities. In addition to documenting expectations, the discussions that lead to creating a responsibility matrix can surface disagreements or coverage gaps so the organization has the opportunity to address them.

More broadly, organizations typically rely on the security awareness program to clarify which security responsibilities apply to all personnel, including items such as:

• Handling information according to the company’s guidelines and the organization’s approach to data classification
• Watching out for suspicious activities that might indicate a cybersecurity event or a scam and reporting them for investigation
• Using established templates, libraries, and standards that incorporate security requirements or guardrails when engaging in business activities
• Reaching out to the security team for guidance as appropriate, such as when launching new projects that require security or privacy considerations

Having clarified what members of the company’s cybersecurity program should do, we need to consider how to track whether these responsibilities are followed and, where practical, enforce the expectations.

Enforce Accountability

Even with the best intentions, those whose primary job isn’t cybersecurity will sometimes forget or not follow through on their security-related responsibilities. To increase the chances that the distributed security measures will be in effect, we can use a combination of three approaches:

• Enforce security expectations using technology to prevent insecure choices or actions. For example, security teams can configure user authentication to require two-factor authentication (2FA) instead of merely reminding employees to enable 2FA. In another example, software development tools can be set up to block code commits that include secrets or vulnerable dependencies. Such measures eliminate the opportunity for non-compliance; however, direct enforcement doesn’t work for all security controls and situations. For instance, some applications don’t allow the organization to centrally control 2FA settings.
• Implement guardrails against severe risks when people take actions or make decisions outside the boundaries the organization considers reasonable. For example, infrastructure-as-code tooling, such as Terraform, allows the creation of preapproved modules with minimum security requirements while letting engineers control other aspects of the infrastructure. Similarly, software developers might need to follow strict change control practices in production while having more leeway in dev environments. Another example of guardrails is the use of network security measures, such as DNS filtering, to restrict access to dangerous website categories.
• Monitor for gaps and take action when the right security steps aren’t taken. Observing security-related activities through log aggregation is a part of this. Another is continuous compliance monitoring, which aims to automate the tracking of security controls. For instance, to confirm that background checks occur, we can query HR and background-checking systems to detect missed employee screenings. Also, modern asset management approaches involve gathering data from multiple sources to identify gaps; for example, organizations can correlate data from systems management and endpoint security tools to identify systems with missing security agents. 

Of the many security controls, ensuring accountability for patch management is particularly challenging because this practice often distributes responsibilities across multiple teams. The software might be patched by DevOps, IT, developers, external vendors, and so on. It’s even possible to assign some patching responsibilities to end users as long as accountability is tracked. For example, people might be allowed to install approved applications that are not centrally managed by the IT team. In that case, the individuals should be keeping the apps up-to-date. Organizations can use automated tools to track when the apps are not maintained and contact end-users reminding them to take action (see a real-world example of this).

Make It Personal

We’ve been exploring ways of counteracting the diffusion of responsibility principle as we distribute security tasks. Communicating expectations and enforcing accountability is a part of the effort to ensure that people don’t ignore their responsibilities. Another way to fight the diffusion of responsibility is to establish a personal connection between the person and the task at hand. What does this mean in the context of cybersecurity?

People get accustomed to the systems they use at work. Many start to think of the company-supplied laptop as “their” laptop. To some extent, they consider the folders where they keep work documents as “their” folders and the applications they’ve customized as “their” apps. The security team can point to this attachment to highlight the person’s connection to such assets, so they’re more likely to remember their related security responsibilities. For example:

• When end users have patching responsibilities for their laptops, for instance, if they need to reboot the system or allow an update to be applied, remind people that these are their systems. Keeping the laptop in top shape allows them to do their best work.
• When people need to remember to include security in projects or design discussions, highlight the benefits of keeping their data secure, which they’re more likely to achieve when considering a security expert’s advice. Addressing security risks upfront will minimize the chances of a disruption to their project.
• When highlighting the need for colleagues to safeguard data shared with third parties, point out that their interactions might be compromised if they don’t follow the necessary security measures. Not only will the company look bad if the data is mishandled or misused, but so will they.

When sharing security responsibilities across stakeholders, also point to the shared business objectives that the organization’s personnel are looking to achieve. To be successful, colleagues should understand the organization’s business goals and how their security responsibilities can enable or hinder the company from reaching them. By framing security tasks in that context, you’re more likely to establish a security program that scales in a way that security will truly be everyone’s responsibility.

As the CISO at a tech company, my responsibilities include empowering our software engineering teams to maintain a strong security posture of our products. While everyone agrees that security is important, the different incentives of security and engineering teams can make it harder to collaborate. Here's some advice on weaving security into the software development cycle based on my experience as a security leader (now, at Axonius) and a product manager (prior to my current role).

Understand the Teams' Motivations

To collaborate with software teams, first understand their worldview. What motivates them? What incentives has the company defined for their work this quarter, this year, and for the longer term? What factors do they believe contribute to their professional success? Security teams need to frame our efforts in a way that works with these goals.

Product teams are primarily driven by business objectives such as shipping requested features, acquiring customers, and hitting revenue for the business. With these motivators, security can get deprioritized, especially when release deadlines loom. Contrast this mindset with that of security teams, which focus on reducing risk, ensuring compliance, responding to incidents, and earning customer trust.

Understanding the motivations of the engineering team will help security professionals maintain levelheadedness, for example, when they don't understand why their security concerns are not immediately addressed. And it'll make it easier to offer security guidance in the right way and at the right time.

Balance Each Other's Responsibilities

Because of the different roles and objectives, engineering and security teams often see the same goal from very different perspectives. That's good because this allows each team to balance each other.

For example, when supporting the expansion of the company's user base, engineering and product management teams might ask, "What new features should we develop to attract more users?" The security teams will wonder, "How will the new features expand our attack surface?"

Even though all teams' work ultimately supports the company's business objectives or mission, we play different roles. We should balance each other's efforts so that there is not too much security (which can slow down the business) and not too much careless engineering (which can expose the company to unacceptable levels of risk).

Apply Pressure While Being Supportive

So, the security team's focus on secure coding principles and risk mitigation should balance product and engineering teams' software and revenue goals. The security team can help the company balance these objectives by applying pressure on other teams. This involves highlighting practices that exceed risk tolerance thresholds, offering guidance, and holding the teams accountable for their security responsibilities.

To apply pressure in a constructive way, security professionals need to understand the world of product managers and software engineers. This means knowing their terminology but also reviewing the relevant roadmap plans and sprint details. This also involves being invited to and attending discussions where prioritization and architecture decisions are made.

Security teams are often in the position to identify or report vulnerabilities in homegrown code or third-party dependencies. Being supportive in this aspect of our practice involves spotting such issues as early in the development process as possible--the earlier we bring up the issue such as during code commit and build, the less costly or disruptive it is for the engineers to address it.

Applying security pressure often means prioritizing the vulnerabilities and influencing the engineering teams to address them in a timely way. This means being careful about not overwhelming developers with immaterial or inaccurate findings and ranking. When prioritizing such issues, we should take into account not only the vulnerability's severity--say based on the results of an automated scan--but also factors such as exploitability and business criticality. We should include in the analysis context and conduct a more nuanced risk analysis to know which security flaws should be prioritized for remediation over others.

We should recognize that the product's code base will always have some vulnerabilities and carry some level of risk. Be pragmatic in deciding what residual risk levels are acceptable. Work with devs to establish SLAs that allow them to ship on time while also fixing the highest-risk issues within a reasonable timeframe after release. Making incremental security gains over multiple release cycles is often more sustainable than aiming for perfection in every release.

Keep Learning About Securing Software Products

To hear more of my thoughts on securing products, watch the Seeding AppSec podcast episode that I recorded with Nir Valtman and Simon A. Wenet. The content of this post draws on our discussion:

Preparing for cybersecurity and data privacy incidents involves creating checklists and documented plans to enable the response team to do their best during the incident. Preparation also includes creating a template that the team can use as the basis for the incident report, which is critical to ensuring that the incident is handled well.

We created such an incident report template when we developed our incident response procedures at Axonius. I’m happy to share the public version of this template with the community in this blog post. Incident responders are welcome to use it to strengthen the way they collect, document, and communicate incident-related details.

The incident report template should be used by the incident response coordinator–the person in charge of the organization’s handling of the incident. It helps the coordinator ask the right questions of the people involved in the various response tasks.

The questions captured in this report template fall into these high-level categories in anticipation of what the report's readers expect to see:

• What happened and when?
• What was the root cause?
• What was and remains to be done?
• What lessons can be learned?
• What are the remaining action items?

The template captures the details related to these questions. It’s based on the report-writing guidelines I prepared for participants of my Cybersecurity Writing course.

Elisabetta Tiani added her expertise to allow the template to be used for both cybersecurity and privacy incidents. Daniel Trauner shared his insights to strengthen the template further.

You can download the template in the Microsoft Word (OOXML) format here. We’re distributing it under the Creative Commons v4 “Attribution” License so that organizations can adjust the template to their needs.

As companies seek to optimize operations and constrain expenses, cybersecurity leaders worry about funding the projects we consider essential. Fortunately, in such an economic climate, we can achieve an outcome that benefits the organization from cybersecurity as well as financial perspectives. Here’s how.

Start by critically reviewing how you’ll spend the security funds; this involves broadening your perspective beyond security. Next, partner with other departments to identify opportunities for them to save money in a way that also decreases the company’s attack surface. You’ll help reduce risk, cut costs, and build goodwill with your colleagues. This way of thinking about cybersecurity brings CISOs closer to the world of CIOs.

Understand the Business Context for Budgeting

Before you can scrutinize your expenses and advise others how they can review theirs, understand why cost reduction is necessary at this specific moment. Consider:

• What’s driving the need to cut budgets by specific amounts? Why that amount and not more or less?
• Are some departments or projects retaining or increasing their funding? If so, why them and not others?
• Which are the most critical business objectives for the organization? Which are less important?
• Are any efforts eliminated from the scope of the company’s business activities, and why?

Identify the factors driving the need for budget constraints and the broader business context behind these mandates. This understanding will guide your decisions about allocating your funds and how to support other department leaders in their budgeting efforts.

Try a Zero-Based Approach to Security Spending

Regardless of the formal process your company uses for budgeting, review your security expenses using an approach known as zero-based budgeting.

Consider this a thought exercise that assumes zero cybersecurity expenses at the start, then adds expenses to the list with an explicit business justification for each project you’d like to fund. This planning method allows you to avoid the inertia of funding efforts just because you funded them last year. To do this, you may need to work with the finance team to itemize the expenses allocated to security at your firm.

For each expense that you’d like to add to your budget, capture the following:

• The cost (upfront, recurring, technology, people, etc.)
• The business benefit to the company (beyond just “stronger security”)
• The rationale for spending the money now and not, say, a year later
• The consequences to the business of delaying the expense

This is one way in which you’ll be able to align security expenses with business needs.

When adding items to the list of potential expenses, look for opportunities to achieve similar business objectives with lower costs. For example, by funding an effort to automate or otherwise streamline security tasks, you might redirect your people’s time to other projects or, if necessary, reduce the need for personnel.

Rank the list of expenses according to business impact, then look at what fits into the company's cybersecurity budget. For the items you consider essential that didn’t fit, the details you prepared when crafting the list will allow you to have meaningful conversations with the company’s leadership regarding the tradeoffs of funding or not funding those projects.

Helping the Company Save Elsewhere

While security professionals focus on protecting the organization from threats, our visibility into unnecessary IT assets offers an opportunity to deliver value in another way. We can provide insights that help other teams save money and get the most out of their limited budgets.

Our ongoing efforts, such as vulnerability scanning, asset management, penetration testing, and compliance monitoring, often identify unnecessary resources in the company’s IT fabric that could put it at risk. This includes:

• Unused software on the endpoints
• Underutilized SaaS services
• Stale, unneeded user accounts
• Unnecessary features in existing software
• Abandoned, unmaintained virtual machines

When we frame the need to decommission unneeded resources solely from the perspective of security, we’re often met with concerns over the possible need for them in just-in-case scenarios. However, if we highlight the positive financial benefits of such actions, we’re more likely to gain support.

By collaborating with IT and other stakeholders in the organization, we can use the visibility that security provides to identify unnecessary IT expenditures. Disabling, reconfiguring, or offboarding these unnecessary components is good for security because it reduces the attack surface. It’s also good for the organization because it reduces unnecessary expenses.

Finding such opportunities will help your colleagues with their budgeting efforts, earn goodwill, and strengthen relationships. And maybe, just maybe, you’ll be able to allocate some of the savings back to the security department.

Help Lower Expenses While Reducing Risk

The mission of the cybersecurity team involves safeguarding the organization’s data. Fortunately, our visibility and insights can also provide value through cost savings. By understanding the business context for cost restraints, scrutinizing and prioritizing our own expenses, and helping the company save elsewhere, we can lower costs. This is a way to contribute to the organization's business success while reducing security risks.