2.5 Plans and policies

2.5 Plans and policies

This is an area where many companies fall short of the mark. Check your environment to see if you have any existing security plans, policies, and/or procedures. These can include physical security, LAN security, Internet access, and even disaster recovery. At this point, you have decided which threats pose an unacceptable risk to your computing environment and what level of action you are willing to take to defend against them. Studying the security plans that your company has and their implementation may help you decide which security measures are most important for your environment. One of the most important parts of this review is the identification of policy compliance. Policies are only good if they are implemented; a thorough implementation plan is required. Part of your security implementation plan should be a review of any existing policies that concern security.

  • Policy goals and objectives

  • Scope

  • Responsibilities

  • Physical security

  • Network security

  • Data classification (data categorization)

  • Access control

  • Password change and enforcement policies and procedures

  • Incident handling procedures

  • Acceptable use policies

  • Change control

  • Training

  • Compliance

2.5.1 Policy goals and objectives

Define what you are trying to accomplish with your policies. The objective defines your approach to Internet security. These approaches could include the use of tools, systems, and employee/user training.

2.5.2 Scope

The scope specifies the assets that will be protected by security policy. The scope could define a specific policy or a body of policies. The scope should include who is impacted by the policy: end-users, employees, customers, vendors, and so on.

2.5.3 Responsibilities

The responsibilities section of the policy document describes how the individuals defined in the scope section will be responsible for the security of your environment. Detail the security responsibilities as needed by region, department, or groups. Depending on the company size, responsibility may be assigned to the following personnel.


The top directors the CxOs are responsible for high-level security strategy and must make the necessary resources available to combat security threats to the business.

Security manager

The security manager is responsible for the entire enterprise security. The security manager defines the enterprise security policies and procedures and works with the business managers to implement the initial risk analyses as well as the individual process risk analysis. The security manager implements each facet of security, such as:

Process owner

The process owner is directly responsible for a particular business process and can be a department manager, a lead engineer, a specification custodian, or any employee tasked with accountability for a business system. The process owner will work with the security manager to analyze risks and recommend the countermeasures for each process. The process owner may not have extensive experience with security, so the recommendation may be at a business level only. For example, the process owner will say, "We need to limit access to this application to a single group." The security manager hears, "Access control will need to be set up and implemented for applicable personnel in the process group via the corporate policies and procedures."


The legal department needs to be involved with the design of the security policies and procedures from day one. Make sure the following issues/items are covered within each policy.


The developers define the responsibilities of the application developers. Security needs to be built into the application from day one of the development cycle.


The users are responsible for security in the enterprise as much as the CxOs. Every user needs to be trained on the company security policy, data categorization, and system procedures as well as understand what the consequences of their actions are and how to act accordingly.


The auditors should be familiar with but independent of the activities performed by the organization or group being audited. They will perform audits specific to requirements in the security policies and procedures.

2.5.4 Physical security

Physical security measures must provide for the protection and access to the physical assets of the business (e.g., servers and applications). The physical security document should describe how the various assets are to be protected (such as locked server rooms, card readers with limited access, or logging systems to track who has access to each type of server).

2.5.5 Network security

The network security document describes how you will protect assets stored on the network. This document could include security steps on the following.

2.5.6 Data classification (data categorization)

Every business possesses data that is owned by someone. The value of this data can vary from one application to another, from one business to another, and even from one competitor to another. Business data should be classified based on the security requirements of that data. A data classification policy document should describe the requirements to classify the data. Do not confuse the classification of data and the service level of that data. You can have data that is open to the public, but if the public cannot read the data due to a DoS attack, then that data is useless no matter what your classification is.

Following are examples of data classifications.


This data/information is available to the public. Access to this data by competitors is acceptable and does not represent a threat to the business.

Vendor restricted

This data is available only to approved vendors and/or business partners. Access to this data by competitors can pose a risk to the business. Access to this data must be logged and restricted.

Internal information (proprietary)

External access to this data is restricted. Access to this data by competitors or the general public could put the business at risk or cause embarrassment. Access to data is restricted to internal employees only and access will be logged.

Confidential information (limited)

This data is confidential within the company and protected from external access. Access to this data can give competitors an advantage in the marketplace. Access will be limited to select employees and groups. All access will be logged. Backup tapes will be controlled.

Secret information

This data will not be placed onto any networked systems. Access will be limited to very select individuals and all access will be logged and monitored. If this data is compromised, the business can be at risk.

2.5.7 Access control

Depending on the application and the data, users may need to be authorized. Define your requirements in this section of the document. Define the access to the authoritative directory for this authentication, and include the following access control features as needed.


Not all authentications will necessarily be from an authoritative directory.

2.5.8 Password change and enforcement policies and procedures

Be careful with this section of the document. Not all applications or operating systems have the same password management systems or rules. You may need several documents to cover each type of password management. Also, consider using a single sign-on system, which can help manage passwords and the password rules. Consider the following examples when setting up your policy document.

Set up password rules to prevent "crackable" passwords

Create some guidelines for users on how to manage their passwords

2.5.9 Incident handling procedures

An incident is an unplanned, unexpected event that requires immediate action to prevent a loss of business, assets, or public confidence. All policies must have an incident handling component plus a feedback component. The feedback loop is the mechanism that will keep the policies current and updated. An incident handling process is critical to permit continuity of important business processes in the event of an incident and allow the business to function. Service levels will be needed to determine what level of handling is needed based on each incident type. An incident where the web site is down and the business cannot conduct electronic transactions will generate a different response than a situation where a user may have lost an e-mail message.

The response team should include representation from these individuals.

Be sure to define the basic procedures for handling an incident. In case of an incident, each of the following points should be implemented.

  1. Preparation. The team should have a charter.

  2. Incident detection. The processes and tools to detect an incident should be in place.

  3. Immediate action. This needs to be prioritized based on a scale of importance (more in Chapter 11).

  4. Communications. This is critical to handling an incident.

  5. Detailed situation analysis. Observe and report what happened.

  6. Recovery. Get the business running again.

  7. Feedback. How can we keep this from happening again?

Following are some general guidelines to help you set up and manage your incident response team.

2.5.10 Acceptable use policies

The acceptable use policy section states how users will be allowed to use network resources. There should be several policies created.

2.5.11 Change control

Some people may argue that change control is not a security concern, but without adequate change control, a site can crash without warning. Hence, our future discussions will address change control as a security concern. Just a simple change can impact the infrastructure and/or application. A concrete check for this is, "Does the site have a change control system and/or policy in place?"

2.5.12 Training

End-user training if very important. A successful security program will include various training methods. These can include:

An educated user is an important weapon in keeping your environment secure.

2.5.13 Compliance

The Compliance section of your security policy will show how you maintain your security. Compliance can include:

Most companies also include an employee compliance application. This application is used to track when employee read and agree to the corporate security policies. Most companies required employees 'certify' themselves every year.

Internet Security(c) A Jumpstart for Systems Administrators and IT Managers
Internet Security: A Jumpstart for Systems Administrators and IT Managers
ISBN: 1555582982
EAN: 2147483647
Year: 2003
Pages: 103
Authors: Tim Speed, Juanita Ellis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net