Lanes in the road: How small and medium businesses can allocate cybersecurity responsibility

After suffering a devastating ransomware attack in early 2023, the law firm Mastagni Holstedt turned around and sued its Managed Service Provider (MSP), LanTech. While the legal case is still open, some important details from it illustrate key lessons for small and medium businesses (SMB) when it comes to cybersecurity.

First of all, the law firm and MSP appear to have only had a verbal contract to provide services. This makes it very difficult to determine who was accountable for doing what.

Additionally, the law firm found out that its backups - stored with the service provider Acronis - had been deleted prior to the activation of the ransomware. This is a common technique for ransomware gangs. They understand that if a victim has backups of its data, the ransom demand will not be especially effective.

Acronis, however, noted that some of the firm's own credentials were used to delete the backups. It would be difficult to fault a software provider for granting access to a user with legitimate credentials, even if after the fact it turned out that the user was malicious. If the opposite situation occurred - where Mastagni Holstedt needed to access its backups but was denied access by Acronis due to a (false positive) indication of suspicious activity - it's easy to see the law firm being equally angered.

Unfortunately, confusion like this is quite prevalent in the security world. So in this post, we'll look at some common techniques for assigning roles and responsibilities when it comes to managing cybersecurity, compliance, and privacy risk. Many of the suggestions are applicable both internally and externally with employees, contractors, vendors, and even customers.

Step 1: Use RACI to clearly define roles

A traditional tool for assigning roles is the RACI matrix. The acronym spells out those who are:

about an action needing to be completed.

The first step towards building cybersecurity responsibility is providing an excellent framework for assigning tasks related to risk management. For example, assume a company needs to collect compliance-related documentation ahead of an upcoming audit. It could allocate duties in the following way:

• Responsible - Governance, Risk, and Compliance (GRC) analysts. Individual contributors like these analysts would be responsible for doing the actual work of collecting the evidence, adding it to the appropriate repositories, and confirming completion of the work. Alternatively, if they have the right tools, they could likely automate most of this process.
 
• Accountable - Director of GRC. This person likely wouldn't be doing the work personally, but would be accountable for the accomplishment of the final goal. Only one person can hold this role, as it requires making decisions in a way that impacts the outcome of the task.
 
• Consulted - Individual business unit leaders. Collecting evidence will likely require the GRC analysts to access a variety of systems, many of which will be owned by other business units like marketing, human resources, and information technology. Thus, the heads of these organizations will require consultation to ensure they are aligned and supporting the mission.
 
• Informed - Vice President (VP) of Operations. Finally, the VP of Operations is unlikely to be involved in the day-to-day of the evidence collection operation, but will have a vested interest in the outcome. Thus, this person should be informed upon completion or if the team encounters any problems requiring additional assistance.

An effective RACI matrix clarifies accountability, reduces uncertainty, and speeds task completion. Similarly, risk ownership is a process that benefits greatly from a structured approach.

Step 2: Document risk ownership clearly using a single source of truth

As an organization grows and matures, it will identify more and more security and compliance risks. While this is normal, the key is managing these risks effectively. We've already talked about the four ways in which businesses can do so (accept, mitigate, transfer, and avoid). But in this section, we'll discuss how they can track these types of decisions effectively.

At the center of a risk ownership program is a risk register. This is the single source of truth that identifies all of the potential issues facing a company, who is accountable for (or owns) them, what decision that person has made about the risk, and when to revisit that decision.

By clarifying things in this manner, everyone in the organization can have an informed discussion about the business's challenges, the resources available to tackle them, and the most efficient way to use them.

With that said practices to avoid include:

Using a purpose-built GRC tool can save you huge amounts of time and effort when constructing your risk register. And it can help you avoid some of these common pitfalls.

Step 3: Vet third parties

In addition to measuring risks posed by internal factors (employee awareness, vulnerabilities in self-hosted applications, lack of appropriate policies and procedures, etc.), understanding external factors is equally - and potentially more - important from a risk assignment perspective.

Third parties such as vendors, but also open source projects, can introduce substantial risks into your supply chain and business operations. Developing an effective set of tools to measure this risk can help you to make informed decisions.

Some example practices include:

• Sending security questionnaires to vendors with access to business-critical data to understand their access control, disaster recovery, encryption, vulnerability management and related procedures. Tracking all of their responses in a single place becomes increasingly vital as you scale.
 
• Reviewing third-party attestation reports, like System and Organization Controls (SOC) 2, and certifications, like ISO 27001. While not foolproof, these standards require adhering to a minimum baseline of security, privacy, and compliance practices.
 
• Using a security ratings tool to understand vendor risk dynamically. A variety of offerings exist to help companies understand the relative security posture of their suppliers. These tools monitor things like open ports, unpatched vulnerabilities, and similar external indicators of the relative risk posed to a network.

While knowing is half the battle, the other half of the battle is equally important. This consists of actually doing something about the risks you've identified.

Step 4: Distribute risk using contracts

As Mastagni Holstedt discovered, its expectations of what its MSP would offer in terms of security protections varied greatly from what the law firm actually got. Without a formal written contract, it's highly likely both parties had different understandings about their roles and responsibilities.

Contracts are the best way to clarify mutual understanding about each party's responsibilities when it comes to security and compliance. Some example ways to use a contract this way include:

• Requiring a vendor to maintain ISO 27001 certification as a condition of continued business. Because the standard requires annual surveillance audits, a contractual requirement like this can help to prevent a vendor from experiencing configuration drift, where the day-to-day realities of business operations mean that its security posture degrades over time.
 
• Establishing service level agreements (SLA) regarding data confidentiality, integrity, and availability. While SLAs addressing the latter are most common, it is certainly conceivable that organizations could assign risks related to data breaches or corruption using an SLA.
 
• Mandating that a vendor participates in your organization's bug bounty program. While running a bug bounty program requires a high level of maturity, it makes sense to include key parts of your supply chain in it once it is up and running. By paying ethical hackers to identify flaws in both your and your suppliers' networks, you can help to improve everyone's security.

Step 5: Apply compensating controls

If, after doing all of the above, however, you determine that there is still unmanaged risk, you have some difficult choices to make. Aside from terminating the vendor contract (avoiding the risk) or just accepting the residual risk, you can take creative approaches to dealing with it.

• If you have concerns about a vendor's data security practices but still need to use it anyway, you could explore methods of risk mitigation like double encryption. With this approach, you may be able to apply your own encryption layer - controlled with keys you manage - underneath the encryption layer the vendor applies to data sitting on its systems. While this can be logistically challenging, it does provide you additional assurance about your data's security in the event of a breach.
 
• Alternatively, you may simply decide to increase your cyber insurance coverage as a result of security gaps you identify in a vendor. Using this additional cost as leverage during negotiations can help you to offset some or all of the increased premium. Additionally, this will likely encourage the vendor to address the underlying security issue.

Conclusion

Confusion and ambiguity are just part of life when it comes to business, and that extends to security. With that said, maximizing clarity to the utmost extent possible will go a long way toward improving your GRC program. When all stakeholders - internal and external - fully understand what is expected of them, they are best equipped to achieve their goals.

To make this happen, SMBs often rely on a patchwork of systems, from Slack to Jira to spreadsheets. Unfortunately, this approach quickly breaks down as the organization grows. That is the exact reason why we designed the Scrut GRC automation platform. It is your one-stop shop for:

• Risk and vendor management.
 
• Cloud asset management.
 
• Audit evidence collection.
 
• Much, much more.

Ready to check out what the Scrut platform can do for you? Book a demo!