Cybersecurity Exceptions - Part 1

If your cybersecurity standards were written to protect the organization, why do you have security exceptions? Today, I will dive into why security exceptions are the norm, discuss the risk they posed, cumulative risk, tracking, expirations, and exception metrics.

Your standard development team writes an excellent standard; it follows all the best practices of the NIST Cybersecurity Framework, the ISO 27001, or any other industry-recognized standards and frameworks, but most of all, it is common sense, right? Anyone working on or with a cybersecurity team in a large organization knows this does not happen! Exceptions happen. The typical exceptions vary; however, the pattern usually falls into three categories:

• First, it comes from projects or any deployments, such as new servers (or replacement/upgrades) or applications.
• Second, and this one is more typical in larger organizations. That is when the corporate office or parent company pushes new security standards to strategic business units (SBUs), conflicting with the SBU's standards. In this scenario, the usual initial analysis will tell you the challenging areas were either communication or stakeholder engagement.
• Third, merger and acquisition (M&A); companies may not perform adequate due diligence on the security controls at the company they are purchasing; or in other cases, these acquired companies are allowed to operate independently and outside the standard corporate security policies for a certain period.

M&A cybersecurity exceptions can be broad and encompass the entire new organization, including several unknown risks, as proper diligence may not have been done. High-profile examples included the Marriott/Starwood Hotels breach in 2018. Although the breach was identified in 2018, it dated back, as far as 2014, before the merger. Another example was the 2016 Yahoo data breach, before finalizing Verizon’s purchase of Yahoo, which cost the organization $350 million in the selling price; however, an additional $117.5 million was the price of a settlement reached in 2019.

A particular cybersecurity exception type worth mentioning is third-party vendors. Organizations may be inclined to address these third-party vendors through their third-party [risk] programs, but what happens when the vendor can’t comply with your organization’s cybersecurity standards? How are those exceptions documented and tracked? Do you use your cybersecurity exceptions program? Or do you use some form of issues management program or platform? How do you account for these potentially cumulative risks in your risk register?

There are two schools of thought regarding third-party vendor risk tracking; I don’t believe there’s a right or wrong way of doing it, but you need to make sure the method you use is an input to your cybersecurity risk program. The first approach is leveraging your cybersecurity exceptions program; given the attributes of a generic exceptions program, the fact that someone will accept or sign off on the risk is a critical deciding factor. The greater the residual risk is, the more senior individuals will have to sign off or accept the risk. Another attribute to consider is an expiration date, which will allow the cybersecurity team to revisit the exception, re-evaluate, and decide to discontinue or re-authorize to continue by requesting sign-offs again.

The issue management, corrective action program, or the plan of actions and milestones (POA&M), depending on your organization or industry, this approach will have various names. The underlying fundamental of this approach is that everything will be fixed as you identify actions that the vendor will take to mitigate their violation(s) of your cybersecurity standards. If the third-party vendor can’t fix everything, create a cybersecurity exception.

I’ll leave you with this final thought, whatever approach you take in your cybersecurity exceptions, make sure it is an input to your cybersecurity risk program. There’s a lot more to cover on this subject, so I’ll cover the risk posed by an exception and cumulative risk in the next episode.