OpenScape Desk Phone CP200 - 400 - 600 V1, Security Checklist, Issue 6

OpenScape Desk Phone CP20X/400/600
Security Checklist
Planning Guide
A31003-C1010-P101-6-76A9
Provide feedback to further optimize this document to edoku@unify.com.
As reseller please address further presales related questions to the responsible presales organization at Unify or at your
distributor. For specific technical inquiries you may use the support knowledgebase, raise - if a software support contract is in
place - a ticket via our partner portal or contact your distributor.
Our Quality and Environmental Management Systems are

implemented according to the requirements of the ISO9001 and
ISO14001 standards and are certified by an external certification
company.
Copyright © Unify Software and Solutions GmbH & Co. KG 08/2017

Mies-van-der-Rohe-Str. 6, 80807 Munich/Germany
All rights reserved.
Reference No.: A31003-C1010-P101-6-76A9
The information provided in this document contains merely general descriptions or
characteristics of performance which in case of actual use do not always apply as
described or which may change as a result of further development of the products.
An obligation to provide the respective characteristics shall only exist if expressly agreed in
the terms of contract.
Availability and technical specifications are subject to change without notice.
Unify, OpenScape, OpenStage and HiPath are registered trademarks of Unify Software and
Solutions GmbH & Co. KG. All other company, brand, product and service names are
trademarks or registered trademarks of their respective holders.
unify.com
Contents 3
Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. History of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. General Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Security Strategy for Unify Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Customer Deployment - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. OpenScape Desk Phone CP Interfaces and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Phone Hardening Measures at a Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Phone Hardening Measures for OpenScape Desk Phone CP SIP and OpenScape Desk Phone CP HFA 11
3.2. Additional Hardening Measures for OpenScape Desk Phone CP SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Additional Hardening Measures for OpenScape Desk Phone CP HFA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Phone Hardening Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Install latest (“up-to-date”) OpenScape Desk Phone CP Phone Software . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Secure Administration Access to the Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Harden Local phone Admin Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Harden Local phone User Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Harden DLS Interface to the Phone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.4. Harden Software Deployment and File Download to the Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Configure Password Policy and Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Authentication of phone at SIP Server (OpenScape Desk Phone CP SIP only). . . . . . . . . . . . . . . . . . . . . 20
4.4.1. Harden Phone to use Digest Authentication (OpenScape Desk Phone CP SIP only) . . . . . . . . . . . . 20
4.5. Secure Signalling and Voice Access to the Phone (OpenScape Desk Phone CP SIP only) . . . . . . . . . . . 21
4.5.1. Harden Signalling to Secure Signalling (OpenScape Desk Phone CP SIP only) . . . . . . . . . . . . . . . . 21
4.5.2. Harden Phone to use Secure (Encrypted) Voice (OpenScape Desk Phone CP SIP only) . . . . . . . . . 23
4.6. Secure Signalling and Voice Access to the Phone (OpenScape Desk Phone CP HFA only) . . . . . . . . . . 24
4.6.1. Harden Connection to HFA Gateway (OpenScape Desk Phone CP HFA only) . . . . . . . . . . . . . . . . . 24
4.6.2. Harden Phone to use Signalling and Payload Encryption (OpenScape Desk Phone CP HFA only) . 25
4.7. Secure Interfaces and Services to the Phone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7.1. PC Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7.2. CCE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7.3. Key Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7.4. SD Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7.5. Remote Call Control (CSTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7.6. Bluetooth Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7.7. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.7.8. Microsoft® Exchange server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7.9. CSTA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7.10. BroadSoft BroadWorks servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7.11. Circuit by Unify server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.7.12. Web Services Interface to OpenScape Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8. Secure Access to Network (Use IEEE 802.1x Access Control) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8.1. Enable 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1. System Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.1. Serial Interface Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Remote Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3. Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4. Monitoring via SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Contents
5.6. SSH Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6. Addendum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1. Default Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2. Password and PIN Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.1. Password Policy supported by OpenScape Desk Phone CP phones . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.2. PW Policy agreed for customers deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3. Certificate Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.1. Credentials used for OpenScape Desk Phone CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.1.1. Credentials used for OpenScape Desk Phone CP SIP and OpenScape Desk Phone CP HFA . 50
6.3.1.2. Credentials used for OpenScape Desk Phone CP SIP only . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1.3. Credentials used for OpenScape Desk Phone CP HFA only . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.2. Setup Certificate Checking Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4. Port Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Introduction 5
1. Introduction
1.1. History of Change

Date Version What
2016-03-11 0.1 Initial Draft
2016-03-14 0.2 Update with comments received
2016-04-15 1.0 Update with comments received
2016-06-14 1.1 Updated Microsoft® Exchange Server,
SD card, and CCE Interface
2016-12-06 2.0 Added OpenScape Desk Phone
CP200 HFA, BroadSoft BroadWorks,
Circuit by Unify, and Key Module
2017-01-31 2.1 Added CSTA server. Updated Blue-
tooth Access, LDAP and Web Ser-
vices
2017-05-23 2.2 Added Web Services Interface (WSI)
and OpenScape Desk Phone CP400/
600 HFA
2017-08-03 2.3 Added OpenScape Desk Phone
CP205 SIP and HFA
Related Topics
1.2. General Remarks

Information and communication and their seamless integration in “Unified Communications and
Collaboration“ (UCC) are important, valuable assets forming the core parts of an enterprise busi-
ness. These assets require every enterprise provide specific levels of protection, depending on
individual requirements to availability, confidentiality, integrity and compliance for the communica-
tion system and IT infrastructure it utilizes.
Unify attempts to provide a common standard of features and settings of security parameters wi-
thin delivered products. Beyond this, we generally recommend
• to adapt these default settings to the needs of the individual customer and the specific charac-
teristic of the solution to be deployed
• to weigh the costs of implementing security measures against the risks of omitting a security
measure and to “harden” the systems appropriately.
Product Security Checklists are published as a basis to support the customer and service depart-
ment in both direct and indirect channels, as well as self-maintainers, to document security setting
agreements and discussions.
The Security Checklists can be used for two purposes:
1. In the planning and design phase of a particular customer project:
Use the Product Security Checklists of every relevant product to evaluate, if all products that
make part of the solution can be aligned with the customer’s security requirements – and do-
cument in the Checklist, how they can be aligned. The Product Security Checklist containing
customer alignments can be identified as Customer specific Product Security Checklist.
This ensures that security measures are appropriately considered and included in the Statem-
ent of Work to build the basis for the agreement between Unify and the customer: who will be
responsible for the individual security measures:
– During installation/setup of the solution
6 Introduction
– During operation
2. During installation and during major enhancements or software upgrade activities:
The Customer specific Product Security Checklists are used by a technician to apply and/or
control the security settings of every individual product.
Usage of Security Checklists (SCL)
Update and Feedback

• By their nature, security-relevant topics are prone to continuous changes and updates. New fin-
dings, corrections and enhancements of this checklist are being included as soon as possible.
Therefore, we recommend using always the latest version of the Security Checklists of the pro-
ducts that are part of your solution.
They can be retrieved from the Unify partner portal http://www.unify.com/us/partners/partner-
portal.aspx for OpenScape Desk Phone CP.
• We encourage you to provide feedback in any cases of unclarity, or problems with the applica-
tion of this checklist.
Please contact the OpenScape Baseline Security Office (obso@unify.com).
Related Topics
1.3. Security Strategy for Unify Products

Reliability and security is a key requirement for all products, services and solutions delivered by
Unify. This requirement is supported by a comprehensive security software development lifecycle
that applies to all new products or product versions being developed from design phase until end
of life of the product.
Products of Unify are developed according to the Baseline Security Policy, which contains the
technical guidelines for the secure development, release and sustaining of the company’s pro-
ducts. It defines the fundamental measures for software security that are taken throughout the
whole lifecycle of a product, from design phase until end of life:
Product planning and design:
Threat and Risk analysis (Theoretical Security Assessment) to determine the essential security
requirements for the product.
Product development and test:
Introduction 7
Penetration Tests (Practical Security Assessment) to discover implementation vulnerabilities and

to verify the hardening of the default system configuration.
Installation and start of operation:
Hardening Guides (Security Checklist) to support the secure configuration of the product accor-
ding to the individual customer's security policy.
Operation and maintenance:
Proactive Vulnerability Management to identify, analyse and resolve security vulnerabilities that
emerge after products have been released, and to deliver guidance to customers how to mitigate
or close these vulnerabilities.
Unify Baseline Security Policy- from Design to EOL
For more information about the Unify product security strategy please refer to the relevant Security
Policies [3], [4], [5], [6], [7].
As we at Unify define a secure product, our products are not secure, but - they can be installed,
operated and maintained in a secure way. The level of the products security should be scheduled
by the customer.
The necessary information for that is drawn up in the Product Security Checklist.
For OpenScape Desk Phone CP SIP and OpenScape Desk Phone CP HFA the Product Security
Checklist is this document.
8 Introduction
1.4. Customer Deployment - Overview

This Security Checklist covers the products OpenScape Desk Phone CP SIP and OpenScape
Desk Phone CP HFA and lists their security relevant topics and settings in a comprehensive form.
Customer Supplier
Company
Name
Address
Telephone
E-mail
Covered Systems (e.g.

System, SW version,
devices, MAC/IP-
addresses)
Referenced Master Version:
Security Checklist
Date:
General Remarks
Open issues to be
resolved until
Date
Related Topics
OpenScape Desk Phone CP Interfaces and Ports 9
2. OpenScape Desk Phone CP Interfaces and

Ports
Considering hardening for OpenScape Desk Phone CP all interfaces and ports have to be analy-
sed.
The interfaces for OpenScape Desk Phone CP SIP and OpenScape Desk Phone CP HFA phones
are shown in landscape diagrams below. For complete information about used interfaces/IP ports
refer to the Interface Management Database (IFMDB) on the Unify Partner Portal
(http://www.unify.com/us/partners/partner-portal.aspx).
10 OpenScape Desk Phone CP Interfaces and Ports
Phone Hardening Measures at a Glance 11
3. Phone Hardening Measures at a Glance

To improve the security on OpenScape Desk Phone CP SIP and OpenScape Desk Phone CP
HFA phones, hardening measures are recommended.
Those measures which should be applied to both CP SIP and CP HFA phones are summarised in
chapter 3.1.
Additional measures which should be applied to CP SIP only are summarised in chapter 3.2.
Additional measures which should be applied to CP HFA only are summarised in chapter 3.3.
The recommended measures are listed in the following chapters.
3.1. Phone Hardening Measures for OpenScape Desk

Phone CP SIP and OpenScape Desk Phone CP HFA
The following measures are recommended for CP SIP and CP HFA phones:
• Install latest (“Up-to-date”) OpenScape Desk Phone CP software during initial startup phase.
The software is ready to download from the Unify Partner Portal
(http://www.unify.com/us/partners/partner-portal.aspx).
• Phone Administration: local, WBM, DLS, serial port

– Secure local phone administration
Physical access, Phone lock
Set passwords & apply password policy (refer to chapter 6.2)
– Hardening of web-based management
Set passwords & apply password policy (refer to chapter 6.2)
Deactivate if not used
Install customer individual WBM certificate and private key
– Hardening of DLS interface
Set communication between phone and DLS to “secure mode”
Use HTTPS server instead of FTP server and as an alternative to the DLS for file and soft-
ware deployment
Certificates (CA & client) must be downloaded and the certificate policy set
• Set passwords and apply password policy (Password and PIN Policies chapter 6.2)
– Apply password policy as recommended
– Set minimum password length
– Modify default admin password
– Set user password
• Enable IEEE 802.1x in the network and at the phone by installing the appropriate certifications
• Interfaces / Ports
– Disable factory reset via hooded claw
– Enable remote trace only when needed
– Enable PC port only when required
– Enable SSH access only when required
– Disable WBM access if not needed
– Enable SNMP only if required
– Secure Serial Interface Access (--> refer to chapter 5.1.1).
– Disable SD card access if not needed
– Use TLS encryption for LDAP
12 Phone Hardening Measures at a Glance
• Microsoft® Exchange server

– Deploy Server CA Certificates and enable checking
• Circuit by Unify
3.2. Additional Hardening Measures for OpenScape

Desk Phone CP SIP
The following additional measures are recommended for CP SIP only:
• Phone Administration: local, WBM, DLS, serial port
– Secure local phone administration
Lock-down configuration items via DLS, so that these are not changeable from the user ac-
count
• Install certificates and configure secure calls

– Use of OCSP to verify validity of certificates and set a proper policy
– Install TLS certificates and private keys as well as CA certificates
– Enable SIP Signalling encryption
– Enable SIP Payload Encryption
• Use digest authentication
• Interfaces / Ports
– Enable CSTA/ CTI access only when required
– Disable Bluetooth if not needed
– Use TLS encryption and authentication for CSTA server
• Send URL
– Use HTTPS for Send URL applications
• BroadSoft BroadWorks (DMS and XSI servers)

3.3. Additional Hardening Measures for OpenScape

Desk Phone CP HFA
The following additional measures are recommended for CP HFA only:
• Install certificates and configure secure calls
– Use of OCSP to verify validity of certificates and set a proper policy
– Install TLS certificates and private keys as well as CA certificates
– Activate signalling and payload encryption (SPE)
–
• Web Services Interface to OpenScape Business
– Use HTTPS for Web Services Interface to OpenScape Business
Phone Hardening Measures 13
4. Phone Hardening Measures
4.1. Install latest (“up-to-date”) OpenScape Desk

Phone CP Phone Software
The latest (“up-to-date”) released OpenScape Desk Phone CP SIP or OpenScape Desk Phone
CP HFA software version should be installed during initial setup. The software is ready to down-
load from the Unify Partner Portal (http://www.unify.com/us/partners/partner-portal.aspx).
For additional security, ensure “Verify SW Upgrade” is enabled prior to installing the latest software
version to ensure only valid software binds are uploaded to the phone.
For improved security it is recommended to perform the initial configuration of OpenScape Desk
Phones in a separate staging lab.
CL-SW status: Up-to-date SW

Measures Up-to-date SW installed for OpenScape Desk Phone CP
References See Phone Administration Manual chapter on Transferring
Phone Software -> Download / Update Phone Software
Needed Access Rights Admin Access
Can be done via DLS, WBM or local administration
Applicable CP20X/400/600 SIP and CP20X/400/600 HFA
Executed:
Verify SW Upgrade is Yes: No:
enabled
Install latest software Yes: No:
version
Phone Types
Software Version Installed
Customer Comments /
Reasons. If some mea-
sures are not executed
then please explain here:
Related Topics
4.2. Secure Administration Access to the Phone

The administration of the phone has to be protected from unauthorized access. There are several
measures to facilitate a secure local phone administration, the hardening of web-based manage-
ment and DLS interface.
Fixed passwords are a serious security risk, and the Password and PIN policy in Chap. 6.2 is
strongly recommended. The access to the phone is possible on two levels: Admin and User. Each
level has its own password policy and password. Separate passwords should be used for Admin
and User access.
14 Phone Hardening Measures
4.2.1. Harden Local phone Admin Access

Related Topics
CL-Secure Admin
Access
Measure • Setup the password policy for Admin password
• Set a secure Admin password for each phone
• If not needed, disable local administration access at the
phone. This can only be done using DLS
• Disable Hooded Claw for Factory reset
References See Chapter 6.2 for setting Password policy
See Phone Administration Manual chapter on Security ->
Password Policy
Executed:
Setup Generic Admin Yes: No:
Password Policy
Set Secure Admin Yes: No:

password
Setup Admin Password Yes: No:

Policy
Disable Local Admin Yes: No:

Access
Disable Hooded Claw for Yes: No:

Factory Reset
Customer Comments and

4.2.2. Harden Local phone User Access

In addition to setting an individual secure password for each phone the following can be done to
harden user access to the phone:
• Where phones should only be used by specific users - for example for phones in secure areas
where visitors are not allowed access to use the phone, or in public areas where public use of
the phone is not allowed then the Phone Lock feature should be turned on. A valid User pass-
word is needed for this feature. Emergency calls are possible while the phone is locked, but
Users will need to unlock the phone to make regular calls and gain access to user data on the
phone - for example call log or directory.
• On OpenScape Desk Phone CP400 and OpenScape Desk Phone CP600, HFA and SIP phones,
the list of current and previous conversations may be displayed. As this information may be con-
sidered private to the user of the phone, the Phone Lock feature should be turned on and the
phone user should lock their phone if they leave it unattended and do not wish other people to
see the contents of their conversation list.
• To prevent users making changes to configuration items the User access can be blocked at the
following levels:
– Particular configuration items can be locked down by configuration of the data constraints
in the DLS
– User access to the User menus can be disabled. The user can still set forwarding and con-
figure the programmable FPK keys, but access to individual user settings is disabled.
IF THE LOCAL USER ACCESS IS DISABLED THEN THE PHONELOCK FEATURE WILL
NOT WORK
• If the customer's security policy is to prevent access to information about the phone setup such
as the IP address being used then access to the diagnostic data should be disabled.
NOTE: for OpenScape Desk Phone CP20X/400/600 SIP phones:

The Phone Lock feature is a local phone based feature. Please refer to the appropriate User
Guides (from the Unify Experts Wiki http://wiki.unify.com/wiki) and chapter 6.2 for Password and
PIN Policies.
NOTE: for OpenScape Desk Phone CP20X HFA phones:

1.The Phone Lock feature is a system based feature. Please refer to the appropriate manual for
the HFA Gateway (from http://www.unify.com/uk/support/manuals.aspx).
2.There is no user access other than setting up user password for CTI purposes through WEBM
only.
NOTE: for OpenScape Desk Phone CP400/600 HFA phones:

1. There are two distinct Phone Lock features; one is local based and the other is system based.
The system based phone lock prevents unauthorised use of the phone in particular making a call
(except emergency calls when configured). It does not prevent an unauthorised user viewing the
phone’s display and any information contained on it. The local based phone lock prevents
unauthorised access to the phone and any information it contains.
2. As the local based Phone Lock offers greater protection, it should be used in preference to the
system based Phone Lock.
3. If the system based Phone Lock is required in preference to the local based Phone Lock, the
local based Phone Lock should be disabled otherwise the two phone locks will interact with each
other.
4. For system Phone Lock feature, please refer to the appropriate Manual for the HFA Gateway
(from http://www.unify.com/uk/support/manuals.aspx).
5. For local Phone Lock feature, please refer to the appropriate User Guides (from the Unify
Experts Wiki http://wiki.unify.com/wiki) and chapter 6.2 for Password and PIN Policies.
CL-Secure User
Access
Measure • Setup Password Policy for User password
• Set an individual User Password for each phone
• Set Phone Lock ON
• Lock Down particular data items by configuration at DLS
• Disable User Access to configuration menus
• Disable access to diagnostic data if needed to comply with
customer's security policy
• Advise users to lock their phone if they leave it unattended and they
do not wish their conversations list to be seen by others
• On CP400/600 HFA only, if system based Phone Lock is required
in preference to the local based Phone Lock, disable local lock
References See Chapter 6.2 for password and PIN policy
See Phone Administration Manual chapter on Security -> Password
Policy
Needed Access Admin Access
Rights
Applicable CP20X/400/600 SIP CP20X/400/600 HFA
Executed:
Setup Generic Yes: No: Yes: No:
User Password
Policy
Setup User Yes: No: Yes: No:
Password Policy
Secure User Yes: No: Yes: No:

password Set
Set Phone Lock Yes: No: Yes: No:

ON
Lock Down Yes: No: Yes: No:

required
configuration data
Disable User Yes: No: Yes: No:
Access
Disable User Yes: No: Yes: No:

access to
diagnostic data
Advise users to Yes: No: Yes: No:
lock their phone if
they leave it
unattended
CL-Secure User
Access
Disable Local Not available Yes: No:
Lock if using
system based
Lock in preference Not applicable:
(CP400/600 only)
Customer
Comments and
Reasons. If some
measures are not
executed then
please explain
here:
Related Topics
4.2.3. Harden DLS Interface to the Phone

The communication between DLS and Phone can be configured in default mode. In the default
mode the phone recognizes the DLS because it knows the DLS IP address. There is no authenti-
cation between Phone and DLS.
• When the DLS IP Address is provided by the DHCP Server, service access with a second DLS
is not possible because DLS IP Address is supplied only by DHCP.
• In the case where the DLS IP Address is not provided by the DHCP Server, a second DLS (even
a threatened one) could take over the control of the phone.
If the communication between DLS and phone is configured in secure mode, they authenticate via
HTTPS mutual authentication. Now a second DLS only can get read/write access to the phone if
it knows the customer specific credentials.
• Independently of the usage of a DHCP Server, a service access with a second DLS is possible,
if the second DLS uses the customer specific credentials for authentication. The phone itself al-
ways contacts the first DLS.
In all cases the security of the DHCP Server access is in customers hand. His network should be
able to recognize a second (may be threatened) DHCP server, e.g. by using an IDS system.
4.2.3.1. Setting communication between phone and DLS to “secure mode”
"Secure mode" offers mutual authentication between DLS and the phone. The connection bet-
ween DLS and phone will be established, if DLS has successfully authenticated the phone and
vice versa. Secure mode with or without PIN (Personal Identification Number) will be set by the
DLS. The PIN has to be inputted at the phone when requested. "Secure mode with PIN" protects
the transfer of the key material and should be preferred. Usage of Secure mode without PIN may
offer an attacker to capture the key material and may get non-authorized access to the DLS and
phone.
Prerequisites for the usage of the secure mode are the following:
• Customer specific key material has to be created, e.g. with customers own CA or with openSSL
or other tool. Provided by customer.
• The key material is distributed by DLS to phones in default mode (in customer network or pre-
configured). The distribution of keys and certificates via DLS (Deployment Service) is depicted
in the Deployment Service Admin Guide, chapter "Automatic Certificate Deployment"
• Both phones as well as DLS have to be set to "secure mode". How to configure the secure mode
for phone is described in "IP Device Configuration".
CL-Secure DLS Access

Measure • If using Default mode ensure that the DLS address is
provided by the DHCP
• For improved security use secure mode between DLS
and Phone
References See Phone Administration Manual chapters on Vendor Spe-
cific: VLAN Discovery and DLS Address and How to Use
Option #43 "Vendor Specific"
See DLS manual Configuration & Update Service (DLS)
Executed:
Provide DLS IP address Yes: No:
from DHCP
Setup Secure mode for Yes: No:

DLS - Phone communica-
tions

4.2.4. Harden Software Deployment and File Download to the

Phone
To provide a secure file download for the files (for example ringer files) and software updates loa-
ded onto the phone HTTPS should be used. A separate HTTPS download server will be needed.
Authentication of the HTTPS server at the phone is also needed and this can be setup by loading
the HTTPS server CA certificate into the phone and configuring the authentication policy. Mutual
authentication is possible when both the HTTPS Server CA certificate and the Phone HTTPS cli-
ent certificate are loaded in the phone.
An Administrator may use the browser based software update facility instead of a separate HTTPS
download server. If an Administrator uses it and leaves their PC unattended whilst the upload is
in progress, the Administrator should lock their PC in the normal manner to ensure the upload con-
tinues in their absence and there is no unauthorized access to the administrator's web page.
CL-Secure Software
Deployment and File
download
Measure • Configure Download of Software Deployment and files
such as screensavers or ringtones to use HTTPS
• Install the HTTPS Server CA certificate and a HTTPS
phone client certificate in the phone
• The HTTPS certificate policy needs to be set to Trusted
or Full
• OCSP checking of the certificate will ensure that the
certificate from the HTTPS server has not been revoked
References See Chapter 6.3 for Certificate Handling
See Phone Administration Manual chapters on Security ->
Certificate Policy and Transferring Phone Software -> Down-
load / Update Phone Software
See DLS manual Configuration & Update Service (DLS) for
installing certificates
Executed:
Configure Phones to use Yes: No:
HTTPS for software and
file download
Install HTTPS certificates Yes: No:

on the phone
Configure Secure File Yes: No:

Transfer certificate policy
Configure OCSP checking Yes: No:

Related Topics
4.3. Configure Password Policy and Passwords

The OpenScape Desk Phone CP phones are delivered with default passwords and password po-
licy. These must be changed to the customer specific passwords and password policy. The recom-
mended password and PIN policy is in chapter 6.2.
CL-Secure pass-
words
Measures • Set the Generic Password Policy
• Set the Admin Access password policy
• Set the User Access password policy
• Set secure Admin password
• Set individual secure User password for each phone
References See Chapter 6.2 for password and PIN policy
See Phone Administration Manual chapter on Security -> Password Pol-
icy
Rights
Executed:
Setup Generic Pass- Yes: No: Partly:
word Policy
Setup Admin Pass- Yes: No: Partly:

word Policy
Setup User Password Yes: No: Partly:

Policy
Set Secure Admin Yes: No:

password
Set Secure User Yes: No:

passwords for
phones
Customer Com-
ments and Reasons.
If some measures are
not executed then
please explain here:
Related Topics
4.4. Authentication of phone at SIP Server

(OpenScape Desk Phone CP SIP only)
4.4.1. Harden Phone to use Digest Authentication (OpenScape

Desk Phone CP SIP only)
To ensure that only authorized phones contact the SIP Server Unify provides the state-of-the-art
Digest Authentication mechanism.
The Digest Authentication uses a Challenge Response Algorithm. It is uses a user ID - which can
be the phone number - and a password. The SIP server sends a Challenge and the phone res-
ponds with its password.
Digest Authentication can be used without Secure signalling over TLS - the password is transmit-
ted in a secure format, but use of TLS signalling is strongly recommended to provide an overall
security for the signalling. Use of TLS will also allow authentication by the phone of the SIP Server
- see chapter 4.5.1.
The Digest Authentication must be configured on the SIP Server before setting up the phone.
Please see the Security Check List for the SIP server.
CL-Secure Phone
Authentication on SIP
Server
Measure • Setup Digest Authentication User ID and Password
References See Phone Administration Manual chapter on System
Settings -> SIP registration
Applicable CP20X/400/600 SIP only.
Not CP20X/400/600 HFA.
Executed:
Set SIP Authentication Yes: No:
User ID and Password in
the phone
Customer Comments /
Reasons:
Related Topics
4.5. Secure Signalling and Voice Access to the Phone

To give privacy for Voice connections, the OpenScape Desk Phone CP SIP phones should use
TLS for the signalling and Secure RTP for the voice connections.
4.5.1. Harden Signalling to Secure Signalling (OpenScape Desk

Phone CP SIP only)
To provide a secure signalling mechanism TLS signalling should be used.
• Configure use of TLS on the SIP server and install server certificates
• Configure TLS on the phone - the port will need to be set to 5061
In addition to using TLS signalling, authentication of the server by the phone can be done by vali-
dating the Server certificate sent by the SIP server.
• Install the SIP Server CA certificate on the phone using DLS
• Configure the TLS certificate validation policy to trusted or full - full is recommended
• Configure OCSP checking to allow revocation checking of the SIP server certificate
It should be noted that if the Backup / Dual registration mode is used as part of survivability setup,
the phone only supports TLS on the connection to the primary SIP server. The connection used
for the backup/dual registration is only possible using UDP or TCP not TLS. To avoid this vulner-
ability the use of DNS-SRV is recommended for survivability setup. To avoid unplanned use of
UDP/TCP when using TLS connections the Backup Proxy Address should be configured as
0.0.0.0.
If the SIP server mutually authenticates the phone, a phone client certificate must be installed on
the phone using the DLS.
CL-SIP Secure
Signalling
Measure • Configure use of TLS on the SIP server and install server
certificates
• Configure TLS on the phone - the port will need to be set
to 5061
• Install the SIP Server CA certificate on the phone using
DLS
• If mutual authentication by SIP server is required, install
phone client certificate on the phone using DLS
• Configure the TLS certificate validation policy to trusted
or full - full is recommended
• Configure OCSP checking to allow revocation checking
of the SIP server certificate
• Configure the Backup proxy address 0.0.0.0
Certificate Policy
See Phone Administration Manual chapter on System
Settings -> SIP Addresses and Ports
Executed:
Set Signalling Transport to Yes: No:
TLS
Set Port for Signalling to Yes: No:

value 5061
Install TLS certificates on Yes: No:

the phone using DLS
Configure Secure SIP Yes: No:

Server certificate policy

CL-SIP Secure
Signalling
Configure Backup Proxy Yes: No:
address to 0.0.0.0

Related Topics
NOTE: The hardening measures to secure signalling to the SIP server will also secure signalling
to the CSTA server (see chapter 4.7.9)
4.5.2. Harden Phone to use Secure (Encrypted) Voice

To provide secure encrypted communication for voice calls, secure calls and the key exchange
protocol (SDES or MIKEY) must be configured.
Secure signalling must be setup before doing the setup for secure voice. (see chapter 4.5.1)
CL-Secure Calls
Measure • Configure Secure Calls
• Configure Key Exchange protocol (SDES or MIKEY)
• If using SDES configure the parameters for SDES
References See Phone Administration Manual chapter on Security ->
Speech Encryption
Executed:
Configure Secure Calls (1) Yes: No:
Configure SRTP type Yes: No:

(Mikey or SDES)
If SDES selected, Yes: No:

configure SDES
parameters
NOTE: (1) DTLS-SRTP will be available but is not recommended currently
4.6. Secure Signalling and Voice Access to the Phone

(OpenScape Desk Phone CP HFA only)
To give privacy for Voice connections, the OpenScape Desk Phone CP HFA phone should
authenticate the HFA Gateway, use TLS and activate signalling and payload encryption (SPE) for
secure signalling and voice communication.
4.6.1. Harden Connection to HFA Gateway (OpenScape Desk

Phone CP HFA only)
The connection to the HFA Gateway can be hardened by using TLS Signalling (see chapter 4.6.2)
and authenticating the HFA Gateway.
The authentication of the HFA Gateway by the phone can be done by validating the Server certi-
ficate sent by the HFA Gateway.
• Install appropriate certificates on the HFA Gateway
• Install the HFA Gateway CA certificate on the phone using DLS
• Configure the TLS certificate validation policy to trusted or full – full is recommended
• Configure the TLS renegotiation setting – Secure is recommended
• Configure OCSP checking to allow revocation checking of the HFA Gateway certificate
If the HFA Gateway mutually authenticates the phone, a phone client certificate must be installed
on the phone using the DLS.
.
CL – HFA Authenticate
Gateway
Measure • Install appropriate certificates on the HFA Gateway.
• Install the HFA Gateway CA certificate on the phone
using DLS
• If mutual authentication by HFA Gateway is required,
install phone client certificate on the phone using DLS
• Configure the TLS certificate validation policy to trusted
or full – full is recommended
• Configure the TLS renegotiation setting – Secure is
recommended
• Configure OCSP checking to allow revocation checking
of the HFA Gateway certificate
Certificate Policy
Applicable CP20X/400/600 HFA only.
Not CP20X/400/600 SIP.
CL – HFA Authenticate
Gateway
Executed:
Install appropriate certifi- Yes: No:
cates on the HFA Gate-
way:
Install TLS certificates on Yes: No:
the phone using DLS:
Configure Secure HFA Yes: No:

Gateway certificate policy:
Configure TLS renegotia- Yes: No:

tion:
Configure OCSP check- Yes: No:

ing:

NOTE: The hardening measures to secure connection to the HFA Gateway will also secure
connection to the Web Services Interface to OpenScape Business (see chapter 4.7.12)
4.6.2. Harden Phone to use Signalling and Payload Encryption

(OpenScape Desk Phone CP HFA only)
To provide secure encrypted signalling and voice communication, signalling and payload encryp-
tion (SPE) must be activated through the Transport Protocol.
To activate signalling and payload encryption:
• Configure use of TLS on the HFA Gateway
• Configure TLS on the phone – the ports will need to be set to 4061 for Cornet TLS and 1300 for
H.225 TLS
When signalling and payload encryption (SPE) is activated, the payload is protected via SRTP and
signalling is protected via TLS
NOTE: The terms “HFA Transport Protocol” and “HFA Backup Transport Protocol” used in the
“HFA Settings” tab on the DLS (See OpenScape Deployment Service Main Menu > IP Devices >
IP Phone Configuration > Signaling and Payload Encryption (SPE)) are equivalent to the terms
“Signalling transport main” and “Signalling transport standby” used in the Administrator settings on
the phone (See System > Security > System)
.
CL – HFA Activate
signalling and payload
encryption
Measure • Configure use of TLS on the HFA Gateway
• Configure TLS on the phone – the ports will need to be set
to 4061 for Cornet TLS and 1300 for H.225 TLS
References See Phone Administration Manual chapter on System Set-
tings -> HFA Addresses and Ports
Applicable CP20X/400/600 HFA only.
Not CP20X/400/600 SIP.
Executed:
Configure use of TLS on Yes: No:
the HFA Gateway
Set Transport Protocol to Yes: No:

TLS
Set Port for Cornet TLS to Yes: No:

value 4061:
Set Port for H.225 TLS to Yes: No:

value 1300

4.7. Secure Interfaces and Services to the Phone

To allow easy initial use of OpenScape Desk Phone CP phones, the majority of services and in-
terfaces are enabled by default. To harden the phone, services and interfaces not used should be
disabled. Also where a more secure protocol is available for a service then that should be confi-
gured, for example use TLS instead of UDP or TCP
4.7.1. PC Port
The PC port allows a LAN cable to be connected directly between the phone and an adjacent PC,
thereby using the same LAN connection for both PC and Phone at the desk. To prevent unauthori-
sed access to the network using the PC port on the phone, the port should be disabled if not nee-
ded.
The default setting for the PC port is disabled, but it should be checked that PC port is disabled on
phones which do not need a local PC connection.
CL-PC Port
Measure • Disable PC Port
References See Phone Administration Manual chapter on LAN Settings
-> LAN Port Settings
Executed:
Disable PC Port if not Yes: No:
needed by user

Reasons
NOTE: If PC port is configured as mirror port, signalling and voice of the phone can be sniffed.
The mirror port setting is reserved for technical specialists.
4.7.2. CCE Interface

The Comms Channel Extender (CCE) interface should be disabled.
This port is used by the HPT tool, and disabling the port will prevent use of the HPT tool.
Enabling the CCE interface will open the port for remote service access by the HPT tool (see chap-
ter 5.5)
NOTE: Disabling Local Admin Access (see chapter 4.2.1) will also prevent use of the HPT tool.
CL-HPT Connection
Measure • Disable CCE access
References See Phone Administration Manual chapter on Security ->
Access Control
Executed:
Disable CCE access if not Yes: No:
needed for HPT

Reasons
Related Topics
4.7.3. Key Module

The OpenScape Desk Phone CP400 phone can be expanded with up to two Key Modules KM400
with 16 function keys. The power saving design allows the connection of two key modules within
the PoE Class 2.
The OpenScape Desk Phone CP600 phone can be expanded with up to four Key Module KM600
if locally powered but will only support one if PoE is used. Disconnecting local power from an
OpenScape Desk Phone CP600 with more than one key module attached will result in the phone
restarting. When the PoE powered OpenScape Desk Phone CP600 has restarted, only one of the
key modules will be powered. The facilities provided by the keys on the non-powered key modules
are no longer available. Full functionality on all key modules can be re-instated by restoring local
power to the OpenScape Desk Phone CP600.
Reducing the number of powered key modules ensures the OpenScape Desk Phone CP600 does
not draw more than its agreed power from PoE.
CL- Key Module

Measure • Ensure OpenScape Desk Phone CP600 phones with
more than one Key Module attached are locally powered.
References See OpenScape Desk Phone CP20X/400/600 Phone
Administration Manual
Needed Access Rights Not appropriate
Applicable CP600 SIP and CP600 HFA only.
Not CP20X/400 SIP or CP20X/400 HFA
Executed:
Ensure OpenScape Desk Yes: No:
Phone CP600 phones with
more than one Key Mod-
ule attached are locally
powered.
4.7.4. SD Card
The OpenScape Desk Phone CP 600 has an SD card slot to support the usage of standard SD
and SDHC cards at default speed. SDXC cards may also be supported provided they are format-
ted with FAT32.
The default setting for SD slot access is disabled, but it should be checked that SD slot access is
disabled on phones which do not need to use SD cards.
Unify recommends to disable the SD slot access if not used. This is general security best-practice
to reduce the likelihood of successful attacks via yet unknown vectors.
CL- SD card
Measures • Disable SD slot access
References See Phone Administration Manual chapter on Feature
Access
Executed:
Disable SD slot access if Yes: No:
not needed by user for SD
card
4.7.5. Remote Call Control (CSTA)

Call Setup is possible by remote CTI clients running on a PC or server. The call control is perfor-
med using CSTA and uaCSTA protocol in SIP messages from the SIP server.
It is possible for this to be used in a malicious way and the service should only be enabled where
needed. A CTI service allowed/not allowed setting is available at Admin level to control this.
When the CTI service is allowed then the user can choose to use auto answer or not. Setting auto
answer to off will prevent unwanted automatic answering of calls setup by a remote client - for ex-
ample for phones in conference rooms or public areas. When Auto Answer is configured off then
each call will be presented to the user, and the user must accept the call before it is answered.
CL-CSTA Access
Measures • Set CTI Service to Disallow if not needed
• Set Auto Answer to No if not needed
References See Phone Administration Manual chapter on Feature
Access
See Phone User Guide chapter on Enhanced phone func-
tions -> incoming calls -> CTI calls
Executed:
If CSTA feature is not Yes: No:
used then set CTI control
to disallow
CL-CSTA Access
If CTI is allowed and Auto Yes: No:
Answer is not wanted or
used then set Auto
Answer to No
4.7.6. Bluetooth Access

On the OpenScape Desk Phone CP 600 phone, Bluetooth is available and allows use of Bluetooth
headsets, transfer of contact information (vcard), proximity monitoring and Eddystone beacon and
iBeacon.
The OpenScape Desk Phone CP 600 uses encryption whenever possible. If and only if the Blue-
tooth device that is being paired does not support encryption, encryption will not be used. The
manual for the Bluetooth device should be consulted to see if it supports encryption. Encryption
is required to ensure there is no disclosure of the data carried between the Bluetooth device and
the OpenScape Desk Phone CP 600 phone through eavesdropping.
Following measures to control access via Bluetooth are available:
• If Bluetooth is not used then it should be disabled
• If a user does not wish to use a Bluetooth headset for unlocking the phone, proximity monitoring
in the headset's configuration should be disabled
• If a user does not wish to broadcast the phone's BD_ADDR over the air, Eddystone beacon and
iBeacon should be disabled
• If an OpenScape Desk Phone CP 600 phone should not track BLE beacons in the company's
localization solution, localization client should be disabled
CL-Bluetooth
Measure • Disable Bluetooth if not used
• Disable Proximity monitoring if not used
• Disable Eddystone beacon if not used
• Disable iBeacon if not used
• Disable Localization client if not used
References See Phone Administration Manual chapter on Bluetooth
See Phone User Guide chapter on Individual phone configu-
ration -> Bluetooth
Needed Access Rights Admin Access / User Access
Executed:
If Bluetooth is not needed Yes: No:
then disable it in Admin
menu
CL-Bluetooth
If Bluetooth is enabled and Yes: No:
proximity monitoring is not
needed, inform users to
disable proximity
monitoring
Eddystone beacon and
iBeacon are not needed,
inform users to disable
beacon
Localization client is not
needed then disable
Localization client in
Admin menu
NOTE: The CP600 phone has implemented the Apple iBeacon technology according to Release
R1 of Apple's Proximity Beacon Specification, dated 2015-09-04. By design, the iBeacon adver-
tisement frame is plainly visible and open to spoofing or hijacking. This is not a security flaw in the
iBeacon per se, but application developers must keep this in mind when designing their applica-
tions with iBeacons. There is no impact on the phone when iBeacon advertisement frames are
spoofed or hijacked; the impact is on the third party application that uses iBeacon. For further infor-
mation, refer to https://developer.apple.com/ibeacon.
4.7.7. LDAP
To harden access to the LDAP server:
• simple authentication should be used with a userID and password configured in the phone
• encrypted LDAP using TLS should be used to prevent data exchanged during an LDAP query
being visible on the LAN
• install the LDAP Server CA on the phone using the DLS
• configure the LDAP Server certificate authentication policy to trusted or full - full is recommen-
ded
• configure OCSP checking to allow revocation checking of the LDAP server certificate
CL-Secure phone
access to LDAP Server
Measure • Configure simple authentication with user ID and
password
• Configure TLS as transport protocol
• Install the LDAP Server CA certificate
• The LDAP Server certificate authentication policy needs
to be set to Trusted or Full
certificate from the LDAP Server has not been revoked
References See Phone Administration Manual chapter on Corporate
Phone book: Directory Settings -> LDAP
Applicable CP20X/400/600 SIP and CP400/600 HFA only.
Not CP20X HFA.
Executed:
Configure Simple Authen- Yes: No:
tication and set the LDAP
User ID and Password in
the phone
Set LDAP Transport to Yes: No:
use TLS
Install certificate on the Yes: No:

phone
Configure Secure LDAP Yes: No:

server certificate
authentication policy

4.7.8. Microsoft® Exchange server

The Microsoft® Exchange Server requires the user to provide the username and password for
simple authentication whenever the user wants to access it. The username and password are
configured in the User Settings on the phone.
To harden access to the Microsoft® Exchange Server, authentication of the server by the phone
can be done by validating the Server certificate sent by the Microsoft® Exchange Server.
• Install the Exchange Server CA on the phone using the DLS
• Configure the Exchange Server certificate authentication policy to trusted or full - full is recom-
mended
• Configure OCSP checking to allow revocation checking of the Exchange server certificate.
CL-Secure phone
access to Microsoft®
Exchange Server
Measure • Install the Exchange Server CA certificate
• The Exchange Server certificate authentication policy
needs to be set to Trusted or Full
certificate from the Exchange Server has not been
revoked
Certificate Policy
See Phone User Guide chapter on Microsoft® Exchange
Server
Applicable CP400/600 SIP and CP400/600 HFA only.
Not CP20X SIP or CP20X HFA.
Executed:
phone
Configure Secure Yes: No:

Exchange server
certificate authentication
policy

4.7.9. CSTA Server

When an IP Telephony solution consists of a separate uaCSTA registrar server (termed “CSTA
server”) and a SIP server, the signalling between the phone and both servers can be secured
using the same TLS configuration and server certificates.
The hardening measures to secure signalling to the SIP server were detailed in chapter 4.5.1.
When these measures are applied:
• Configuring the SIP transport as TLS on the SIP interface will automatically configure TLS for
the CSTA server.
• Installing the SIP Server CA certificate on the phone using DLS for the SIP server will automati-
cally add it for the CSTA server.
• Configuring the TLS certificate validation policy for the SIP server will automatically configure
the same policy for the CSTA server.
• Configuring the OCSP checking to allow checking of the SIP server certificate will automatically
allow checking of the CSTA server certificate.
The SIP and CSTA server certificates should be signed by the same Certificate Authority (termed
“CA”) to take advantage of the automatic behaviour.
Should the SIP and CSTA server certificates be signed by different CAs, two separate root CAs
will need to be installed on the phone; one for the SIP server and the other for the CSTA server.
When these certificates are approaching their expiry, new root CA certificates must be installed on
the phone before the old ones have expired. The start date for the new certificates must be before
the end dates of the expiring certificates.
If the CSTA server mutually authenticates the phone, a phone client certificate must be installed
The same phone client certificate will be used to authenticate the phone to the SIP server if au-
thentication is requested by the SIP server.
These measures are repeated here as a reminder that the same settings apply to both the SIP
server and the CSTA server.
Table: Access to CSTA Server
CL-Secure Signal-
ling to the CSTA
Server
Measures The hardening measures implemented to secure SIP Signalling (See
chapter 4.5.1)
• Configured SIP Transport Protocol to TLS
• Installed the SIP Server CA certificate on the phone using DLS
• Configured the TLS certificate validation policy to trusted or full – full
is recommended
• Configured OCSP checking to allow revocation checking of the SIP
and CSTA server certificates
• If mutual authentication by CSTA server is required, install phone
client certificate on the phone using DLS
References See Chapter Certificate Handling for Certificate Handling.
See Phone Administration Manual chapter on Security -> Certificate Pol-
icy
See DLS manual Configuration & Update Service (DLS) for installing
certificates
See Phone Administration Manual chapter on System Set- tings -> SIP
Transport
See Phone Administration Manual chapter on System Set- tings -> Stan-
dard CSTA Server Address and Port
Applicable Only applicable to IP Telephony solutions that consist of a separate
uaCSTA registrar server and SIP server which have certificates signed
by the same Certificate Authority.
CP20X/400/600 SIP only. Not CP20X/400/600 HFA
Rights
Executed:
Signalling Transport Yes: No: Not applicable:
set to TLS
CL-Secure Signal-
ling to the CSTA
Server
TLS certificate Yes: No: Not applicable:
installed on the
phone
Secure SIP Server Yes: No: Not applicable:
certificate policy con-
figured
OCSP check config- Yes: No: Not applicable:
ured
If Mutual Authentica- Yes: No: Not applicable:

tion is required,
phone client certifi-
cate installed on the
phone
Customer Com-
ments and Reasons.
not executed then
4.7.10. BroadSoft BroadWorks servers

The OpenScape Desk Phone CP SIP phones use HTTPS connections to BroadSoft BroadWorks
DMS and XSI servers for the transfer of configuration and call log information, respectively.
BroadSoft BroadWorks Servers require a username and password for simple authentication whe-
never the user wants to access it. The username and password are configured in the Admin Set-
tings on the phone.
There may be occasions when the phone will fail to authenticate with the DMS server because the
user name and/or password are incorrect. This data is normally configured by the administrator of
the phone. To allow the data to be entered when there isn’t an administrator available, a popup will
be displayed which will allow anybody to enter the user name and password for the DMS server.
No security threats have been introduced by doing this.
To harden access to the BroadSoft BroadWorks Servers, authentication of the server by the phone
can be done by validating the Server certificate sent by the BroadSoft BroadWorks Servers:
• Install the BroadSoft BroadWorks DMS Server CA on the phone using the DMS
• Install the BroadSoft BroadWorks XSI Server CA on the phone using the DMS
• Configure the BroadSoft BroadWorks DMS Server certificate authentication policy to trusted or
full – full is recommended
• Configure the BroadSoft BroadWorks XSI Server certificate authentication policy to trusted or
full – full is recommended
• Configure OCSP checking to allow revocation checking of the BroadSoft BroadWorks DMS and
XSI server certificates.
NOTE: Additional Notes and Hardening Measures: Obtaining Call Logs through XSI Interface
1. As the URI to select call log entries from the XSI server has the user name embedded in it, it is
essential the XSI server is configured to authenticate the requests to ensure the call log entries
remain confidential to each user.
2. Where there are local privacy issues, the call log feature should be disabled on the XSI server.
Any requests from the phone will result in no call log entries being obtained because there should
be no call log entries on the XSI server.
CL – Secure phone
access to BroadSoft
BroadWorks
Measure • Configure simple authentication with username and
password
• Install the BroadSoft BroadWorks DMS Server CA
certificate
• Install the BroadSoft BroadWorks XSI Server CA
certificate
• The BroadSoft BroadWorks DMS Server certificate
authentication policy needs to be set to Trusted or Full –
Full is recommended
• The BroadSoft BroadWorks XSI Server certificate
authentication policy needs to be set to Trusted or Full –
Full is recommended
certificates from the BroadSoft BroadWorks DMS and XSI
Server have not been revoked
Certificate Policy
See Phone User Guide chapter on BroadSoft BroadWorks
Not CP20X/400/600 HFA
Executed:
Configure username and Yes: No:
Password for the
BroadSoft BroadWorks
DMS and XSI servers
Install certificates on the Yes: No:
phone using the DMS
Configure Secure DMS Yes: No:

server certificate
Configure Secure XSI Yes: No:
server certificate
CL – Secure phone
access to BroadSoft
BroadWorks

4.7.11. Circuit by Unify server

The Circuit by Unify Server requires the user to provide the username and password for simple
authentication whenever the user wants to access it. The username and password are configured
in the User Settings on the phone.
To harden access to the Circuit by Unify Server, authentication of the server by the phone can be
done by validating the Server certificate sent by the Circuit by Unify Server.
• Install the Circuit by Unify Server CA on the phone using the DLS
• Configure the Circuit Server certificate authentication policy to trusted or full – full is recommen-
ded
• Configure OCSP checking to allow revocation checking of the Circuit server certificate.
CL – Secure phone
access to Circuit by
Unify Server
Measure • Install the Circuit by Unify Server CA certificate
• The Circuit Server certificate authentication policy needs
to be set to Trusted or Full
certificate from the Circuit Server has not been revoked
References See chapter 6.3 for Certificate Handling
Certificate Policy
See Phone User Guide chapter on Circuit by Unify Server
Applicable CP400/600 SIP and CP400/600 HFA only.
Not CP20X SIP or CP20X HFA.
Executed:
phone using the DLS
Configure Secure Circuit Yes: No:

server certificate
CL – Secure phone
access to Circuit by
Unify Server

4.7.12. Web Services Interface to OpenScape Business

OpenScape Desk Phone CP400 HFA and OpenScape Desk Phone CP600 HFA provide access
to the Unified Directory and other UC functionality to OpenScape Business users through the Web
Services Interface (WSI) on OpenScape Business.
Access to the OpenScape Business Web Services (server and port) are configured in the Admi-
nistrator settings on the phone.
The Web Services Interface requires UC user credentials (UC user name and password) for sim-
ple authentication before accessing UC features. The UC credentials user name and password
are configured in the User Settings on the phone.
For OpenScape Business users without UC license, a restricted “non-UC” mode is available. This
allows access to the Unified Directory (phonebooks of OpenScape Business), but not to any other
UC features. In this case, the Gateway subscriber password (HFA password) is required for Web
Services authentication instead of UC user credentials. Without configured Gateway subscriber
password, access to OpenScape Business Web Services in non-UC mode is not possible.
The two connections to HFA Gateway and Web Services Interface can be secured using the same
TLS configuration and server certificates.
The measures to harden the connection to the HFA Gateway were detailed in chapter 4.6.1.
When these measures are applied:
• Installing the HFA Gateway CA certificate on the phone using DLS for the HFA Gateway will au-
tomatically add it for the Web Services Interface to OpenScape Business.
• Configuring the TLS certificate validation policy for the HFA Gateway will automatically configure
the same policy for the Web Services Interface to OpenScape Business.
• Configuring the TLS renegotiation setting for the HFA Gateway will automatically configure the
same setting for the Web Services Interface to OpenScape Business.
• Configuring the OCSP checking to allow checking of the HFA Gateway certificate will automati-
cally allow checking of the Web Services Interface server certificate.
These measures are repeated here as a reminder that the same settings apply to both the HFA
Gateway and the Web Services Interface to OpenScape Business.
The HFA Gateway and Web Services Interface server certificates should be signed by the same
Certificate Authority (termed “CA”) to take advantage of the automatic behaviour.
Should the HFA Gateway and Web Services Interface server certificates be signed by different
CAs, two separate root CAs will need to be installed on the phone; one for the HFA Gateway and
the other for the Web Services Interface. When these certificates are approaching their expiry, new
root CA certificates must be installed on the phone before the old ones have expired. The start
date for the new certificates must be before the end dates of the expiring certificates.
If the HFA Gateway mutually authenticates the phone, a phone client certificate must be installed
The same phone client certificate will be used to authenticate the phone to the Web Services In-
terface if authentication is requested by the Web Services Interface.
In addition to downloading certificates onto the phone and configuring the validation policy and
OCSP checking:
• To provide secure communication between the phone and the UC Server Protocol HTTPS
should be used.
NOTE: Additional Notes and Hardening Measures:

1. OpenScape Desk Phone CP400 HFA and OpenScape Desk Phone CP600 HFA only use a
limited functional subset of the Web Services Interface commands. The UC server on OpenScape
Business controls which functions are allowed for particular clients.
2. OpenScape Desk Phone CP400 HFA and OpenScape Desk Phone CP600 HFA always tries to
connect to the UC server, when connected to the OpenScape Business system and UC server
configuration (IP address and port) is given.
3. The Web Services Interface to OpenScape Business may return phonebook, presence, and call
log information. To ensure the confidentiality of this information, HTTPS must be used. It is
essential that the default configuration on OpenScape Business which blocks HTTP connections
has not been overridden.
CL-Secure Signal-
ling to the Web
Services Interface
Measures The measures implemented to harden the HFA Gateway (See
chapter 4.6.1)
• Installed the HFA Gateway CA certificate on the phone using DLS
• Configured the TLS certificate validation policy to trusted or full – full
is recommended
• Configured OCSP checking to allow revocation checking of the HFA
Gateway certificate
• If mutual authentication by HFA Gateway is required, install phone
client certificate on the phone using DLS
In addition:
• Configure phones to use HTTPS for the UC Server Protocol
• Configure phones with OpenScape Business Web Services server
and port addresses
• Confirm default configuration on OpenScape Business which blocks
HTTP connections has not been overridden
References See chapter 6.3 for Certificate Handling.
See Phone Administration Manual chapter on Security -> Certificate Pol-
icy
See DLS manual Configuration & Update Service (DLS) for installing
certificates
Applicable CP400/600 HFA only.
Not CP20X/400/600 SIP. Not CP20X HFA.
Rights
CL-Secure Signal-
ling to the Web
Services Interface
Executed:
TLS certificate Yes: No: Not applicable:
installed on the
phone
Secure HFA getaway Yes: No: Not applicable:
configured
OCSP check config- Yes: No: Not applicable:
ured
If Mutual Authentica- Yes: No: Not applicable:

tion is required,
phone client certifi-
cate installed on the
phone
UC Server Protocol Yes: No: Not applicable:
set to HTTPS
Web Services server Yes: No: Not applicable:

and port addresses
configured
Confirmed default Yes: No: Not applicable:
configuration on
OpenScape Business
which blocks HTTP
connections has not
been overridden
Customer Com-
ments and Reasons.
not executed then
4.8. Secure Access to Network (Use IEEE 802.1x

Access Control)
The customer has the option to enable IEEE 802.1x in the network and at the phone by configuring
the 802.1x and installing the appropriate certificates. This should be done in a secure "staging"
area.
Support of IEEE 802.1x provides means of authenticating and authorizing a device attached to
local area networks. For details and further information please refer to http://wiki.unify.com/
images/a/ae/DLS_-_Certificate_Management_for_802_1x.pdf, http://wiki.unify.com/index.php/
VoIP_Security and htttp://wiki.unify.com/images/2/23/IEEE_802.1X_Configuration_Manage-
ment.pdf
4.8.1. Enable 802.1x
CL-Enable 802.1x
Measures • Configure 802.1x options
• Install certificates onto the phone
• Check that 802.1x certificate policy is trusted.
• Set MSCHAP-ID and password for PEAP mode
References See IEEE 802.1x Configuration Management and DLS Cer-
tificate Management for 802.1x
Executed:
Configure 802.1x options Yes: No:
Load 802.1x phone Client Yes: No:

certificate onto the phone
for EAP-TLS mode
Load RADIUS server CA Yes: No:
certificate onto the phone
Check 802.1x certificate Yes: No:

authentication policy is
trusted
Set MSCHAP-Identity and Yes: No:
Password for PEAP mode

sures are not
executed then please
explain here:
42 Administration
5. Administration
5.1. System Access

Access to the administration of the phone has to be protected from unauthorised access. Access
to the configuration of the phone is available two levels:
• User level access - see chapter 4.2.2 or details how to harden the user access
• Admin level access - see chapter 4.2.1 for details how to harden the admin access
5.1.1. Serial Interface Access

Access at a Linux level is possible using the serial interface with the special serial interface adap-
tor. To prevent unauthorised access this interface should be set to unavailable.
CL-Serial Interface
Access
Measure • Set serial interface to Unavailable
References See Phone Administration Manual chapter on Security
Access Control
Executed:
Set Serial Port access to Yes: No:
unavailable

Reasons:
Administration 43
5.2 Remote Administration

The Remote administration access must be hardened:
• DLS - see chapter 4.2.3
• Web Based Management - see chapter 5.3
5.3. Web Services

Web services are provided on the phone to provide access to User and Admin configuration me-
nus for use by web-based clients.
Access is only available using HTTPS. Attempts to access using the standard HTTP port are au-
tomatically redirected to HTTPS.
On delivery a default Web Server certificate (see note below) is provided on the phone for this port.
This must be replaced with a customer generated certificate.
The WBM access uses the same User and Admin passwords to restrict access to authorised
users. Secure passwords must be set as in checklist chapters 4.2.1 and 4.2.2.
To prevent unauthorised access via WEB browser and to reduce the probability of security vulne-
rabilities via the WEB browser, the WBM access should be disabled if WBM is not used.
CL-Web Access
Measure • Disable WBM access
• Install Customer generated Web Server Certificate (see
note below)
References See Phone Administration Manual chapter on Security
Access Control
Executed:
Disable WBM access if Yes: No:
not needed
Install Web Server Yes: No:

Certificate if Web Access
is used
Reasons:
NOTE: The default Web Server certificate provided on the phone is signed using SHA-1. From
Q1 2017, the three main web browsers (Internet Explorer, Chrome and Firefox) will introduce
functionality to their applications that will start impairing access to certificates that use SHA-1.
Initially, they will ask the user to acknowledge that WBM access may not be secure and it is very
possible that at some time the browsers will raise the bar further and block access completely. This
functionality is not an issue when WBM has been disabled or customer generated certificates
signed using SHA-2 have been downloaded to the phone. For further information, refer to Unify
44 Administration
Security Advisory Report - OBSO-1701 SHA-1 certificates: depreciation in 2017 (http://

www.unify.com/us/Home/Internet/web/Container%20Site/Misc/Footer-content/privacy-policy/
security-advisories.aspx.
5.4. Monitoring via SNMP

The OpenScape Desk Phone CP Phones use SNMP V1:
• to send traps to the SNMP Server for maintenance and QDC data
• for query of the phone MIBs
A community string is available in SNMP V1 which is comparable with a userID or a password that
allows access to read the MIBs on the phone. This must be set to allow access for SNMP query.
Similarly, servers receiving the Traps also make use of a community string. These are configured
separately for traps and diagnostic traps (QDC data) in the phone.
As the community strings are transmitted in clear text they can be eavesdropped easily.
If SNMP is not used then to prevent unauthorised access to information SNMP should be disabled.
CL-SNMP Access
Measure • Disable SNMP if not used
• If SNMP is used then Set the snmp community strings for
query, trap and diagnostic trap (QDC)
References See Phone Administration Manual chapter on IP Network
Parameter -> SNMP
Executed:
Disable SNMP if not used Yes: No:
Set SNMP Community Yes: No:

Strings (Query/Trap/
Diagnostics)
Reasons:
Administration 45
5.5 Diagnostics
Trace data logging can be done either locally on the phone or to a remote server. The remote trace
is done using the standard remote syslog function. This is transmitted in clear text and to prevent
unwanted disclosure of information:
• Disable Remote trace if not needed
• Enable the Remote Trace User Notification function
Remote diagnostic access is available using the HPT tool. Remote service access for the HPT tool
is allowed when local Admin access and the CCE interface are both enabled. To prevent unwanted
access the CCE interface should be disabled. This needs to be done after each diagnostic sessi-
on where HPT is used.
NOTE: Disabling Local Admin Access (see chapter 4.2.1) will also prevent access for the HPT
tool.
NOTE: Disabling CCE Interface (see chapter 4.7.2) will also prevent access for the HPT tool.
CL-Diagnostic Access
Measure • Disable the remote trace facility (only needed for debug/
service fault finding)
• Enable the Remote Trace User Notification function
• Disable CCE interface (see chapter 4.6.2)
References See Phone Administration Manual chapter on Diagnostics ->
Remote Tracing - Syslog, and Diagnostics -> HPT Interface
Executed:
Set remote trace status to Yes: No:
OFF
Set remote trace user Yes: No:

Notification to ON
Disable CCE interface if Yes: No:

not needed for HPT

Reasons:
46 Administration
5.6. SSH Interface

The Secure Shell interface is reserved for technical specialists. It is deactivated by default and
can be enabled by the Admin user via WBM or DLS for each access. It is enabled for a limited
period of time only, and a password is set for the access. A different password should be used for
each access. To prevent all access via secure shell the secure shell allowed can be disabled. This
is done via DLS.
CL-SSH Interface
Access
Measure • Disable SSH Interface Access using DLS
References See Phone Administration Manual chapter on SSH - Secure
Shell Access
Executed:
Set secure shell allowed Yes: No:
to OFF (via DLS only)

Reasons:
Addendum 47
6. Addendum
6.1. Default Accounts

There are two access levels available on the phone. These are fixed as User and Admin and can-
not be changed. Each access level has its own password and password policy.
6.2. Password and PIN Policies

A password policy is a set of rules designed to enhance computer security by encouraging users
to employ strong passwords and use them properly. OpenScape Desk Phone CP technically sup-
port the password policies depicted in chapter 6.2.1. For every password rule, a default value and
a range of values that can be configured for that rule are given. If the default values do not fit with
the customer’s password policy, the values the customer wants to be configured shall be depicted
in chapter 6.2.2.
48 Addendum
6.2.1. Password Policy supported by OpenScape Desk Phone

CP phones
# Password policy of Default value Recommended Setting

OpenScape Desk Phone (range of possible
CP values)
Password PIN * Password PIN*
1 Minimal PW Length 6 (6-24) 6 (6-24) 8 6
2 Minimal number of upper 0 (0-24) - 1 -
case letters
3 Minimal number of lower 0 (0-24) - 1 -
case letters
4 Minimal number of 0 (0-24) (length) 1 -
numerals
5 Minimal number of special 0 (0-24) - 1 -
characters
6 Maximal number of 0 (0-24) 0 (0-24) 3 3
repeated characters
7 Minimum character count 0 (0-24) 0 (0-24) 2 2
for changed characters
8 Password History 0 (0-99) 0 (0-99) 5 5
9 Number of days password 180 (1- 180 (1- 180 180
is kept in history 999) 999)
10 Maximum password age in 0 (0-99) 0 (0-99) 90 90
days
11 Minimum password age in 0 (0-24) 0 (0-24) 1 1
hours
12 Notification before 0 (0-99) 0 (0-99) 4 4
password expiration in
days
13 Password change requires True True Not Not
knowledge of old configurable configurable
password
14 Force change default False False Can be set Can be set
passwords/PINs after the = true when = true when
first use PW is PW is
changed changed
from DLS from DLS
15 Maximum number of 0 0 5 5
erroneous login attempts (0=infinite, (0=infinite,
2-5) 2-5)
16 Account lockout duration 0 (0-99) 0 (0-99)
in minutes
17 Automatic logoff after not 2 (1-5) 2 (1-5) 2 2
used period in minutes
NOTE: *OpenScape Desk Phone CP Phones have a single configuration for both passwords and
PINs. A PIN is a numeric only password and will use the same policy as configured for a password
where possible.
Addendum 49
6.2.2. PW Policy agreed for customers deployment

These are the customer PW/PIN rules for the PW Policy on OpenScape Desk Phone CP . Please
implement them as default values. Filling the below table with customer specific values is only
necessary if
• the customer PW Policy is different from the recommended values depicted in chapter 6.2.1 and
there is no implemented Security Checklist where a PW Policy for the whole Customer scenario
is already stated.
The setting of the password policies on the phone for Generic, User and Admin Policy is detailed
in the OpenScape Desk Phone CP Administration manual chapter Security -> Password Policy.
Admin Password User Password
Minimal Length
Minimal number of upper case letters
Minimal number of lower case letters
Minimal number of numerals
Minimal number of special characters
Maximal number of repeated characters
Change interval
Maximum number of erroneous login attempts
Minimum character count for changed
characters
Password History
Number of days password is kept in history
Maximum password age in days
Minimum password age in hours
Notification before password expiration in
days
Maximum number of erroneous login attempts
Account lockout duration in minutes
Automatic logoff after not used period in
minutes
6.3. Certificate Handling

Certificates are used to provide authentication of connected servers and Digital keys. Customer
generated certificates must be installed on the phone. This chapter gives a list of the certificates
used on the phone.
In addition to installing certificates on the phone, the certificate validation policy must be configu-
red.
There are three levels of checking available:
None: There is no authentication of the server
Trusted: The following is checked
• that it is trusted (this means: the chain of trust for the digital signature provided by the remote
entity ends up in one of the trusted (e.g. Root CA certificates, which are preconfigured for that
interface on the phone)
• that it is not expired (i.e. current date/time is within the certificate's given validity period)
• that it is not revoked (using OCSP)
Full: It is assumed the server is trusted and there is no need to perform any additional checks.
The following checks additional to the "Trusted" policy:
• that it has the correct identity (according to settings in altSubjectName and/or the common name
(CN) in the Subject). This may be a FQDN, IPv4 or IPv6 address
• that it has the correct use of the following critical extension: OCSP signing
50 Addendum
The CLs for those functions which make use of certificates detail the actions needed to setup up
the certificates for that function.
6.3.1. Credentials used for OpenScape Desk Phone CP

Some of the credentials used for OpenScape Desk Phone CP are common to SIP and HFA. The-
se are detailed in chapter 6.3.1.1.
Some of them are only used for SIP. These are detailed in chapter 6.3.1.2.
Some of them are only used for HFA. These are detailed in chapter 6.3.1.3.
6.3.1.1. Credentials used for OpenScape Desk Phone CP SIP and OpenScape
Desk Phone CP HFA
# Interface Credential Customer Expiration Unify Usage

requirement Date for Default
for Customer credentials
OpenScape specific
Desk Phone key
CP Phone material
credentials
1 HTTPS Server CA None Remote Server
File Certificate Authentication for file
Download download
2 HTTPS Phone Client None Mutual Authentication
File Certificate of phone
Download
3 802.1x 802.1x None Authentication of
Phone Phone by remote
Certificate RADIUS Server
4 802.1x RADIUS None Authentication of
Server CA remote RADIUS
Certificate Server
5 WBM WBM Server Unify Authentication of
HTTPS Certificate Default phone by WEB
Certificate browser and
encryption
CCE TLS
Same Certificate also

used for encryption of
CCE interface to HPT
PC applications
6 OCSP OSCR 1 None Authentication of
Signature signature returned
CA from OCSR 1
Certificate
7 OCSP OSCR 2 None Authentication of
Signature signature returned
CA from OCSR 2
Certificate
8 LDAP via Server CA None Authentication of
TLS Certificate remote LDAP Server
Addendum 51
9 Microsoft Server CA None Authentication of

® Certificate remote Microsoft®
Exchange Exchange Server
Server
HTTPS
10 Circuit Server CA None Authentication of
Certificate remote Circuit Server
previously known as
Ansible Server
6.3.1.2. Credentials used for OpenScape Desk Phone CP SIP only

for Customer credentials
OpenScape specific
Desk Phone key
CP Phone material
credentials
1 Send URL Server CA None Authentication of
1 HTTPS Certificate remote server for
Send URL function 1
Send URL function 2
Send URL function 3
4 SIP TLS Server CA None Authentication of
Certificate remote SIP Server
and remote CSTA
Server (see chapter
4.7.9)
5 SIP TLS Phone None Authentication of
Client Phone by remote SIP
Certificate Server and remote
CSTA Server (see
chapter 4.7.9)
6 BroadSoft Server CA None Authentication of
BroadWor Certificate remote BroadSoft
ks DMS BroadWorks DMS
Server
7 BroadSoft Server CA None Authentication of
BroadWor Certificate remote BroadSoft
ks DMS BroadWorks XSI
Server
52 Addendum
6.3.1.3. Credentials used for OpenScape Desk Phone CP HFA only

for OpenScape Customer credentials
Desk Phone specific
CP Phone key
credentials material
1 HFA TLS Server CA None Authentication of
Certificate remote HFA Gateway
and Web Services
Interface to
OpenScape
Business (see
chapter 4.7.12)
2 HFA TLS Phone None Mutual
Client Authentication of
Certificate Phone by remote
HFA Gateway and
Web Services
Interface to
OpenScape
Business (see
chapter 4.7.12)
6.3.2. Setup Certificate Checking Policy
CL – Certificate
Checking
Measure The level of validation that is done on certificates received by the phone
is configurable. The validation levels available are:
• None
• Trusted – only certain aspects of the received certificate are checked
• Full – all aspects of the received certificate are checked
The Default setting is “None” except for the 802.1x certificate which has
the default “Trusted”.
References See Phone Administration Manual chapter on Security -> Certificate
Policy
Rights
Applicable CP20X/400/600 SIP CP20X/400/600 HFA
Executed:
Set authentica- Yes: No: Yes: No:
tion policy for
https secure file
transfer:
Set authentication Yes: No: Not available
policy for secure
SIP signalling:
Addendum 53
CL – Certificate
Checking
Set authentication Not available Yes: No:
policy for secure
HFA gateway:
policy for secure
SendURL:
Set authentication Yes: No: Yes: No:
policy for 802.1x:
Set authentication Yes: No: Not available CP20X HFA

policy for LDAP
CP400/600 HFA only:
via TLS:
Yes: No:
policy for secure
DMS server
policy for secure
XSI server
policy for secure
Exchange server
(CP400/600 only)
policy for secure
Circuit server
(CP400/600 only)
Customer Com-
ments and Rea-
sons. If some
measures are not
executed then
please explain
here:
6.4. Port Table

For latest updates of the OpenScape Desk Phone CP SIP and OpenScape Desk Phone CP HFA
port tables refer to the Interface Management Database (IFMDB) via Unify Partner Portal.
Use the link http://www.unify.com/us/partners/partner-portal.aspx, go to Menu item "support" and
then click IFMDB in the pull down menu.
54 References
7. References
[1] OpenScape Desk Phone CP SIP and OpenScape Desk Phone CP HFA administrator docu-
mentations (e-Doku or Portal / product information)
[2] VoIP security http://wiki.unify.com/index.php/VoIP_Security
http://wiki.unify.com/index.php/VoIP_Security
[3] DLS – Certificate Management for 802.1x / EAP-TLS http://wiki.unify.com/images/a/ae/DLS_-
_Certificate_Management_for_802_1x.pdf
http://wiki.unify.com/images/a/ae/DLS_-_Certificate_Management_for_802_1x.pdf
[4] OpenStage and Desk Phone IP - Provisioning Interface http://wiki.unify.com/images/c/c7/
OpenStage_Provisioning_Interface_Developer%27s_Guide.pdf
http://wiki.unify.com/images/c/c7/OpenStage_Provisioning_Interface_Developer%27s_Guide.pdf
[5] Interface Management Database (IFMDB) available via Unify Partner Portal
http://www.unify.com/us/partners/partner-portal.aspx
[6] Security Policy – Vulnerability Intelligence Process http://networks.unify.com/security/adviso-
ries/Security_Policy_Vulnerability_Intelligence_Process.pdf
[7] Center of Internet Security – Security Benchmarks https://benchmarks.cisecurity.org/en-us/
?route=downloads.multiform
[8] OpenScape Business Interfaces – Protocols – Web Services Interface (HTTP/HTTPS)
http://wiki.unify.com/wiki/OpenScape_Business_Interfaces#Web_Services_Interface_.28HTT-
P_.2F_HTTPS.29

OpenScape Desk Phone CP200 - 400 - 600 V1, Security Checklist, Issue 6

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OpenScape Desk Phone CP200 - 400 - 600 V1, Security Checklist, Issue 6

Hochgeladen von

Copyright:

Verfügbare Formate

OpenScape Desk Phone CP20X/400/600

Our Quality and Environmental Management Systems are

Copyright © Unify Software and Solutions GmbH & Co. KG 08/2017

5.6. SSH Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1.1. History of Change

1.2. General Remarks

Usage of Security Checklists (SCL)

Update and Feedback

1.3. Security Strategy for Unify Products

Penetration Tests (Practical Security Assessment) to discover implementation vulnerabilities and

1.4. Customer Deployment - Overview

Covered Systems (e.g.

2. OpenScape Desk Phone CP Interfaces and

3. Phone Hardening Measures at a Glance

3.1. Phone Hardening Measures for OpenScape Desk

• Phone Administration: local, WBM, DLS, serial port

• Microsoft® Exchange server

3.2. Additional Hardening Measures for OpenScape

• Install certificates and configure secure calls

• Use digest authentication

• BroadSoft BroadWorks (DMS and XSI servers)

3.3. Additional Hardening Measures for OpenScape

4. Phone Hardening Measures

4.1. Install latest (“up-to-date”) OpenScape Desk

CL-SW status: Up-to-date SW

Software Version Installed

4.2. Secure Administration Access to the Phone

4.2.1. Harden Local phone Admin Access

Set Secure Admin Yes: No:

Setup Admin Password Yes: No:

Disable Local Admin Yes: No:

Disable Hooded Claw for Yes: No:

Customer Comments and

4.2.2. Harden Local phone User Access

NOTE: for OpenScape Desk Phone CP20X/400/600 SIP phones:

NOTE: for OpenScape Desk Phone CP20X HFA phones:

NOTE: for OpenScape Desk Phone CP400/600 HFA phones:

Secure User Yes: No: Yes: No:

Set Phone Lock Yes: No: Yes: No:

Lock Down Yes: No: Yes: No:

Disable User Yes: No: Yes: No:

4.2.3. Harden DLS Interface to the Phone

4.2.3.1. Setting communication between phone and DLS to “secure mode”

CL-Secure DLS Access

Setup Secure mode for Yes: No:

Customer Comments and

4.2.4. Harden Software Deployment and File Download to the

Install HTTPS certificates Yes: No:

Configure Secure File Yes: No:

Configure OCSP checking Yes: No:

Customer Comments and

4.3. Configure Password Policy and Passwords

Setup Admin Pass- Yes: No: Partly:

Setup User Password Yes: No: Partly:

Set Secure Admin Yes: No:

Set Secure User Yes: No:

4.4. Authentication of phone at SIP Server

4.4.1. Harden Phone to use Digest Authentication (OpenScape

4.5. Secure Signalling and Voice Access to the Phone

4.5.1. Harden Signalling to Secure Signalling (OpenScape Desk

Set Port for Signalling to Yes: No:

Install TLS certificates on Yes: No:

Configure Secure SIP Yes: No: