Security Policies Vs. Security Procedures
June 16, 2015 Patrick Botz
|
It seems that many people don’t understand the difference between security policies and procedures. When I ask to see a customer’s security policy, if I get anything, it is usually documentation about how system security values should be set. Once in a while it contains a description about how certain tasks will be accomplished. For example, updating applications on the production system. While this kind of documentation is useful, it is not a security policy. In short, security policy identifies acceptable and/or unacceptable uses of various business assets. Importantly, security policy shouldn’t include descriptions of how to enforce, prevent, or identify wanted and unwanted behavior. Security procedures, on the other hand, do describe various processes and techniques that will be used to enforce, prevent, or identify wanted and unwanted behavior. The documents I usually get are examples of security procedures. Consider an organization that requires management approval before developers are given *ALLOBJ special authority on the production system. This is an example of a security policy statement. In order to enforce this policy, the company uses the help desk ticketing system along with a homegrown application to accomplish 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 management-approved box was checked. It then writes a log file entry with the date, time, ticket number, and the programmer user profile name to record the event. The program then calls another program that adopts a user profile that has *ALLOBJ and then calls QCMD. The programmer has *ALLOBJ authority until the program is ended. For the example discussed above, a security procedures document will contain a description that includes statements about the following elements:
Descriptions of the security related system value settings should be included along with the process to be followed when/if they need to be changed temporarily. Basically, any actual security related settings (e.g., special authorities required by various groups of employees, which TCP/IP servers should not be started automatically, etc.) are all topics that should be included in a security procedures document. Also important to include in a security procedures document is a description of the process to be followed in order to gain 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 may only be bypassed by executing the security policy exception approval process. The security policy would then describe the procedure. If homegrown applications are used to implement some or all of the procedure, the program documentation describes the mechanisms and tools used to accomplish the objectives of the program. Essentially, security policy defines behavior and security procedures define how those behaviors are enforced, prevent, 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 Lead Security Architect at IBM, and he founded the IBM Lab Services security consulting team. You can connect with Pat here. RELATED STORIES Job User Name And Current Job User
|
