Evaluation Report Access Director Report Polycom ® RealPresence® Access Director 12 November 2015 Prepared by ICSA Labs 1000 Bent Creek Blvd., Suite 200

Evaluation Report

Polycom® RealPresence® Access Director™

12 November 2015

Prepared by ICSA Labs 1000 Bent Creek Blvd., Suite 200

Mechanicsburg, PA 17050 www.icsalabs.com

CTXX-POLYCOM-2015-1112-02

http://www.icsalabs.com/

Polycom RealPresence Access Director Evaluation Report


Page i of i Copyright 2015 ICSA Labs. All Rights Reserved. 1000 Bent Creek Blvd., Suite 200 Mechanicsburg, PA 17050 https://www.icsalabs.com

Table of Contents

Executive Summary ................................................................................................................................... 1

System Components ................................................................................................................................. 3

Test Topology ............................................................................................................................................ 4

Product Deployment ................................................................................................................................. 4

Basic SIP and H.323 Functionality ............................................................................................................. 8

Platform Security ...................................................................................................................................... 9

Functional Security .................................................................................................................................... 9

Administration Testing ............................................................................................................................ 10

Persistence .............................................................................................................................................. 10

Documentation ....................................................................................................................................... 11

Logging .................................................................................................................................................... 11

Summary ................................................................................................................................................. 11

Partners and Resources .......................................................................................................................... 12

Appendix A – Evaluation Requirements.................................................................................................. 13

Testing Information ................................................................................................................................. 19



Page 1 of 19 Copyright 2015 ICSA Labs. All Rights Reserved. 1000 Bent Creek Blvd., Suite 200 Mechanicsburg, PA 17050 https://www.icsalabs.com

Executive Summary

About this Evaluation Polycom, Inc. contracted ICSA Labs, an independent division of Verizon, to test and evaluate the Polycom® RealPresence® Access Director™ (RPAD), which is a Session Border Controller (SBC) component of the Polycom® RealPresence® Platform. The goal of this engagement was to evaluate the RPAD’s functionality as an SBC and that it will not negatively affect security controls or introduce security vulnerabilities itself while allowing H.323 and Session Initiation Protocol (SIP) videoconferencing functionality.

About ICSA Labs The goal of ICSA Labs is to significantly increase user and enterprise trust in information security products and solutions. For more than 20 years, ICSA Labs, an independent division of Verizon, has been providing credible, independent, 3rd party security product testing and certification for many of the world’s top security product developers and service providers. Enterprises worldwide rely on ICSA Labs to set and apply objective testing and certification criteria for measuring product compliance and performance. ICSA Labs manages and facilitates technology consortia that focus on emerging, well-defined technologies. The consortia provide for information exchanges among industry leading developers, and for the development of product testing and certification programs and standards. For more information about ICSA Labs, please visit www.icsalabs.com.

About Polycom, Inc. Companies choose Polycom for solutions that enable their geographically dispersed workforces to communicate and collaborate more effectively and productively over distances. Using Polycom telepresence, video, and voice solutions and services, people connect and collaborate from their desktops, meeting rooms, class rooms, and mobile settings. Organizations from a wide variety of industries and the private sector work with Polycom standards-based solutions.

About Session Border Controllers Session Border Controllers (SBCs) are used to control the signaling and data streams involved in VoIP/video calls conducted by businesses every day. The SBC usually sits on the edge of the network and is used to control SIP and H.323 traffic flow in both directions, help protect against DoS attacks and hide the topology of the organization’s private network.

Customer Provided Product Overview Polycom® RealPresence® Firewall Traversal and Security solutions remove communication barriers to allow your teams to collaborate more effectively over video. These solutions provide a secure route for users to connect from virtually any location and device, providing support for business-to-business and intra-company collaboration. The Polycom® RealPresence® Access Director™ enables users within and beyond the firewall to securely access video services—whether you are at home, in the office or on the go. A software based edge server—RealPresence Access Director—securely routes communications, management and content through firewalls without requiring additional client hardware or software.

http://www.icsalabs.com/




Areas of Evaluation Polycom contracted ICSA Labs to evaluate the RPAD in the following areas:

• Provide basic SIP and H.323 functionality

o Verify protocol support for SIP and H.323

o Client registration through the RPAD

o URI dialing

o Voice/Video calling capabilities

• Provide platform security

o Secure administrative access

o Vulnerability testing

o Cryptography

• Functional Security

o Policy Enforcement

o Denial of Service (DoS) testing

o No Vulnerabilities introduced

• Administration

o Secure administrative interface

o Administrative authentication

o Remote administration

• Persistence

o Configuration

o Log storage

o Date/Time

• Documentation

o Complete and accurate

• Logging

o Authentication attempts

o Voice/Video call attempts

Summary of Findings During the course of this evaluation it was determined that the RPAD has met and passed all evaluation criteria used during this evaluation.




System Components

Introduction ICSA Labs requires that vendors submit for evaluation at ICSA Labs all hardware, software, and documentation that comprise the product under test. For the purposes of this document, the term product refers to the complete system submitted by the vendor to ICSA Labs to be evaluated during testing. This includes any and all documentation, hardware, firmware, software, host operating systems, management stations, etc. used during testing. Servers providing common management services such as syslog and NTP are provided by ICSA Labs and are not considered part of the product under test. This section details the components of the product (or product family) submitted by Polycom for evaluation. All items not listed in this section, as well as any relevant components, were provided by ICSA Labs.

Hardware Polycom, Inc. submitted the following hardware to ICSA Labs for this evaluation:

• RPAD – The RPAD was installed on a server with (2) six-core 2.0Ghz Xeon Processors. The RPAD was equipped with (4) gigabit Ethernet ports, (2) USB ports, and a serial port. The RPAD contained (2) 146GB hard drives.

Polycom, Inc. also submitted the following hardware in support of the RPAD Evaluation:

• Site A

o (1) RealPresence® Collaboration Server (RMX® 2000)

o (1) HDX® 4000

o (1) Apple iPad (with Polycom RealPresence Mobile version 1.3.2-21855_4520)

IOS Version 5.1.1

o (1) Distributed Media Application (DMA)

o (1) RealPresence® Resource Manager (RPRM, one dedicated, one virtualized)

• Site B

o (1) RPAD

o (1) RPRM (Virtualized)

o (1) DMA (Virtualized)

• Mobile

o (1) Apple iPad (with Polycom RealPresence Mobile version 1.3.2-2185_4520)

IOS Version 5.1.1

Software Polycom, Inc. submitted the following software to ICSA Labs for this evaluation:

• RPAD version 4.2.1_build_199531.

Documentation To satisfy documentation requirements, Polycom, Inc. provided the Network Security Lab team with the following electronic documents in order to assist in the installation, configuration, and administration of the RPAD for this evaluation:




• Polycom® RealPresence® Access Director™ System, Administrator’s Guide 4.2 – June, 2015

• Polycom® RealPresence® Access Director™ System, Getting Started Guide 4.2 – June, 2015

• Polycom® RealPresence® Access Director™ System, Release Notes, Software Version 4.2.1.1 – September 2015

Test Topology

Introduction ICSA Labs designs individual test plans for each custom test in order to simulate a realistic deployment of products in a typical end user environment. Since products submitted for testing can often be configured many different ways, ICSA Labs frequently confronts many configuration-related decisions both before and after installing products under test. For the purposes of this engagement, ICSA Labs installed and configured the products as a typical end user would and according to their intended use. The provided documentation was used to assist with all configuration decisions. The final configuration used for testing is detailed within the Product Deployment section of this evaluation report.

Test Description ICSA Labs deployed the RPAD (RPAD) in the test infrastructure which was designed to simulate an enterprise network deployment. Two sites were created, each containing Polycom, Inc. communications equipment located in their respective private networks, and an RPAD located in each DMZ. Each site was protected with a network firewall and the sites were located on different public networks. Security of the system was tested in site to site communication scenarios as well as in public mobile client scenarios.

Test Bed Diagram

Product Deployment

Introduction Products can often be configured many different ways. Therefore, ICSA Labs frequently confronts many configuration-related decisions before ever adding a single security policy rule on a product in the lab. ICSA Labs decided to deploy the RPAD using the following:




• NAT with a one to one mapping– for inbound/outbound services.

• DNS servers were hosted both internally and externally, as the product itself did not support being a DNS server.

• The RPAD was deployed in a DMZ behind a firewall with a rule set containing only services defined in the supplied documentation.

Detailed Findings The RPAD was configured to reside in the site’s DMZ within the ICSA Labs test infrastructure. The general network settings were found under “Admin” > “Network Settings”. The Network Security Lab team configured the hostname and DNS settings on this page.

The IP address, subnet mask, and IP default gateway were configured on the “Advanced network setting” tab within the same section. The “Configuration Wizard” button was clicked on and the steps to finish the networking configuration were followed.




A new administration account was then created. From “Users”, “Add User” was selected and all of the required information was completed. Clicked on “Associated Roles” and moved “Administrator” into the “Selected roles” section and clicked “OK”.

The next step was to integrate with the Polycom, Inc. communications equipment located in each site. Before integration can occur, a provisioning admin account must be created on the RealPresence Resource Manager (RPRM) within the site. Next, the RPAD will connect to the RPRM by going under “Admin” > “Polycom Management System”. Enter the “Login Name”, the “Password”, and the IP address of the RPRM, and click “Connect”.




The last steps include configuring SIP and H.323 settings. Under “Configuration” > “SIP Settings” configure the External Unencrypted port 5060 with TCP/UDP selected as the transport. Configure the External Encrypted port 5061 with TLS selected as the transport. Configure the Internal Port Settings with 5070 as the unencrypted port and 5071 as the encrypted port.




Under “Configuration” > “H.323 Settings” configure the H.225 Registration Admission Status (RAS) port as 1719 and the H.225 call signaling port as 1720. Add the CIDR networks the RPAD utilizes.

Basic SIP and H.323 Functionality

Introduction Basic functionality for this custom testing engagement was defined to evaluate basic protocol support for SIP and H.323, client registration, Uniform Resource Identifier (URI) Dialing, and video/voice capabilities. ICSA Labs used the multiple site architecture described earlier to ensure site to site functionality as well as mobile client functionality.




Detailed Findings The RPAD was evaluated on its ability to allow clients to make and receive video/voice calls including multiple line call support. Multi-protocol support was also evaluated. Various aliases were used throughout testing including E.164 aliases SIP aliases, and H.323 aliases. Client registration as well as endpoint authentication methods were tested. The RPAD met all of the Basic Functionality Evaluation criteria and no issues were found throughout testing.

Platform Security

Introduction Once configured, the product must be able to prevent unauthorized control of any administrative interface. Also, the product must demonstrate through testing that it is not vulnerable to any publicly known exploits or vulnerabilities as well as not introduce vulnerabilities while enforcing its policy configuration. Finally, the product must be able to mitigate as well as not be rendered inoperable by any trivial Denial of Service (DoS) attack. The Network Security Lab team uses commercial, in-house-created, and freely-available testing tools to attack and probe the product. Detailed Findings ICSA Labs evaluated the RPAD to verify that it is not susceptible to commonly known vulnerabilities or exploits, including network-based attacks. The Network Security Lab team used a combination of commercial and open source tools to scan for possible vulnerabilities. The Network Security Lab team then attempted to exploit possible vulnerabilities. Administrative access was also tested to ensure that no unauthorized administrative access to the machine could be gained through the Web UI.

Functional Security

Introduction Once configured, the product must be able to maintain basic functionality, and be secure against attacks directed at the functionality of the product. The Network Security Lab team utilized network scans to




determine open ports and services. The results of the scans were used to generate a thorough functional security testing plan that would attempt to alter the functionality of the product.

Detailed Findings ICSA Labs evaluated the RPAD to verify that its services and features function as intended and as a user would reasonably expect. ICSA Labs ensured the RPAD’s ability to function in a Network Address Translation (NAT) scenario through a network firewall. The Network Security Lab team also ensured only traffic designed to flow through the RPAD was allowed. During routine calls, the Network Security Lab team deployed a number of commercial and open source tools in an attempt to disrupt or degrade the service provided through the RPAD. Several fuzzers for SIP and H.323 were used during attacks, however the service was not found to be degraded or disrupted. Polycom, Inc. RPAD met all Functional Security Evaluation criteria. The Network Security Lab team found that the functionality of the RPAD operated securely and as a user would reasonably expect.

Administration Testing

Introduction Products under test can often have more than a single method by which administration is possible. Whether the product can be administered remotely using vendor-provided administration software, from a web browser-based interface, via some non-networked connection such as a serial port, or via some other means, authentication must be necessary before access to administrative functions is granted. The Network Security Lab team tests not only that authentication mechanisms exist but that they also cannot be bypassed for all administrative interfaces. Detailed Findings ICSA Labs evaluated the RPAD to verify that administrative functions exist to properly install and configure the product for intended operation and that appropriate controls exist to ensure that no unauthorized control of its administrative functions can be obtained. All configurations were performed through the web interface. Appropriate use of a strong TLS cipher suite was confirmed. SSH access can be turned on; however standard admin users cannot access this functionality. It is for the sole purpose of Polycom, Inc. technical support personnel use. The RPAD met all of the Administration Evaluation criteria and no issues were found throughout testing.

Persistence

Introduction Power outages, electrical storms, and inadvertent power losses should not cause the product to lose valuable information such as the configuration, log data, authentication data, and system clock information. This section documents the findings of the Network Security Lab team while testing the RPAD against the persistence requirements. Detailed Findings ICSA Labs evaluated the RPAD to verify that configuration information, administrative settings, stored log data, and date and time settings are persistent across all system restarts.




Polycom, Inc. RPAD met all of the Persistence Evaluation criteria. The Network Security Lab team found that all configuration information, administrative settings, log data, and date and time information were persistent across all planned and unplanned system restarts.

Documentation

Introduction The Network Security Lab team evaluated the documentation provided with the product to verify that the vendor supplies adequate documentation to assist an end user with the installation, configuration, maintenance, and administration of the product. Throughout testing, the Network Security Lab team used the documentation provided and evaluated it for accuracy, completeness, and usefulness. Detailed Findings Polycom, Inc. RPAD met all of the Documentation criteria. The Network Security Lab team found the provided documentation contained all the information necessary for installation, configuration and administration of the RPAD.

Logging

Introduction This evaluation requires the product to provide extensive logging capabilities. ICSA Labs evaluated the RPAD to verify that it has the ability to capture, store, and present adequate system and network event information to enable an administrator to audit security related events. For the purposes of these tests, it is not required that logging is enabled at all times or that it is enabled by default. However, the capability must exist to capture the required log events and information.

Detailed Findings The Polycom, Inc. RPAD stores log data internally and can be configured to transmit logs to a remote syslog server. Internal logs are divided into several logs based on event/function. There are several log files including webAdmin.log, utility.log, snmp.log, sipService.log, h323Service.log, activeCallAuditor.log, etc. The RPAD provides the ability to archive logs as well, and both active and archived logs can be downloaded and viewed. The RPAD provides the ability to set the log retention period, and log roll-over (archiving) frequency. The RPAD also allows five application log level settings that range from DEBUG to FATAL. The Network Security Lab team configured the RPAD to store the logs locally and selected INFO as the log level setting. Analysts performed a number of actions, including accessing the administrative interface, initiating calls, and changing the configuration to ensure that the RPAD properly logged all activity. The Network Security Lab team also configured the RPAD for logging to a remote syslog and found no issues in the performance of the RPAD using this method. The Polycom, Inc. RPAD met all of the Logging Evaluation criteria. The Network Security Lab team found that the logging capabilities available on the RPAD permitted administrators to adequately audit security-related system and network events.

Summary During the course of testing by the Network Security Lab team, it was determined that Polycom, Inc. has met and passed all of the evaluation criteria used during this evaluation. No violations were found throughout testing.




Partners and Resources

Introduction This evaluation was made possible through the use of ICSA Labs’ partnerships, commercial tools, open source tools and resources available on the Internet. The following is a list of partnerships, tools and resources used during this evaluation.

Commercial Partnerships

Open Source Projects / Other Commercial Tools

Other Research Sources




Appendix A – Evaluation Requirements Introduction Polycom, Inc. (“Polycom”) has asked ICSA Labs, an Independent Division of Verizon (“ICSA Labs”) to test and evaluate the RealPresence Access Director (RPAD). The goal of this engagement will be to evaluate that the RPAD can maintain the existing security and integrity level of any network while not negatively affecting security controls or introducing security vulnerabilities itself while adding H.323 and SIP videoconferencing functionality. Evaluation Requirements 1. Documentation – Verify that the vendor supplies adequate documentation to enable an administrator to

properly and securely install and administer the product.

1.1. Installation Documentation – Polycom must include some measure of written and/or electronic guidance indicating how to properly perform installation.

1.2. Administration Documentation – Polycom must include all written and/or electronic guidance

applicable for administration and maintenance. 1.3. Additional Documented Coverage – The written and/or electronic Polycom documentation must

indicate:

1.3.a. The base version of all software and firmware components comprising the RPAD 1.3.b. The default settings for all components of the RPAD, including:

1.3.b.1. Available administrative interfaces 1.3.b.2. Administrative authentication information 1.3.b.3. Network settings

1.4. Accurate Documentation – All Polycom documentation used for the purposes of testing must not

be inaccurate. 1.5. Log Event Dispositions Defined – Polycom must include written and/or electronic guidance

defining all possible values that indicate a Disposition of the Event.

2. Administration – Verify the product provides a secure administrative interface to perform all required management functions.

2.1. Administrative Functions – Administrative Functions must exist as part of the RPAD to:

2.1.a. Configure and change or acquire the date and time 2.1.b. Configure and change Authentication Configuration Data 2.1.c. Configure and change Remote Administration settings




2.1.d. Configure and change the configuration policies 2.1.e. Configure and display requisite network settings 2.1.f. Listing of dynamically opened ports 2.1.g. Listing of currently active calls 2.1.h. Enable logging of the Required Log Events 2.1.i. Review Required Log Data

2.2. Administrative Interface – Polycom must include an Administrative Interface from which the RPAD

Administrative Functions are accessible. 2.3. Administrative Interface Authentication – To access the Administrative Functions, the RPAD must

have the capability to require authentication through an Administrative Interface using an Authentication Mechanism.

2.4. Remote Administration – In the event that the RPAD supports remote administration, all remotely

accessible administrative interfaces must be cryptographically protected.

3. Functionality – Verify the product operates properly and as a reasonable user would expect.

3.1. Protocol Support – The RPAD must support the following protocols according to industry standards:

3.1.a. H.323 3.1.b. SIP

3.2. Client Registration – The RPAD must support the following client registration methods:

3.2.a. Manual

3.3. URI Dialing - The RPAD must support the following URI dialing methods:

3.3.a. E.164 Aliases 3.3.b. H.323 Aliases 3.3.c. SIP Aliases 3.3.d. DNS Aliases

3.4. Video/Voice calling capabilities

3.4.a. Make and receive calls 3.4.b. Multiple lines

4. Persistence – Verify that configuration and log data on the product is persistent across system power

outages due to loss of power.




4.1. Configuration Policy Persistence – When electrical power is reapplied after being lost or removed,

the RPAD must do one of the following:

4.1.a. Enforce the same configuration policy that was being enforced prior to the loss or removal of power; or

4.1.b. Enforce a deny-all policy, while including an Administrative Function(s) capable of

restoring the RPAD to the same configuration policy that was being enforced prior to the loss or removal of power.

4.2. Log Persistence – In the event that electrical power is lost or removed from the RPAD, all

Required Log Data for all Required Log Events not in transit between the RPAD and other RealPresence components must persist and remain the same when electrical power is reapplied.

4.3. Authentication Configuration Data Persistence – In the event that electrical power is lost or

removed from the RPAD, all Authentication Configuration Data must persist and remain the same when electrical power is reapplied.

4.4. Remote Administration Configuration Persistence – In the event that electrical power is lost or

removed from the RPAD, Remote Administration settings must remain configured the same when electrical power is reapplied.

4.5. Date and Time Persistence – In the event that electrical power is lost or removed from the RPAD, the RPAD must continue to keep track of the date and time such that the date and time are accurate when electrical power is reapplied.

5. Platform Security – Verify the product is secure from exploitation or exposure and that it does not

introduce any known vulnerabilities to the network where it is installed.

5.1. Administrative Access Testing – The RPAD must demonstrate through testing that no unauthorized control of its Administrative Functions can be obtained.

5.2. Vulnerability Testing – When enforcing a security policy, the RPAD must demonstrate through

testing that it is not vulnerable to the evolving set of vulnerabilities known in the Internet community that are capable of being remotely tested.

5.3. Security Testing – In the event that the RPAD transmits, receives, records, or stores any

potentially sensitive information, the RPAD must effectively prevent unauthorized access to the information.

5.4. Cryptography – The RPAD must support industry standard and accepted best practices for all

cryptographic functions.

6. Functional Security – Verify the product is able to implement its functionality in a secure manner.

6.1. Policy Enforcement - Verify the RPAD properly enforce the configured configuration policy. 6.2. Proper Services Operation – Verify the RPAD, while enforcing a policy, must allow permitted

services in that policy to function as designed. 6.3. Enterprise Firewall Traversal – The RPAD must properly support connections between endpoints

protected by a network firewall with NAT enabled and endpoints on the Internet with NAT enabled.




6.3.a. Endpoints on a network protected by a firewall (both with and without NAT enabled) to endpoints directly connected to the Internet.

6.3.b. Endpoints on a network protected by a firewall (both with and without NAT enabled) to

endpoints on a separate network similarly protected by a firewall.

6.4. No Vulnerabilities Introduced – When enforcing a security policy, the RPAD must demonstrate through testing that it does not introduce vulnerabilities to private and service network servers.

6.5. No Other Traffic – The RPAD must demonstrate through testing that nothing other than that

specified in the security policy traverses the RPAD. 6.6. Denial of Service – The RPAD must demonstrate through testing that:

6.6.a. It is not rendered inoperable by any trivial denial of service type attacks; and 6.6.b. It fails closed if rendered inoperable through any denial of service type attack for which

there is no known defense.

7. Logging – Verify the product is able to provide an administrator the means necessary to properly audit security-related events. The captured log data should be able to provide the administrator enough information to monitor events that may impact the security or integrity of the product.

7.1. Logging Behavior - The RPAD must have the capability to log all required log events and log data;

however, the RPAD is not required to have logging enabled at all times or by default. 7.2. Log Data Presentation - All required log data must be available for review upon demand and

presented in a human readable format while preserving the relative sequence of events. 7.3. Precision of Date and Time - The date and time recorded by the RPAD for all required log events

must reflect the exact date and time to the precise second that the event occurred using the following formats:

7.3.a. The date recorded by the RPAD for each required log event in the log file must consist of

the four digit year, month, and day. 7.3.b. The time recorded by the RPAD for each required log event in the log file must consist of

the hour, minute, and second.

7.4. Accuracy of Log Data - All required log data captured by the RPAD must be accurate. 7.5. Remote Logging Requirements - In the event that required log data is sent to a remote logging

server, the RPAD must incorporate a unique identifier with the other required log data distinguishing the source of the log message.

7.6. Linking multiple logs for a single event - In the event that the RPAD uses multiple repositories to

store the required log data for a single log event, the RPAD must include some means to clearly and accurately link the corresponding log messages.

7.7. The RPAD must be capable of capturing the required log data for the following types of events:

7.7.a. Administrative Authentication Attempts - The RPAD must be able to log all authentication attempts. Each of these recorded log events must include the following log data:




7.7.a.1. Date and Time 7.7.a.2. Description of the event 7.7.a.3. Which administrative interface, if multiple administrative interfaces exist 7.7.a.4. User identification if multiple users exist 7.7.a.5. Statement of success or failure to authenticate

7.7.a.5.1. Failed authentication attempts must include the reason for failure

7.7.b. Attempts to establish calls - The RPAD must be able to log all successful and unsuccessful attempts to establish calls between endpoints. Each of these recorded log events must include the following log data:

7.7.b.1. Date and Time 7.7.b.2. Source IP or Host Name 7.7.b.3. Destination IP or Host Name 7.7.b.4. Service Name or Protocol 7.7.b.5. Source Port 7.7.b.6. Destination Port 7.7.b.7. Message Type (e.g. ARQ, LRQ, Release Complete) 7.7.b.8. Session Identification 7.7.b.9. Event Disposition (e.g. Permitted or Denied) 7.7.b.10. User Identification, if applicable 7.7.b.11. Reason for failure, if applicable

7.7.c. Attempts to Register - The RPAD must be able to log all successful and unsuccessful attempts by endpoints to register with an H.323 gatekeeper or SIP registrar. Each of these recorded log events must include the following log data:

7.7.c.1. Date and Time 7.7.c.2. Source IP or Host Name

7.7.c.3. Destination IP or Host Name 7.7.c.4. Event Disposition (e.g. Permitted or Denied) 7.7.c.5. Reason for failure, if applicable




7.7.d. System Startup – The RPAD must log each startup of the system itself. Each of these recorded log events must include the following log data:

7.7.d.1. Date and Time 7.7.d.2. Event Disposition (e.g. The system has started)

7.7.e. Configuration Changes – The RPAD must log configuration changes related to operational

events. Each of these recorded log events must include the following log data:

7.7.e.1. Date and Time 7.7.e.2. User identification 7.7.e.3. Statement of configuration change

7.7.f. System Clock Changes – The RPAD must log all system clock changes regardless of

method used (e.g. manual or NTP). Each of these recorded log events must include the following log data:

7.7.f.1. Date and Time the event occurred 7.7.f.2. Date and Time previous to the system clock change 7.7.f.3. Date and Time after the system clock change 7.7.f.4. IP address of the NTP peer or server selected as its synchronization source, if

applicable




Testing Information This report is issued by the authority of the Managing Director, ICSA Labs. Tests are done under normal operating conditions. Please visit www.icsalabs.com for the most current information about this and other products.

Lab Report Date 12 November 2015

Test Location ICSA Labs 1000 Bent Creek Blvd., Suite 200 Mechanicsburg, PA 17050

Product Developer’s Headquarters Polycom, Inc. 6001 America Center Dr. San Jose, CA 95164 Copyright 2015 ICSA Labs. All Rights Reserved. Testing reports shall not be reproduced except in full, without prior written approval of ICSA Labs. All other product, brand and company names in this document are trademarks or registered trademarks of their respective companies.

Documents

Evaluation Report Access Director Report Polycom ® RealPresence® Access Director 12 November 2015 Prepared by ICSA Labs 1000 Bent Creek Blvd., Suite 200