Cisco Webex Teams Security Lab Guide v1.1

Cisco dCloud
Cisco Webex Teams Security Lab v1

Last Updated: 25-September-2019
About This Demonstration

Cisco Webex provides customers with a comprehensive set of security and compliance capabilities. This includes state of the art
end-to-end encryption capabilities for data in transport and data at rest, policy components, and compliance functionality. The
architecture relies on micro services for these capabilities.
Cisco Webex integration with Cloud Access Security Broker (CASB) / Data Leakage Protection (DLP)
Cloud access security broker (CASB) is an on-premises or a cloud-based software that sits between cloud service users and cloud
applications. It monitors all activity and enforces security policies. A CASB can offer a variety of services, including, but not limited
to monitoring user activity, warning administrators about potentially hazardous actions, enforcing security policy compliance, and
automatically preventing malware.
Cisco Cloudlock is the cloud-native CASB and Cloud Cybersecurity Platform that helps accelerate use of the cloud, including the
apps you buy and build. Cisco Cloudlock secures your cloud users, data, and apps across Software-as-a-Service (SAAS), Platform-
as-a-Service (PAAS), Infrastructure-as-a-Service (IAAS), and orchestrates security across your existing security investments.
Data loss prevention software detects potential data breaches/data ex-filtration transmissions and prevents them by monitoring,
detecting and blocking sensitive data while in-use (endpoint actions), in-motion (network traffic), and at-rest (data storage).
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Lab Guide v1.1 Page 1 of 89
Cisco dCloud
eDiscovery
eDiscovery search and extraction tool—while standard Cisco Webex Teams customers have access to only 90 days of content,
Pro Pack customers can access unlimited data within Webex Teams spaces. Use email addresses, space IDs, keywords, and
specific time limits to narrow the search. For more information, see Ensure Regulatory Compliance of Cisco Webex Teams
Content.
End-to-End Encryption
End-to-End encryption is based on the model of a centralized Key Management Server (KMS). Components of the Cisco Webex
solution (i.e. clients) request key material through a secure channel from a centralized KMS.
The figure bellow shows the separation of key management infrastructure from the component concerned with data storage. The
client participating in a Webex communication retrieves keys from the KMS, encrypts data (messages or files), and sends the
encrypted information to be stored in the content server. Similarly, for data retrieval a client needs authorization to retrieve the
required keys from the KMS. Upon receiving keys from the KMS, the client can request the encrypted data from the content store
and decrypt it.
Figure 1. Realms of Separation (without Hybrid Data Security)
Cisco dCloud
The architecture of Cisco Webex allows customers to either use the Cisco provided KMS in the cloud (default) or to deploy their own
instance of the KMS in a customer owned datacenter (Cisco Hybrid Data Security – HDS, enhanced feature available as part of the
Cisco Webex Pro Pack). By deploying a separate instance of KMS in the customer environment, the customer’s encryption keys for
their Webex organization are now located and owned by the customer. This provides an additional level of security and control to
the customer.
Figure 2. Hybrid Data Security
Figure 3. KMS Federation Example
While increasing security with Cisco Hybrid Data Security, seamless business to business communication in Cisco Webex is
maintained through the concept of KMS Federation. Example shows two enterprise organizations with locally deployed KMS
instances being securely federated.
Cisco dCloud
This guide for the Collaboration Webex Security Lab includes:
• About This Demonstration
• Requirements
• About This Solution
• Topology
• Session Users
• Get Started
• Scenario 1: Data Leakage Protection (DLP) Cisco Cloudlock Integration with Cisco Webex Teams
• Scenario 2: Cisco Webex Teams eDiscovery
• Scenario 3: Install Cisco Webex HDS Configuration Utility & Enable HDS
• Scenario 4: Deploy Cisco Webex HDS
• Scenario 5: Cisco Webex HDS at Work
• Scenario 6: Enhanced Logging Experience (Optional)
• Appendix
Requirements
Table 1 outlines the requirements for this preconfigured demonstration.
Table 1. Requirements
Required Optional
● Laptop with Cisco AnyConnect® ● Cisco AnyConnect
About This Solution

Cisco Webex HDS consists of a set of virtual machines provided as a VMware OVA template. In addition, there are customer
provided components:
• Database – PostgreSQL
• Logging Infrastructure – Syslog compliant logging facility
• X.509 Certificate – for mutual secure communication
This lab will explain in detail how to deploy and configure all components required for Cisco HDS.
Also included in the lab are steps to configure a Cloudlock integration.
Cisco dCloud
Topology
This content includes preconfigured users and components to illustrate the scripted scenarios and features of the solution. Most
components are fully configurable with predefined administrative user accounts. You can see the IP address and user account
credentials to use to access a component by clicking the component icon in the Topology menu of your active session and in the
scenario steps that require their use.
Figure 4. dCloud Topology
Table 2. System Details
Name Description Host Name (FQDN) IP Address Username Password
Postgre1 PostgreSQL postgre1.dcloud.cisco.com 198.18.135.58 root C1sco12345
Postgre2 PostgreSQL postgre2.dcloud.cisco.com 198.18.135.59 root C1sco12345
Syslog Syslog Server syslog.dcloud.cisco.com 198.18.135.60 root C1sco12345
ELK Elasticsearch, Logstash, and Kibana elk.dcloud.cisco.com 198.18.135.61 root C1sco12345
ESXi VMware ESXi esxi.dcloud.cisco.com 198.18.133.31 labroot C1sco12345
Workstation 1 Windows 10 wkst1.dcloud.cisco.com 198.18.1.36 dcloud\cholland C1sco12345
Workstation 2 Windows 10 wkst2.dcloud.cisco.com 198.18.1.37 dcloud\aperez C1sco12345
Workstation 3 Windows 10 Wkst3.dcloud.cisco.com 198.18.1.38 dcloud\kmelby C1sco12345
Cisco dCloud
Session Users
A Cisco Webex organization is created with a DNS domain at the start of the exercise. Please refer to the Cisco dCloud portal for
details. To login to Cisco Webex use the following email addresses and passwords.
Figure 5. DNS Domain Information
Table 3 contains details on preconfigured users available for your session.
Table 3. User Details
User Name User ID Password Email Address
Anita Perez aperez C1sco12345 aperez@ssXXX.dc-YY.com
Charles Holland cholland C1sco12345 cholland@ssXXX.dc-YY.com
Kelly Melby Kmelby C1sco12345 kmelby@ssXXX.dc-YY.com
Cisco dCloud
Get Started
BEFORE PRESENTING
Cisco dCloud strongly recommends that you perform the tasks in this document with an active session before presenting in front
of a live audience. This will allow you to become familiar with the structure of the document and content.
It may be necessary to schedule a new session after following this guide in order to reset the environment to its original
configuration.
PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.
Follow the steps to schedule a session of the content and configure your presentation environment.
Initiate your dCloud session. [Show Me How]
NOTE: It may take up to 30 minutes for your session to become active.
For best performance, connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on
your laptop [Show Me How]
• Workstation 1: 198.18.1.36, Username: dcloud\cholland, Password: C1sco12345
NOTE: You can also connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How]. The dCloud Remote
Desktop client works best for accessing an active session with minimal interaction. However, many users experience connection and
performance issues with this method.
Cisco Hybrid Data Security requirements pre-configured for you

Cisco Hybrid Data Security requires an external, customer provided, SQL database. Currently PostgreSQL version 9.x is the only
supported database product. To streamline the flow of the exercise your “database administrator” has installed and configured the
database for you. A complete step-by-step instruction to install and configure the database can be found in the appendix of this
document.
NOTE: In case you are running through this exercise at your own time, there are two PostgreSQL servers provided as part of the
topology. While postgre2.dcloud.cisco.com has been completely preconfigured for you, postgre1.dcloud.cisco.com is a blank Linux
server that allows you to go through all install and configuration steps yourself.
The Cisco HDS components do provide extensive logging information that enables customers to monitor and maintain the different
services and their communication with the Cisco Control Hub. It is required to provide a Syslog destination as part of the Cisco HDS
configuration. A very basic solution can be a Syslog daemon running on a Linux or similar server. While this will allow the HDS
components to send messages which are stored by syslog in a flat file it doesn’t provide any search or alerting capabilities for specific
events or messages. For a production deployment it is recommended to evaluate a more feature rich redundant logging infrastructure
with alerting and dashboard capabilities. In the optional section of this lab guide an example deployment is provided based on Elastic
Search. Basic syslog server is configured for you on the syslog.dcloud.cisco.com Linux machine. Please refer to the appendix of this
document for the steps required to configure a basic syslog server on Linux.
Cisco dCloud
A Cisco HDS clusters requires a single x.509 digital certificate for authentication against the Cisco Webex Control Hub Service. The
certificate needs to be trusted by the Certificate list and needs to have a friendly name of “kms-private-key”. No additional subject
alternate names are required. For the purpose on of this exercise free 90-day certificates are utilized. The process to issue Let’s
Encrypt certificates includes creating a certificate signing request (CSR) and use Let’s Encrypt tools to send the CSR to the Let’s
Encrypt service and get the certificate issued are documented in the appendix of this document.
NOTE: Because of the 90 days limited lifetime of the let’s encrypt certificate it is NOT recommended to use this for a production
deployment of Cisco HDS.
Cisco dCloud
Scenario 1. Data Loss Prevention (DLP) Cisco Cloudlock integration with Cisco
Webex Teams
NOTE: The Cloudlock and eDisovery scenarios of the lab guide are completely independent of the Hybrid Data Security scenarios.
If you would like to complete the HDS scenarios only, you can skip directly to the scenario and start the lab.
Cisco Cloudlock Cleanup
Cisco Cloudlock currently does not provide an API or any easy process to clean up an existing configuration – a functionality not
required for regular operations. For this exercise, a manual cleanup is required.
Open a web browser using incognito/private mode and navigate to the Cloudlock instance
(https://demo.cloudlockng.com/gate/login), from the dropdown list select Webex Teams and click GO. (For most of the
Cloudlock lab you can use your own web browser, however, you can also connect to workstation 1 (198.18.1.36) with
username / password dcloud\cholland / C1sco12345)
NOTE: To prevent issues due to browser caching with logins, it’s always best to use an incognito/private browser.
Login with cholland@ssXXX.dc-YY.com and password dCloud123!
Click Accept on the next page.
Navigate to Settings and on the Platform tab, verify if there is an existing integration.
If the Status reads Not Authorized or Needs authorization, you can skip to Step 10. If it reads Authorized then continue on
to the next step.
Click Edit.
Figure 1. Edit authorization
Click Revoke Authorization at the bottom right of the pop up.
Cisco dCloud
On the Configure Platform dialog, check Delete old incidents and click Revoke Authorization
Figure 2. Revoke Authorization
In the Revoke confirmation dialog select OK. After clicking OK the Status changes to Needs authorization.
Next, navigate to Policies.
For every policy listed (except the default Blacklisted IPs policy), use the dropdown list in the Status column and choose Delete
Policy and click Delete Policy.
For the default Blacklisted IPs policy, verify that the Status is listed as Inactive. If it is not, change it to Inactive now. When
finished your policy list show look like the Figure 3.
Figure 3. Policy list
You have now completed the Cloudlock cleanup process.
Cisco dCloud
Enable Compliance Officer Role in Cisco Webex Control Hub
Full administrators can assign the compliance officer role to any person within their organization. Full administrators can't assign the
compliance officer role to themselves, another full administrator must assign the role to them.
Using the same browser, open a new tab and navigate to the Webex Control hub (http://admin.webex.com). Enter the email
cholland@ssXXX.dc-YY.com and click Sign In. If you are not using the same browser for Cloudlock then enter dCloud123!
as the password.
Click Accept (if needed).
To integrate Cisco Cloudlock with Webex Teams a user with compliance officer privileges is required. In this exercise you will promote
Anita Perez to compliance officer for the organization.
By selecting this role, we are giving this user permissions to do DLP, eDiscovery, and archival function. We will use the event API
provided by Cisco Webex Teams to give these permissions.
In the next step of this exercise Cloudlock is used to request these permissions.
NOTE: For this lab exercise, please select the Full Administrator privileges for Anita. This role is currently required for the
Cloudlock integration to work.
Navigate to Users and click Anita Perez from the list.
From the fly-out window, select Administrator Roles.
Figure 1. Administrator Roles
Cisco dCloud
Select Full administrator privileges and click Save.
Figure 2. Anita Perez Full Administrator Privileges
After you see the message User Successfully Updated, click User.
Figure 3. Exit Anita Perez Administrator Roles
Cisco dCloud
Select Service Access.
Figure 4. Anita Perez Service Access
Cisco dCloud
Select Compliance Officer and click Save.
Figure 5. Anita Perez Compliance Officer Service Access
Configure Cloudlock integration with Cisco Webex Teams
Now you will authorize Cloudlock to Webex Teams. The authorization has to be completed by a compliance officer to obtain the
correct permissions to delete messages within Webex Teams. Because of this you will have to log out of Cloudlock with Charles
(who is not a compliance officer), close the browser (to clear the cache), open the browser again (using incognito/private mode),
and log back into Cloudlock using Anita’s account. Anita’s account has already been added to Cloudlock as an admin so she can
browse to the platforms page.
Log out of Cloudlock as Charles AND close the browser.
Reopen the browser in incognito/private mode and log into Cloudlock (https://demo.cloudlockng.com/) using Webex Teams as
Anita aperez@ssXXX.dc-YY.com / dCloud123!
Click Accept.
Click Settings.
You will now link Cloudlock to your Webex organization.
Next to Webex Teams and under the Actions column click Authorize.
Cisco dCloud
Figure 1. Linking Webex Teams
Click Authorize again.
On the next page a prompt for authorization appears to confirm Cloudlock to have access to specific functions in Cisco
Webex, click Accept.
The Status changes to Authorized. Click Edit.
The configuration dialog allows you to apply policies to different scopes, leave the scope Monitor and files of all users. Other
options will be explored in a later step of the exercise. Click Close.
NOTE: The Charles and Anita user accounts have been pre-configured with limited roles in the Cloudlock instance for this lab. In
the figure bellow you can see the Superadmin view. As you will notice, Manage Users and Manage Roles are not available for
Charles or Anita. This restriction was applied to keep the integrity of the base lab. These roles will not be needed for this lab.
Cisco dCloud
Figure 2. Manage Users
Cisco dCloud
Create a Cloudlock Policy for Cisco Webex Teams
Configure a predefine policy
Cloudlock provides a significant number of predefined policies, such as: Social Security Numbers, Country specific ID numbers,
SWIFT number, etc.
To create a policy to monitor and issue actions related to elements in Cisco Webex Teams, navigate to Policies, select Add a
Policy, and choose Add Predefined Policy.
Figure 1. Create Policy
Choose Credit Card Number from the Predefined Policies option (use the search function to find it), select Critical as the
policy Security Level and click Configure Policy.
Figure 2. Configure Policy
Cisco dCloud
NOTE: By default, Cloudlock is configured to catch the most exact matches, which will result in fewer incidents. In this
configuration Cloudlock may not catch all instances that your company requires. In this case, you will change the search tolerance
level to lenient which will result in more matches/incidents. The lenient tolerance level works for this lab, but you will need to
determine which tolerance level works best for your company.
Under the Content tab click Tolerance.
Select the radio button for Lenient.
Figure 3. Tolerance
Feel free to review the Content, Context, Summary tabs by clicking on each tab. As you saw earlier, the Content and
Context tabs have individual configurations pages such as Threshold, Tolerance, Exposure, etc. When you are finished
looking, click Save All Changes at the bottom right of the screen.
Next, you will create response actions to the policy defined in the previous step.
On the Policies page, click Create from the Response Actions column for the credit card policy you just created.
Figure 4. Create Response Actions
There are two types of specific response actions possible: Global and Platform.
Recommended action(s) are to notify the user and/or compliance officer either via the Webex Teams platform or by email.
Cisco dCloud
Most times, for Webex Teams, a recommended action would be to delete the message or file that violates a policy as well as notify
the user and compliance officer(s).
Continuing in this exercise you will perform the following actions:
• Delete any message or file that contains a credit card number.
• Notify the compliance officer (Anita Perez) that the user violated the credit card policy.
• Notify the user that a credit card number most not be shared via Webex Teams.
Drag all the Platform Specific actions to the dotted box to the right.
For the action of Notify the Admin via Message you need to specify Anita’s Webex Teams email address
(aperez@ssXXX.dc-YY.com) as the owner.
NOTE: In the search box there may be many of the same email addresses for the users. This is due to the emails being used over
and over again. Just pick any of the emails for aperez.
For the message to be sent to the admins enter: {{user}} has violated the Webex Teams security policy {{policy}}.
For the message sent to the user enter: You have violated the company’s Webex Teams security policy {{policy}}. The
offending message has been deleted. The incident has been logged and reported to the compliance officer.
After you are finished configuring the response actions, click the last Save button. (You might need to scroll down the page to
see it.)
NOTE: Each section has its own Save button and those can be clicked as well.
Cisco dCloud
Figure 5. Response Actions Settings
Navigate back to the main policies page by clicking the Policies link at the top or the main tab on the left. Verify the response
actions have been correctly created.
Figure 6. Verify Response Actions Settings
Cisco dCloud
Configure a customized policy (Build your own)
In this exercise you will create a new custom policy, based on a regular expression. This can be utilized for non-normalized
searches.
On the Policies page, click Add a Policy and choose Build your own.
Choose the option Custom Regex for the Policy Type, Critical for the Severity Level and enter a name, such as
Confidential content, for the Policy Name. Then click Configure Policy.
Figure 1. Create New Policy
Next, you will need to create a regex that will match the word confidential with a lowercase or uppercase C, to support both
cases, use [cC]onfidential in the Flag content that matches this Regular Expression box. Keep the rest of the
configuration options at default. Similar to the Credit Card policy, this custom policy is applied to all Cisco Webex users and
spaces, for now.
Cisco dCloud
Click Save All Changes.
Figure 2. Configure Confidential Policy
Create the same Response Actions as you did with the Credit Card Policy.
Figure 3. Create Response Actions
Drag all the Platform Specific actions to the dotted box to the right.
For the action of Notify the Admin via Message you need to specify Anita’s Webex Teams email address
(aperez@ssXXX.dc-YY.com) as the owner.
For the message to be sent to the admins enter: {{user}} has violated the Webex Teams security policy {{policy}}.
For the message sent to the user enter: You have violated the company’s Webex Teams security policy {{policy}}. The
offending message has been deleted. The incident has been logged and reported to the compliance officer.
Cisco dCloud
After you are finished configuring the response actions, click the last Save button.
You should now have two new policies as shown in Figure 4.
Figure 4. Policies
Test the Policy Configurations.
To test the policies you created you will need to create some messages in Cisco Webex Teams.
If not already, connect to Workstation 1 (198.18.1.36) with username / password dcloud\cholland / C1sco12345, start the
Cisco Webex Teams client and login with cholland@ssXXX.dc-YY.com / dCloud123!.
Cisco dCloud
On workstation 1 open the Webex Teams clients and create a 1:1 space ( > Contact a Person) with Kellie Melby. Next,
send a message with the word confidential in the text.
Figure 1. Confidential Message to Kellie
Create a Space with Kellie and Monica Cheng called Stock Price, send a message that states: with this confidential
information you will know when to buy or sell.
Type in one of the spaces or a new one a credit card number like the following message: This is my Credit Card number
5307700612341234.
Send a few more messages in the 1-to-1 conversation and in the Stock Price space. Create some more spaces and send
more messages if you would like.
Observe the Cisco Webex Teams client to see Cloudlock DLP policies actions
After a few minutes you will start seeing action being taken on all the messages that match the policies you created earlier.
NOTE: If you enabled HDS earlier the lab it can take Cloudlock takes at least 5 minutes to start working. Once it does start working
the messages should be removed much faster (less than a minute).
1. Go to one of the spaces you sent confidential or a credit card number. Notice that the message you had sent was deleted by
Anita Perez who is the compliance officer.
2. Notice there is now a new space created between Charles and the Security Center bot.
3. Select that space and you will see for every violation a separate message will appear. This is the message you configured to
send to the user when a policy occurred. You will have a separate message for every violation.
4. Connect to Workstation 2 (198.18.1.37) and login with username / password dcloud\aperez / C1sco12345.
5. Open the Webex Teams client and login with aperez@ssXXX.dc-YY.com / dCloud123!
6. You see that as the compliance officer, Anita was notified by the Security Center bot that Charles Holland violated security
policies.
Next, you will test the Confidential policy with a file. Cloudlock can inspect content and/or filenames of different files. By default, it
inspects both content and/or filenames based on the two policies that you created.
Cisco dCloud
7. On the Workstation 1 desktop there is a file called presentation.pptx and it contain a slide that have the confidential word.
Upload it to your Stock Price space.
Figure 2. Uploaded PPT
Once the file has been uploaded, after a few minutes it is removed by the compliance officer (Anita Perez).
Figure 3. PPT Deleted
The file was removed because the policy applied to anyone that uploads a file labeled confidential. In the next step, you will
change the confidential policy only to apply to spaces with external participants.
Cisco dCloud
8. Return to the web browser and login to Cloudlock (if not already) as Charles or Anita and edit the policy for the word
Confidential. In the Detection Criteria Column, click Edit.
Figure 4. Edit Policy
9. Navigate to Context > Exposure and click Webex Teams to expand it.
Cloudlock provides multiple options to select for which objects in Webex Teams a policy applies or which objects are specifically
excluded from a policy.
10. In this example select Shared with any external user and then click Save All Changes.
11. On Workstation 1 create a new space. Invite Kellie and obiwan@identitylab12.ciscolabs.com. This space allows business
to business collaboration with external participants.
Cisco dCloud
Users are notified if a space contains external participants by the yellow icon [ ] in the bottom right corner shown in the above
figure.
12. Since the policy has changed and now only applies to spaces with external participants, send a message from Charles to Kellie
in their 1:1 space with the word confidential in the message. The message will no longer be deleted or raise a policy violation.
13. Send a similar message into the space with external participants.
Because it is an external user the policy is applied to this space. The content is deleted, and as before, the user (Charles) and
the compliance office (Anita) get a notification.
Incident Reports in Cisco Cloudlock
Go back to Cloudlock admin interface and check the reports of the incidents that occurred during our tests.
1. Click on Dashboard.
Since there is only a single integration in Cloudlock, only the Cisco Webex Teams application is displayed.
2. Click Webex Teams within the Platform Statistics box to view incidents within Webex Teams.
3. Click cholland@ssXXX.dc-YY.com in the Users with most incidents box to view incidents for a user.
4. Click an Incident ID.
Cisco dCloud
5. You can see all the information that was logged such as which Webex Teams space was affected, who sent it, what was
matched, etc. Figure 27 shows confidential material policy violation and details about that event are displayed. This refers to the
upload of the PowerPoint file and shows that the word confidential was found on slide 2 which triggered the incident. Click the
tabs at the top (Access Control, Incident History, Incident Notes) of the incident to view more information.
Figure 1. Incident
Cisco dCloud
6. Go back to the dashboard and click on Webex Teams. You see all the incidents for the Webex application.
Cisco dCloud
Scenario 2. Cisco Webex Teams eDiscovery
NOTE: This section assumes you completed the previous Cloudlock section that setup the Cloudlock integration and also
configured Anita as a compliance officer. In addition, the last section also setup test messages that were sent in order to violate
policy configuration.
If, a company requires details for legal proceedings, the compliance officer can access the Cisco Webex Teams eDiscovery Search
and Extraction tool from Cisco Webex Control Hub. These tools can generate reports that contain all of the conversations held
in Cisco Webex spaces and any files shared within those spaces.
Administrators can limit the number of messages and files that are kept by configuring a data retention policy. When the data retention
threshold period is met, aging content is purged.
A compliance officer can search Cisco Webex Teams for space, IDs, keywords, and any email address of a user in an organization.
Reports are generated from the e-Discovery console and can be downloaded in JSON format files. JSON files can be viewed in a
human readable format in the Firebox browser or other tools.
Click here for a reference script to convert the json file to concordance format (common format in legal discovery).
Using the eDiscovery Console
1. In the browser, Anita is logged into Cloudlock as an active user. Open a new tab and navigate to the Webex Control Hub
(https://admin.webex.com). If you already have a browser open before, and Anita isn’t the active user, please close the
browser and relaunch to clear the cache.
2. Login in with the compliance officer, Anita Perez aperez@ssXXX.dc-YY.com / dCloud123!.
3. Click Accept.
4. From the Control Hub page navigate to Troubleshooting > Status and click View eDiscovery. The eDiscovery option is only
available if the user has the compliance officer role assigned to them.
5. Browser opens a new tab/window to the eDiscovery console.
The eDiscovery Console provides these options to do a search:
• Define a specific data range for your search
• Search for a specific user or search in a specific Space ID
• Search for messages that contains a specific string
6. For this exercise search for content created by cholland@ssXXX.dc-YY.com. Leave the time range as it is and enter the
word confidential. Click Search.
NOTE: Messages were sent with the word confidential in the previous section.
NOTE: Search keywords are case sensitive.
Cisco dCloud
Figure 2. eDiscovery Search
You will see a message stating that Cisco Webex Teams is conducting a search based on your criteria.
After few minutes, a report is provided on those search parameters with a summary of the number of spaces, messages, and files
that match. An estimated size of the total report is specified.
7. Give the report a meaningful name and description and then click Generate Report.
The console displays a prompt that the report is being generated, the browser will ask for permission to send notification. Please
acknowledge, you will see a popup notification once the report has been created.
NOTE: The report generation can take a few minutes.
Cisco dCloud
Figure 3. eDiscovery Search
8. If the page does not refresh after seeing the completion message, then click the Search tab and click back to Reports.
9. Download [ ] the zip file with all the information. The report, in zip file format, is available on the desktop.
10. Right-click on the file and use 7-zip to extract it to a new directory.
NOTE: If not on Workstation 2, use a similar extraction tool on your computer.
Figure 4. Extract Report
Cisco dCloud
11. Open the folder it will show a directory per space where the search word occurred.
NOTE: Inside each directory is a JSON file and a folder. The later contains all the files that exist in each space.
Inspecting the JSON Report created by Cisco Webex Teams eDiscovery
Each JSON file describes all the messages and all the participants of each room where the search word appears.
The JSON file can be opened by double clicking with notepad++ (already install in the desktops of the workstation). Notepad++
also has a plugin for JSON. Alternatively, there are plenty of online translators, for example, https://jsoneditoronline.org/. Copy-
paste from Notepad++ to the right side of the web page, examine the translated readable output.
Notice that there are nine objects (more or less, depending on the number of messages that matched the search criteria in each
space).
Cisco dCloud
Each message fully describes an object in each space.
Cisco dCloud
In the Array, number 0 is always the last message in that space. The content of the message is in the actor array in the object
array under the displayName field.
More information about the format and different fields in the JSON file can be found at:
https://collaborationhelp.cisco.com/article/en-us/nr70c1m
Spend some time exploring the JSON Object.
NOTE: Additional 3rd party eDiscovery platforms, like Actiance, allow customers to conduct advance searches and enhanced
visualization as well as reports of the incidents.
This concludes this scenario.
Cisco dCloud
Scenario 3. Install Cisco HDS Configuration Utility & Enable HDS
Install Docker components
For this deployment, we will use the syslog server to deploy Docker. This deployment will allow us to create the configuration ISO
for the HDS environment.
NOTE: The Docker image for creation and maintenance of the Cisco HDS ISO configuration image is intended to be installed on an
administration workstation. Because of some implications of running all components of this lab virtual, for this exercise the Docker
environment is run on a Linux host. While this works, there are some security and usage implications not recommended for production
deployment.
NOTE: All YUM and Docker commands require to be run as root. If not signed in as root all commands need to be prefixed with
sudo to switch to root privileges.
Deploy Cisco HDS Configuration Utility
Configuration for the Cisco HDS nodes is deployed through a virtual ISO file mounted on each HDS node in the VMware ESXi
environment. Cisco provides a configuration utility to create and update the ISO configuration image as a Docker container. The next
steps show how to pull and deploy the Docker image to create the Cisco HDS ISO configuration.
The required parameters specified can be found in the Cisco HDS deployment guide:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/datasecurity/cmgt_b_hybrid-data-
security/cmgt_b_hybrid-data-security_chapter_01.html.
Connect to Workstation 1 (198.18.1.36) if not already using username / password: dcloud\cholland / C1sco12345. Once
connected, on the desktop, launch a new instance of PuTTY.
Connect to syslog.dcloud.cisco.com (also a saved session) and login with Username: root and Password: C1sco12345.
Login to the Docker hub to access the Cisco HDS configuration Docker image using the following command:
docker login -u sparkhdsreadonly -p AtAideExertAddisDatumFlame
Use the following command to pull the Cisco HDS configuration Docker image:
docker pull ciscosparkhds/hds-setup:stable
Note: This might take a moment to download. Wait for the Pull complete message for each instance.
Run the Cisco HDS configuration Docker container using the following command:
docker run -p 8080:8080 --rm -it --name ciscohds ciscosparkhds/hds-setup:stable
Figure 1. Cisco HDS Configuration Docker Container
Cisco dCloud
Enable Cisco Webex HDS from the Webex Control Hub
On Workstation 1 open Firefox and login into the Cisco Webex Control Hub management interface:
http://admin.webex.com with Userid: cholland@ssXXX.dc-YY.comand Password: dCloud123!.
Click Accept if prompted at the first logon to confirm the terms and conditions of the service.
In the Cisco Webex Control Hub menu, navigate to Services.
On the Hybrid Data Security card click Set Up.
NOTE; The setup process might take a moment before the next screen opens.
Before the Hybrid Data Security nodes can be registered in the administration portal the software has to be downloaded and
deployed. Select the radio button next to No, I need to install and configure the software.
Click Next.
Figure 2. Register Hybrid Data Security Node
Click OK to save the VMware ESXi OVA template to the local disk. It will save to the desktop by default.
Click Ok on the Register Hybrid Data Security Node window in the Webex Control Hub.
Configure Cisco Webex HDS
Using Firefox, open a new browser tab and navigate to the syslog host where the HDS config Docker is already installed:
http://198.18.135.60:8080.
Click Log in [ ]. If you are using the same browser as you logged into with Control Hub you won’t need to login again,
however, if you aren’t, then login with the credentials Userid: cholland@ssXXX.dc-YY.com and Password: dCloud123!.
After successfully logging in, the browser will show an error Unable to connect. This error is caused by the fact that the Docker
image is running on a Linux host and not on a local workstation. Please change the URL from 127.0.0.1 to 198.18.135.60 and
press Return.
Cisco dCloud
Figure 3. Change URL
Click Get Started. The Hybrid Data Security screen opens.
Figure 4. Get Started
Cisco dCloud
First, the configuration tool asks if a new configuration is to be created or an existing configuration ISO file should be updated.
Select No since this is a new install and there is no existing ISO file. On the main screen of the Cisco Hybrid Data Security
configuration tool the required steps are displayed to create the configuration ISO file.
Click Continue.
Figure 5. ISO Import
IMPORTANT: It is extremely important that when an ISO file already exists, that an update of the configuration parameters is
specified. Not doing so can destroy access to existing data encrypted with on premise KMS keys!
Browse to the Desktop where the certificate was copied for you.
Select the hds.pfx file.
Enter the Keystore Password: Cisco,123.
Figure 6. X.509 Certificate Location
Click Continue.
If you receive a Warning, check the box for I understand and wish to continue, then click Continue.
Next, configure the database parameters used by the Cisco Webex HDS nodes to connect to the PostgreSQL database.
The parameters are:
a. Host and Port: postgre2.dcloud.cisco.com:5432
b. Database Name: hdsdb
c. Username: hdsuser
d. Password: Cisco,123
Cisco dCloud
IMPORTANT: If you choose to install and configure the database server yourself please make sure that you enter
postgre1.dcloud.cisco.com:5432 to point HDS to the correct database host.
Figure 7. Database Credentials
Click Test Database Credentials and if successful, click Continue.
Specify the Syslog destination used by Cisco HDS nodes for logging messages. Syslog URL: udp://198.18.135.60:514.
Figure 8. Syslog URL
Click Continue.
Configure the Key Access Level. This configuration will define to what extent a Cisco HDS Key Management Server will share
keys with entities outside your organization. Currently, there is only the option available to share keys with other entities.
NOTE: Cisco’s policy is not to allow customers to share any key material beyond their own organization. This will imply that Webex
Teams spaces with users outside a user’s own organization (“KMS federation”) are not allowed.
Select the Service Account and Select Cloud Access radio button.
Click Continue.
Cisco dCloud
NOTE: Components deployed on premise as part of Cisco Hybrid Data Security require multiple service accounts and password
be created. It is the customer administrator’s responsibility to change these passwords periodically.
Click Continue.
Figure 9. Change Hybrid Data Security Service Account Passwords
This concludes the configuration of the ISO file for Cisco HDS nodes. After 10-15 seconds click the Download ISO link and
save the file, config-drive.iso, to the desktop which is the default location.
Figure 10. Download ISO
Cisco dCloud
Scenario 4. Deploy Cisco Webex HDS
Deploy Cisco HDS VMware OVA Template
The dCloud lab infrastructure for this lab provides a standalone VMware ESXi host used to deploy the Cisco HDS OVA template. To
activate Cisco HDS a minimum of 2 nodes is required. For production deployments, a minimum of 3 nodes is recommended.
From Workstation1 launch the VMware vSphere client via the icon on the Desktop or taskbar [ ].
Logon to the ESXi host with the following parameters:
a. IP address / Name: 198.18.133.31
b. User name: labroot
c. Password: C1sco12345
Click Login and Ignore the Security Warning.
From the File menu select Deploy OVF Template.
Figure 1. Deploy OVF Template
On the Source screen click Browse….
Navigate to the Desktop folder (default download location) and select the hds.ova file.
NOTE: The location of the hds.ova file depends on browser used, alternatively check the Downloads.
Click Next. The file is validated on selecting next and can take a moment before moving to the next screen.
On the OVF Template Details screen, select Next.
On the Name and Location screen enter hds01 as the name for virtual machine.
Figure 2. Name the Virtual Machine
Cisco dCloud
Click Next.
On the Deployment Configuration screen keep 2 CPU selected on the Configuration dropdown list.
Figure 3. Set the Number of CPUs
CAUTION: For production deployments, the default, Thick Provisioned Lazy Zeroed, should be chosen. Thin Provisioning should
be used with caution and for purposes in this lab to save disk space on the SAN! While VMware states that there is no performance
penalty between Thick or Thin provisioned virtual machines, other implications such as running out of space on a ESXi datastore
with thin provisioned machines must be taken into account and properly monitored and planned for.
Click Next.
On the Storage screen, click on VM Datastore instance for the destination storage location.
Figure 4. Storage Destination
Click Next.
Cisco dCloud
IMPORTANT: Set the Disk Format to Thin Provision.
Figure 5. Disk Format
CAUTION: For production deployments, Thin Provisioning should be used with caution! While VMware states that there is no
performance penalty between Thick or Thin provisioned virtual machines, other implications such as running out of space on a ESXi
datastore with thin provisioned machines must be taken into account and properly monitored and planned for.
Click Next.
On the Network Mapping screen keep VM Network as the Destination Network.
Click Next.
On the final screen, click Finish.
Wait for the VM deployment to finish. Upon successful deployment, the message Completed Successfully appears.
Figure 6. Successful Deployment
Click Close.
Repeat the virtual machine deployment steps to deploy a second Cisco HDS node called hds02.
After deploying the second HDS node, in the vSphere client, click Inventory, then ESXi server 198.18.133.31 and finally the
Virtual Machines tab.
Highlight both nodes (Shift or Ctrl click), hds01 and hds02, and right-click on the selection.
From the shortcut menu, select Power > Power On. Alternatively select both nodes and press Ctrl+B.
Cisco dCloud
Figure 7. Power on the VMs
Open the Console for the hds01 (node hds02 when repeating) virtual machine from the VMware vSphere Client by clicking
on the console button [ ] after selecting the virtual machine or by right-clicking on virtual machine and from the shortcut
menu selecting Open Console.
Figure 8. Open Console
When prompted with ciscoecp_<designator> login: login with Username: admin and Password: cisco.
NOTE: It can take 3 to 5 min for the login prompt to display. Wait for the correct prompt before attempting to login. Until then, the
prompt will display localhost login: and the screen will refresh a number of times.
Figure 9. Login Prompt
Next, the system prompts you to change the default password. Enter the current password cisco.
Then enter the new password C1sco12345 twice.
Figure 10. Set New Password
Cisco dCloud
The Cisco HDS virtual machine console displays a security disclaimer. Confirm with by selecting OK.
NOTE: To navigate through the following screens click the mouse once in the screen and then use the Up/Down and Right/Left
arrows and press the Enter key to make a selection. To release the mouse press Ctrl+Alt.
To configure the basic parameters (hostname, IP address, DNS, NTP) select Edit Configuration from the menu.
Figure 11. Edit Configuration
Select Yes to acknowledge the notification: Changes to this node will end active calls currently using this node.
NOTE: This does not apply for Cisco HDS nodes.
Figure 12. Acknowledge Warning
Select Static for the IP address configuration of the Cisco HDS node.
Figure 13. Set Type of IP Address
Set the following parameters for the node being configured:
Table 4.
Parameter hds01 hds02
Hostname hds01 hds02

Domain dcloud.cisco.com dcloud.cisco.com
IP Address 198.18.135.64 198.18.135.65
Mask 255.255.192.0 255.255.192.0
Gateway 198.18.128.1 198.18.128.1
DNS 198.18.133.1 198.18.133.1
NTP 198.18.128.1 198.18.128.1
Cisco dCloud
For this exercise arrow down and delete the other four NTP servers.
IMPORTANT: For production deployments, more than one NTP servers are required to ensure that the Cisco HDS nodes have a
time synchronization source. A valid time source is required for the nodes to validate certificates used for encrypted communication.
Figure 14. Node hds01 Parameters
Figure 15. Node hds02 Parameters
Confirm that all parameters have been correctly configured and then select Save Changes & Reboot.
Figure 16. Confirm Settings
Cisco dCloud
Note: Only node hds01 is shown in Figure 16.
Acknowledge the notification that changes to the node can result in reconfiguration of components by selecting Done.
Figure 17. Acknowledge Changes
To exit the VMware Console window press Ctrl+Alt.
Close the console window.
Repeat the initial configuration steps to configure node hds02.
Upload Cisco HDS configuration ISO image into the VMware Datastore
From the VMware vSphere client select the ESXi server 198.18.133.31.
Select the Configuration tab.
From the Hardware menu container, click Storage.
Under Datastores, right-click on the VM Datastore option and select Browse Datastore….
Figure 1. Browse to the Datastore
Click the Upload Files button [ ] and then select the option Upload File….
Figure 2. Upload File
Cisco dCloud
In the Upload Items dialog, navigate to the Desktop, select the config-drive.iso file, and click Open.
Click Yes to acknowledge the replacement warning dialog.
Figure 3. Acknowledge Warning
Close the Datastore Browser – [VM Datastore] window.
From the VMware vSphere client select the ESXi server 198.18.133.31 navigate to the Virtual Machines tab.
Highlight both nodes, hds01 and hds02, and right-click on the selection.
From the shortcut menu, select Power > Shut Down Guest. Alternatively select both nodes and press Ctrl+D.
Click Yes to confirm guest shutdown and wait for the VMs to power off.
Next, begin to mount the Cisco HDS configuration ISO image within the virtual machine. Right-click hds01 (repeat the same
steps for hds02) virtual machine and from the shortcut menu select Edit Settings….
Figure 4. Edit Settings
To confirm the warning about limited editing from vSphere Client click OK.
Under the Hardware tab click on CD/DVD drive 1.
Under Device Type select the radio button for Datastore ISO File and click Browse….
Browse to the VM Datastore and select the config-device.iso image.
Click OK.
Under Device Status check the boxes for Connect at power on.
Cisco dCloud
Figure 5. Set the CD/DVD drive settings
Click OK.
Repeat the steps for the hds02 node to connect the ISO to it.
Power up both HDS virtual machines.
Registering Cisco Hybrid Data Security nodes with the Cloud
Open the tab in the Firefox browser you had opened to the Control Hub earlier (https://admin.webex.com).
Login with Username: cholland@ssXXX.dc-YY.com and Password: dCloud123!.
Navigate to Services and then on the Hybrid Data Security card click Set Up.
Cisco dCloud
With both Cisco HDS nodes running, select Yes, I’m ready to register my Hybrid Data Security Node and click Next.
Figure 1. Ready to Register
On the Register Hybrid Data Security Node screen enter the following parameters:
a. Hybrid Data Security Cluster name: dcloud.cisco.com
b. FQDN or IP address of HDS node: hds01.dcloud.cisco.com (hds02.dcloud.cisco.com when repeating)
Figure 2. HDS Node Parameters
Click Next.
The following confirmation screen shows the previously entered parameters. Select Go to Node. This action redirects the
browser to the web interface of the Cisco HDS node and start the cloud registration process.
A new tab opens with a redirect to the node.
Cisco dCloud
Since the web interface on the Cisco HDS node is using a self-signed certificate, the browser is not able to verify the certificate
and displays the security exception shown in Figure 3. Select Advanced and Add Exception in the next dialog shown in
Figure 4.
Figure 3. Advance
Figure 4. Add Exception
On your browser, follow the respective prompts to accept the security exception. Click Confirm Security Exception.
Figure 5. Firefox Security Exception Dialog
On the registration confirmation dialog check: Allow Access to the Hybrid Data Security Node.
Click Continue.
Cisco dCloud
Close the Registration tab in the Firefox browser.
Congratulations you have registered your first Cisco Hybrid Data Security Node!
Return back to the Webex Control Hub and click Add Resource from the Hybrid Data Security Services page. Repeat the
steps 1-13 for node hds02 using the parameters below. Close the browser tab after the second HDS node has registered
successfully.
Figure 6. Register hds02
Check the status of the Hybrid Data Security Nodes
The service shows the status Operational under the HDS Cluster list select dcloud.cisco.com.
NOTE: The status can also be: Impaired Service (Directly after registering.) or Not Operational (While the new nodes are being
setup).
The dialog box shows the configuration parameters and status of the Cisco HDS cluster. Select Open nodes list on the fly-out
window.
Cisco dCloud
The newly registered Cisco HDS nodes verify the software version deployed from the OVA template against the latest available
software version released to the cloud. The HDS nodes will automatically go through the upgrade process if needed. If an
upgrade is available, you will see a message at the top of the page to Install now… Then you would click Upgrade Now from
the confirmation dialog box. HDS nodes are automatically upgraded and installed,
Figure 1. Upgrade Now
The Node List page displays the upgrade progress for both HDS nodes. It will take approximately 5-10 minutes for the upgrade
process, wait for the updates to complete before proceeding to the next step.
The Status changes to Running when the Upgrade is complete. Don’t continue until both have a status.
Figure 2. HDS Nodes Ready
Enable Cisco Webex HDS Service
After the HDS nodes have been upgraded, in the Control Hub navigate to Services > Hybrid Data Security card and click
Edit settings.
NOTE: In the General section an email address can be specified that receives notifications about the status of the Cisco HDS
nodes. This is not part of this lab exercise.
Under Service Status the Webex Organization can be enabled to start using the Cisco Hybrid Data Security node for issuing
keys to users. Click on Start Trial.
Cisco dCloud
NOTE: For this lab exercise Cisco HDS will be enabled using 2 nodes. For production deployments, at least 3 nodes are suggested.
Observe that the Service Status now shows Trial Mode is enabled and the FQDN of the Cisco HDS Cluster.
IMPORTANT: This lab uses a trial Webex organization. Under no circumstances should the trial organization be moved to production.
Please DO NOT PRESS the button!
Currently there are no users enabled for Cisco HDS (trial). Click the Add Users link. (See the screen above.)
Add the following email addresses to the Cisco HDS trial (press enter after typing the email address to add the second
address):
cholland@ssXXX.dc-YY.com
aperez@ssXXX.dc-YY.com
Click Add Users after entering both users listed above.
The Service Status page now confirms that two users are active for use with Cisco HDS.
Figure 1. User Status
Now all new Webex Teams spaces created by the users activated for Cisco HDS will be provided with encryption keys by the
locally deployed HDS nodes. Existing spaces that the user initiated before deployment and activation of Cisco HDS will continue
to use the Cisco Cloud Key Management Server – existing keys are NOT being migrated from the cloud to the Cisco HDS nodes.
Cisco dCloud
Scenario 5. Cisco Webex HDS at Work
Basic Client Operations with Cisco Hybrid Data Security
NOTE: If the DLP (Cloudlock) and eDiscovery parts of this lab have already been completed, logout and restart the Cisco Webex
Teams client on ALL workstations by clicking on the avatar and selecting Sign out. Then exit the Webex Teams client.
On workstation 1 the Webex Teams client.
Login to Webex Teams with Username: cholland@ssXXX.dc-YY.com and password: dCloud123!. Follow the above note
and make sure to log off and exit the Webex Teams client if you already completed the DLP (Cloudlock) and/or eDiscovery
modules of the lab. You will also need to logout/login to all Webex Teams clients including Anita’s on workstation 2
(198.18.1.37, dcloud\aperez / C1sco12345) then client login of username: aperez@ssXXX.dc-YY.com and password:
dCloud123!. Failure to log out and back will cause the next steps to fail. If this is the first time logging into the Webex Teams
clients, then you can continue with the exercise.
From the main screen click on the button and Contact a Person.
Enter Anita and select the user that is displayed.
Type a message and send to Anita. Since Charles and Anita are enabled for HDS the end-to-end encryption keys for this new
space are provided by the local KMS.
In a new Firefox browser tab, browse to the URL https://developer.webex.com/getting-started.html
Click Login and if needed enter Username: cholland@ssXXX.dc-YY.com Password: dCloud123!.
On the page, under Authentication, copy the access token.
On the desktop of workstation1, open the document get_uuids.py with Notepad++.
Replace <bearer from developer.webex.com goes here> with the access token you obtained from the developer.webex.com
website. Make sure there is a single blank between the word Bearer and the token.
Figure 1. Replace Text
Cisco dCloud
Figure 2. Token Inserted
Save and Close the file.
On workstation1 open a Windows Command window [ ].
Change to the directory: cd c:\Users\cholland\desktop and run the command python get_uuids.py.
Figure 3. Run Command
Keep this window open and available, the UUIDs are required in later steps.
NOTE: Cisco Webex is obfuscating real user IDs and PII information as much as possible. To identify KMS activities of a particular
user it is required to know the users UUID.
Cisco dCloud
From a new PuTTY session (right-click the top bar of the window of the existing session and choose New Session from the
menu) to the syslog server (root/C1sco12345) (don’t close the existing one that is running the Docker container) and run the
following command:
cat /var/log/messages | grep <UUID of cholland>
Figure 4. New PuTTY session
Observe that similar messages (as shown in the example in Figure 76) are displayed. The example shows several requests to
KMS. Hostnames (hds01 and hds02). It also shows that both nodes are being used simultaneously and are load balancing. The
first line shows a KMS:REQUEST with a method: create and the UUID associated with Charles Holland. Bottom KMS:REQUEST
with method: retrieve is a request from the client for the created key.
Figure 5. Output
On workstation 2 (RDP to 198.18.1.37. Login with Username: dcloud\aperez and Password: C1sco12345).
Launch Cisco Webex Teams client.
Logon to Webex Teams with aperez@ssXXX.dc-YY.com / dCloud123!. Then check the 1:1 conversation between Charles
and Anita and send a reply.
In the PuTTY window on workstation 1, run the command: cat /var/log/messages | grep <UUID of Anita>.
Observe that this time the example is slightly different since the key was created by the initial request of Charles when he
established the 1:1 conversation with Anita we only see a KMS:REQUEST with method: retrieve when Anita opens the
conversation.
Figure 6. KMS:Request
Cisco dCloud
INFORMATION: The concept of KMS Federation is introduced, that concept being the ability to share keys between different Cisco
Cloud KMS, the.
Federation in this context doesn’t share the pain and misery that the Collaboration industry has lived through with protocols like SIP
or XMPP. There are no additional configuration steps required to allow business to business communication in environments that
use an on premise KMS. The certificate deployed with KMS is used to establish a mutually authenticated connection between the
on-premise deployment and the Cisco Collaboration Cloud. This allows multiple customer deployed KMS instances to seamlessly
and securely federate.
In this exercise, Charles and Anita are both users that have been enabled for KMS. Next is an example where a user is part of the
conversation that either uses the Cisco Cloud KMS or a customer that has also deployed Cisco Webex HDS and runs its own KMS.
NOTE: For continuous monitoring of all KMS related messages open a new terminal window (PuTTY) to the syslog machine, use
the following command and keep window open: tail -f /var/log/messages|awk '$5 == "kms:" {print $0}'
Return to Workstation 1 and create a new Webex Teams team using a Name of your choosing.
Select the new team, click Team members, and add Anita and Kellie to the team.
Click on Spaces within the team and write something into the General space of that newly created team.
On Workstation 3 (RDP to 198.18.1.38. Login with Username: dcloud\kmelby and Password: C1sco12345). Launch the
Webex Teams client and login with kmelby@ssXXX.dc-YY.com / dCloud123!.
Check the team that you created in the previous step, of which Kellie is a member, and write something into the General space.
User Kellie is part of same Webex organization as Charles and Anita. Kellie has not been enabled for the Webex HDS trial hence
the user is still using the Cisco Cloud KMS. Inviting Kellie to a team/space that was created by a HDS enabled user (Charles)
shows that keys are being shared between the local KMS and users based on the cloud KMS.
Check the syslog server with the following command: cat /var/messages | grep <UUID of Kellie>.
NOTE: Similar to the previous example, the UUID of Kellie is requesting keys from the local KMS via the federation link with the
cloud KMS on which Kellie is hosted.
Figure 7. Key Request
Return to Workstation 1, create a new Webex Teams team and add the following members: Anita and
luke@identitylab12.ciscolabs.com. The second member is an external user in a Webex Org that is also enabled for
HDS/KMS. Creation of this space will force the two KMS to establish a federated connection.
NOTE: The UUID below represents the KMS deployed in Webex Org. identitylab12.ciscolabs.com.
This is not the best way to grep the information we need – check further how to best get the messages we need for this piece.
Cisco dCloud
Return to the syslog server and enter the following command:
cat /var/log/messages | grep a45b82ef-2093-4b7d-a8e0-24ef195603c5 | more
Look for the message EPHEMERAL_KEY_COLLECTION – first section of messages in Figure 79 and Figure 80 shows the
establishment of KMS Federation.
Figure 8. Look for Message
Use this command to display messages that relate to the user Luke, in Org. identitylab12.ciscolabs.com, retrieving keys from
the local KMS.
cat /var/log/messages | grep 7b97da7e-0855-4241-a720-7c56e52ef46e | more
Figure 9. Display Messages
Cisco dCloud
Scenario 6. Enhanced Logging Experience – Optional Module

Storing the logs produced by the KMS nodes in a flat file with a standard syslog doesn’t provide a good experience to administrators
to monitor and/or troubleshoot KMS activities. In this section, a standard syslog is replaced by an Elastic Stack to provide more
visibility, enhanced search, and the ability to create dashboards visualizing the data produced by KMS.
CAUTION: Cisco does not specifically recommend or require the use of Elastic Stack. There are many other logging solutions that
can receive standard syslog messages available that can be utilized. The example provided in this scenario is not intended for
production use Instead this scenario shall only give an overview of the benefits of using an enhanced logging solution. This
information is provided as is with no warranty or support by Cisco. Use at your own risk.
Configure ELK
For this exercise the components of Elastic Stack (Logstash, Elasticsearch, and Kibana) are deployed in a single Docker container
without redundancy or high availability.
Note: Docker and the ELK container have already been installed for you on the ELK machine. For your reference, please refer to
the appendix of this document on how to install Docker on a Linux host and prepare the machine for ELK.
For Elastic Search to correctly parse the log messages received from KMS nodes some additional configuration needs to be added
to the standard Docker image retrieved from the repository. Docker provides a build option where existing images can be modified
with additional files or other configuration parameters (required files have been already downloaded from the GitHub repository in
the previous chapter).
NOTE: Configuration files and scripts required for this scenario are hosted in the following GitHub repository
https://github.com/tobiasneumann42/ciscohds_elk.
To pull the content to the local machine git command must be installed. The following steps to install git are for documentation
purposes only – This has been done for you!
To install git with the command yum –y install git.
Using PuTTY, open a new terminal session to the elk Linux host (elk.dcloud.cisco.com and root/C1sco12345). To clone
the latest version from the GitHub repository run the following command from the directory /root:
git clone https://github.com/tobiasneumann42/ciscohds_elk
The files are located on the elk machine under /root/ciscohds_elk.
From the PuTTY connection to the ELK server enter cd /root/ciscohds_elk and run the command:
docker build . -t elkhds
Docker allows existing images, downloaded from the repository, to be modified based on definitions made through an input file
called Dockerfile. The above command will take the information from the Dockerfile and update the image from the repository
with exercise specific configuration information and create a new image called elkhds.
Cisco dCloud
After the Docker container is built from the previous step, start the elkhds Docker container with the following command:
docker run -p 5601:5601 -p 9200:9200 -p 9300:9300 -p 514-515:514-515/udp -p 5044:5044 -t --name elk01 elkhds
The command, specifies the ports, instructs Docker which ports from the container to expose on the host system (see Table 5).
The name, parameter, is just a reference for the instance and, elkhds, refers to the image that was created in the previous step
based on the provided Dockerfile.
Table 1. Port Specifications for Docker
Protocol/Port Item Description
TCP 5601 Kibana Web front end and visualization component of ELK
TCP Elasticsearch REST API
TCP 9300 Elasticsearch Node communications
UDP 514-515 Logstash Syslog receiver ports. (514 standard syslog, 515 KMS)
Congratulations! You have successfully installed an ELK stack. In the next exercise, the required configuration changes are applied
to make use of this new component.
Update HDS configuration ISO Image
For HDS nodes to use the Elastic Stack for logging, the configuration of the ISO image needs to be modified accordingly. Original
image is configured to send all syslog messages to the 198.18.136.60 (syslog.dcloud.cisco.com) UDP port 514. To use ELK, the
HDS nodes need to send syslog messages to 198.18.136.61 (elk.dlcoud.cisco.com).
On the syslog machine, if not still running, launch the Cisco Webex HDS configuration tool with the following command:
docker run -p 8080:8080 --rm -it --name ciscohds ciscosparkhds/hds-setup:stable
In the browser, browse to 198.18.135.60:8080 (refer to the lab section Configuring Cisco Webex HDS for details – remember
to replace 127.0.0.1 with 198.18.135.60 after authentication).
On the main screen click Get Started.
On the ISO Import screen, to change an existing configuration ISO you must select Yes for import and Browse… and select
the existing file config-drive.iso from the desktop. Then click Continue.
Cisco dCloud
IMPORTANT: This step is VERY important. Not selecting the existing ISO and instead creating a new file for an active HDS
deployment can render the existing keys in the database unusable. User data encrypted with these keys will be lost.
On the X.509 certificate configuration screen, select Yes to continue using the existing certificate chain and private key. Click
Continue.
Figure 1. X.509 Certificate
Confirm the information on the Database Credentials screen and click Continue. (password is Cisco,123)
Figure 2. Database Credentials
Cisco dCloud
On the System Logs configuration screen, change the Syslog URL to udp://198.18.135.61:515. Changing the Syslog URL
instructs the HDS nodes to send log traffic to the elk host using UDP on port 515. Then click Continue.
NOTE: Make sure you change the port as it is not the default syslog port that elk is listening on for KMS messages.
Figure 3. System Log Location
Keep Service Account and Select Cloud Access selected and click Continue.
Confirm Reset Service Account Passwords by clicking Continue.
Download the updated ISO to Workstation1.
Figure 4. Download ISO
Upload the ISO to the VMware data store
From the VMware vSphere client select the ESXi server 198.18.133.31.
Select the Configuration tab.
From the Hardware menu container click on Storage.
Under Datastores, right-click the VM Datastore and from the shortcut menu select Browse Datastore….
Click on the Upload Files button [ } and then select the option Upload File….
Cisco dCloud
In the Upload Items dialog, navigate to the location, c:\users\cholland\desktop, where you previously downloaded the
config-drive(1).iso file to and click Open and then Yes.
Figure 1. Newly Uploaded ISO File
Close the VMware datastore dialog box.
To activate the new configuration, shutdown the hds01 (hds02 when repeating) virtual machine. Right-click on hds01 (hds02
when repeating) and from the shortcut menu select Power > Shutdown Guest.
Figure 2. Shutdown Virtual Machine
Once shutdown is complete, edit the virtual machine properties by, right-clicking on the VM and selecting Edit Settings. Then
click OK.
Click on CD/DVD drive 1. Select the Datastore ISO File and click Browse….
Select the newly uploaded ISO from the VM Datastore, config-drive(1).iso. Make sure the Connect a power on check box is
selected.
Click OK.
Power on [ ] virtual machine hds01 (hds02 when repeating).
Check that the Cisco Webex Control Hub that hds01 is in operation. Then repeat steps 1-13 for hds02.
Copy Access Token to the ELK Host
The script used to update the UUID information with user readable data against the Cisco Webex REST API requires an access
token. For a continuous running script it is recommended to register an application on developer.webex.com. The provided
parameters allow an application to use a Refresh Token to create new Access Tokens before expiration. In this example, the script
is run using the Access Token that was obtained earlier from the developer.webex.com site.
Go to developer.webex.com and copy the access token (as explained in the earlier module to gather UUIDs).
Open Windows PowerShell [ ] and enter the following commands, this will provide the epoch time value.
NOTE: Enter each line one at a time and not all at once.
Cisco dCloud
$date1 = Get-Date -Date "01/01/1970"

$date2 = Get-Date
(New-TimeSpan -Start $date1 -End $date2).TotalSeconds
Figure 1. PowerShell get epoch time
Open Notepad++, create a new file and enter the following information:
{"expires_in": 9999999, "refresh_token": "FFFF", "token": "< token from

developer.webex.com>", "timestamp": <time value from PowerShell command>}
Figure 2. PowerShell get epoch time
Save the file as webex_teams_proc.token on the desktop of the workstation.
Launch a new PuTTY terminal connection to the elk host and issue the following commands:
mkdir /tmp/scripts
cp /root/ciscohds_elk/tmp/scripts/webex_proc.py /tmp/scripts/
In a Windows Command window, change the path to cd c:\users\cholland\desktop and issue the following command to
copy the Webex API access token to the elk host.
pscp webex_teams_proc.token root@elk:/tmp/scripts/webex_teams_proc.token
On the ELK server, change the directory to cd /tmp/scripts and launch python3.6 webex_proc.py.
Leave the script running. It will update the user information in the elastic backend on a continuous basis. The script operation
can be monitored by creating a new PuTTY terminal window to the elk host and the issuing the following command:
tail -f /var/log/webex_proc.log.
Create Continuous Traffic for the local KMS
To create continuous traffic against the local KMS, a script is provided that creates new Webex Teams spaces periodically, adds all
users to it and sends a message to the space. All clients (workstations) retrieve a key for every new space created to decrypt space
title and content.
Cisco dCloud
On Workstation 1 open a new Windows Command window (click the button in the task bar and type cmd).
From the path cd c:\users\cholland\desktop, copy the webex_hds_traffic.py script file to the desktop with the following
command:
pscp root@elk:/root/ciscohds_elk/webex_hds_traffic.py webex_hds_traffic.py
Enter the password C1sco12345 and press Enter.
Using Notepad++, edit the script on the Desktop, webex_hds_traffic.py, to add the Bearer token from
developer.webex.com.
Save the file.
Run the script with C:\users\cholland\Desktop> python webex_hds_traffic.py and keep it running in the background (do not
close the window).
First Steps in Kibana
In the following, from Workstation 1, you will navigate to the Kibana web portal and familiarize yourself with the navigation of the site
and interpret some of the messages sent by the HDS nodes.
From Workstation 1, using Firefox, open a new tab and browse to the following URL: http://elk.dcloud.cisco.com:5601
When connecting for the first time, select @timestamp from the Time Filter field name and then click Create to configure a
default index that is used to store information.
Figure 1. Connecting for the First Time
Wait a couple of minutes and press the refresh index icon (circular arrows). This will update the field index mapping in elk.
Cisco dCloud
In the main Discover dialog screen of Kibana, all messages are displayed including a graphical representation of messages
received in the selected timeframe. Information can be searched using full text from the query field.
Figure 2. Discover
Kibana allows search queries, visualizations, and dashboards to be configured. In the following steps this will be explored. You will
use the commands bellow to copy the predefined .json file to Workstation 1.
From directory c:\users\cholland\desktop> run: pscp root@elk:/root/ciscohds_elk/hdselk.json hdselk.json.
Return to the Kibana web portal and navigate to Management and click on Saved Objects.
Figure 3. Navigate to Management
Cisco dCloud
From the next screen select Import. Select the hdselk.json file copied in the previous step from the desktop.
Figure 4. Import Saved Object
Click Yes, overwrite all to confirm the overwriting of any existing objects.
Figure 5. Confirm Overwriting
On the Kibana main search page click Discover. In the search field enter Charles.
In the previous scenario, using a standard syslog server, the log messages only contained the userID in UUID format. Using
the python script running in the background, the log entries now also contain detailed user information in human readable format.
Figure 6. Search for Charles
Cisco dCloud
Select the triangle at the start of the message. Parsing patterns for HDS added to the ELK infrastructure creates index fields
for a specific part of the log messages. These can be utilized for graphical representation or mathematical computations.
Figure 7. Select the Triangle
Figure 8. User specific Information
Next use the objects imported in the previous step into Kibana. Click Discover and then Select Open.
The page shows the available stored queries, click on KMS Health.
Figure 9. Select KMS Health
Cisco dCloud
Cisco Webex HDS nodes send continues health status messages including current memory utilization. The preconfigured
search shows all related health status information.
Figure 10. KMS Health
Click Discover and then Select Open.
This time select webexhds_KMS_key_requests. This output provides HDS administrators with direct visibility on who is
requesting keys from on-premise KMS.
Figure 11. Key Requestors
Cisco dCloud
Pulling it all together, let’s visualize the information returned by the queries and create a nice dashboard. In Kibana select
Dashboard and HDS_dash01.
Figure 12. Navigate to the HDS Dashboard
In addition to visualizing the data, administrators can create notifications on thresholds.
Figure 13. Customized Dashboard
This concludes the lab.
Cisco dCloud
Appendix A. Installing the Database Used by Cisco Hybrid Data Security
Install PostgreSQL Database Components

In this section, you will install PostgreSQL database on host postgresql01 (commands assume install on CentOS 7. For other Linux
distributions, these commands might be slightly different).
Launch PuTTY from the icon [ ] on the Taskbar.
Under Saved Sessions, double click on postgre1 to launch the SSH session. Alternatively, connect to the IP Address
198.18.135.58.
Login as root with password C1sco12345.
At the [root@postgre1 ~] prompt, issue the command: yum clean all
Figure 1. Clean up yum
Install the yum repository for PostgreSQL version 9.6 required for Cisco HDS using the following command:
yum -y install https://yum.postgresql.org/9.6/redhat/rhel-7-x86_64/pgdg-redhat96-9.6-3.noarch.rpm
Install PostgreSQL version 9.6 and required dependencies using the following command:
yum -y install postgresql96-server postgresql-contrib
Figure 2. Install PostgreSQL
Initialize PostgreSQL using the follow command: /usr/pgsql-9.6/bin/postgresql96-setup initdb
Cisco dCloud
Enable PostgreSQL to automatically start on system boot using the following two commands:
systemctl start postgresql-9.6
systemctl enable postgresql-9.6
Figure 3. Initialize and Enable PostgreSQL
Basic Configuration of the PostgreSQL Database for Cisco HDS
Switch to the (Linux) user using the following command: su postgres
Launch PostgreSQL command line: psql
Figure 1. First Set of Commands
Create a new PostgreSQL user for use with HDS deployment using the following command:
CREATE USER hdsuser WITH PASSWORD 'Cisco,123';
Create a new PostgreSQL database for use with HDS deployment using the following command:
CREATE DATABASE hdsdb OWNER hdsuser;
Assign the required privileges to the database as well as the user created in the previous steps:
GRANT ALL PRIVILEGES ON DATABASE hdsdb to hdsuser;
ALTER ROLE hdsuser WITH SUPERUSER;
Figure 2. Create User and Database
Exit psql utility: \q
Cisco dCloud
Exit from PostgreSQL user: exit
Figure 3. Exit PstgreSQL
Edit the PostgreSQL configuration file: nano /var/lib/pgsql/9.6/data/pg_hba.conf
Figure 4. Edit Configuration file
Add the following line to allow access from external hosts in the IP range 198.18.0.0/16 to the database with md5
authentication.
# IPv4 local network connections for HDS nodes:
host all all 198.18.0.0/16 md5
CAUTION: This rather large range is specific to the setup in the Cisco dCloud environment. For production deployments, only the
specific Cisco Webex HDS nodes and systems required to monitor database operations should be allowed to communicate with the
database.
Figure 5. External Host Access
Save changes and exit from Nano editor with Cntrl-X and Y.
Figure 6. Exit from the Nano Editor
Figure 7. Save changes
Cisco dCloud
Press Enter when requested to Write the file name.
Figure 8. Write File
Edit the postgresql.conf file: nano /var/lib/pgsql/9.6/data/postgresql.conf.
By default, PostgreSQL only listens to SQL requests on localhost (127.0.0.1). For external database connections, as required
by Cisco HDS, PostgreSQL has to be configured to listen on other configured IP address(s). In the section CONNECTION AND
AUTHENTICATION change the following:
IMPORTANT: Make sure the hash # at the start of the lines is removed.
a. listen_addresses = ‘*’ (include the single quotes)
b. TCP port is set to 5432
Figure 9. Set parameters
Save and exit with Ctrl-X, press Y followed by pressing Enter.
Restart PostgreSQL to activate the changes by entering in the following command: service postgresql-9.6 restart.
Figure 10. Restart PostgreSQL
Cisco dCloud
Check the status of PostgreSQL with the command: systemctl status postgresql-9.6.service.
Figure 11. Status Check of PostgreSQL
Install & Configure PostgreSQL Admin – Web-based Monitoring Tool
NOTE: Installation of the monitoring software is not mandatory. The software is used in this lab to demonstrate some of the inner
workings between the Cisco HDS nodes and the database.
Us the following command to install a web server which is required for PostgreSQL Admin: yum –y install httpd.
NOTE: Because of an intermittent issue with yum –y install commands, the installation might not work. If the installation fails, please
retry using the command without the –y option and manual confirm “y” when prompted.
Figure 1. Install Web Server
Cisco dCloud
Figure 2. Install Complete
Enable httpd to automatically start on system boot with the following commands:
systemctl start httpd.service
systemctl enable httpd.service
PHP is required for PostgreSQL Admin. Using the following command, install the required PHP components:
yum -y install php php-pgsql
Figure 3. Install PHP components
Figure 4. PHP Component Install Complete
Next install the PostgreSQL Admin components: yum -y install phpPgAdmin
Figure 5. PostgreSQL Admin Component Install
Cisco dCloud
Figure 6. Successful Install
To access the PostgreSQL Admin webpage the default configuration must be modified. Open the phpPgAdmin.conf file using
the command: nano /etc/httpd/conf.d/phpPgAdmin.conf and change the following parameters:
a. Under <IfModule mod_authz_core.c> change Require local to Require all granted
b. Under <IfModule !mod_authz_core.c> change Deny from all to Allow from all
Figure 7. Webpage Parameters
Save and exit with Ctrl-X and Y.
Open the config.inc.php config file using the command: nano /etc/phpPgAdmin/config.inc.php
Cisco dCloud
Change the following parameters:
IMPORTANT: Do not copy and paste these commands.

$conf[‘servers’][0][‘desc’] = ‘postgre1’;
$conf[‘servers’][0][‘host’] = ‘postgre1.dcloud.cisco.com’;
$conf[‘servers’][0][‘port’] = 5432;
$conf[‘servers’][0][‘sslmode’] = ‘allow’;
Figure 8. Parameter Changes
Restart the PostgreSQL server using the command: systemctl restart postgresql-9.6.service
Tell the httpd service to reload configuration with the following command: systemctl reload httpd.service
Login to PostgreSQL Web Admin http://postgre1.dcloud.cisco.com/phpPgAdmin/ from a browser on Workstation1.
NOTE: A shortcut is provided in Internet Explorer.
Select the database host postgre1 from the panel on the left and logon with the credentials for the database admin created
earlier in the PostgreSQL install section Username: hdsuser Password: Cisco,123.
Figure 9. Browse to and select postgre1
Cisco dCloud
Figure 10. Login
After successfully logging in, the pane on the left displays details for the available databases. While the hdsdb has been created
from the PostgreSQL CLI tool, it has not been populated yet. This will automatically occur on the first Cisco HDS being registered
to the cloud and activated.
Figure 11. Available Database View
This concludes the installation and configuration of the PostgreSQL database and the monitoring components.
Deploy Syslog Server
For the CentOS Linux host syslog.dcloud.cisco.com in this lab the Syslog daemon has already been installed. You don’t need to
install the syslog server, however, you will need to follow these steps to configure the process.
In the event that a Syslog server needs to be installed on Linux (CentOS 7), the following command can be utilized:
yum -y install rsyslog
Configure Syslog Server
From the Desktop launch a new instance of PuTTY.
Connect to syslog.dcloud.cisco.com and login with Username: root and Password: C1sco12345.
Using the nano editor open the rsyslog.conf file: nano /etc/rsyslog.conf
Cisco dCloud
Verify within the syslog.conf configuration file that UDP and/or TCP service is enabled by removing the hash ‘#’ sign from the
front of the lines of code under # Provides UDP syslog reception and # Provides TCP syslog reception.
Figure 1. Verify Configuration
Cisco HDS machines can use either protocol (UDP or TCP) for sending logging messages.
Restart the Syslog daemon by entering in the following command: systemctl restart rsyslog.service.
Figure 2. Restart the Syslog daemon
Verify that Syslog is listening to the correct protocols and ports by entering in the following command: netstat -antup |
grep 514.
Figure 3. Verify Protocols and Ports
Do not close the syslog session as it will be used in the next scenario.
Cisco dCloud
Acquire Certificate for use with Cisco Webex HDS
For the purpose of this exercise, Let’s Encrypt is used as the issuer for these free, valid for 90 days, certificates.
Install and configure Let’s Encrypt for a temporary certificate
Continuing in the PuTTy session connected to the syslog server, run the following command: yum clean all.
To begin, it is necessary (in addition to installing the required tools) to add the required repository using the following
command: yum -y install epel-release
Figure 1. Add Repository
Figure 2. Repository Installed
Install the Let’s Encrypt tools using the following command: yum –y install letsencrypt
Figure 3. Install Let’s Encrypt Tools
Change to the letsencrypt directory: cd /root/letsencrypt
Using nano, modify the openssl.conf file: nano openssl.cnf
Change the last line (subjectAltName) of the configuration file to match the domain of your pod.
Cisco dCloud
Figure 4. Change the Subject Alt Name
Save and exit with Cntl-X and Y.
Create the certificate signing request using openssl using the following commands:
CAUTION: A file with the commands for openssl and letsencrypt, can be found on the desktop of Workstation1. Please modify
the commands to match your POD’s domain then copy and paste them into the PuTTY terminal window on the Linux host syslog.
If the commands are not modified, using another domain will cause issues.
openssl req \
-new -newkey rsa:2048 -sha256 -nodes \
-keyout privkey1.pem -out signreq.der -outform der \
-subj "/C=UK/ST=Some State/L=Some Place/O=<your-POD-domain>/emailAddress=webmaster@hds.<your-POD-
domain>/CN=hds.<your-POD-domain>" \
-reqexts SAN \
-config openssl.cnf
Figure 5. Openssl Commands
Issue the certificate request from the Let’s Encrypt’s Staging server using the following commands:
Cisco dCloud
CAUTION: Let’s Encrypt production servers only allow a limited number of requests. To ensure that their servers are not blocking,
please use the staging server first and upon successful response repeat the request with the production server.
letsencrypt certonly \
--standalone \
--preferred-challenges http \
--server https://acme-staging.api.letsencrypt.org/directory --text \
--config-dir letsencrypt/etc --logs-dir letsencrypt/log \
--work-dir letsencrypt/lib --email "webmaster@hds.<your-POD-domain>" \
--csr "signreq.der"
Agree to the Terms and Conditions by selecting A.
Select N on share email address.
Figure 6. Certificate Request for Staging Server
Upon the successful completion of the challenge handshake please remove the files created before running the command
against the Let’s encrypt production environment: rm –f 000*
Figure 7. Handshake Challenge
Cisco dCloud
Now enter the following commands to issue the certificate request against the Let’s Encrypt production server:
letsencrypt certonly \
--standalone \
--preferred-challenges http \
--server https://acme-v01.api.letsencrypt.org/directory --text \
--config-dir letsencrypt/etc --logs-dir letsencrypt/log \
--work-dir letsencrypt/lib --email "webmaster@hds.<your-POD-domain>" \
--csr "signreq.der"
Agree to the Terms and Conditions by selecting A.
Select N for the share email address request.
Note: The Screenshot shows that Let’s encrypt is verifying the certificate request by sending an http request to the FQDN for which
the certificate is requested. This requires the host to be accessible from the internet via the requested FQDN.
Figure 8. Certificate Request
Now that there are three files, the certificate, the chain of root CAs, and private key files, the components need to be converted
into a single pfx file. Use the following openssl command to convert the components:
openssl pkcs12 -export -out hds.pfx -inkey privkey1.pem -in 0000_cert.pem -certfile 0000_chain.pem -
certfile 0001_chain.pem -name kms-private-key
Cisco dCloud
When prompted for an export password enter Cisco,123 twice.
Figure 9. Password Request
To create the configuration for the Cisco HDS nodes the hds.pfx certificate file needs to be copied to Workstation1. To do
this, first open a command prompt window on Workstation1 and change directory to the downloads folder using this
command
cd c:\users\cholland\downloads.
Use the PuTTY Secure Copy command (PSCP) to initiate the copy: pscp root@syslog:letsencrypt/hds.pfx hds.pfx
When prompted, enter the syslog machine root password: C1sco12345.
Figure 10. Copy File to Workstation 1
Install and configure Docker for HDS configuration tool
Return to the PuTTy window connected to the syslog server. At the [root@syslog letsencrypt]# prompt, return to the root
directory by issuing the command cd /root.
Install Docker using the following command: yum -y install docker.
Figure 1. Install Docker
Start the Docker daemon using the following command: systemctl start docker.
Enable the automatic start of Docker on boot: systemctl enable docker.
Verify that Docker is installed and running: docker run hello-world.
Cisco dCloud
This command downloads a test image and runs it in a container. When the container runs, it prints an informational message
and exits. You might need to scroll up again to see the following output.
Figure 2. Verify Docker is Installed
Install and prepare ELK
NOTE: Command to install Docker is: yum -y install docker.
NOTE: To start the Docker daemon enter the command: systemctl start docker.
NOTE: To enable the automatic start of Docker on boot issue the following command: systemctl enable docker.
NOTE: To verify if Docker is working correctly issue the command: docker run hello-world.
To increase the virtual memory configuration for Linux, required for ELK to run, issue the command: sudo sysctl -w
vm.max_map_count=262144.
To make this change permanent edit /etc/sysctl.conf. Enter the command: nano /etc/sysctl.conf.
Figure 1. Permanent Virtual Memory Increase
Verify that the setting has been correctly applied by issuing the command: sysctl vm.max_map_count.
Pull the latest version of elk from Docker registry by issuing the command: docker pull sebp/elk:553
NOTE: This process might take some time.
Cisco dCloud

Cisco Webex Teams Security Lab Guide v1.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco Webex Teams Security Lab Guide v1.1

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Cisco Webex Teams Security Lab v1

About This Demonstration

Figure 1. Realms of Separation (without Hybrid Data Security)

Figure 2. Hybrid Data Security

Figure 3. KMS Federation Example

This guide for the Collaboration Webex Security Lab includes:

• About This Demonstration

• About This Solution

• Scenario 2: Cisco Webex Teams eDiscovery

• Scenario 4: Deploy Cisco Webex HDS

• Scenario 5: Cisco Webex HDS at Work

• Scenario 6: Enhanced Logging Experience (Optional)

● Laptop with Cisco AnyConnect® ● Cisco AnyConnect

About This Solution

• Logging Infrastructure – Syslog compliant logging facility

• X.509 Certificate – for mutual secure communication

Also included in the lab are steps to configure a Cloudlock integration.

Figure 4. dCloud Topology

Table 2. System Details

Name Description Host Name (FQDN) IP Address Username Password

Postgre1 PostgreSQL postgre1.dcloud.cisco.com 198.18.135.58 root C1sco12345

Postgre2 PostgreSQL postgre2.dcloud.cisco.com 198.18.135.59 root C1sco12345

Syslog Syslog Server syslog.dcloud.cisco.com 198.18.135.60 root C1sco12345

ELK Elasticsearch, Logstash, and Kibana elk.dcloud.cisco.com 198.18.135.61 root C1sco12345

ESXi VMware ESXi esxi.dcloud.cisco.com 198.18.133.31 labroot C1sco12345

Workstation 1 Windows 10 wkst1.dcloud.cisco.com 198.18.1.36 dcloud\cholland C1sco12345

Workstation 2 Windows 10 wkst2.dcloud.cisco.com 198.18.1.37 dcloud\aperez C1sco12345

Workstation 3 Windows 10 Wkst3.dcloud.cisco.com 198.18.1.38 dcloud\kmelby C1sco12345

Figure 5. DNS Domain Information

Table 3 contains details on preconfigured users available for your session.

Table 3. User Details

User Name User ID Password Email Address

Anita Perez aperez C1sco12345 aperez@ssXXX.dc-YY.com

Charles Holland cholland C1sco12345 cholland@ssXXX.dc-YY.com

Kelly Melby Kmelby C1sco12345 kmelby@ssXXX.dc-YY.com

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

Initiate your dCloud session. [Show Me How]

NOTE: It may take up to 30 minutes for your session to become active.

• Workstation 1: 198.18.1.36, Username: dcloud\cholland, Password: C1sco12345

Cisco Hybrid Data Security requirements pre-configured for you

Cisco Cloudlock Cleanup

Login with cholland@ssXXX.dc-YY.com and password dCloud123!

Click Accept on the next page.

Figure 1. Edit authorization

Click Revoke Authorization at the bottom right of the pop up.

Figure 2. Revoke Authorization

Next, navigate to Policies.

Figure 3. Policy list

You have now completed the Cloudlock cleanup process.

Enable Compliance Officer Role in Cisco Webex Control Hub

Click Accept (if needed).

Navigate to Users and click Anita Perez from the list.

From the fly-out window, select Administrator Roles.

Figure 1. Administrator Roles

Select Full administrator privileges and click Save.

Figure 2. Anita Perez Full Administrator Privileges

Figure 3. Exit Anita Perez Administrator Roles

Select Service Access.

Figure 4. Anita Perez Service Access

Select Compliance Officer and click Save.

Figure 5. Anita Perez Compliance Officer Service Access

Configure Cloudlock integration with Cisco Webex Teams