Chapter 2. Security Policies and Responses

Being defeated is often a temporary condition. Giving up is what makes it permanent.

—Marlene vos Savant

Having security policies is the most essential first step to protecting and securing your network. Policies provide the basis for defining what is acceptable and appropriate behavior within your company and network. At the most fundamental level, policies form the “rule of law” against which everything else is judged.

Consider a security policy that is analogous to rules and laws found in your neighborhood. What would life be like? If you wanted to accomplish anything worthwhile, it would be unbearable. Viewed in this light, a security policy defines what is acceptable or not inside and outside your network. This is a fundamental definition of the role of security policy, yet there are many additional reasons that define a security policy’s usefulness:

• Sets the expectations for procedures

• Defines appropriate behavior

• Communicates an operational and business consensus

• Provides a foundation for HR action if unacceptable behavior occurs

• Defines roles and responsibilities of each group in securing the company

• Assists in prosecuting legal action if unacceptable behavior occurs

• Provides definitions for concepts and ideas that are crucial in securing your network

• Allows for required tools to be defined by justifying funds for network security

Having a security policy allows and enables everyone within a company to clearly understand who is responsible for what and sets the policies and processes of each department within your organization. For example, customer service will understand their responsibilities in protecting sensitive customer information, human resources will understand what is expected of employees, and manufacturing and development will know how to protect the results of expensive research and development. Of course, the most important result of a security policy will be what a security policy means to an IT department. From the security policy, the IT staff knows what to configure on servers, the tools they need, rules for firewalls, virtual private network (VPN) settings, and so on—the list is endless.

You might wonder what some of the most commonly used security policies are and what areas of IT should consider using a policy? The SANS Security Policy Project (http://www.sans.org/resources/policies) provides a variety of security policies, some of the more common of which are described in Table 2-1.

Table 2-1. Common Security Policies

In addition to knowing what is expected, every person or department in a company is affected by a security policy. As you can see from the following list, each group within an organization is affected:

• Generic user—Because users access network resources, your policy impact them the most.

• Management team—This group is ultimately concerned with the protection of corporate resources and data while monitoring the financial impact.

• Accountants, legal, and investors—Understand that the company’s responsibility to protect itself depends on such policies while recognizing the positive impact a security policy can have.

• Security management team—This group’s role is defined in the policy to pinpoint what group is being tasked with security policy enforcement.

The following section discusses what could be viewed as the most important first question for designing a security policy: who and what to trust.

Defining Trust

Trust is a central theme in many aspects of security and must be foremost in your mind when discussing security policies. In a perfect world, there would be no issues with trust; you would trust everyone, and they would always do the right thing. Unfortunately, that is not realistic, nor does it take into account other factors such as bugs in network resources. Again, trusting the resources on your network would be great, but remember that buggy hardware and software is commonplace in networking.

A security policy can be written with the belief that no one in an organization is to be trusted; however, that would not likely work. It is a well-known fact that users circumvent policies that are too restrictive. Therefore, a balance between trust and securing the network must be struck. This balance is different for each organization, but the need for security does not change.

When considering the level of trust to write into a security policy, consider the following items and keep them in mind as your policy is being developed:

• Determine who receives access to each area of your network

• Determine what they can access and how

• Balance trust between people and resources

• Allow access based on the level of trust for users and resources

• Use resources to ensure trust is not violated

• Define the appropriate uses of your network and its resources

There are many other things to consider beyond this short list, including your company’s politics and users’ reactions. A security policy cannot possibly account for every consideration, but it is important to understand the reactions a security policy brings out in people.

According to the SANS Security Policy Project, security policies should emphasize what is allowed, not what is prohibited. Where appropriate, supply examples of permitted and prohibited behavior. This way, there is no doubt; if not specifically permitted by the security policy, the behavior in question is prohibited. The security policy should also describe the ways to achieve its goals. Table 2-2 lists the security policy sections and describes their content.

Table 2-2. Generic Description of a Security Policy’s Contents

Your security policy defines the resources that your organization needs to protect and the measures you will take to protect them. In other words, it is, collectively, the codification of the decisions that went into your security stance. Policies must be published and distributed to all employees and other users of your system. Management should ensure that everyone reads, understands, and acknowledges their role in following them and in the penalties that violations can bring.

As stated previously, you can trust everyone or trust no one; neither option works effectively when trying to balance productivity and security. Users all have differing views as to a network’s security needs, and they all have a certain level of inherent fear. Users fear that their jobs might be more difficult as a result of security, or that they might be punished if they make a mistake or forget to do something. Ultimately, people at any level do not like to feel restricted when they are trying to work. These kinds of attitudes are normal, emotional reactions, so they must be understood and managed appropriately for the security policy to provide balanced protection for your company. Building involvement in security policy development by including representatives from the areas listed in Table 2-3 is highly recommended.

Table 2-3. Members of the Policy Review Team (from the SANS Security Policy Project)

The personal minefield can be avoided if you ask the involved groups for their input as part of the policy development process. This allows you to do a little social engineering for the good folks by allowing these groups to participate in the process; they will more readily accept increased security restrictions in this case.

The following section reviews some actual security policies that my company (Granite Systems) uses and helps define how we treat security.

Acceptable Use Policy

SANS (http://www.sans.org) provides a wide range of security policies that are freely available on its website. These policies are based on these publicly available policies. Visiting SANS will complement what you learn from and implement based on this chapter. Granite Systems (http://www.granitesystems.net) based their policies on those recommended by SANS and have graciously allowed the publication of its internal practices in this book.

In this policy, the company’s IT Security Department is known simply as the Corporate Security Team for Granite Systems. Granite Systems and other Granite Systems-specific departments appear in italics throughout the policy; if you want to reuse this policy, you can replace these designations with your own.

Policy Overview

The Corporate Security Team’s intentions for publishing an Acceptable Use Policy are not to impose restrictions that are contrary to Granite Systems’ established culture of openness, trust, and integrity. Corporate Security is committed to protecting Granite Systems’ employees, partners, and the company from illegal or damaging actions by individuals, either knowingly or unknowingly.

Internet/intranet/extranet-related systems, including but not limited to computer equipment, software, operating systems, storage media, network accounts providing electronic mail, WWW browsing, and FTP, are the property of Granite Systems. These systems are to be used for business purposes that serve the interests of the company, its clients, and its customers.

Effective security is a corporatewide team effort involving the participation and support of every Granite Systems employee, contractor, business partner, or any affiliates who deal with information and information systems. It is the responsibility of every computer user to know the guidelines contained within this security policy and to conduct their activities accordingly.

Purpose

The purpose of this security policy is to outline the acceptable use of computer equipment at Granite Systems. These rules are in place to protect the employee and Granite Systems. Inappropriate use exposes Granite Systems to risks, including but not limited to virus attacks, compromise of network systems and services, and legal issues.

Scope

This security policy applies to employees, contractors, consultants, temporaries, and other workers at Granite Systems, including all personnel affiliated with third parties. This policy applies to all equipment that is owned or leased by Granite Systems, to include personal equipment that might come in contact with the corporate IT infrastructure.

General Use and Ownership

1. While Granite Systems’ Corporate Security Team desires to provide a reasonable level of privacy, users should be aware that the data they create on the corporate systems remains the property of Granite Systems. Because of the need to protect Granite Systems’ network, management cannot guarantee the confidentiality of information stored on any network device belonging to Granite Systems.
2. Employees are responsible for exercising good judgment regarding the reasonableness of personal use. Individual departments are responsible for creating guidelines concerning personal use of Internet/intranet/extranet systems. In the absence of such policies, employees should be guided by departmental policies on personal use and, if there is any uncertainty, employees should consult their supervisor or manager.
3. The Corporate Security Team recommends that any information that users consider sensitive or vulnerable be encrypted. For guidelines on information classification, see the Corporate Security Team’s Information Sensitivity Policy. For guidelines on encrypting e-mail and documents, go to Security Team’s Awareness Initiative.
   

   Note

   

   In many cases, you will see a security policy that references other policies within an organization. This is considered reasonable and considered a best practice. This allows you to keep a policy specific to the topic at hand. Consider the preceding points, which reference encryption of data. Realistically, everyone within an organization must read and sign an acceptable use Security Policy; however, compare that to those who would be expected to encrypt data, a vastly different list and type of person. Thus, these policies are kept separate, thereby allowing or preventing confusion on the part of the user.

4. For security and network maintenance purposes, authorized individuals within Granite Systems may monitor equipment, systems, and network traffic at any time, per the Corporate Security Team’s Audit Policy.
5. Granite Systems reserves the right to audit any and all networks and related systems on a periodic or ad hoc basis to ensure compliance with this policy.

Security and Proprietary Information

1. The user interface for information contained on Internet/intranet/extranet-related systems should be classified as either confidential or not confidential, as defined by corporate confidentiality guidelines, the details of which can be found in the Granite Systems Human Resources policies. Examples of confidential information include, but are not limited to the following:
   

   — Company private or confidential

   — Corporate strategies or projections

   — Competitor-sensitive or competitive analyses

   — Trade secrets, patents, test results

   — Specifications, operating parameters

   — Customer lists and data

   — Research data

   Employees should take all necessary steps to prevent unauthorized access to this information. If an employee suspects that such information has been released outside the company, he should notify Corporate Security immediately.

2. Keep passwords secure and do not share accounts. Authorized users are responsible for the security of their passwords and accounts. System-level passwords should be changed quarterly; user-level passwords should be changed every six months.
3. All PCs, laptops, and workstations should be secured with a password-protected screensaver with the automatic activation feature set at 10 minutes or less, or by logging off (Ctrl-Alt-Delete for Win2K users) when the host will be unattended.
   

   Note

   

   The items discussed in 2 and 3 presuppose that best practices are, in fact, being used. This means there is a dependency that servers require users to change passwords and that these passwords follow specific guidelines, as you will see later in the section, “Password Policy.”

4. Use encryption of information in compliance with Corporate Security Acceptable Encryption Use policy.
5. Because information contained on portable computers is especially vulnerable, special care should be exercised. Protect laptops in accordance with the “Laptop Security Tips.”
6. Postings by employees from an Granite Systems e-mail address to newsgroups should contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of Granite Systems, unless posting is in the course of business duties.
7. All hosts used by the employee that are connected to the Granite Systems Internet/intranet/extranet, whether owned by the employee or Granite Systems, shall be continually executing approved virus-scanning software with a current virus database.
   

   Note

   

   This portion of the policy reflects the strong trend of people checking e-mail from multiple PCs and different physical locations. Consider an employee who might check his free web mail service at work and download a file that contains a virus without realizing it. The goal here is to ensure that, when at work, an approved virus checker catches this virus. However, if an employee accesses the same e-mail from a home PC that she uses to connect to the corporate network, the vulnerability and ramifications should be closely considered.

8. Employees must use extreme caution when opening e-mail attachments received from unknown senders that might contain viruses, e-mail bombs, or Trojan horse code. When in doubt, employees are advised to manually scan the document and contact Corporate Security before opening them.

Unacceptable Use

The following activities are, in general, prohibited. Employees can be exempted from these restrictions during the course of their legitimate job responsibilities (For example, systems administration staff might have a need to disable the network access of a host if that host is disrupting production services.)

Under no circumstances is an employee of Granite Systems authorized to engage in any activity that is illegal under local, state, federal or international law while utilizing Granite Systems-owned resources.

The lists that follow are by no means exhaustive, but they attempt to provide a framework for activities that fall into the category of unacceptable use. If an employee has any questions regarding the appropriateness of an action, he should contact Corporate Security for clarification.

System and Network Activities

The following activities are strictly prohibited, with no exceptions:

1. Violations of the rights of any person or company protected by copyright, trade secret, patent, or other intellectual property or similar laws or regulations, including, but not limited to the installation or distribution of “pirated” or other software products that are not appropriately licensed for use by Granite Systems.
2. Unauthorized copying of copyrighted material including, but not limited to digitization and distribution of photographs from magazines, books, or other copyrighted sources, copyrighted music, and the installation of any copyrighted software for which Granite Systems or the end user does not have an active license is strictly prohibited.
3. Exporting software, technical information, encryption software, or technology in violation of international or regional export control laws is illegal.
   

   The appropriate employee manager should be consulted prior to export of any material that is in question.

   Note

   

   These first several instances are important for a security policy and an organization on many different levels. Consider probably the most vocal and legally active organizations on the Internet:

   • Recording Industry Association of America (http://www.riaa.org)

   • Report Cable Theft (http://www.cabletheft.com/)

   • Business Software Alliance (http://www.bsa.org/)

   These organizations monitor theft, pirating, copyright violations, and so on, and prosecute those who engage in these activities. Individuals and businesses have been the primary legal targets of those engaged in this activity; they have been successful and are set to tackle educational institutions and the pirating that goes on from their campuses.

4. Introduction of malicious programs into the network or server (for example, viruses, worms, Trojan horses, e-mail bombs, and so on).
5. Revealing your account password to others or allowing use of your account by others. This includes family and other household members when work is being done at home.
   

   Note

   

   Note that no one in the company will ever ask for your password. In the event of a technical difficulty, they will reset the password. Never reveal your password to anyone and, if asked, report the request to corporate security immediately.

6. Using an Granite Systems computing asset to actively engage in procuring or transmitting material that is in violation of sexual harassment or hostile workplace laws in the user’s local jurisdiction.
7. Making fraudulent offers of products, items, or services originating from any Granite Systems account.
8. Making statements about warranty, expressly or implied, unless it is a part of normal job duties.
9. Effecting security breaches or disruptions of network communication. Security breaches include, but are not limited to, accessing data of which the employee is not an intended recipient or logging in to a server or account that the employee is not expressly authorized to access, unless these duties are within the scope of regular duties. For purposes of this section, “disruption” includes, but is not limited to, network sniffing, pinged floods, packet spoofing, denial of service, and forged routing information for malicious purposes.
10. Port scanning or security scanning is expressly prohibited unless prior notification to Corporate Security Team is made.
11. Executing any form of network monitoring that will intercept data that is not intended for the employee’s host, unless this activity is a part of the employee’s normal job/duty.
12. Circumventing user authentication or security of any host, network, or account.
13. Interfering with or denying service to any user other than the employee’s host (for example, denial of service attack).
14. Using any program/script/command, or sending messages of any kind with the intent to interfere with or disable a user’s terminal session via any means, locally or via the Internet/intranet/extranet.
15. Providing information about or lists of Granite Systems employees to parties outside Granite Systems.

E-mail and Communications Activities

1. Sending unsolicited e-mail messages, including the sending of “junk mail” or other advertising material to individuals who did not specifically request such material (e-mail spam).
2. Any form of harassment via e-mail, telephone, or paging, whether through language, frequency, or size of messages.
3. Unauthorized use or forging of e-mail header information.
4. Solicitation of e-mail for any other e-mail address, other than that of the poster’s account, with the intent to harass or to collect replies.
5. Creating or forwarding “chain letters,” “Ponzi,” or other “pyramid” schemes of any type.
6. Use of unsolicited e-mail originating from within Granite Systems’ networks of other Internet/intranet/extranet service providers on behalf of, or to advertise, any service hosted by Granite Systems or connected via Granite Systems’ network.
7. Posting the same or similar nonbusiness-related messages to large numbers of Usenet newsgroups (newsgroup spam).

Enforcement

Any employee found to have violated this policy might be subject to disciplinary action, up to and including termination of employment.

Conclusion

Every security policy should end with a few common elements to clear up any potential miscommunication and confusion on the part of the user now that he understands what is permitted and what is not:

1. Enforcement—The most important element is the enforcement and the ramifications to an employee if these policies are violated.
2. Definitions—Not every employee or user will understand some of the terminology used in a policy; therefore, it is a good idea to provide yet another level of clarification by defining industry-specific terms.
3. Revisions—Changes are always applied to policies such as these. The source of these changes alter with time; however, it might be a change in management, new laws, or perhaps a clarification of older laws, new threats against your network’s security, your company has decided it wants to become certified (for example, ISO), or perhaps your company has new technology that needs to be covered. All these factors might require a policy change, and it is wise to document the changes.

While these kinds of policies have a tendency to upset people who think they are entitled something from their employer, in fact they are not; they are there to contribute to the company’s business goals. This fundamental truth allows the policy to protect the company, its employees, and everyone associated with it. Quoting from Star Trek II: The Wrath of Khan, “The needs of the many outweigh the needs of the few.” Being one of a few power users in my organization, I do not look forward to approving policies; however, it is the right thing to do for the company.

Password Policy

SANS (http://www.sans.org) provides a wide range of security policies that are freely available on its website. These policies are based on these publicly available policies. You should visit SANS and use discussions in this chapter to spark your ideas. Granite Systems (http://www.granitesystems.net) based these policies on those recommended by SANS and allowed me to present them here.

In this policy, the company’s IT Security Department is known simply as the Corporate Security Team for Granite Systems. Granite Systems and other Granite Systems-specific departments will appear in italics throughout the policy; if you want to reuse this policy, you can replace these designations with your own.

Overview

Passwords are an important aspect of computer security. They are the first line of protection for user accounts. A poorly chosen password might result in the compromise of Granite Systems’ entire corporate network. As such, all Granite Systems employees (including contractors and vendors with access to Granite Systems systems) are responsible for taking the appropriate steps for selecting and securing their passwords, as outlined in the following sections.

Purpose

The purpose of this policy is to establish a standard for the creation of strong passwords, the protection of those passwords, and to define how often you should change them.

Scope

The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any Granite Systems facility, has access to the Granite Systems network, or stores any nonpublic Granite Systems information.

General Policy

All system-level passwords (for example, root, enable, NT admin, application administration accounts, and so on) must be changed on at least a quarterly basis.

• All production system-level passwords must be part of the Corporate Security Team’s administered global password management database.

• All user-level passwords (for example, e-mail, web, desktop computer, and so on) must be changed at least every six months. The recommended change interval is every four months.

• User accounts that have system-level privileges granted through group memberships or programs such as administrator or root must have a unique password from all other accounts held by that user.

• Passwords must not be inserted into e-mail messages or other forms of electronic communication.

• Passwords must never be given out to anyone, regardless of their position in the company. Employees are instructed to contact Corporate Security if anyone asks for your password, before giving it out.

• Where SNMP is used, the community strings must be defined as something other than the standard defaults of “public,” “private,” and “system,” and must be different from the passwords used to login interactively. A keyed hash must be used where available (for example, SNMPv2).

All user-level and system-level passwords must conform to the guidelines described in the following section.

General Password Construction Guidelines

Passwords are used for various purposes at Granite Systems. Some of the more common uses include user-level accounts, web accounts, e-mail accounts, screensaver protection, voicemail password, and local router logins. Because few systems have support for one-time tokens (that is, dynamic passwords that are only used once), everyone should be aware of how to select strong passwords.

Poor, weak passwords have the following characteristics:

• The password contains less than eight characters.

• The password is a word found in a dictionary (English or foreign).

• The password is a common usage word such as the following:

— Names of family, pets, friends, coworkers, fantasy characters, and so on

— Computer terms and names, commands, sites, companies, hardware, software

— The words Granite Systems, energy, Granite Systems, or any derivation

— Birthdays and other personal information such as addresses and phone numbers

— Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, and so on

— Any of the previous words spelled backward

— Any of the previous words preceded or followed by a digit (for example, secret1, 1secret)

— Sports teams or famous players

Strong passwords have the following characteristics:

• Contain both upper- and lowercase characters (for example, a-z, A-Z)

• Have digits and punctuation characters and letters (for example, 0-9, !@#$%^&*()_+|~-=`{}[]:“;’<>?,./)

• Are at least eight alphanumeric characters in length

• Are not words in any language, slang, dialect, jargon, and so on

• Are not based on personal information, names of family, and so on

• Passwords should never be written down or stored online. Try to create passwords that you can remember easily. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: “This May Be One Way To Remember,” and the password could be: “TmB1w2R!” or “Tmb1W>r~,” or some other variation. NOTE: Do not use either of these examples as passwords.

Password Protection Standards

Do not use the same password for Granite Systems accounts as for other non-Granite Systems access (for example, personal ISP account, option trading, benefits, and so on). Where possible, do not use the same password for various Granite Systems access needs. For example, select one password for the engineering systems and a separate password for IT systems. Also, select a separate password to be used for an NT account and a UNIX account.

Do not share Granite Systems passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential Granite Systems information.

Following is a list of “don’ts”:

• Do not reveal a password over the phone to ANYONE.

• Do not reveal a password in an e-mail message.

• Do not reveal a password to the boss.

• Do not talk about a password in front of others.

• Do not hint at the format of a password (for example, “my family name”).

• Do not reveal a password on questionnaires or security forms.

• Do not share a password with family members.

• Do not reveal a password to coworkers while on vacation.

If someone demands a password, refer him to this document or have him call someone in the Corporate Security Team.

Do not use the “Remember Password” feature of applications (for example, Eudora, Outlook, Netscape Messenger).

Again, do not write passwords down and store them anywhere in your office. Do not store passwords in a file on any computer system (including Palm Pilots or similar devices) without encryption that has been approved by the Corporate Security Team.

Change passwords at least once every six months (except system-level passwords, which must be changed quarterly). The recommended change interval is every four months.

If an account or password is suspected to have been compromised, report the incident to the Corporate Security Team and change all passwords immediately.

The Corporate Security Team or its delegates can perform password cracking or guessing on a periodic or random basis. If a password is guessed or cracked during one of these scans, the user will be required to change it.

Enforcement

Any employee found to have violated this policy might be subject to disciplinary action, up to and including termination of employment.

Conclusion

Every security policy ends with a few common elements. These elements clear up all potential miscommunication and confusion on the part of the user, now that she understands what is permitted and what is not.

1. Enforcement—The most important element is the enforcement and the ramifications to an employee in the event that these policies are violated.
2. Definitions—Not every employee or user understands some of the terminology used in a policy; thus, it is always a good idea to provide yet another level of clarification by defining industry specific terms.
3. Revisions—Changes are always applied to policies such as these. The source of these changes alter with time, however; it might be a change in management, new laws, clarification of older laws, new threats against your network’s security, your company has decided it wants to become certified (for example, ISO), or perhaps your company has new technology that needs to be covered. All these factors might require a policy change, and it is wise to be able to document the changes.

Users always try and get around the restrictions placed on them via a password policy—no one likes to remember the cryptic passwords required in such a policy. If a user does remember a password that meets these guidelines, do not worry—he will have to change it soon!

Unfortunately for users, they will have to remember and follow this policy. Note that password security is the first step in protecting your network; as such, beginning with the right expectations of your users helps to ensure that the overall security of your organization is preserved.

The next section examines a security policy that is targeted at virtual private networks (VPNs) and what to look for to ensure their security.

Virtual Private Network (VPN) Security Policy

Chapter 7, “IPSec Virtual Private Networks (VPNs),” covers VPNs in more detail; however, because this chapter covers security policies, the growth of VPNs that are in use today demands inclusion of a sample policy for VPNs here. This policy is prefaced by a brief definition of what a VPN is, but you should refer to Chapter 7 for the full scope of this technology.

VPNs are becoming popular and have matured considerably in the last several years. Many companies are using them as a means of securely connecting small remote offices or users of every description. The connections can be made secure through the use of IPSec (IP Security) and L2TP (Layer Two Tunneling Protocol) and with the increasing prevalence of high-speed Internet connections such as DSL or cable VPNs becoming very affordable. Therefore, it becomes important to have a security policy to regulate their use so that all traffic is properly secured.

SANS (http://www.sans.org) provides a wide range of security policies that are freely available on its website. These security policies are based on these publicly available policies. I strongly encourage you to visit SANS and use the discussions in this chapter to spark your ideas. Granite Systems (http://www.granitesystems.net) based these policies on those recommended by SANS and have allowed me to present them here.

In this policy, the company’s IT Security Department is known simply as the Corporate Security Team for Granite Systems. Granite Systems and other Granite Systems-specific departments appear in italics throughout the policy; if you want to reuse this policy, you can replace these designations with your own.

Purpose

The purpose of this policy is to provide guidelines for Remote Access IPSec or L2TP virtual private network (VPN) connections to the Granite Systems corporate network.

Scope

This policy applies to all Granite Systems employees, contractors, consultants, temporaries, and other workers, including all personnel affiliated with third parties that utilize VPNs to access the Granite Systems network. This policy applies to implementations of VPN that are directed through a VPN Concentrator or VPN-aware Firewall.

Policy

Approved Granite Systems employees and authorized third parties (customers, vendors, and so on) can utilize the benefits of VPNs, which are a “user managed” service. This means that the user is responsible for selecting an Internet service provider (ISP), coordinating installation, installing any required software, and paying associated fees.

Additionally:

1. It is the responsibility of employees with VPN privileges to ensure that unauthorized users are not allowed access to Granite Systems internal networks.
2. VPN use is to be controlled using either a one-time password authentication such as a token device or a public/private key system with a strong pass phrase.
3. When actively connected to the corporate network, VPNs force all traffic to and from the PC over the VPN tunnel; all other traffic is dropped.
4. Dual (split) tunneling is NOT permitted; only one network connection is allowed.
5. Split-tunneling is a method of configuring a VPN and is either on or off. Essentially, if split-tunneling is on, users are allowed to simultaneously connect to the corporate network and the Internet. This presents a danger to the corporate network’s security because if an attacker were to take control of the computer creating a VPN to the corporate network, the attacker could also gain access to the companies network via the VPN. It is therefore considered best practice to disable split-tunneling.
6. VPN Concentrators are set up and managed through Granite Systems network operational groups.
7. All computers connected to Granite Systems internal networks through VPN or any other technology must use the most up-to-date antivirus software that is the corporate standard and can be downloaded through the corporate intranet. This also includes personal computers.
8. VPN users are automatically disconnected from Granite Systems’ network after thirty minutes of inactivity. The user must then log in again to reconnect to the network. Pings or other artificial network processes are not to be used to keep the connection active.
9. Users of computers that are not Granite Systems-owned equipment must configure the equipment to comply with Granite Systems’ VPN and Network Security policies.
10. Only VPN Clients approved by the Corporate Security Team can be used.
11. By using VPN technology with personal equipment, users must understand that their machines are a de facto extension of Granite Systems’ network and, as such, are subject to the same rules and regulations that apply to Granite Systems-owned equipment; that is, their machines must be configured to comply with all Corporate Security Policies.

Conclusion

Every security policy should end with a few common elements; these elements clear up all potential miscommunication and confusion on the part of the user now that he understands what is and is not permitted:

1. Enforcement—The most important element is the enforcement and the ramifications to an employee if these policies are violated.
2. Definitions—Not every employee or user understands some of the terminology used in a policy; thus, it is always a good idea to provide yet another level of clarification by defining industry-specific terms.
3. Revisions—Changes are always applied to policies such as these. The source of these changes alter with time, however; it might be a change in management, new laws, or perhaps a clarification of older laws, new threats against your network’s security, your company has decided it wants to become certified (for example, ISO), or perhaps your company has new technology that needs to be covered. All these factors might require a policy change, and it is wise to document the changes.

VPN technology is ever-evolving, faster than most. As discussed, businesses are deploying VPNs in ever-increasing numbers; therefore, it is crucial that all organizations have policies governing their use. If there is a mistake with a VPN, the consequences can be costly from both a security and financial perspective.

The next section covers the security policy that is necessary when corporate business partners or other third parties need to connect to your organization’s network—a very sensitive situation, indeed.

Extranet Connection Policy

This security policy deals with “how to handle” and “the requirements” necessary for those not affiliated with your organization to connect to and access resources on the network.

The “who’s” and “why’s” behind such a request vary greatly and, when considering them, you should review the section on trust in Chapter 1, “Here There Be Hackers!” before making a decision. Requests will come to you from the following parties:

• Contractors trying to do legitimate work with your company

• Business partners of all sorts

• Customers, usually large and requiring special handling

This security policy provides the necessary guidelines for answering such requests and the requirements to be placed on the requestor. It also allows for the members of the IT Staff to deal with pushy and insistent people, making this policy a virtual panacea.

SANS (www.sans.org) provides a wide range of security policies that are freely available on its website. These policies are based on these publicly available policies. You should visit SANS and use the discussions in this chapter to spark your ideas. Granite Systems (http://www.granitesystems.net) based these policies on those recommended by SANS and allowed the policies to be presented here.

In this policy, the company’s IT Security Department is known simply as the Corporate Security Team for Granite Systems. Granite Systems and other Granite Systems-specific departments appear in italics throughout the policy; if you want to reuse this policy, you can replace these designations with your own.

Purpose

This document describes the policy under which third-party organizations or consultants connect to the Granite Systems network for the purpose of conducting business that is related to Granite Systems.

Scope

Regardless of whether a dedicated telecommunications circuit (such as frame relay or ISDN), broadband, or VPN technology is used for the connection, connections between third parties that require access to nonpublic Granite Systems resources fall under this policy. Connectivity to third parties such as Internet service providers (ISPs) that provide Internet access for Granite Systems or to the Public Switched Telephone Network (PSTN) do not fall under this policy.

Security Review

All new extranet connectivity will go through a security review with the Corporate Security Team. The security review ensures that all access matches the business requirements in the best possible way, and that the principle of least access is followed.

Third-Party Connection Agreement

All new connection requests between third parties and Granite Systems require that the third party and Granite Systems representatives agree to and sign the Third-Party Agreement. This agreement must be signed by the Vice President of the Sponsoring Organization as well as a representative from the third party who is legally empowered to sign on behalf of the third party. The signed document is to be kept on file with the company’s Legal Department and Corporate Security Department.

Business Case

All production extranet connections must be accompanied by a valid business justification, in writing, that is approved by the Director of Corporate Security. Included in this business case is the identification of the network resources that are requesting to be accessed.

Point of Contact

The Granite Systems Sponsoring Organization must designate a person to be the point of contact (POC) for the extranet connection. The POC acts on behalf of the Sponsoring Organization and is responsible for those portions of this policy and the Third-Party Agreement that pertain to it. In the event that the POC changes, the relevant extranet organization must be informed promptly.

Establishing Connectivity

Sponsoring Organizations within Granite Systems that want to establish connectivity to a third party are to file a new site request with the Corporate Security team. The sponsoring organization engages the Corporate Security Team to address security issues that are inherent in the project. The Sponsoring Organization must provide full and complete information as to the nature of the proposed access to the extranet group and Security Team, as requested.

All established connectivity must be based on the least-access principle, in accordance with the approved business requirements and the security review. In no case does Granite Systems rely upon the third party to protect Granite Systems’ network or resources.

Modifying or Changing Connectivity and Access

All changes in access must be accompanied by a valid business justification and are subject to security review. Changes are to be implemented via corporate change management process. The Sponsoring Organization is responsible for notifying the Corporate Security Team when there is a material change in their originally provided information so that security and connectivity evolve accordingly.

Terminating Access

When access is no longer required, the Sponsoring Organization within Granite Systems must notify the extranet team responsible for that connectivity; this terminate the access. This might mean a modification of existing permissions up to terminating the circuit, as appropriate. The Corporate Security Teams must conduct an audit of their respective connections annually to ensure that all existing connections are still needed and that the access meets the needs of the connection. Connections that are deprecated and are no longer being used to conduct Granite Systems business are terminated immediately. Should a security incident or a finding that a circuit has been deprecated and is no longer being used to conduct Granite Systems business necessitate a modification of existing permissions or termination of connectivity, Security Team notifies the POC or the Sponsoring Organization of the change before taking any action.

Conclusion

Every security policy should end with a few common elements. These elements clear up all potential miscommunication and confusion on the part of the users now that they understands what is and is not permitted:

1. Enforcement—The most important element is the enforcement and the ramifications to an employee if these policies are violated.
2. Definitions—Not every employee or user understands some of the terminology used in a policy; thus, it is always a good idea to provide yet another level of clarification by defining industry-specific terms.
3. Revisions—Changes are always applied to policies such as these. The source of these changes alter with time, however; it might be a change in management, new laws, or perhaps a clarification of older laws, new threats against your network’s security, your company has decided it wants to become certified (for example, ISO), or perhaps your company has new technology that needs to be covered. All these factors might require a policy change, and it is wise to document the changes.

It is always a touchy subject to grant such access to those outside your company. One of the things that happens is that employee A works with business partner Z, who needs to access some resource on your network; to complete the business, employee A promises partner Z access. Alternatively, it is someone in management that makes a promise.

These scenarios are common, and this policy helps ensure that, if such a requirement is needed, the proper due diligence is taken before making any promises given this established process.

Perhaps the fastest growing certification authority is the International Standards Organization (ISO). The following section briefly discusses how ISO has entered into the security arena. It is fitting to bring it to your attention because more and more companies are becoming ISO-certified to one degree or another.

ISO Certification and Security

Compliance with any internationally recognized standard is becoming more important. As a result, and because standards relevance is a common currency of instant legitimization, many companies are pursuing such a course. The ISO offers many standards, and all are valuable in their own right. For purposes of this discussion, the concern lies with standard ISO17799.

The ISO17799 standard is extremely comprehensive in its security coverage, and it contains a significant number of controls that are arranged into nine different areas:

• Business continuity planning—Details how to allow businesses to continue operating after a major failure or disaster.

• System access control—Outlines the control and access to information of all types within an organization and, more importantly, how to detect unauthorized activities.

• System development and maintenance—Covers the process of protecting assets and building security into all aspects of the organization’s IT systems, software, and data.

• Physical and environmental security—Ensures that unauthorized access or damage is prevented, regardless of the intent.

• Compliance—Allows organizations to know (via auditing) that they are not violating any civil law, statutory, regulatory, or contractual obligations, and informs them of any security requirements.

• Personnel security—Discusses how to reduce the risk of human error, theft, and misuse, thereby allowing minimization of damage from security incidents and malfunctions, and learning from such incidents.

• Security organization—Outlines how to maintain and manage the security of information within an organization.

• Computer and operations management—Details how to minimize risk while increasing security to ensure the safeguarding of information to prevent loss, modification, or misuse.

• Asset classification and control—Describes how to maintain the appropriate protection of corporate assets and to ensure that information assets receive an appropriate level of protection.

The ISO certification is briefly discussed here, but the standard is perhaps one of the most comprehensive and will be growing in use. To learn more, visit the ISO website at http://www.iso.org.

When delivering the security policy to users, you must then determine the most effective manner in which to present them to help facilitate compliance and support from your users. This is often much easier said than done.

Many discussions on the concepts and goals of security policies always seem to gloss over the delivery of these policies. Yet it is crucial for everyone to understand and more importantly support these policies. To not reach for this goal and to make the effort dooms the policy to failure and backlash from users because they will resent the policy from the beginning.

Handling these types of situations is similar to handling interpersonal relationships. Beyond good interpersonal skills, consider the following additional suggestions:

• Ensure that all policies are presented during new employee orientation.

• Always allow a sample of the personnel affected by a security policy to review it and provide input comment before implementing.

• Provide a security policy refresher course.

In general, you should keep policies short, less than two pages. There is no need to complicate the situation. Occasionally, you might have to go over, but not usually. In closing, ensure that your policies are updated annually, if not sooner, to reflect the changes of the past year.

Sample Security Policies on the Internet

Of course, the policies presented here are simply one means of meeting an organization’s needs; what works well for one organization might not be ideal for another. Thus, you should refer to the following additional resources on security policies:

• http://www.sans.org/rr/catindex.php?cat_id=50—This site contains articles and papers written by GIAC-certified professionals.

• http://www.ietf.org/rfc/rfc2196.txt?Number=2196—The Site Security Policies Procedure Handbook.

• http://www.securityfocus.com/data/library/Why_Security_Policies_Fail.pdf—A white paper (PDF).

Some general websites with information security policies include the following:

• http://www.security.kirion.net/securitypolicy/

• http://www.network-and-it-security-policies.com/

• http://www.brown.edu/Research/Unix_Admin/cuisp/

• http://iatservices.missouri.edu/security/

• http://www.utoronto.ca/security/policies.html

• http://irm.cit.nih.gov/security/sec_policy.html

• http://w3.arizona.edu/~security/pandp.htm

• http://secinf.net/ipolicye.html

• http://ist-socrates.berkeley.edu:2002/pols.html

• http://www.ruskwig.com/security_policies.htm

• http://razor.bindview.com/publish/presentations/InfoCarePart2.html

• http://www.jisc.ac.uk/index.cfm?name=publications

Chapter Summary

This chapter discussed what many view as simply paperwork when, in reality, a security policy reflects your company’s commitment to security. It included key concepts in writing a security policy, such as determining who and what to trust and who to involve in the writing and crafting of a security policy.

This chapter also presented a variety of sample security policies. These security policies reflect the current trends and major areas upon which companies can improve. Specifically, these areas include what is considered acceptable use of corporate IT resources, how to ensure that you have effective passwords, when and how to use VPNs, and what restrictions to use when connecting your network to a business partner’s network.

Chapter 3, “Overview of Security Technologies,” discusses the use of technologies that have evolved to support and enhance network security. Many of these technologies are used today without the reader understanding when or where they are operating. After reading this chapter, you should understand the benefits of these technologies, where they operate, and some of their associated risks.

Chapter Review

1. How important is it to involve other departments and employees in the crafting of security policies?

2. True or false: It is a well-known fact that users circumvent security policies that are too restrictive. Explain your answer.

3. What are three things that you should keep in mind when writing or reviewing a security policy?

4. Why is it important to include an enforcement section in every security policy?

5. An Acceptable Use Policy defines what kind of expectations for users?

6. When and under what circumstances should you reveal your password to someone?

7. Which of the following sample passwords would be considered effective when checked against the corporate password policy?

a. wolfpack

b. thomas67

c. simonisnot4

d. sJ8Dtt&efs

e. Missing$4u

8. Define VPN and the role it can play within a company’s network infrastructure.

9. VPNs support a technology called split tunneling: define this technology and explain whether it should be used in a network?

10. How frequently should security policies be updated or reviewed?