NextPlane ConverseCloud Security and Privacy FAQs

To augment the information on our website, we have compiled this list of frequently asked questions on the security aspects of the NextPlane ConverseCloud federation service along with details of internal NextPlane processes with regards to the protection of customer data. If you need further assistance or have a question that is not listed, please contact our security team at privacy@nextplane.net.

NextPlane ConverseCloud acts as a universal federation and interoperability hub between Unified Communication (UC) and Team Collaboration (TC) platforms. As a result, you can easily establish interoperability between your internal UC and TC platforms. You can also federate them externally with your customers, partners, or suppliers, regardless of their underlying platform.

As a universal hub, ConverseCloud performs a transformation of XMPP, SIP, and API-based protocols as well as the conversion between different formats of encapsulated text messages for platforms such as Microsoft Skype for Business (S4B), Cisco IM & Presence, and Slack.

ConverseCloud enables users to exchange messages with rich text and emoji reactions, add external contacts, and see Presence and status. Users can also participate in teams, channels, and spaces, and share files with other UC or Team Collaboration platforms, inside or outside of the enterprise.

For IM, some translation is also necessary for the content of messages to take into account each vendor's support for plain text, rich text, and other embedded content.

For Presence, this translation requires handling competing standards for the format of Presence information (often called a Presence Document). ConverseCloud also performs translation to and from all of the UC vendor's supported Presence Document formats, including standard formats such as PIDF, XPIDF, and XCAP, as well as proprietary formats such as Microsoft Enhanced Presence.

NextPlane views accurate Presence states as the foundation for any real-time collaboration within any messaging platform. You do not message colleagues if their Presence is unknown or unavailable. As a result, NextPlane ConverseCloud also performs semantic translation for Presence states within a Presence Document.

NextPlane ConverseCloud uses equivalence-based mapping to map specific Presence states on different platforms when there is no one-to-one correspondence. For example, Slack has two Presence states (Active and Away), but Microsoft Teams has five Presence States (Available, Busy, DND, Appears as Away, and Be Right Back).

After ConverseCloud terminates and decapsulates the message from each platform, ConverseCloud determines the routing destinations and reassembles each message based on what is expected by the target UC or TC platform of the message. For most federations, ConverseCloud routes the messages based on the domain of the destination address.

NextPlane ConverseCloud supports Domain Sharing (a.k.a Intracompany Federation)—interoperability of different messaging and collaboration platforms that share the same domain name. With Domain Sharing, each platform routes chat and presence messages to other platforms that share the same domain. NextPlane Domain Sharing does not require guest accounts.

To connect different TC platforms, like Microsoft Teams, and UC platforms, such as Cisco Jabber, that share the same domain name, NextPlane uses 'virtual domains.' Virtual domains are not real domains. They are used solely by NextPlane ConverseCloud to allow messaging platforms to differentiate the federated traffic from their local traffic. Consequently, these platforms can route their federated traffic to the NextPlane ConverseCloud Service, and from there, NextPlane ConverseCloud strips the virtual domain name and sends it to the correct destination.

NextPlane ConverseCloud Domain Sharing also supports Intracompany Federation between TC platforms such as Microsoft Teams, Cisco Webex Teams, and Slack. In this case, NextPlane ConverseCloud does NOT require virtual domains to connect the different TC platforms in the
same domain.

ConverseCloud uses TLS (transport layer security) for all SIP and XMPP signaling, as well as for API-based communication between federating our supported UC and TC platforms.

The NextPlane ConverseCloud Federation Service has several major internal components, which NextPlane hosts on AWS:

• The Administration Server
  The Administration Server is a web-based console used to administer ConverseCloud servers and services.
  
  
• The Federation Servers
  The Federation Servers maintain audit logs of the SIP and XMPP sessions that they have processed. These logs are directly sent to our Splunk instance and are never written to a local storage device.
  
  
• The ConverseCloud API Federation Servers
  The ConverseCloud API Federation Servers maintain audit logs of HTTPS sessions which are directly sent to AWS CloudWatch and are never written to a local storage device.
  
  
• Audit Logs
  An audit log entry includes the source and destination SIP URIs and XMPP JIDs, the message type, and other information such as the timestamp and Federation Server that processed the session. Note that outside of users’ URI or JID addresses (such as user@company.com), neither personal information nor message content is logged within NxPFS.
  NextPlane audit logs are used for troubleshooting, service monitoring, and usage reporting. Audit logs are sent directly to Splunk. NextPlane maintains them on a 90-day rolling basis.
  
  
• The Microsoft SQL Server 2016
  The Microsoft SQL Server database contains the configurations and domain information required by the Federation Servers.
  
  
• MySQL Database
  The MySQL Database contains the service data—tenant ID, application ID, user ID, which are used by apps on the Team Collaboration platforms (Microsoft Teams, Webex Teams, Slack).
  
  
• The Redis Cache Servers
  The Redis servers store the temporary session data (e.g., SIP dialog information) in the Redis disk-backed memory cache. SIP session data only stores session parameters such as call ID, and SIP addresses of the users involved. All session entries are removed at the end of the session.

Is there a documented information security policy in place?
Yes, NextPlane has a security policy in place.

What areas does NextPlane information security policy or policies cover?
NextPlane information policy covers the following areas:

• Data privacy
• Organization of information security
• Asset management
• Personnel security
• Physical and environmental security
• Communications and operations management
• Access control
• Information security incident management
• Business continuity management

Is there a compliance procedure in place to ensure that the Information Security policy is read, understood, and implemented by the staff, e.g., test, evaluation?
Yes, we have compliance procedures in place.

Have the Information Security policies been formally reviewed and signed off by management?
Yes, NextPlane management has reviewed and signed off on the information security (infosec) policies.

Is there a Risk Assessment process and Acceptance from Senior Management in place to account for any Exceptions to the Information Security Policies?
Yes, NextPlane management has to sign-off on any exceptions to infosec policies.

What is NextPlane’s physical security?
NextPlane hosts the NextPlane ConverseCloud production environment on the Amazon Web Service (AWS) located in Oregon, USA.

Do you have facility standards?
AWS enforces facility and environmental standards that ensure maximum uptime through redundancy and environmental safeguards designed to prevent outages in the event of mechanical or electrical failures.

What is NextPlane’s production network security?
NextPlane protects its production network by multiple firewalls and a state-of-the-art security information and event management (SIEM) system that supports the network security architecture design. By monitoring and reporting on the system configuration and application activity, the agents enable NextPlane to prevent malicious or anomalous activity on the NextPlane servers.

Is all network traffic entering and exiting the production network routed through perimeter firewalls?
The NextPlane ConverseCloud servers are in a server pool configuration behind both a Cisco ASA firewall and an HAProxy load balancer and AWS load balancer. NextPlane uses the HAProxy load balancer to distribute the incoming SIP or XMPP traffic across the Federation Servers and uses the AWS load balancers to distribute the incoming HTTPS to back-end servers for API federation.

What are network ports allowed on the ConverseCloud firewall?
The NextPlane ConverseCloud firewalls enforce perimeter security by blocking all the incoming connection requests to the Federation Servers except for the message traffic that is explicitly allowed on ports 5060 and 5061 (for SIP), 5269 (for XMPP) and 443 (HTTPS).

Is all network traffic entering and exiting the production network routed through a network intrusion detection system (IDS)?
No, NextPlane only processes XMPP and SIP messages, IDS is not necessary.

How are the NextPlane ConverseCloud servers monitored for unauthorized changes and activities?
All logs-in to the servers are logged and are reviewed on a biweekly basis.

What is NextPlane Application Security?
The core security focus is the application code and customer data that are processed within the system. NextPlane uses TLS encryption for all the data in transit from the application production network.

Does NextPlane encrypt federated traffic?
Yes, NextPlane ConverseCloud uses TLS for all the SIP or XMPP-signaling communication between the federated UC solutions wherever supported. When an XMPP UC solution does not natively support TLS, NextPlane ConverseCloud falls back to TCP-based communications. When the NextPlane ConverseCloud servers initiate a connection, by default, they use TLS version 1.2 (TLSv1.2) for SIP, XMPP, or HTTPS. However, due to a “version intolerance” issue present in certain older TLS server deployments or hardware load balancers and firewall devices, NextPlane ConverseCloud uses TLSv1.0 by default. In these older deployments, the server endpoint does not accept higher TLS version numbers, and it is impossible to establish a connection unless the client only advertises TLSv1.0. In particular, NextPlane ConverseCloud uses TLSv1.0 to support federation services with legacy UC platforms.

For more information, please see:

• https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TLS_-_SSL_3.0_Intolerant_Servers
• http://blog.nexcess.net/2014/04/04/tls-1-2-and-openssl-1-0-1e-frequently-asked-questions/

Are there instances when ConverseCloud does not encrypt the federated traffic?
Yes, for XMPP/TLS federation—the traffic between NextPlane ConverseCloud and Cisco WebEx Messenger—NextPlane and Cisco have jointly developed and mutually agreed on a modified certificate trust protocol that does not require a private key per WebEx Messenger federated domain.

With this modification, ConverseCloud uses a modified certificate trust protocol for all the federated domains while establishing federation with Cisco WebEx Messenger domains. In such cases, the common certificate (i.e., the DN in the certificate) is bound to the FQDN of CC-X’s.
The above protocol is supported when TLS is required for BroadSoft Broad Cloud (XMPP) Service.

Does NextPlane ConverseCloud use Public Certificates for encryption?
Yes, NextPlane ConverseCloud only accepts SIP, XMPP, and HTTPS TLS connections from domains that use public certificates that have been signed by a certificate authority approved by NextPlane, such as Entrust or GoDaddy.

Does NextPlane ConverseCloud store my private keys?
No, ConverseCloud does not require private keys for establishing federations.

How does NextPlane ConverseCloud process SIP and XMPP Messages?
All of the IM and presence messages federated through the NextPlane ConverseCloud Federation Service undergo the following processing steps:

• An XMPP or SIP connector receives a message from an authorized domain, and the connector decrypts the message (if necessary).
• Routing algorithms are applied to determine the destination domain.
• The translation is performed on the message to make it understandable to the destination domain.
• The translated message is encrypted (if necessary, depending on whether the destination domain accepts encrypted messages) and is sent out through the sending connector
  (XMPP or SIP).
• An audit log entry is created. It includes the source and destination addresses, the message type, and other information such as the timestamp and Federation Server that processed the message. NextPlane does not log the message content.

How does NextPlane ConverseCloud process API-based federation?
All of the IM and presence messages federated through the NextPlane ConverseCloud API Federation Servers undergo the following processing steps:

• HTTPS connector receives a message from an authorized domain, and the connector decrypts the message.
• The message is sent to the NextPlane Federation service.
• Routing algorithms on the Federation server are applied to determine the destination domain.
• The translation is performed on the message to make it understandable to the destination domain.
• The translated message is encrypted (if necessary, depending on whether the destination domain accepts encrypted messages) and is sent out through the sending connector (XMPP, SIP or HTTPS)
• An audit log entry is created. It includes the source and destination addresses, the message type, and other information such as the timestamp and Federation Server that processed the message. NextPlane does not log the message content.

Does NextPlane ConverseCloud store my messages?
No, NextPlane ConverseCloud processes and delivers messages in real-time. All the processing takes place while the message is in memory, and at no time is there a persistent data store used to store the message.
Only the first messages sent via the API are stored in the server memory, however, only until the federation request is accepted. After that messages are removed from the RAM.

Does NextPlane ConverseCloud provide end-to-end encryption?
No, NextPlane ConverseCloud provides full encryption with each of the federated sources and destination UC edge servers. However, ConverseCloud Federation Servers need to decrypt and re-encrypt SIP or XMPP messages, for a very short duration (in the order of tens of milliseconds) and only in memory, before sending them to the destination address.
For the NextPlane API, which is used by end-users for communication, all the traffic between the application and NextPlane ConverseCloud servers is encrypted via the HTTPS connection (TLS 1.2).

What type of data is stored by NextPlane ConverseCloud?
NextPlane ConverseCloud servers automatically record a log entry for each UC solution message processed through them. The log entry only has the metadata and NOT the contents of a UC solution message. The metadata consists of the following fields:

• Sender SIP URI or XMPP JID (e.g., john@abc.com)
• Receiver SIP URI or XMPP JID (g., peter@xyz.com)
• Message type (IM, Presence, file share)
• Time and date of the message
• Call-ID (an ID identifying a chat session or a call)
• Error or response code (generated by the UC solution or ConverseCloud if applicable)

For API-based federations, Nextplane ConverseCloud database servers store such information as:

• User’s email or ID
• Microsoft Teams tenant ID
• User’s first and last name

Does NextPlane encrypt the ConverseCloud database?
Yes, NextPlane encrypts its database and all the backups, where users’ emails, first and last names, as well as tenant IDs are stored.

Who has access to the NextPlane ConverseCloud audit logs?
The NextPlane ConverseCloud audit log is internal to NextPlane.

Do you have a retention policy for the NextPlane ConverseCloud audit logs?
Yes, NextPlane deletes ConverseCloud logs on a 120-day rolling basis.

Where do you store the NextPlane ConverseCloud logs?
The NextPlane ConverseCloud logs are never written to the local disk of the servers. They are stored in our Splunk cloud instance for real-time troubleshooting and usage reporting.

Are there access control policies in place?
Yes, NextPlane has an access control policy in place to address:

• Account usage/password policies
• Appropriate access/need to know
• Access logging

Do you have access controls in place on applications, operating systems, databases, and network devices to ensure users have the least privilege?
Yes, NextPlane controls access across all the components of ConverseCloud to ensure the appropriate privilege level.

How is privileged access controlled and managed?
The NextPlane Administration Server (NxPAS) is only accessed using a secure VPN connection with MFA authentication via Duo Security service.

Are activities for account usage attributable to a unique person (i.e., each account should be systematically assigned to one person)?
Yes, each administrator is assigned their own account. NextPlane does not have shared administration accounts.

What is NextPlane’s password policy?
NextPlane’s password policy is the following:

• Length – a minimum of 7 characters
• Complexity – 3 of the following 4:
  • English upper case
  • English lower case
  • Numeric characters (0 through 9)
  • Non-alphabetic printable characters

Are user accounts locked out after at most five unsuccessful attempts?
Yes, after five unsuccessful attempts.

Is there a policy in place that prohibits users from sharing passwords?
Yes, ConverseCloud administrators can NOT share passwords.

Are successful logins logged and reviewed?
Yes, we use the Splunk access control module to collect and review successful and unsuccessful logins.

How is privileged access controlled and managed?
The NextPlane Administration Server (NxPAS) can only be accessed using a secure VPN connection with MFA authentication via Duo Security service.

Do you have documented System hardening standards/procedures in place?
Yes, NextPlane has internal documentation for our server images.

Is there a vulnerability scanning and penetration testing process in place?
Yes, NextPlane uses the Splunk security module to scan for vulnerabilities. Penetration testing is not applicable as ConverseCloud only processes XMPP and SIP traffic and ONLY accepts traffic from the known customer domains.

Is there a process in place (e.g., alert service) to identify newly discovered security threats and vulnerabilities?
Yes, NextPlane uses the Splunk security module to scan for security threats vulnerabilities and notify key security and Ops personnel by email or Pager Duty.

Is there a formal operational change management/change control process in place for making changes to your production environment?
Yes, NextPlane has formal change management in place.

Does NextPlane do system backups?
Yes. NextPlane does not store any customer data. Our database only stores configuration data, which we back up every week.

Are NextPlane system backups encrypted?
As per the above question, NextPlane does not encrypt backups.

Is NextPlane network access limited to only business-required ports and protocols?
NextPlane firewall enforces perimeter security by blocking all the incoming connection requests to the Federation Servers except for the message traffic that is explicitly allowed on ports 5060 and 5061 (for SIP) and 5269 (for XMPP).

Is all network access logged?
NextPlane uses Splunk for monitoring unauthorized changes and security violations.

Are network events reviewed as part of a periodic operation security procedure?
Yes, NextPlane reviews, on no less than a weekly basis, all security and security-related audit logs for anomalies.

Is every connection to the external network terminated at a firewall?
Yes, all connections terminate on the firewall.

Are code changes, updates, patches, etc. tested on development or quality assurance (QA) before implementation?
Yes, NextPlane has separate development and QA instances of ConverseCloud to test before releasing it to production.

How does NextPlane handle software updates?
Software updates, such as OS patches and new features, are tested on the QA environment and scheduled in an appropriate change window for deploying into production.

Is there a documented anti-virus/malware policy or program that has been approved by management, communicated to staff and an owner to review and maintain such policy?
Yes, NextPlane uses Norton 360 Premier and Malware Byte Pro for anti-virus and malware protection.

Is there a remote access policy in place?
Yes, NextPlane has a remote access policy in place.

Do you use two-factor authentication for remote access?
Yes, NextPlane uses Duo security MFA for remote access via a secure VPN.

Do you limit, monitor, log, and revoke access when no longer required?
Yes, NextPlane has a remote access policy in place.

Do you have a business continuity plan (BCP) in place?
Yes, NextPlane has a BCP in place for failover within the same datacenter. NextPlane performs daily backups on our database servers with a recovery plan in place.

How does NextPlane handle incident reporting?
NextPlane has a process for communicating operational and security incidents using the Statuspage.io service (http://NextPlane.statuspage.io/).