If you are implementing or supporting a VPN solution, use a VPN policy to ensure that your users understand the requirements for computing on the VPN. A VPN policy is sometimes called a remote access policy, a term used when dial-up lines and modems were the primary means to access the network remotely.

Keep in mind that a VPN policy should be a part of your overall policy framework, not a standalone. If you try to develop your VPN policy in isolation from the overall policy framework, you may find that you are duplicating information, or potentially writing VPN policy that conflicts with other aspects of your overall security policy framework. For example, if you put a requirement in your VPN policy that user passwords must be 15 characters long but the password policy states that passwords have to be eight characters long, you will confuse end users.

The components of a solid VPN policy include:

• Introduction—State the policy by name and tell how it fits into the organization’s policy framework.
• Purpose—Describe the issues the policy addresses and how the policy should be used. Include references to any applicable governance, risk, or compliance issues, as well as any specific legal or regulatory requirements supported by the document.
• Scope/binding nature statement—Describe the systems, networks, or people covered by the policy, and outline the penalties for not following the policy. The phrase “disciplinary action up to and including termination” is common in security policies.
• Definitions/acronyms—Define technical terms or acronyms used in the policy. Readers of the policy may not be familiar with the terms or jargon used.
• Document—Include the document creator, creation date, version, document status (e.g., draft, template, policy, and guidelines), as well as any version tracking information.
• Policy—This is the actual policy language. Be very clear in this section, leaving as little open to interpretation as possible.
• Optional elements
  • Summary—If your policy is long, you may want to summarize it in a bulleted list at either the beginning or end of the policy. This provides employees a quick method to check for policy statements.
  • Roles and responsibilities—If your document is lengthy, or you need to document who does what under the policy, include roles and responsibilities. For example, a policy dealing with infrastructure might include roles for the system manager, system architect, end user, developer, or other key people within the organization.

Some specific topics to include in your VPN policy are:

• Restrict remote access to the organization’s VPN solution.
• Prohibit split tunneling.
• Define which classes of employee can access the network by VPN. This could include regular employees, vendors, contractors, and temps, or it could be restricted to only home office workers, depending on business requirements.
• Define which types of VPN connections will be permitted.
• Define authentication methods permitted.
• Prohibit sharing of VPN credentials.
• List the configuration requirements for remote hosts, including current virus protection, anti-malware, host-based intrusion detection system (HIDS), and a personal firewall. Some VPN solutions include the ability to check for these types of configurations.
• Prohibit the use of noncompany equipment or, if personal systems may connect to the VPN, define the minimum standards for those connections.
• Define required encryption levels for VPN connections.
• If you will be using your VPN for network-to-network connections, define the approval process and criteria for establishing a network-to-network connection.

Have your policy reviewed and approved by your communications, legal, and human resources departments before release. Document the appropriate approvals in the document status portion of the policy, then communicate the policy to the employees. Posting the policy to an information security or security policy intranet website is a common practice. Once it is available on the intranet, you can use standard communications methods to make employees aware of the policy requirements. These methods can include email, a structured awareness program, inclusion in new-hire training, or even web-based or in-person policy training. The method you select will be based on your organization’s size, locations, and requirements. The key with any type of awareness training is to structure your communications to the correct audience. A group of engineers will require a very different introduction to a technical policy than a sales team.

These are just some of the factors in developing a VPN policy for your organization. Although these should form the basis for the development of your organization’s policy, be sure to cover all applicable requirements. One sure way to alienate your employees is to release a policy that makes no sense to them or that you have to revise too soon to cover things you didn’t think of in the first version. Take your time, consider all the requirements, and you will end up with a usable VPN policy.