Well said, Fred.
John
John G. Cronican, Jr. (BEE, MSSM, CISSP, IAM)
Sr. Infrastructure Technologist
iProtect Sempra Energy
Sempra Energy Corporate Center & Sempra Energy Utilities
10949 Technology Place
San Diego, CA 92127
(858) 613-5738 (Desk)
(619) 787-1906 (Cell)
(619) 978-2493 (Pager)
JCronican@sempra.com
-----Original Message-----
From: Fred Cohen [mailto:fred.cohen@all.net]
Sent: Monday, January 16, 2006 1:55 PM
To: security-management@securityfocus.com
Subject: Re: How to organize a lot of policies?
A lot of discussion seems to surround the layering of policies to
procedures. The reason I have gone to the three layer approach
(policies, control standards, procedures) rather than the two layer
approach (policies and procedures) is that I find a natural
distinction. Policies get top management approval and deal with the
governance issues. Control standards deal with the specifics of the
issue rather than the governance of the issue. Procedures deal with
implementation in specific systems and situations. By dividing in
this way, top management only needs to see what is important to
governance and things change far less frequently for the policies.
Control standards then also encompass things like ISO17799
implementation issues as opposed to the top-level issues, which
removes all of the details from the policies and places them in more
direct control of those responsible for their implementation. For
example, we just did a policy, control standard, and set of
procedures for risk aggregating changes at a large enterprise.
The policy is about two pages and reflects who is in charge of what,
what the approval processes are, what the conditions are for having
to deal with this policy, and the appeals process should anyone
decide they don't like the way things went or are going. It then
identifies two control standards that apply, one operated and defined
by the CIO and the other operated and defined by the CISO.
The control standards go into details that are implementation
independent but define what is needed and why and what has to be
identified and addressed in order for a risk aggregating change to
take place. They include lots of things like what materials have to
be provided to whom for them to understand whether the aggregated
risk is properly defined, what process should be used for evaluating
the resulting risks, how the retun on investment for the new
configuration is to be compared to the previous configuration to show
that it is worth the investment, impact on operational costs, and so
forth. This changes as the import of different things change and can
be changed by the CISO or CIO (respectively) without further
acceptance by top management. They can also waive requirements should
they decide to as long as it remains within the policy which says, in
essence, that they include the waiver in the report to the top
management folks in charge of risk management.
Finally there are the procedures which are defined by those who
implement the systems so as to meet the requirements of the control
standards. These are approved by the CIO and CISO as meeting the
requirements they have and of course have lots of details like how to
configure this or that system, settings for firewalls, how many users
can login at one time, and you name it. These change every time a new
software package is added or an update that changes the management or
user interface shows up. They require no approval but are subject to
audit review as are all of the other elements of the control
standards and policy.
I have found this 3-layer approach to work a lot better than the 2-
layer approach, especially for large enterprises where more than a
few people are involved in these sorts of things and they come up
more than once every long while.
FC
-- This communication is confidential to the parties it is intended
to serve --
Security Posture securityposture.com tel/fax
University of New Haven unhca.com 925-454-0171
Fred Cohen & Associates all.net 572 Leona Drive
ASP Press asp-presss.com Livermore, CA 94550
