SECURITY POLICY

It would be a gross omission if security policies were not discussed in some manner, albeit a much talked about aspect of information security and a broadly accepted requirement for a successful security program. Nevertheless, its role in a penetration test cannot be understated.

A security policy is one of the most important components of a successful information security program. Security policies play a critical role in managing the organization’s security by defining a desired posture that the organization strives to achieve and maintain. Policies set the bar for the organization’s security, and infor- mation security management and operations personnel are tasked with driving the organization to that mark.

A security policy is the foundation on which all security operations are built. Without a security policy to define the expectations of the security controls it is effectively impossible to establish a well-fortified security program.

As discussed above, the existence of a risk analysis is key to the value a test can offer to a company. However, appreciative of the fact that an ethical hack is part of a risk analysis, a previous risk analysis may not be available — a chicken-and- egg scenario. It is at this point a security policy takes front stage. A security policy will state the acceptable uses and procedures in maintaining the desired security level. These attributes will help in the planning of the test, shape the tasks to be performed, and assist in evaluating success factors. All of which will culminate into a deliverable formatted to accommodate proper integration.

However, this makes several assumptions about the completeness of the existing policies. A book sitting on the shelf in the IT director’s office for the last couple of years does not count. Moreover, what should also be noted is that the structure of the deliverable and resulting implementation plans will be based mostly on the presentation of security within the policy as opposed to measurable risk factors. Therefore, an old or outdated security policy will greatly affect the value of the test.

Unfortunately, many security policies suffer from neglect. Many organizations have security policies simply because other organizations and legal requirements demanded them to be implemented. Unfortunately, many are not maintained, prop- erly communicated, or used as a guide in day-to-day activities. The requirements for a firm to have a policy, politically or legally driven, tend to ensure a policy is created but do not instill a method for maintaining it. Many policies have become paperweights and are referenced only in the event an employee contests being reprimanded for poor and insecure behavior.

Security policies come in many forms, from simple documents to policy appli- cations that work within the environment to ensure they are communicated and applied. Policies are created to describe, detail, and communicate the expected security practices as well as the processes that are to be followed to protect, defend, and recover from attacks. They also help act as a reference for configuring new systems, connections to the network, adding remote users, and integrating new technology or applications.

There are several policy structures that can be leveraged to create a well- organized policy and inherently assist their development. With any comprehensive collection of information, content organization is a key factor of the degree to which the information is integrated and used.

At the most fundamental level, a security policy is comprised of collections of statements, with each containing supporting material. A policy statement generally defines the organization’s stance on a particular aspect of information security. The supporting material behind a policy statement consists of standards, guidelines, and procedures that outline specific processes to enforce the policy.

• Policy Statement. Policy statements should be clear statements on the particular aspect of security that provide no room for interpretation. They should provide generalized, yet pertinent information on what is expected to be practiced within the organization. Policy statements should avoid justification of the policy, details that are supported by the standards, guidelines, or procedures, or any specific technology associated with the policy. All these characteristics tend to add complexity and open the opportunity to interpretation. Allow the details to be addressed in the supporting statements.

• Standard. A standard is the actual definition of the technical nature of the requirement communicated by the policy statement. Standards provide specific details that explain or quantify the policy statement with which they are associated. Standards should be detailed and clear in communi- cating the requirements of the policy statement by quantifying the neces- sary attributes of the policy. However, the standard should not include procedures or step-by-step processes on how to implement the policy. The goal is to define the final structure associated with the statement. • Guideline. A guideline is a collection of supporting activities to help

associate everyday activities with the support of the policy statement. Guidelines provide general suggestions or recommendations that further

clarify the policy with general details or suggestions for their implemen- tation. Without guidelines, the policy statement and standard would have little meaningful impact on the typical user. To accomplish this, guidelines should provide associated technologies and guidance in various condi- tions. However, once again, the processes for carrying out the policy should not be addressed within the guidelines.

• Procedure. A procedure defines the tasks required to meet the require- ments set forth in the policy. Procedures are step-by-step instructions detailing how a particular task is to be performed. These are executed to implement and enforce policy statements, or to measure the organization’s compliance with a particular statement for later auditing purposes. Pro- cedures should be very clear on performance of necessary tasks and should avoid any information outside the scope of simply providing the steps to complete and enforce.

Following is a simple example of the policy structure. • Policy Statement:

– Users shall use strong passwords on all network systems and elements. • Standards:

– Passwords must be at least eight characters in length.

– Each password must contain alphabetic, numeric, and special charac- ters.

• Guidelines:

– Users should avoid using personal information that can be easily guessed, such as a name or critical number as a password.

– Users should seek combinations of words that are easy to remember yet difficult to guess.

– Users should avoid the use of passwords that are commonly found in dictionaries.

– Users should avoid writing the password down. • Procedures:

– Enforce password policy on NT Domains. • Log on to domain controller as Administrator. • Run the User Manager application.

• Select “Accounts…” from the Policies menu.

• Configure the system’s password policy to mirror the organization’s password policy.

• Click “OK” and close the User Manager application.

As we show later, the existence and proper language of a policy regarding penetration testing or evaluating security through the act of exploitation becomes critical to ensure that the value of the test is realized and meets the requirements of the overall expectations of the security controls within an organization.