More company’s cybersecurity strategy is falling into the trap of transferring risk to third-parties, so that they don’t have to take accountability, but it’s mostly a facade.

We’re now in a world of everything as a service and managed services across all facets of our IT systems, which is extremely powerful and gives us a bunch of exciting benefits, especially in software engineering, as it allows us to focus more on delivering value to our customers.

However, when it comes to security the primary motivation for outsourcing can be to transfer risk to an external source. That way when things go pear-shaped, we have someone else to blame.

The National Institute of Standards and Technology (NIST) have a series of “special publications”, where they share guidelines and recommendations for building, running, and maintaining secure systems. One of these publications is NIST 800-39, and it proclaims, “Risk sharing or risk transfer is the appropriate risk response when organizations desire and have the means to shift risk liability and responsibility to other organizations.”

This sentiment is echoed across compliance frameworks such as ISO 27001, but is it really a viable option?

The first and obvious problem with this approach is that it in no way addresses the security issue, it simply shifts the blame to someone else. You’re essentially paying for it to be someone else’s problem.

The second problem is the third-parties which companies are transferring risk to have robust terms and conditions which will remove all liability, so it’s a symbolic transfer of risk and not legally binding. This leads us back to the first problem, we’re paying for it to be someone else’s problem, but it’s not their problem either. We’re essentially gambling with the security of our customer data through the transferring of risk.

If you look in the terms and conditions in relation to the recent Crowdstrike Falcon content update outage, which crippled access to 8.5 million Windows devices, you’ll see that although we can point to them as the problem, in reality they told you upfront not to even use their product in the first place.

I won’t quote the terms and conditions linked above as they’re long form and laden with legal buzzwords, but essentially they’re saying that there are no assurances the product will work at all, don’t use it in sensitive environments, and if anything goes wrong it’s not their fault.

Final thoughts

As security professionals we should be taking more responsibility for the security of the systems we have running in production. There is too much focus on ticking a compliance box, and not enough focus on actually doing the work. If we’re willing to be custodians of customer data, it’s our responsibility to ensure we have the capabilities to protect it.

We might be able to maintain the facade we create through transferring risk, and when things inevitably do go wrong we might even be financially protected and maintain our reputation. However, as security professionals we should feel obligated to influence positive change and ensure we do the best by our customers. Sweeping security issues under the rug simply isn’t good enough.