IS AUDITING GUIDELINE

REVIEW OF VIRTUAL PRIVATE NETWORKS

DOCUMENT G25
The specialised nature of information systems (IS) auditing and the skills necessary to perform such audits require standards that apply
specifically to IS auditing. One of the goals of the Information Systems Audit and Control Association (ISACA) is to advance globally
applicable standards to meet its vision. The development and dissemination of the IS Auditing Standards are a cornerstone of the ISACA
professional contribution to the audit community. The framework for the IS Auditing Standards provides multiple levels of guidance.

Standards define mandatory requirements for IS auditing and reporting. They inform:
− IS auditors of the minimum level of acceptable performance required to meet the professional responsibilities set out in the ISACA Code
of Professional Ethics for IS auditors
− Management and other interested parties of the profession’s expectations concerning the work of practitioners
®
− Holders of the Certified Information Systems Auditor (CISA ) designation of requirements. Failure to comply with these standards may
result in an investigation into the CISA holder's conduct by the ISACA Board of Directors or appropriate ISACA committee and, ultimately,
in disciplinary action.

Guidelines provide guidance in applying IS Auditing Standards. The IS auditor should consider them in determining how to achieve
implementation of the standards, use professional judgment in their application and be prepared to justify any departure. The objective of
the IS Auditing Guidelines is to provide further information on how to comply with the IS Auditing Standards.

Procedures provide examples of procedures an IS auditor might follow in an audit engagement. The procedure documents provide
information on how to meet the standards when performing IS auditing work, but do not set requirements. The objective of the IS Auditing
Procedures is to provide further information on how to comply with the IS Auditing Standards.

COBIT resources should be used as a source of best practice guidance. Each of the following is organised by IT management process, as
defined in the COBIT Framework. COBIT is intended for use by business and IT management as well as IS auditors; therefore, its usage
enables the understanding of business objectives, and communication of best practices and recommendations, to be made around a
commonly understood and well-respected standard reference. COBIT includes:
− Control Objectives—High-level and detailed generic statements of minimum good control
− Control Practices—Practical rationales and guidance on how to implement the control objectives
− Audit Guidelines—Guidance for each control area on how to obtain an understanding, evaluate each control, assess compliance, and
substantiate the risk of controls not being met
− Management Guidelines—Guidance on how to assess and improve IT process performance, using maturity models, metrics and critical
success factors

Glossary of terms can be found on the ISACA web site at www.isaca.org/glossary. The words audit and review are used interchangeably.

Disclaimer: ISACA has designed this guidance as the minimum level of acceptable performance required to meet the professional
responsibilities set out in the ISACA Code of Professional Ethics for IS auditors. ISACA makes no claim that use of this product will assure a
successful outcome. The publication should not be considered inclusive of any proper procedures and tests or exclusive of other procedures
and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific procedure or test, the
controls professional should apply his/her own professional judgment to the specific control circumstances presented by the particular
systems or information technology environment.

The ISACA Standards Board is committed to wide consultation in the preparation of the IS Auditing Standards, Guidelines and Procedures.
Prior to issuing any documents, the Standards Board issues exposure drafts internationally for general public comment. The Standards
Board also seeks out those with a special expertise or interest in the topic under consideration for consultation where necessary. The
Standards Board has an ongoing development programme and welcomes the input of ISACA members and other interested parties to
identify emerging issues requiring new standards. Any suggestions should be e-mailed (standards@isaca.org), faxed (+1.847. 253.1443) or
mailed (address at the end of document) to ISACA International Headquarters, for the attention of the director of research standards and
academic relations.

This material was issued on 1 April 2004.

Information Systems Audit and Control Association 2003-2004 Standards Board

Chair, Claudio Cilli, Ph.D., CISA, CISM, CIA, CISSP Value Partners, Italy
Svein Aldal Scandinavian Business Security AS, Norway
John W. Beveridge, CISA, CFE, CGFM, CQA Commonwealth of Massachusetts, USA
Sergio Fleginsky, CISA PricewaterhouseCoopers, Uruguay
Christina Ledesma, CISA, CISM Citibank NA Sucursal, Uruguay
Andrew MacLeod, CISA, FCPA, MACS, PCP, CIA Brisbane City Council, Australia
Ravi Muthukrishnan, CISA, CISM, FCA, ISCA NextLinx India Private Ltd., India
Peter Niblett, CISA, CA, CIA, FCPA WHK Day Neilson, Australia
John G. Ott, CISA, CPA Aetna Inc., USA
 1. BACKGROUND

1.1 Linkage to Standards

1.1.1 Standard S6 Performance of Audit Work states, "During the course of the audit, the IS auditor should obtain sufficient, reliable and
relevant evidence to achieve the audit objectives. The audit findings and conclusions are to be supported by appropriate analysis
and interpretation of this evidence."
1.1.2 Guideline G16 Effect of Third Parties on an Organisation’s IT Controls provides guidance.
1.1.3 Guideline G17 Effect of Nonaudit Roles on the IS Auditor’s Independence provides guidance.

1.2 Linkage to COBIT

1.2.1 COBIT Framework states, "It is management's responsibility to safeguard all the assets of the enterprise. To discharge this
responsibility, as well as to achieve its expectations, management must establish an adequate system of internal control."
1.2.2 COBIT Management Guidelines provides a management-oriented framework for continuous and proactive control self-assessment
specifically focused on:
„ Performance measurement—How well is the IT function supporting business requirements?
„ IT control profiling—What IT processes are important? What are the critical success factors for control?
„ Awareness—What are the risks of not achieving the objectives?
„ Benchmarking—What do others do? How can results be measured and compared?
1.2.3 Management Guidelines provides example metrics enabling assessment of IT performance in business terms. The key goal
indicators identify and measure outcomes of IT processes, and the key performance indicators assess how well the processes are
performing by measuring the enablers of the process. Maturity models and maturity attributes provide for capability assessments
and benchmarking, helping management to measure control capability and identify control gaps and strategies for improvement.
1.2.4 Management Guidelines can be used to support self-assessment workshops and can also be used to support the implementation
by management of continuous monitoring and improvement procedures as part of an IT governance scheme.
1.2.5 COBIT provides a detailed set of controls and control techniques for the information systems management environment. Selection
of the most relevant material in COBIT applicable to the scope of the particular audit is based on the choice of specific COBIT IT
processes and consideration of COBIT’s information criteria.
1.2.6 The COBIT references located in the appendix of this document offer the specific objectives or processes of COBIT to consider
when reviewing the area addressed by this guidance.

1.3 Need for Guideline

1.3.1 The purpose of this guideline is to describe the recommended practices in carrying out the review of virtual private network (VPN)
implementations so that the relevant IS Auditing Standards are complied with during the course of the review.

2. VIRTUAL PRIVATE NETWORK (VPN)

2.1 Definition
2.1.1 Virtual Private Networking—New Issues for Network Security , published by the IT Governance Institute, defines VPN as a:
“…network of virtual circuits that carries private traffic through public or shared networks such as the Internet or those provided by
network service providers (NSPs).” For the purpose of this guideline, this definition of VPN is used.
2.1.2 In the context of VPN, the terms “tunnel” and “tunneling” are often used. The process of encapsulating one type of packet in
another packet type so the data can be transferred across paths that otherwise would not transmit the data is called tunneling. The
paths the encapsulated packets follow in an Internet VPN are called tunnels.

2.2 VPN Models

2.2.1 There are three common VPN models for deployment. The major differences among the models are in the location of their service
end points or tunnel end points, the level of management required, quality of service, and the reliance on direct service provider
involvement. The three most common models are:
„ Pure provider model
„ Hybrid provider model
„ End-to-end model

2.2.2 In the pure provider model, most of the VPN functionality is built into the service provider infrastructure and not in the network of
the organisation. This model is often deployed over one service provider’s network. There is a clear line of distinction between the
organisation’s network and the service provider’s network. Remote access to the organisation’s network is typically provided by a
dedicated circuit (such as, T1, T3), ATM connections or dedicated frame relay connections. The customer owns and operates the
remote access VPN-related equipment and software in the network, while equipment and software inside the service provider’s
network, from the physical circuit out, is owned and operated by the service provider. The service provider initiates VPN tunnels
from edge-to-edge of the network and relies on the private circuits on either end for security. In this model, the provider has a high
level of control over the network and is responsible for capacity planning, design, configuration, diagnostics and troubleshooting.

Page 2 Review of Virtual Private Networks Guideline

2.2.3 The hybrid provider model involves the networks of both the service provider and the organisation. A VPN tunnel is initiated from
inside the provider’s network, and the tunnel is terminated at the organisation’s network. In this model, the service provider is
responsible for the initiation of the VPN tunnels for the remote users after the users are authenticated. When the remote user
reaches the organisation’s network, a second authentication may be required before being granted access permission to the
private network. Users can access the network facilities as if they are directly connected to the enterprise LAN, once they are
authenticated.
2.2.4 In the end-to-end model, the service provider serves only as a transport for the VPN data. The service end points or tunneling
could be the desktop or a VPN device that serves as a proxy for multiple desktops. Both service end points are outside the service
provider’s network. This model can be used for remote access or to connect multiple sites.

2.3 VPN Usage

2.3.1 There are various ways to use a VPN, depending upon the model used. The most common are:
„ Site-to-site connectivity
„ Remote access connectivity
„ Extended enterprise extranet connectivity

2.3.2 The site-to-site connectivity provides separate intranets to connect securely, effectively creating one large intranet. Site-to-site
VPNs are often used by geographically distributed organisations to create a single logical network.
2.3.3 The remote access connectivity permits mobile employees to access the organisation’s intranet, via the Internet, using a secure
network communications. This is used in combination with global dial-up, wireless and broadband ISPs. Many organisations use
remote access VPNs to provide low-cost network accessibility to their employees.
2.3.4 Extended enterprise extranet connectivity provides connections to networks outside the enterprise. Business, research or
marketing partners often use these to speed communications through secured connections. Generally, extranets have stronger
controls in place to allow, manage and monitor network-to-network traffic, and the internal network may be protected from the
extranet via firewalls.

2.4 VPN Architecture

2.4.1 There are many possible options for installing VPNs. A VPN supplied by a network service provider is one of the most common
approaches to connect an organisation to the Internet. The VPN architecture in any organisation could be one or combinations of
the following:
„ Firewall-based VPNs
„ Router-based VPNs
„ Remote access-based VPNs
„ Hardware (black box)-based VPNs
„ Software-based VPNs

2.4.2 The firewall-based VPNs are the most common form of implementation. Since most organisations already use a firewall to
connect to the Internet, they need to add encryption software and some kind of authorisation software.
2.4.3 There are two types of router-based VPNs. In one, software is added to the router to allow encryption to occur. With the second
type, a third-party vendor-supplied external card must be inserted into the same chassis as the router to off-load the encryption
process from the router’s CPU to the card.
2.4.4 With remote access-based VPNs, someone from a remote location can create an encrypted packet stream or tunnel to a network
device in the organisation.
2.4.5 With hardware (black box)-based VPNs, the vendor offers a black box, or a device with encryption software, to create a VPN
tunnel. The black box VPN device is ordinarily behind the firewall or on the side of the firewall to secure the data, but in fact the
VPN system may be wholly independent of the firewall.
2.4.6 In software-based VPNs, the software handles the tunneling to another client or encryption of packets. Software is loaded on the
client and the server. Traffic starts from a specific client within the organisation and makes a connection to a server located at the
remote site. Traffic leaving the client is encrypted or encapsulated, and routed to its destination. The same applies for someone
trying to connect to the internal network.

2.5 VPN Configuration/Topology

2.5.1 When configuring the VPN, parameters must be set for key length, authentication servers, connection and idle timeouts, certificate
generation and key generation, and distribution mechanisms. There are numerous ways to configure and implement VPN
architecture and to place the architecture in a VPN topology. Organisations could use one or combinations of the following most
commonly used topologies in a VPN configuration:
„ Firewall-to-client
„ LAN-to-LAN
„ Firewall-to-intranet/extranet
„ Hardware and software VPN

2.5.2 Firewall-to-client is the most commonly used topology, and it applies to remote users who dial into an internal network.
2.5.3 LAN-to-LAN is the second most commonly used topology. It extends the firewall-to-client topology to different remote offices and
among offices, business partners and suppliers when a VPN tunnel has been created between two sites.
2.5.4 In firewall-to-intranet/extranet topology, intranets are used by employees and extranets are used externally by customers,
business partners and suppliers. When remote users try to access servers on the extranet or intranet, a decision must be made as
to which server they may access.

Review of Virtual Private Networks Guideline Page 3

 2.5.5 Hardware and software VPNs are stand-alone devices designed to implement VPN technology algorithms. A VPN device is
ordinarily behind the firewall on the internal network. Data packets flow through the firewall and the VPN device. As the packets
pass through these devices, they can be encrypted. Generally in software encryption models like the SSL protocol, the special
devices (authentication) are not required and the packet flow is encrypted by the software.

2.5.6 VPN technologies and protocols include:

„ PPTP (point to point tunneling protocol)
„ L2TP (layer 2 tunneling protocol)
„ IPSec (Internet protocol security)
„ SSL (secure socket layer)

3. RISKS ASSOCIATED WITH VPNs

3.1 Types of Risks

3.1.1 Since VPN is a communication infrastructure for the business that uses third-party services, the risks associated with it could be
categorised as:
„ Security risk
„ Third-party risk
„ Business risk
„ Implementation risk
„ Operating risk

3.2 Security and Legal Risk

3.2.1 The security risks relating to VPNs include:
„ Inadequate assessment of security and legal risks arising out of using VPNs
„ Insufficient security programs to mitigate risks to information assets arising out of VPNs
„ Inadequate protection of data while they are at the point before entering the VPN, or once they arrive at the point on leaving
the VPN
„ Failure to secure information while unencrypted over a given network path (internal networks before encryption device or
external networks after decryption device)
„ Lack of implementation that could result in confidentiality, integrity, nonrepudiation and/or availability issues.

3.3 Third-party Risk

3.3.1 The reliance on third-party service providers could result in risks such as:
„ Choice of an inappropriate provider
„ Inadequate relationship management
„ Inadequacies in service level agreements (SLA) and metrics
„ Inappropriate governance and management process
„ Inadequate measuring and monitoring of SLAs and metrics
„ Inadequate backup/redundancy strategy
„ Insufficient benchmarking of the relationship and services
„ Abuse of access to data on the VPN

3.4 Business Risk

3.4.1 Risks such as the following could lead to nonfulfillment of the management or business expectations:
„ Inadequate alignment to business strategy
„ Inadequate cost savings
„ Failure to achieve security requirements
„ Insufficient ease of use
„ Failure to address scope and span of user needs
„ Loss/degradation of service in other areas of the organisation or process

3.5 Implementation Risk

3.5.1 Risks such as the following could lead to the implementation of an ineffective and inefficient solution:
„ Inadequate attention to and investment in up-front design
„ Inappropriate selection of the VPN model for organisation
„ Inadequate use of the third parties where appropriate
„ Insufficient attention to security in design
„ Inappropriate recovery processes
„ Failure to design service level expectations and measurements
„ Inappropriate integration strategy
„ Ineffective change, project or implementation management processes
„ VPN client risk (same interface accept Internet and VPN traffic)

3.6 Operating Risk

3.6.1 Risks such as the following result in ineffective and inefficient utilisation/operation of the VPN:
„ Inadequate resources to operate effectively
„ Lack of reliability

Page 4 Review of Virtual Private Networks Guideline

 „ Impairment of quality of service
„ Lack of interoperability
„ Failure to encapsulate
„ Inadequate capacity
„ Failure to provide redundancy or back up
„ Use of personal devices (home computing) for business purpose (lack of security configurations, antivirus software, personal
firewalls)
„ Lack of confidentiality on operation parameters or data

4. CHARTER

4.1 Mandate
4.1.1 Before commencing a review of a VPN, the IS auditor should provide reasonable assurance of the requisite mandate by virtue of
the IS auditor’s position or the required written mandate provided by the organisation, to carry out the envisaged review. In case
the review is initiated by the organisation, the IS auditor also should obtain reasonable assurance that the organisation has the
appropriate authority to commission the review.

5. INDEPENDENCE

5.1 Professional Objectivity

5.1.1 Before accepting the assignment, the IS auditor should provide reasonable assurance that the IS auditor’s interests, if any, in the
VPN solution being reviewed would not in any manner impair the objectivity of the review. In the event of any possible conflict of
interests, the same should be communicated explicitly to the organisation, and a written statement of the organisation’s
awareness of the conflict should be obtained before accepting the assignment.
5.1.2 In case the IS auditor has/had any nonaudit roles in the VPN being reviewed, the IS auditor should consider guideline G17 Effect
of Nonaudit Roles on the IS Auditor’s Independence.

6. COMPETENCE

6.1 Skills and Knowledge

6.1.1 The IS auditor should provide reasonable assurance of the necessary technical knowledge to review the VPN. A clear
understanding of the business requirements and the technical aspects of the VPN is necessary while reviewing the VPN
implementation in an organisation.
6.1.2 The IS auditor also should provide reasonable assurance of access to the relevant technical skill and knowledge to carry out the
review of the VPN. Review of VPN would call for good technical knowledge to evaluate aspects such as the encryption
technologies used, network security architecture and security technologies. The IS auditor should have adequate knowledge to
review these aspects. Where expert inputs are necessary, appropriate inputs should be obtained from external professional
resources. The fact that external expert resources would be used should be communicated to the organisation in writing.

7. PLANNING

7.1 High-level Risk Assessment

7.1.1 The IS auditor should gather information regarding the business and its requirements for the VPN to carry out a high-level risk
assessment.
7.1.2 The VPN-related risks referred to in section three should be considered depending on the stage at which the review is being
carried out, such as during design (pre-implementation), implementation or post-implementation.
7.1.3 The relevant COBIT information criteria—effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability—
that need to be reviewed and confirmed should also be identified.
7.1.4 The relevant aspects of Control Objectives for Net Centric Technology (CONCT) should also be considered in this context, since
these are extensions of COBIT criteria to network-centric environments such as those supported by VPNs.
7.1.5 This high-level risk assessment will help determine the scope and coverage of the review.

7.2 Scope and Objectives of the Review

7.2.1 The IS auditor, in consultation with the organisation where appropriate, should clearly define the scope and objective of the review
of the VPN. The aspects to be covered by the review should be explicitly stated as part of the scope. The high-level risk
assessment referred to in section 7.1.1 would dictate which aspects need to be reviewed and the extent and depth of the review.
7.2.2 For the purpose of the review, the stakeholders in the solution also should be identified and agreed upon with the organisation.
7.2.3 Any key concerns of the stakeholders should also be included, as appropriate, in the scope and objectives of the review.
7.2.4 In case the review scope includes third-party providers, the IS auditor must assure the audit clause was included in the contract.

7.3 Approach
7.3.1 The IS auditor should formulate the approach in such a way that the scope and objectives of the review could be fulfilled in an
objective and professional manner. The approach followed should depend on whether the review is pre-implementation, at the
implementation stage or post-implementation. The approach should be appropriately documented. When and where external

Review of Virtual Private Networks Guideline Page 5

 expert inputs would be used also should be specified as part of the approach. Any planned use of testing/monitoring tools should
also be stated as part of the approach.

7.4 Sign-off for the Plan

7.4.1 Depending on the organisational practices, the IS auditor may obtain the concurrence of the organisation for the plan and
approach.

8. PERFORMANCE OF THE VPN REVIEW

8.1 General
8.1.1 This section addresses the wide spectrum of aspects to be addressed during the execution of a VPN review. For a specific VPN
review, aspects relevant to the review should be identified from this wide spectrum of aspects depending on the envisaged scope
and objectives of the review.
8.1.2 The VPN review should be carried out per the defined approach (with refinements as appropriate), so the envisaged objectives of
the review are fulfilled.
8.1.3 In general, study of available documentation (such as, business case, system documentation, contracts, service level agreements
and logs), discussions with the stakeholders and service providers, and observation should be used appropriately in gathering,
analysing and interpreting the data. Where appropriate, the IS auditor should test the significant processes/functions in the VPN
environment to verify that the processes/functions are performing as intended.
8.1.4 Where necessary and agreed upon with the organisation, external expert inputs could be used suitably in the collection, analysis
and interpretation of the data.
8.1.5 The inferences and recommendations should be based on an objective analysis and interpretation of the data.
8.1.6 Appropriate audit trails should be maintained for the data gathered, analysis made, inferences arrived at and corrective actions
recommended.

8.2 Pre-implementation Review

8.2.1 The pre-implementation review, carried out before the VPN solution is implemented (during design stage), should address the
appropriateness of the:
„ Requirements for a VPN solution
„ Cost-benefits of the proposed solution
„ Proposed VPN technology, such as VPN model, VPN architecture, VPN configuration/topology and VPN usage
„ Proposed security architecture and features, including the proposed encryption technologies
„ Redundancy and backup facilities planned
„ Management approvals
„ Proposed project management structures and monitoring mechanisms
„ Selection process for the choice of the service provider
„ Proposed contract, SLAs and metrics
„ Statutory requirements, if any, that need to be fulfilled

8.2.2 To address these aspects, the IS auditor should:

„ Study the VPN requirements—business as well as technical
„ Study the business case (costs and benefits) and the approvals for the same
„ Review the VPN design document outlining the technology aspects
„ Review whether the proposed solution would conform to one of PPTP, L2TP and IPSec protocols
„ Review the proposed security architecture and encryption technology
„ Review the tender process, including the technical and commercial evaluation of the alternate proposals and the ultimate
choice of the service provider
„ Study the proposed project management structure
„ Study the proposed contracts, SLA and metrics
„ Study the statutory requirements to be fulfilled
„ Evaluate the redundancy and backups proposed
„ Review the strategy proposed for integrating the VPN with the applications
„ Use external experts, where necessary, to evaluate the appropriateness of the technology and security aspects
„ Study the proposed training plans
„ Study any related audit/review reports
„ Evaluate the results of the above with reference to their appropriateness as well as their adequacy to mitigate the risks—
security risk, third-party risk, business risk, implementation risk and operating risk
„ Evaluate how COBIT and CONCT criteria are being fulfilled
„ Highlight the risks and issues arising out of the review for necessary corrective action.

8.3 Implementation Review

8.3.1 The implementation review happens during the implementation, and accordingly, it should address whether the:
„ Implementation is progressing per the approved plans and within agreed time frames and costs
„ VPN technology—VPN model, VPN architecture, VPN configuration/topology and VPN usage—is implemented as intended
„ Security scheme and the encryption technologies used are robust and are as designed
„ The planned redundancy and backup facilities are implemented
„ The actual contracts, SLAs and metrics address the organisation’s requirements

Page 6 Review of Virtual Private Networks Guideline

 „ The statutory requirements, if any, are addressed

8.3.2 To address the above referred aspects the IS auditor should:

„ Study the project progress reports and minutes of meetings
„ Evaluate the actual implementation of the technologies against the plans and identify the deviations, if any
„ Confirm whether the solution is certified to conform to one of PPTP, L2TP and IPSec protocols
„ Evaluate the actual security architecture and encryption technology implemented for conformance with the approved design
„ Study the actual contracts, SLA and metrics that were agreed upon
„ Evaluate the redundancy and backups established
„ Review the actual integration of the VPN with the applications
„ Use external experts, where necessary, to evaluate the appropriateness of the technology and security aspects actually
implemented
„ Evaluate the adequacy of the testing and migration processes to assess whether they address all kinds of users and cover
such things as capacity, bandwidth, access control and encryption in an appropriate manner
„ Evaluate the billing mechanisms being built
„ Assess whether the legacy connections are being retired, their billings discontinued and equipments disposed of
progressively with the implementation of the VPN
„ Study the earlier pre-implementation audit report, if any, and any other related review reports to assess whether the risk
mitigation actions recommended earlier are being implemented
„ Evaluate the results of the above with reference to their appropriateness as well as their adequacy to mitigate the risks—
security risk, third-party risk, business risk, implementation risk and operating risk
„ Evaluate how COBIT and CONCT criteria are fulfilled
„ Highlight the risks and issues arising out of the review for necessary corrective action

8.4 Post-implementation Review

8.4.1 The post-implementation review occurs after the implementation of the VPN, and hence, it should address whether the:
„ Envisaged benefits are being achieved
„ One-time costs are as planned and reasonable
„ Ongoing billings are reasonable and as agreed
„ VPN technology is being used as intended
„ VPN and its usage are in conformance with the security policies and procedures including data classification
„ Third parties accessing the VPN via extranets have signed the relevant security and confidentiality agreements and are
complying with the same
„ The users accessing through remote connection and using laptops use necessary security features including personal
firewalls, where appropriate
„ There are appropriate processes for the management of digital certificates
„ The SLAs and metrics, including quality of service (QoS), are measured, monitored and escalated on a regular basis for
timely actions
„ The data are sufficiently protected at entry and exit points as well as over unencrypted links using appropriate procedures
„ Appropriate security tools and processes are in place for such things as virus checking and intrusion detection
„ The services and costs are comparable and competitive
„ The redundancy and backup facilities are functioning appropriately
„ The statutory requirements, if any, are addressed

8.4.2 To address the above referred aspects the IS auditor should:

„ Study the project completion report
„ Review the VPN technology in actual use for its conformance with the approved design
„ Confirm whether the solution is certified to conform to one of PPTP, L2TP and IPSec protocols
„ Review the ongoing billings on a sample basis
„ Carry out sample checking of compliance with security policies and procedures
„ Check third-party access as well as the agreements signed by third parties regarding extranet access
„ Check the remote and laptop access processes as well the laptops for appropriate security settings
„ Review the actual SLAs and metrics including QoS and the actual process of monitoring them
„ Check the security implementation across the network
„ Test the backup and redundant facilities
„ Carry out periodic benchmarking to provide reasonable assurance of continued reasonableness of charges and quality of
services
„ Use external experts, where necessary, to evaluate the appropriateness of the technology and security aspects in place
„ Use appropriate tools to test relevant aspects of the VPN solution
„ Review the help desk process supporting the VPN
„ Evaluate the results of the above with reference to their appropriateness as well as their adequacy to mitigate risks—security
risk, third-party risk, business risk, implementation risk and operating risk
„ Evaluate how COBIT and CONCT criteria are fulfilled
„ Highlight the risks and issues arising out of the review for necessary corrective action

9. REPORTING

9.1 Report Content

9.1.1 The report on the VPN review should address the following aspects depending on the scope of its coverage:
„ The scope, objective, methodology followed and assumptions

Review of Virtual Private Networks Guideline Page 7

 „ Overall assessment of the solution in terms of key strengths and weaknesses as well as the likely effects of the weaknesses
„ Recommendations to overcome the significant weaknesses and improve the solution
„ The extent of compliance with COBIT’s information criteria and CONCT criteria, and the effect of any noncompliance
„ Recommendations regarding how the experience could be used to improve similar future solutions or initiatives

9.1.2 The observations and recommendations should be validated with the stakeholders and organisation, as appropriate, before
finalising the report.

10. FOLLOW-UP

10.1 Tracking Actions Agreed

101.1 The actions agreed at the end of the VPN review should be assigned due dates and tracked for completion. Outstanding issues
should be escalated to appropriate management for necessary action.

11. EFFECTIVE DATE

11.1 This guideline is effective for all information systems audits beginning on or after 1 July 2004. A full glossary of terms can be
found on the ISACA web site at www.isaca.org/glossary.

APPENDIX

COBIT Reference
Selection of the most relevant material in COBIT applicable to the scope of the particular audit is based on the choice of specific COBIT IT
processes and consideration of COBIT information criteria.

In a VPN, a communication infrastructure, the following aspects are more relevant:

„ PO1—Define a Strategic IT Plan
„ PO3—Determine Technological Direction
„ PO5—Manage the IT Investment
„ PO8—Ensure Compliance With External Requirements
„ PO9—Assess Risks
„ PO10—Manage Projects
„ AI3—Acquire and Maintain Technology Infrastructure
„ AI4—Develop and Maintain Procedures
„ AI5—Install and Accredit Systems
„ AI6—Manage Changes
„ DS1—Define and Manage Service Levels
„ DS2—Manage third-party services
„ DS3—Manage Performance and Capacity
„ DS4—Ensure Continuous Service
„ DS5—Ensure Systems Security
„ DS9—Manage the Configuration
„ DS12—Manage Facilities
„ DS13—Manage Operations
„ M1—Monitor the Processes

The information criteria most relevant to a VPN review are:

„ Primary: availability, confidentiality, effectiveness and integrity
„ Secondary: efficiency, compliance and reliability

References
Virtual Private Networking—New Issues for Network Security, IT Governance Institute, USA, 2001
Control Objectives for Netcentric Technology (CONCT), IT Governance Institute, USA, 1999

 Copyright 2004
Information Systems Audit and Control Association
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Telephone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: standards@isaca.org
Web site: www.isaca.org

Page 8 Review of Virtual Private Networks Guideline