Security Exception Tracking - WST

In even the most rigorously managed networks or systems, there’s always some exception to security policies that must be allowed at some point. Maybe it’s a critical operational need, maybe it’s a temporary issue during a big rollout, maybe something new has cropped up and the rules need to be bent for little bit to keep the wheels rolling…it happens. But granting and tracking exceptions to security policies should be part of a managed process.

Let’s start with a basic question: why does an exception need to be made? There should be a pressing organizational need, and not simply a convenience request to save a few workflow steps. Security policies and configurations exist for important reasons, and poking holes in your defenses generates risk. Those risks need to be carefully considered before opening any gaps.

How are you going to track exceptions? That may depend on your organization’s size and complexity. Some examples include adding exception tracking to regular meeting agendas, or using internal ticketing systems, or even simple calendar reminders; think about options that might work best for your teams. If you are already tracking audit and exam exceptions with a specific process, consider adding security policy exceptions to that process as well for centralized management.

Consider who can (or who should) sign off on granting an exception? That might vary based on the risk level of a specific exception. Do you have clarity around those approval processes? You may need to have several folks chime in before making changes. Also think about who is accountable for exception tracking; it’s an important job.

Think about what additional controls might be used to mitigate risks generated by an exception. Layered security measures may help provide enough risk mitigation for your organization to manage an exception for a short time. Speaking of time…

When are exceptions reviewed? This is a biggie, since without some timeframe in place, an exception may very well morph into the “norm” if it’s never reassessed. Higher-risk exceptions may require shorter review windows. Look for ways to limit the time an exception is in place.

Authored by: David Bentley, CISSP