Skip to main content

Control Center

Monitor dashboard

The Control Center dashboard is a customizable visual display providing a quick security overview of all protected endpoints and network status.

Dashboard portlets display various real-time security information using easy-to-read charts, thus allowing you to quickly identify any issues that might require your attention.

console_dashboard_op_48435_en.png

This is what you need to know about dashboard portlets:

  • Control Center comes with several predefined dashboard portlets.

  • Each dashboard portlet includes a detailed report in the background, accessible with just one click on the chart.

  • There are several types of portlets that include various information about your endpoint protection, such as update status, malware status, firewall activity.

    Note

    By default, the portlets retrieve data for the current day and, unlike reports, cannot be set for longer intervals than one month.

  • The information displayed via portlets refers to endpoints under your account only. You can customize each portlet's target and preferences using the dashboard.edit Edit Portlet command.

  • Click the chart legend entries, when available, to hide or display the corresponding variable on the graph.

  • The portlets are displayed in groups of four. Use the vertical scroll bar or the up and down arrow keys to navigate between portlet groups.

  • For several report types, you have the option to instantly run specific tasks on target endpoints, without having to go to the Network page from the left side menu to run the task (for example, scan infected endpoints or update endpoints). Use the button at the lower side of the portlet to take the available action.

The dashboard is easy to configure, based on individual preferences. You can edit portlet settings, add additional portlets, remove or rearrange existing portlets.

Refreshing portlet data

To make sure the portlet displays the latest information, click the refresh.png Refresh icon on its title bar.

To update the information for all the portlets at once, click the refresh.png Refresh Portlets at the top of the dashboard.

Editing portlet settings

Some portlets offer status information, while other report on security events in the last period. You can check and configure the reporting period of a portlet by clicking the edit.png Edit Portlet icon on its title bar.

Adding a new portlet

You can add other portlets to obtain the information you need.

To add a new portlet:

  1. Log in to GravityZone Control Center.

  2. Go to the Dashboard page from the left side menu.

  3. Click the add_dashboard.png Add Portlet button at the upper side of the console. The configuration window is displayed.

  4. Under the Details tab, configure the portlet details:

    • Type of background report

    • Suggestive portlet name

    • The time interval for the events to be reported

    For more information on available report types, refer to Report Types.

  5. Under the Targets tab, select the network objects and groups to include.

  6. Click Save.

Removing a portlet

You can easily remove any portlet by clicking the remove.png Remove icon on its title bar. Once you remove a portlet, you can no longer recover it. However, you can create another portlet with the exact same settings.

Rearranging portlets

You can rearrange dashboard portlets to better suit your needs. To rearrange portlets:

  1. Log in to GravityZone Control Center.

  2. Go to the Dashboard page from the left side menu.

  3. Drag and drop each portlet to the desired position. All other portlets between the new and old positions are moved to preserve their order.

    Note

    You can move portlets only within the positions already taken.

Create GravityZone security certificates

Overview

Browsers need Control Center Security certificate to recognize Control Center website as trusted.

The Root Certificate

Digital certificates are verified using a chain of trust. A Root certificate (hereinafter known as the Root) is the top-most certificate of the tree, the private key of which is used to "sign" other certificates. All certificates immediately below the Root certificate inherit the trustworthiness of the Root certificate.

Marking Root Certificates as trusted

Several different approaches are possible to make the devices trust the SSL certificate presented by the MDM server. We will present three of them, but only two make sense as a realistic and practical deployment scenario.

  1. Obtain a SSL certificate from a source the device already trusts.

    For example, get a certificate for the specific IP or hostname of the device from a Certificate Authority like Verisign, Thawte or another major vendor. The device will trust this certificate and the management relationship can be established.

    This solution is not practical for most of the Enterprise deployments.

  2. The business has a self-signed Root certificate.

    The certificate needs to be imported before the enrollment can take place.

    Fortunately, Apple has foreseen this need and made it possible to include the certificates and MDM configuration into the same payload. Also, the enrollment happens in two steps:

    1. The certificates from the payload are imported and the Root will be trusted;

    2. The connection to the MDM server is made and the device becomes managed.

  3. The business has an intermediate certificate obtained from a major third party.

    The certificate is issued by an intermediate Certificate Authority. This certificate uses a chain of trust, which starts from the Root (already trusted by the device).

    The intermediary has to be included in the profile.

Creating security certificates

Note

This is a simple approach, suitable for testing purposes or a deployment that is not integrated with any existing public-key infrastructure (PKI).

  1. Generate a Root certificate

  2. Generate a Signing certificate

  3. Generate an SSL certificate

  4. Generate the trust chain containing certificates from steps 1 and 2

  5. Upload them in the GravityZone Console

  1. On a Linux OS machine with OpenSSL installed, in the same folder, create the bash scripts as root user:

    1. Open a new file with the name mentioned in the text editor and create the script file from the list below.

      e.g.: #vim createroot.sh

    2. Type :i to switch from view mode to edit mode.

    3. Copy the commands mentioned for each file into the editor.

    4. Save the file.

      e.g.: Type the :wq key sequence.

    The script names and content (must be run as root user):

    1. createroot.sh

      #!/bin/bash

      openssl req -newkey rsa:2048 -days 365 -x509 -keyout rootkey.pem -out root.cer -sha256 -subj "/C=XX/O=XX/CN=XX/"

      Note

      Replace the Country C=XX, the Organization O=XX and the Common Name CN=XX suitable for you.

      E.g.: "/C=RO/O=Bitdefender/CN=MDM Root/"

    2. createssl.sh

      #!/bin/bash

      openssl req -new -newkey rsa:2048 -keyout sslkey.pem -out ssl.csr -sha256 -subj "/CN=$1/" -batch

      openssl x509 -req -days 365 -sha256 -in ssl.csr -CA root.cer -CAkey rootkey.pem -CAcreateserial -CAserial root.serial -out ssl.cer -extfile <(printf "extendedKeyUsage = serverAuth \n subjectAltName=IP:$1")

      Note

      For subjectAltName, you can also use DNS or FQHN instead of IP.

      E.g.: subjectAltName=DNS:$1

    3. createcom.sh

      #!/bin/bash

      openssl req -new -newkey rsa:2048 -keyout comkey.pem -out com.csr -subj "/CN=$1/" -batch

      openssl x509 -req -days 365 -in com.csr -CA root.cer -CAkey rootkey.pem -CAcreateserial -CAserial root.serial -sha256 -out com.cer

    4. createincident.sh

      #!/bin/bash

      openssl req -new -newkey rsa:2048 -keyout incidentkey.pem -out incident.csr -subj "/CN=$1/" -batch

      openssl x509 -req -days 365 -in incident.csr -CA root.cer -CAkey rootkey.pem -CAcreateserial -CAserial root.serial -sha256 -out incident.cer

    5. createsvacom.sh

      #!/bin/bash

      openssl req -new -newkey rsa:2048 -keyout svacomkey.pem -out svacom.csr -subj "/CN=$1/" -batch

      openssl x509 -req -days 365 -in svacom.csr -CA root.cer -CAkey rootkey.pem -CAcreateserial -CAserial root.serial -sha256 -out svacom.cer

    6. createsgn.sh

      #!/bin/bash

      openssl req -out sgn.csr -new -newkey rsa:2048 -keyout sgnkey.pem -subj "/C=XX/O=XX/CN=XX/" -batch

      openssl x509 -req -days 365 -in sgn.csr -CA root.cer -CAkey rootkey.pem -CAcreateserial -CAserial root.serial -sha256 -out sgn.cer -extfile noCA.cnf -extfile <(printf "extendedKeyUsage = serverAuth \n subjectAltName=IP:$1")

      rm sgn.csr

      Note

      • For subjectAltName, you can also use DNS or FQHN instead of IP.

        E.g.: subjectAltName=DNS:$1

      • Replace the Country C=XX, the Organization O=XX and the Common Name CN=XX suitable for you.

        E.g.: "/C=RO/O=Bitdefender/CN=MDM Signing Certificate/"

    7. createchain.sh

      #!/bin/bash

      cat root.cer sgn.cer >chain.pem

    8. noCA.cnf

      basicConstraints=CA:false

  2. Generate the certificates with the use of the previously created scripts.

    In bash shell, run the scripts as root user in the following order:

    1. The Root certificate

      #chmod +x createroot.sh

      #./createroot.sh

      Remember the password protecting the private key.

      Result files: root.cer, rootkey.pem.

    2. Control Center Security Certificate

      #chmod +x createssl.sh

      #./createssl.sh IP|FQHN

      Provide either the IP or the Fully Qualified Host Name depending on the configuration of the server.

      As always, remember the password.

      Result files: the SSL certificate - ssl.cer, the private key - sslkey.pem.

  3. Upload the corresponding files into Control Center.

    The upload procedure is explained in Certificates.

Important

When using a CA-signed certificate for the Incidents server, make sure the appliance hostname is properly configured. Otherwise, the certificate may not be propagated correctly.

For instructions on configuring the hostname, refer to: Configure hostname settings.

In this section: