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