Security exceptions

Indeed, if we have policies and standards we will have exceptions too. Let's face it; it is hard to implement everything by the letter of the law due to complexity, costs, and limitations of software and hardware. There are two schools of thought on policy implementation, one school, only put in policies on what is currently being done or with little effort, the other, write a policy that the enterprise should be implementing. The first school of thought may not be ideal, but upper management may not want to hear that the enterprise is dismally implementing a policy that has been written. On the other hand, upper management that understands security will want to push the enterprise to a higher standard and push for the best feasible policy.

In either case of policy creation and enforcement, there will be exceptions. Exceptions are not necessarily a bad thing, but they must be documented with a path to resolution and a timeframe to do so. Without an acceptable timeframe with accountability the exceptions, which are a security shortcoming, may be introducing unnecessary risk to the enterprise. Assigning a risk level for the exception and developing required remediation timelines is crucial for exceptions to serve their purpose while ultimately getting in adherence to policy. Indefinite exceptions cannot be an acceptable practice as this undermines the intent of policy and maintains a revolving door of risk.

Security policy exceptions require proper documentation not only to make it clear what the exceptions are, but when audit time comes around, due diligence, through following a formal process will reduce the impact of identified exceptions.

The following items should be documented for security policy exceptions:

  • Exception number
  • Date and time
  • Exception requester
  • Exception owner (responsible party for remediating the exception)
  • Exception approver
  • System, application, configuration (which has the exception)
  • Cost, complexity, limitation (cause of the exception)
  • Portion of policy not met (what part of the policy the exception is for)
  • Exception remediation date (when the exception expires and remediation is required): Cannot be indefinite, and exceptions must be remediated
  • Next review date

Ideally, exceptions would be managed in a system that can be used to track the progress of each exception and provide an overview of all open, closed, and in progress exceptions. Exception systems can also send notifications to owners or preferably roles (in case of personnel changes) as a friendly reminder to get their open exception in compliance with written policy. Additionally, providing a searchable repository allows for better reporting and metrics on open exceptions that may indicate a trend that needs addressing at the policy tier.

The primary focus for exceptions is not only opening and closing them, but also analyzing patterns of exceptions. Are the same portions of the security policy creating multiple exceptions again and again? This may be an indicator that the policy is either identifying a serious issue within the organization or that the policy may need to be tweaked to better fit how the enterprise is functioning.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.227.26.217