Policy exception as Risk Acceptance?

[lfkentwell]

I'm implementing an ISMS in an organization and there is some debate over how to record a policy exception.  Personally, I think this is down to the organization preferences, its regulatory needs etc. but interested in opinions from a "best practice" perspective.

In short, it's pretty clear when we identify as existing risk, regardless of how it was identified or what the risk is, we will write it up as a risk in whatever register we establish.  Assign either mitigation activity or accept the risk.  Simple enough.

What about a policy exception.  What do we collectivity think.  Raise it as risk with an accept action?

Interested in thoughts from people on how they approach it both from their organization's perspective and from a best practice perspective.

[Early_Adopter]

Well it’s really another register of some sort I would say. Will all your exceptions create risks(How and Why)?

For example I need this software for my old app -“ I know it has CVEs, oh they are critical, but we don’t use that functionality… can you approve? Yes “Security Bob from the application team requesting said it’s OK. Three years would be great! Could you do five?” Sorry I don’t understand what you mean by what other risks are caused by having the legacy components in the environment? Oh it’s so old I shouldn’t think attackers look at it anymore… I’m sure it will be fine”… “Yes, we still need Python 2 everywhere, well it’s because the developers don’t like how Python 3 handles floating points… can you just deploy it in all the images?”

So - I think it’s important to have very clear expiries by on your exceptions, in a register and they expire and if the accountable people let it it will stop working as expected 30, 90 or 180 days later, and be re-reviewed if there is a new request - be very wary of extending lest your exceptions become consumer durables.

[CISOScott]

You definitely want to track them. Like @Early_Adopter says you also need to have time limits that either expire or provide a review for renewal.

Risk acceptances should be, ideally, for short periods of time until you can find a way to mitigate them or migrate off of that platform/product/etc.

By having indefinite acceptances or exceptions, you kill the desire to ever modernize or seek out another solution.

[Caute_cautim]

@CISOScott @lfkentwell @Early_Adopter   These are dangerous, these policy exceptions need to have time limits, to ensure they are reviewed on a regular basis and not put aside. 

We have too many examples of legacy systems, hiding in far flung areas of organisations, which then subsequently are compromised, and lead to major disruption and embarrassment, let alone major investigations.

They to be on the risk management system, with time limits or re-visits regularly scheduled to ensure any risks and potential threats are minimised.   It is a compromise, which has a sting in the tail.

Regards

Caute_Caute

[Early_Adopter]

@Caute_cautim

Completely. Exceptions are in themselves risks. So many cases of “It’s not exploitable…” becoming part of the furniture, next thing you know you’ve got three year old dependencies that devs and admins carry on with because people have left/that’s the way we always did it.