IS AUDITING GUIDELINE REVIEW OF VIRTUAL PRIVATE NETWORKS DOCUMENT #060.020.120

IS AUDITING GUIDELINE REVIEW OF VIRTUAL PRIVATE NETWORKS DOCUMENT #060.020.120 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 060.020 (Evidence) states, "During the course of the audit, the information systems auditor is to obtain sufficient, reliable, relevant and useful evidence to achieve the audit objectives effectively. The audit findings and conclusions are to be supported by appropriate analysis and interpretation of this evidence." 1.1.2 Refer to IS Auditing Guideline 050.010.040 Effect of Third Parties on the Organisation s IT Controls 1.1.3 Refer to IS Auditing Guideline 020.010.010 Effect of Nonaudit Roles on the IS Auditor s Independence 1.2 Linkage to COBIT 1.2.1 COBITFramework 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 selfassessment 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 Page 2 Review of Virtual Private Networks Guideline

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. 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 Review of Virtual Private Networks Guideline Page 3

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. 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) Page 4 Review of Virtual Private Networks Guideline

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 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 Review of Virtual Private Networks Guideline Page 5

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 020.010.010 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 3 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 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. Page 6 Review of Virtual Private Networks Guideline

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 w ith 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 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 of Virtual Private Networks Guideline Page 7

Review the actual integration of the VPN w ith 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 Page 8 Review of Virtual Private Networks Guideline

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 Review of Virtual Private Networks Guideline Page 9