Non - Another approach you might consider is this --
- create your information security policy to be very high-level policy
statements (rules) that will "never" need an exception. As a rule of
thumb, consider the 10 Commandments as policy statements
- create "security requirements" that address all of the various elements
to support those policy statements. The requirements are not going to be
security solutions, but are intended to set the minimum security
baselines. Have your data owners, application owners, information system
owners, etc determine if the security requirements are applicable or not
applicable to them, agree to implement those requirements that are
applicable, and document those that are not applicable. The result of
that effort will be a documented detailed security requirements document
for that particular data store/application/ or information system which
the auditor can then audit against.
- create technical standards that the requirements can call if needed
- create processes and procedures that define the how-to get things done
and by whom. This effort may result in the biggest bang for the buck...
- train people in all of these...
The only "exception" process in this scenario may be security requirements
exceptions. If you take the approach that business units "can not" do
something, then you will find yourself butting heads - that is, if you
survive the battle at all. Identify the Risk Acceptors (usually business
managers) who are responsible for all other company assets, to make
decisions on and accept responsibilities for their information assets as
well.
Just wanted to give you another perspective....
Dave Lyons, CISM
Blue Oasis Technologies
760-271-9264
Your policy should probably not just say "you CAN NOT do this period"
and leave everyone wondering what should be done in this case or in that
case...
While thinking about your policy ,you should consider not just the risks
you are trying to mitigate ("let's forbid that because it is
dangerous..."), but also what may be needed in regard to doing business
that you are going to disturb if you forbid something completely ("we
can not forbid that completely because X will not be able to perform Y
and they may need to!").
You will than have to say in the policy "general policy is that you CAN
NOT do this, unless you ...." and than point to procedures that cover
the areas where you expect to have requests for policy "exceptions".
Each procedure should than have an owner (the person that will
approve\disapprove the request - he should be familiar with the relevant
domain), and will include the form for the request, and the criteria
that will be used when evaluating the request.
If you provide an example of a specific area that gives you grief, the
discussion can get more focused.
-----Original Message-----
From: Non Proprio [mailto:non@synaxis.org]
Sent: ä 28 àå÷èåáø 2004 15:34
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.
