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.