That seems dead-on, and similar to something I found in the Cresson Wood
examples under ISO17799 (2000) section 3 on security policy.
There are specific technical issues that I don't want cluttering up the policy,
but which need documented.
I began outlining my thoughts on a formal process document for each case that
is brought up. I want all sides to have some skin in the game rather than just
tossing things over the fence and running away. I also want to be sure that
there is a way to track all the deviations from standard practice, and when
necessary (and possible) retract or shut them down.
---
Policy Exception Approval
Outline of Exception being Granted (express *what* is being granted)
Limits of Exception (To what systems or areas does it apply?)
Revocation of Exception (when can the exception be revoked by security)
Timeline of Exception (how long is it granted)
Exception Approval Agreement (signature lines)
+Requestor
+Responsible Executive Sponsor
+Network Security Director
On Oct 28, 2004 01:55 PM, Picard Linda M Contr 805 CSPTS/SCCA
<linda.picard@scott.af.mil> wrote:
Write a risk assessment indicating what the exceptions to the policy
are. Access the level of risk for the exceptions, high, medium or low.
If you have a high or medium vulnerability they must be mitigated.
Report to upper management, they can accept the risk or not. It's their
call!
-----Original Message-----
From: Non Proprio [mailto:non@synaxis.org]
Sent: Thursday, October 28, 2004 8:34 AM
To: security-management@securityfocus.com
Subject: Security policy exceptions template?
After years of whining, crying, shouting, etc., we have at least a
skeletal, enterprise security policy.
Now the question is how to approve and document exceptions to the
policy. There is no formal change control or management framework for
software (I know ... ugh).
I have all the Cresson Wood materials, 17799, CoBiT, etc. so what I'm
really looking for is a CYA I guess, but I also want to do what's best
for my company given the relatively crude maturity level of internal
processes.
