It seems a lot of people don’t understand the difference between security policies and procedures. When I ask to see a client’s security policy, if I get something, it’s usually documentation of how the system’s security values ââshould be set. Occasionally it contains a description of how certain tasks will be accomplished. For example, updating applications on the production system. While this type of documentation is useful, it is not a security policy.
In short, the security policy identifies acceptable and / or unacceptable uses of various business assets. It is important to note that the security policy should not include descriptions of how to apply, prevent or identify desired and unwanted behavior.
Security procedures, on the other hand, describe various processes and techniques that will be used to enforce, prevent, or identify desired and unwanted behavior. The documents I usually receive are examples of security procedures.
Consider an organization that requires management approval before developers are given special * ALLOBJ authority over the production system. This is an example of a security policy statement. In order to apply this policy, the company uses the ticketing system of the help desk as well as a house application to achieve this. The program requires the programmer to enter a help desk ticket number. The program checks this against the help desk ticketing system and ensures that the box approved by management has been checked. It then writes a log file entry with the date, time, ticket number, and programmer user profile name to record the event. The program then calls another program which adopts a user profile that has * ALLOBJ and then calls QCMD. The programmer has the right * ALLOBJ until the end of the program.
For the example discussed above, a security procedures document will contain a description that includes statements about the following:
- Developer user profiles on the production system will not have special authorities assigned to them.
- To get the special authority required for debugging, developers will use the “ELVPRV” program (elevated privilege).
- A reference to the security policy statement that this procedure is intended to enforce is also very helpful.
Descriptions of security-related system value settings should be included with the process to follow when they need to be changed temporarily. Basically all the actual settings related to security (e.g. special authorities required by various groups of employees, TCP / IP servers should not be started automatically, etc.) are all topics that should be included in a security procedures document.
It is also important to include in a security procedures document a description of the process to be followed in order to obtain approval for an exception to a specific security policy or to use an undocumented process or procedure. In these cases, the security policy states that: Policies can only be bypassed by running the security policy exception approval process. The security policy would then describe the procedure. If local applications are used to implement all or part of the procedure, the program documentation describes the mechanisms and tools used to achieve the objectives of the program.
Essentially, the security policy defines the behavior and the security procedures define how these behaviors are enforced, avoided and / or identified.
Patrick Botz is President and CTO of Botz & Associates. His expertise includes security strategy, security policy enforcement, password management, single sign-on (SSO), industry and government compliance, and biometrics. He is the architect of the SSO stat! service. Previously, he worked as a chief security architect at IBM and founded the security consulting team of IBM Lab Services. You can connect with Pat here.
Name of the EIM identifier
Job user name and current job user