Cavirin Platform User Guide - (Version 1.1)

Follow

The Cavirin Platform User Guide introduces how to use the Platform to assess security. For those who are new to the Cavirin Platform, this guide first provides a conceptual understanding of the Cavirin solution (Part I) and then familiarizes the reader with the Platform's user interface (Part II). The conceptual understanding and UI familiarity prepare the reader for the detailed descriptions in the Cavirin Platform Operations Guide and for deriving the greatest benefit from the Cavirin solution.

For the introductory "Cavirin Platform Concepts," the reader does not need access to the Platform. This second part of the guide is a walkthrough of live product use, so the reader would gain the most meaning from it by having access to the Platform. To recap:

  • "Part I: Cavirin Platform Concepts" introduces at a high level the purpose of the product and how it accomplishes that purpose.
  • "Part II: Getting Started on the Cavirin Platform" introduces how a system administrator (just "admin" from now on) or security analyst configures the system, configures and initiates an assessment of security issues, and uses the results. More than a tour of the Cavirin dashboard and other screens, the Part II describes in a general way how to accomplish tasks introduced in Part I. This section completes the goal of "getting started."

Together, these two parts of the Cavirin Platform User Guide provide the requisite understanding to start using the platform at a basic level and to understand the detailed product information in the Cavirin Platform Operations Guide (planned).

NOTE:  The word ‘platform’ does not mean a physical appliance. The Cavirin solution can run on bare metal, under the control of a hypervisor, or within a container that is on-premises or in the cloud. The Cavirin solution runs on top of Ubuntu 14.04.

Other Platform documents are:

Table of Contents

 

Part I: Cavirin Platform Concepts   4

Cavirin's Assessment of Security Weakness and Suggested Remediation  5

Key Capabilities  5

Cavirin's Libraries of Security and Regulatory Benchmarks  7

Policy Benchmarks and Frameworks  8

Workflow for Security Assessment 10

Risk Signaling and APIs  16

Analytics  19

Part II - Getting Started on the Cavirin Platform   20

Network Parameters  20

Top-level Screens and Functional Areas  20

Dashboard  20

Infrastructure  21

Policy Packs  21

Reports  21

Risk Signaling Engine  22

First-time Login  23

The Administrative Management Tasks  26

Installing the Platform License in the License Information Screen  27

The Discover and Test Wizards  28

Using the Dashboard  29

Notifications  29

Date Range for Compliance Summary in the Dashboard  30

Creating and Applying Templates for Displays in the Compliance Summary  31

Compliance Summary  32

Results Details  33

Infrastructure: for Discovering Resources and Assessing Security and Compliance Risk  38

Introduction to Discover Resources & Assess Security, Risk, & Compliance  39

Introduction to User Credentials, Resource Credentials, and Docker Credentials  40

How to Add a Cloud Account 40

First-time Discovering and Assessing Resources in the Whole Environment 43

Select Policy Packs  51

Schedule Tests  51

All Resources  53

My Groups  55

Policy Packs  58

Looking into a Policy Pack, Control Group, Policy, and Remediation  58

Policy Pack Profiles and Editable Policies  61

Reports for the Assessments  63

The All Reports Screen  63

Showing a Report in a Browser and Drilling Down to a Specific Asset and Policy  64

Risk Signaling Engine  71

Configuring Alert Rules  71

Integrating the Platform with Third-party Incident Alerting Services  74


 

 

Part I - Cavirin Platform Concepts

This is the first of two main parts in the Cavirin Platform Getting Started. It starts with definitions of the most basic terminology in all of Cavirin's Platform documentation.

The basic Platform terminology follows:

  • Policy framework is an umbrella term that refers to all the benchmarks, the policies in all the policy packs, and the other mechanisms that support Cavirin's mission of securing assets and resources through security awareness.
  • Policy packs are collections of individual security policies established by a wide range of standards organizations, such as the National Institute of Standards and Technology (NIST). A policy pack provides a security baseline. Multiple policy packs can be applied in an assessment of a group of assets.  Furthermore, the policy pack can be applied in an assessment for all operating systems or a specific operation system. Selecting one OS to test usually results in a subset of policies to be applied.
  • Group is a user-specified, logical collection of assets or resources that an admin can create and target for an assessment.
  • Control families: a policy pack has sets of policies called control families. A control family is a logical and purposeful association of individual policies. Examples of control families are Access Control (AC) and Configuration Management (CM). Each control family can contain many children, children of children, and individual policies.
  • control is part of the policy pack hierarchy, as is in the following example for NIST: Control family → Control → Detailed control → Policy/Rule. In the Platform taxonomy, hierarchy is simply this relationship: control family → policy (or rule).
  • Security benchmarks applied by Cavirin are from the Center for Internet Security (CIS) and the Defense Information Systems Agency (DISA). Cavirin uses current best practices to create new benchmarks where they do not yet exist. Cavirin Engineering has contributed to multiple benchmarks from CIS and continues to author new benchmarks for OSs, clouds, and frameworks.
  • Resource discovery examines an organization's entire on-prem or cloud network and individual resources (servers, containers, operating systems, and so on). For a cloud environment, the choices of policy packs to apply determines how deep into the cloud the Platform discovery reaches.
  • Severity refers to the seriousness or danger of a security issue or weakness. Severity can be high, medium, and low. In the Cavirin Platform, severity provides to the security analyst, response team, CISO, or admin, the priority-order for remediation.
  • Compliance score results from the following calculation: 100 x weighted average of rule weights.  Most new or potential customers of Cavirin initially have a score of no more than 50 - 60, which should be cause for serious concern.
  • Agentless means that the platform does not use agents for discovery or analysis. The agentless architecture means lighter overhead and less attack surface.
  • Workload is an instance of an OS or a virtual machine.

Other Platform documents are:

Cavirin's Assessment of Security Weakness and Suggested Remediation

To counteract the 10-fold increase in attack surface that has come with the migration of computing and data storage to the cloud and the use of containers, the Cavirin Platform:

  • Scales along with an expanding or contracting cloud to identify and eliminate blind spots that can develop with volatile cloud scaling up or down
  • Supports on-prem deployments; Docker™ containers; cloud platforms (AWS in the current release)
  • Supports up to a million or more workloads (OS instances or VMs) across complex IT infrastructures

The Cavirin Platform collects diverse security information, organizes the information into an easily understood presentation, and proposes a mitigation for each type of weakness. The Platform's assessments can be scheduled or manually initiated. Assessments can provide on-demand, audit-ready reports. A Cavirin installation can run on the customer's premises (on-prem for short) or in a cloud hosted by Amazon Web Services (AWS).

Cavirin's coverage can be viewed in three categories:

  • Discovery
  • OS image and cloud hardening
  • Reporting

Key Capabilities

This section introduces the Cavirin Platform's capabilities at a high level. A summary of the capabilities follows:

  • The Cavirin Platform itself is agnostic in relation to an organization's operating systems, containers, and deployment model, and, therefore, provides a unified view across deployment models. For example, the Platform can assess a hybrid on-prem and cloud deployment as one target.
  • Unified risk assessment is enabled by Cavirin's unified view. With unified assessment, Cavirin can offer remediation guidance without conflict between security standards and deployment models. For example, with a PCI ecosystem that exists both on-prem and in the cloud, the Platform can group together both domains to generate a single assessment.
  • Being agnostic gives the Cavirin solution great flexibility in testing and remediation.
  • The Platform matches the scale of cloud deployments and their operational speeds.
  • The Platform offers compliance guidance for on-prem and cloud deployments.

Agentless Operation

The agentless architecture enables operational flexibility across all deployment models (on-prem, cloud, and hybrid) and makes installation easier. The absence of agents means the Platform does not introduce attack vectors by way of agents. Also, there is no need to weigh the impact of agents on performance, nor are there agents to manage, update, or debug. In a large data center or cloud deployment, agents represent a significant footprint because they must be installed on thousands of nodes. The agentless architecture applies to containers, eliminating the need to deploy potentially thousands of ‘sensors’ or ‘probes’ that are burdensome to track due to the speed of container creation and destruction.

Cloud Agnostic

The system is cloud-agnostic, as the figure below illustrates. (In the current release, AWS is supported.)

To test the security of a cloud, the admin targets the cloud with the Cloud Policy Pack that has the specific guidelines for the organization's sector (HIPAA, PCI, or other). The policy pack automatically recognizes the type of cloud and runs the right compliance tests for that type of cloud.  First, the Cavirin Platform recognizes the underlying cloud and runs an OCI assessment on the management console. Next, the Platform discovers the running instances in the cloud and recognizes all the operating systems in the cloud. Finally, it applies the correct version of PCI to each instance of the OSs. The OS can be a specific OS or all OSs that discovery identifies.

 

Container Agnostic

The system supports Docker in the current release (more environments are inevitable):

The Platform can assess an image from any public or private registry. The assessment can be scheduled, or it can be orchestrated through a RESTful API as part of the CI/CD process.

For Docker, Cavirin tests images (containers at rest), but not containers in the current release, against the patches and vulnerabilities specific to Docker. (Containers are stored on disk or in a registry. Container means an image that the Docker engine has loaded in memory and is in the running state.)

Device and OS Agnostic

The way to target a policy pack is by specifying any one of the following:

  • The cloud account
  • The container image
  • An IP address range (on-prem only)

Cavirin discovers the operating systems within the target and automatically applies the right benchmark versions. For example, multiple operating systems might be running on subnet 10.10.10.0/24, so an assessment might target that address range for policy pack NIST 800-53r4, as the figure below illustrates. The Platform applies the right benchmarks to each node.

 

Cavirin's Libraries of Security and Regulatory Benchmarks

Cavirin maintains a very extensive set of security and regulatory benchmarks and regularly adds to them (about every two weeks). A benefit of having extensive libraries is that organizations do not have to look at multiple vendors to cover different parts of their infrastructure.

Scalability

Platform operation can scale to the largest cloud deployments by relying on a microservices architecture that performs linearly as more cloud resources become active. The Platform's elastic nature permits it to scale up and down on-demand as a customer’s workload scales, permitting it to track the customer’s actual cloud utilization. For example, as the number of instances to discover grows, the Platform spins up additional discovery processes, based on the added IP address ranges. The Cavirin OS-agnostic solution needs only one asset discovery phase to identify all the operating systems on all servers. Subsequently, the policies are applied to all nodes in parallel. Subsequently, the admin can do a rediscover to find what has changed.

Speed and Security

Speed and security factors:

  • Being agentless and OS-agnostic, the Platform delivers very fast times to baseline and analysis times that are independent of the number of policies it applies.
  • Admins quickly learn the security posture after a change in their environment because the Platform spins up and shuts down its assessment resources in parallel with the elasticity of the cloud and container deployments.
  • Cavirin’s deployment flexibility matches the security needs of any type of customer. (When an on-prem operation migrates to the cloud--whatever the security platform is--it must maintain the enterprise’s security approach and keep the inside-the-firewall approach.)

Policy Benchmarks and Frameworks

An easy way to understand the Cavirin solution is through its policy frameworks. Cavirin's comprehensive, dynamically curated policy packs help security-conscious IT organizations to stay current in infrastructure/application risk assessments for multiple security benchmarks, such as CIS and DISA (Defense Information Systems Agency), and for vertical regulatory standards, such as PCI and HIPAA.

More specifically, a policy pack can contain anywhere from a handful to hundreds of individual policies (or rules). Example control families in the NIST 800 53r4 policy pack are Access Control (AC), Contingency Planning (CP), and Configuration Management (CM). Within each control family, individual policy names are identified. For example, when the NIST policy pack is applied to all operating systems, the NIST policy pack has the control family Access Control (AC). AC is further divided into sets of policies such as Account Management (which has many individual policies), Access Enforcement (which has many individual policies), and so on.

The Cavirin security team evaluates published benchmarks, selects the control families that are relevant, and adds them to a policy pack. In some cases, policies map to the best practices of a specific cloud provider, resulting in combined names such as ‘CIS AWS’ or ‘CIS Docker.’ 

When creating an assessment for servers, an admin can specify the security objectives and select the type of business and data center.

The figure below illustrates the relationship of policy packs to the supported OSs in the current release of the Platform. To start an assessment, Cavirin's abstraction engine needs one or more policy packs to be selected. The figure illustrates a policy pack named NIST 800 53r4. The Platform subsequently tests the policies and controls against the OS targets that are present, as the figure below suggests.

NOTE: The current release does not support the following: SSAE 16, FedRAMP, CIS CSC, Azure, ESXi, Google Cloud Platform, MySQL, and fedora.

 

 

List of Cavirin Policy Packs

The figure below illustrates a partial list of the policy packs.

 

 

Workflow for Security Assessment

Most goals of Cavirin's security assessment can be reached by two paths. This User Guide focuses on the beginning path, in a screen called Discover Resources & Assess Risk, Security, and Compliance in the current release. This screen presents a series of wizards that guides the admin through the following tasks:

  • Setting up and starting resource discovery in an organization's computing environment (for all resources, initially)
  • Selecting policies to apply during in an assessment
  • Scheduling the assessment, immediately or later

After the assessment, an admin examines the results and considers the remediation that Cavirin recommends for each issue.

The next figure shows that the UI presents three wizards; it's not what the admin actually sees--the wizards appear in sequence, not in parallel.  

Discovery of Resources

Discovery is the first task in Discover Resources & Assess Risk, Security, and Compliance. To discover resources, the admin starts the Discover Resources wizard by providing some essential information, such as where the target resides: in a cloud, on-prem, in a Docker image.

NOTE: If the computing environment is in a cloud, the cloud account information must first be specified in the Cloud Management area. A description of how to add a cloud account is in Phase II of this User Guide, 'Getting Started on the Cavirin Platform.'

The Platform identifies the assets by using the following criteria:

  • For on-prem data centers, starting and ending IP addresses
  • For AWS:
    • IAM Role
    • Amazon Resource Name (ARN)
    • Secret key and access key
  • For Docker:
    • The image name if the repository is in the Docker hub
    • A fully qualified URI for a repository in a cloud and a tag for a specific image in that repository (AWS cloud in the current release)

The Cavirin Platform discovers an organization’s resources as the first part of an assessment. The admin has options for discovering the resources but not testing them, or subsequently, the admin can assess the resources on-demand or set up schedules for assessments. An organization should frequently run assessments because an enterprise’s security posture can drift from a known baseline in minutes.

Segmented Logical Groups

For targeting assets in diverse deployment modes, the Platform supports the creation of logical groups through adaptive segmentation. Adaptive segmentation is the micro-segmentation of assets through cloud-native mechanisms for grouping the resources. The Platform then applies security benchmark tests on the workloads in each segment. For example, an enterprise might have PCI servers in an on-prem data center and in an AWS cloud, and the admin wants a single, normalized view of the servers' compliance configuration. An admin-configured group spans these different environments, and the admin manages the group as if it were in a single location.

The Platform offers a simple approach for moving resources across adaptive groups and aligns with the DevOps “pet vs cattle” cloud model.

Selecting the Policy Packs

The second step is to identify one or more policy packs the Platform uses to assess the resources. As previously noted, the system assesses all assets, regardless of OS, (the application of the policy packs is OS-agnostic). To gain deeper insight into a policy pack, the admin can drill down into the individual control families but, in the current release, can only view the control family.

 

 

Applying Policy Packs and Testing for Vulnerabilities

After the resources are discovered and the policy packs selected, the admin initiates the assessment of the server configurations and other targeted resources against the benchmarks. After an assessment:

  • A color-coded severity count and pass/fail count is recorded and displayed in the Dashboard (see next figure).
  • A report is automatically generated for this assessment (see next section, "Reporting").

The Dashboard visualizes the assessment results, highlighting the security and compliance posture of the infrastructure, including the trends over user-specified time periods.

The next figure depicts the Dashboard. It summarizes:

  • The overall security posture, over a selectable time period and for different severities. See the area marked (1).
  • A real-time compliance score for the environment in (2) and breaks down results to numbers of policy checks that passed and the failed checks by severity (high, medium, and low).
  • User-selected details for the results (3), in the lower part of next figure and in subsequent figures.

 

 

The dashboard supports detailed, user-selected views that offer more insight into the results of an assessment. In the preceding figure (3) and next figure, the RESULTS DETAILS dropdown is visible. Each choice in this dropdown begins with the words "Show me . . . " and is followed by a type of information. For example, the option "Show me overall compliance for my infrastructure" opens a comprehensive, dynamic sunburst representation of the whole infrastructure. The next few figures illustrate a few of the options that RESULTS DETAILS can display. These figures show the most security violations, compliance by OS, and compliance state by severity level.

 

 

 

 

 

 

Reporting

This section introduces the reporting that automatically follows an assessment. The admin examines the details of the assessment, including the specific resources that failed a policy test, and then sees Cavirin's recommended remediation. Based on the identified gaps, a security engineer, security analyst, or the chief security officer (CISO) can prioritize the compliance failures for the admin to apply remediation(s).

A report facilitates:

  • OS hardening
  • Identification of gaps in the application of recommended security or regulatory benchmarks (the policy violations)
  • Remediation (closing the gaps)

When the Reports icon in the navigation pane, the default display All Reports shows all existing reports. Two courses of action are available for an existing report. The admin or security team member can:

  • Click the name of the existing report to open it in HTML, as illustrated in the next figure. From here, the admin can export the report to PDF or a spreadsheet, share it, or archive it. At the bottom of this screen, the admin, security analyst, response team, or CISO can drill deeply into the details.
  • Mark the checkbox next to the report name (not shown) to display the following actions for an admin to choose:
    • Generate the report (to a PDF or Excel spreadsheet, same option as in the HTML presentation)
    • Repeat the assessment to generate up-to-the minute data of the security posture
    • Delete the report

Although an assessment can use multiple policy packs, each report for an assessment can focus on only one policy pack at a time. If the assessment included multiple policy packs, the admin produces a report for each policy pack as needed. The figure shows:

  •  In the upper-left corner of the figure below, the admin has selected the report for the CISPP policy pack.
  • The current compliance score (44), so the state is alert.
  • Half-way down the screen, the control families in the assessments; the numbers of passes and failures; and the severities for each control family. The drilldown lists the issues within individual control families ("Issues Count per Control Family"). Control families are categories of similar policies within a policy pack. For CISPP, some example control families are Access Authentication and Authorization, Initial Setup, and Local Policies, and each of these has many individual policies.
  • The number of resources tested, which is the next stage of drilldown (bottom of the figure): The bottom of the window lists resources (although this figure shows only one of the five resources, ip-172.31.18.17), and that this report includes all of the operating systems against which the CISPP policy was run. Part II of this Guide provides more details about drilldown.

 

 

Risk Signaling and APIs

The Platform can function as a central dashboard for an enterprise’s security compliance posture. It can take inputs from endpoint protectors (such as MobileIron), management apps (including CyberArk), and logs (including Splunk SIEM), and then send alerts to Slack, PagerDuty, or ServiceNow. Integrating a new application is a simple process of developing to the published APIs, and Cavirin can supply a set of popular pre-integrations. Cavirin’s RESTful APIs support the Platform integration with customers' applications and platforms.

The Risk Signaling Engine (RSE) lets the Platform send notifications of risk to the designated recipients. It sends the notifications through APIs to the application selected for this purpose (Slack, ServiceNow, or PagerDuty).

 

 

The next figure shows a fictional assortment of alerts in the default All Alerts screen for RSE. When an admin selects an alert, the options to Edit, Delete, or Integrate the alert (with optional notification service) appear.

 

 

 

The next figure shows when no integration exists. To add a new integration, the admin clicks Add Integration in the upper-right corner.

 

The next figure shows the window with instructions for adding a PagerDuty integration.

 

 

Analytics

Cavirin’s analytics capabilities fall into one of the following categories:

  • Detective and retrospective analytics
  • Predictive and preventative analytics

Detective and Retrospective Analytics

The Platform gathers critical security configuration data across hybrid infrastructures and can analyze this data for historical trends. For example, security personnel or an admin might want to know if a security posture is improving over time. Subsequently, the admin might want to dissect this data into multiple dimensions, such as cloud, datacenter, or by technology or OS, to identify important trends. The historical trend provides a basis for understanding the events that have increased or decreased the security weaknesses.

These capabilities are presented in a conversational interface that permits the admin to raise questions about:

  • The top few configurations that have always been troublesome over time
  • Events that resulted in reduction of risk score (or, to put it conversely, an increase in compliance score)
  • Techniques of remediation that brought the greatest security improvement

 

 

Part II - Getting Started on the Cavirin Platform

This is the second major part of the Cavirin Platform User Guide. To benefit the most from the hands-on nature of this workflow, the reader ideally has access to a Cavirin Platform. The framework of this section is based on the tasks an admin performs in the five major screens of the Platform.

Before describing the Platform interface, this section describes networking parameters that must be in place for the Platform VM. For background, the reader should have already prepared with conceptual understanding from Part I. As needed, the reader can refer back to Part I.

This part of the Cavirin Platform User Guide introduces product usage; its starting point is right after the product has been installed and when the admin is about to log into the Platform for the first time. To help the reader stay oriented and refresh the understanding from Part I, "Cavirin Platform Concepts,' a brief description of the functions in each of the top-level screens follows after "Networking Parameters."

Network Parameters

This section describes networking parameters that are necessary for the Platform to communicate with an organization's environment to assess. Open TCP ports and OS-dependent services are necessary for giving access to the Platform. These networking parameters are listed below but not configured on the Platform. They must be configured before the admin performs the tasks described in the "Discover Resources & Assess Risk, Security, and Compliance" section. Some differences exist between the Linux and Windows networking parameters:

Windows

  • Windows Remote Management (WinRM) should be enabled and running. By default, WinRM is installed but not running.
  • WinRM is on port 5985. WMI uses port 135. Windows uses ports 5985 and 135 for remote desktop and ICMP for pings. 
  • Windows should have administrator privileges, so the Cavirin admin should have WMI privileges.

Linux

  • Linux uses SSH and must have access through port 22 and also support ICMP for pings.
  • The user's credentials should include root privileges, and the user should be enabled for passwordless sudo.

Top-level Screens and Functional Areas

Regardless of the top screen or any other screen in the UI, two areas of control are always visible:

  • The blue bar at the top of all windows is for administrative actions. In this dropdown, the following functions are available:
    • Cloud Management, for viewing, adding, or modifying cloud accounts for AWS (in the current release). If customer resources are in a cloud, the admin must add a cloud account and credentials in this area before discovering the resources. 
    • User Management, for viewing, creating, suspending, or deleting user accounts.
    • Feedback and Support is a link to the Cavirin support portal. It contains resources such as important notifications, a form for submitting a request or question, hotfixes, a FAQ, directions for uploading support logs, and so on. A product guide and release notes are not in the current release.
    • API documentation.
  • The navigation pane at left is for selecting one of the main functional areas or to log out.

Dashboard

The (default) dashboard screen presents general information about the state of an organization's security posture:

  • Summarizes the current security posture, based on the most recent assessment. The display filters let the admin specify time, OS, and policy packs and their control families. The often-used display choices can be saved as dashboard display templates so that the admin does not need to re-specify the filters over and over.
  • Indicates trends from a high-level view by showing the security posture during selectable windows of time.
  • Provides meaningful ways to view the security posture (but not with the granularity of a report). Some of the suggested viewpoints are:
    • Where devices are contributing to the most security violations
    • Where specific devices are failing specific policies
    • Violations with the greatest impact on IT infrastructure
    • Where to focus to improve compliance
    • Where and how compliance is improving

Infrastructure

The Infrastructure screen is where the admin configures and initiates assessments of the resources. Two pathways exist to the tasks of configuring and initiating assessments: the Discover & Assess wizards or the discrete configuration of individual aspects of the assessment. The Discover & Assess wizards support configurations that must be done for the first-time discovery and are unique to Discover & Assess. Subsequently, most Discover & Assess actions be performed outside the wizards, in the pages for All Resources, My Groups, Resource Credentials, and Schedule and Notification.

The Infrastructure screen also:

  • Lists details about all the resources the Platform has discovered
  • Allows an admin to add or remove container images from an assessment
  • Allows an admin to create and uncreate logical groups of resources for the purpose of assessing security weakness
  • Allows an admin to add, edit, or delete resource credentials that the Platform needs for communicating with assets
  • Allows an admin to schedule the tests and configure the way notifications go to interested parties

Policy Packs

The Policy Packs screen contains information for all the policy packs, their thousands of policies, and the recommended remediation for each failed policy test. Users can look at policies and remediation by drilling down through a policy in Policy Packs or, when the Platform shows an asset failed a test, more quickly find the remediation by drilling into a report when a browser displays it in HTML. Put another way, a user cannot act upon a policy pack in the Policy Pack screen.

NOTE: To apply a policy pack for an assessment, the admin uses the Infrastructure screen, where the admin has two ways to initiate an assessment. He or she can select a group and policy packs in My Groups for an assessment or use the Discover & Assess wizards. In the second of these wizards, Select Policy Packs, the admin can specify policy packs for the assessment.

The Policy Pack screen provides the following:

  • A visual representation of how policy packs relate to control families and individual policies or rules.
  • A display of all the policy packs, their control families, and the individual policies or rules, so the admin can see the details of individual policies and remediation steps for non-compliance.

Reports

A report is auto-generated at the end of an assessment. The Reports screen gives options for exporting the reports in PDF or Excel, viewing it in HTML, and emailing the report. When viewing in HTML, the user can drill into resources to see the details of policies and remediation of compliance failures.

The default page lists all reports for all policy packs and user-defined logical groups. For each report listed in the default page, the meta data consists of:

  • Report name (a name that is based on user-specified templates of scheduled reports or default of no template ("resourcename-Test")
  • Date of most recent test
  • Test status (completed or not)
  • Policy packs
  • Group
  • Risk score

Risk Signaling Engine

Risk Signaling Engine (RSE) supports the transmission of alerts that can be delivered by email or through an integrated notification application, such as Slack, ServiceNow, JIRA, or PagerDuty. Email notification does not involve an integration.

An alert consists of the following information:

  • Name of the alert
  • Date of the alert
  • A (brief) description
  • A detailed rationale, which provides reasons for the alert
  • Groups to which this alert
  • Integrations – the third-party tools that carry the alerts to designated recipients (no need to integrate email)
  • State (enabled/disabled)
 

First-time Login

This section describes what an admin sees the first time he or she logs into a new Platform installation. The information here is limited to the login screen, password reset, the welcome screen, and a mockup of the Dashboard.

An example of a regular login screen appears as follows:

 

 

After the admin enters the default login credentials, a popup opens and requires a password change. Subsequently, the Welcome screen opens (see next figure).

The three areas in the center of the Welcome screen are Discover Resources, Select Policy Packs, and Schedule Tests; these are not actionable and contain only basic information about these three major areas of Platform functionality. Below the Discover Resources text is a link for Resources. Clicking this link pops up a list of pre-requisite information the admin needs for subsequent specification steps. (Popup is illustrated in the subsequent figure.)

Two live options take the admin to the next part of product use:

  • Clicking skip (lower-right) takes the admin to a mockup of the Dashboard.
  • Clicking Get Started opens a facility called Discover Resources & Assess for Risk, Security, and Compliance. This facility is a series of wizards that lead the admin through the three functional areas already mentioned. The wizards in Discover Resources & Assess for Risk, Security, and Compliance are Discover Resources, Select Policy Packs, and Schedule Tests. Access to the Discover Resources & Assess for Risk, Security, and Compliance option is available in the Infrastructure during regular operation and also in the Dashboard mockup (see also the subsequent section, "Infrastructure, for Discovering Resources and Assessing Compliance"). 

NOTE: If an organization is using a cloud service, the admin must add a cloud account before using the wizards in the Discover Resources & Assess Risk, Security, and Compliance screen. A description of how to add a cloud account is a later section called 'How to Add a Cloud Account.'

 

 

The popup pictured below appears after a user clicks the "Resource Credentials" link (see figure above). This popup has a list of internal credentials (not what an admin uses for logging into the Platform). The Platform provides internal credentials when it requests a connection with a networked resource and that resource requires Platform credentials before it allows the connection. (Details about resource credentials appear in the later section called "The Credentials.")

  • Credential Type refers to Microsoft Administrator or Linux.
  • Usage is global or restricted, where global means the credentials can be applied to any resource, and restricted means credentials are offered to the devices (resources) in a user-selected group.
  • Username is an internal name that the Platform offers to a resource in an organizations resources.
  • Password or PEM-key is the choice the admin specifies for the second part of the (internal) credentials.

 

 

The next figure shows the mockup of the Dashboard (but only a small portion of the Dashboard). Also, it repeats some information from the preceding Welcome screen and shows another skip button. Three actions are available in this mockup:

  • Clicking the dropdown for "Notification" in the administrative area in the upper-right corner and selecting "Account Management" if the customer is using a cloud service provider (CSP): cloud accounts must be added in this area before the assets can be discovered in Discover & Assess. The descriptions for adding an AWS cloud account are in How to Add a Cloud Account.
  • Clicking skip to go to the full Dashboard if the customer is using a cloud service provider (CSP): the admin must add cloud accounts in an Administrator area before starting Discover & Assess for assessing resources. (Note: upon first login to a new Platform install, the Dashboard shows no data to show in the Compliance Summary but does offer buttons in the navigation pane for opening the other top-level Cavirin components of Infrastructure, Policy Packs, and so on).
  • Clicking the Continue to Discover and Test button if customer wants to assess on-prem, cloud, or Docker (containerized) images: Discover & Assess presents a series of wizards for discovery, policy packs, and assessment. Some mandatory specifications can be made only in the Discover & Assess wizard called Discover Resources. For a description of how to proceed through the Discover and Test wizards, see the 'Discover Resources & Assess for Risk, Security, and Compliance' section.

 

The Administrative Management Tasks

This section introduces the tasks accessed through the Administrative dropdown, shown in the next figure. Some of the tasks are important to perform for first-time use of the Platform. For example, if the target environment is in the cloud, at least one cloud account must be added here before the admin can perform discovery on the organization's resources and computing assets.

 

 

  • Cloud Management opens the window for adding, editing, or deleting cloud accounts. This option is vital for starting the use of the Cavirin Platform on resources in a cloud. 
  • User Management is for displaying information about user accounts or creating, editing, or deleting user accounts.
  • License Information presents the mechanism for uploading a new license and shows current information about the license, as the section describes.
  • Application Settings is deactivated in the current release.
  • Feedback and Support opens a page at the Cavirin website with a variety of information sources and contact information for registered users. It also has a link for submitting requests.
  • API Documentation displays the necessary support for APIs. 

Installing the Platform License in the License Information Screen

When you first connect to the Cavirin server, it prompts you to upload the license key file in the License Information screen (accessed through the administrative management dropdown, as the next figure illustrates).

The License and Plans area shows information about the current license (for example, installation and expiration dates). The next figure illustrates the following steps:

  1. Click the Upload License Key button. A popup for browsing appears over the License and Plans area.
  2. Click Browse and browse to the file. Upon locating and selecting the file, click Open (on a Mac) or equivalent.
  3. Click Done in the License and Plans area.

The Discover and Test Wizards

So far, two opportunities to launch Discover Resources & Assess Risk, Security, and Compliance have been presented (one in the Dashboard mockup in Part I and one in the Infrastructure screen). The Discover & Assess wizards–after installing the Platform and logging into it–is good for discovering all resources and testing them against multiple policy packs. For many enterprises, however, regular use of the Cavirin Platform can naturally lead to somewhat more granular and diverse setups. Whether for more specific use of the Discover and Test wizards or for even more specific assessments, the Infrastructure screen is the location of this work. For an introduction to Infrastructure, see "Infrastructure: for Discovering Resources and Assessing Security, & Compliance Risk."

 

 

Using the Dashboard

This section focuses on the Dashboard. The next figure illustrates the upper part of the Dashboard. This section first describes how to use the Dashboard options for screen manipulation and filtering and then how to read the graphical representations of data. Descriptions start at the top of the screen.

 

Notifications

In the blue banner's administrative area at the top of nearly all screens, clicking the roster-icon drops down an informational list called Notifications, as the next figure shows. These items are expandable through up-down arrowheads (see 'View All').

The notifications consist of:

  • Under Latest Tests, the score and time stamp for the indicated group's assessment
  • Under Scheduled Tests, the scheduled time for tests according to a user-configured template in Infrastructure → Schedule and Notifications
  • Under Event Log, the status and time of entries in the Event Log
  • Under Updates, the number and date of the build 

 

 

Date Range for Compliance Summary in the Dashboard

All the data in the Compliance Summary display is bound by the From and To dates. See upper-left corner of the next figure. Regardless of other filters for time and scope, the Compliance Summary data is confined to the time between the From/To dates (inclusive).

NOTE: The From and To dates must be before today's date.

Although the total of collected data comes from the From/To time period, an admin can change the time scale (x-axis) of the display by choosing the DayWeekMonthQuarter, or Year in the drop-down list under "Compliance Summary." Consider the following scenario to understand the interaction of From/To dates and the choice of DayWeekMonthQuarter, or Year for the x-axis scale. If From/To is a two-month period, daily assessments have been performed, and the scale is Daily, the Compliance Summary area will show many bar graphs, and they will not fit in the default space, but in this case, the UI displays a slider so the admin can shift the display back and forth to, for example, look at the daily trends over the two-month period.

The next figure illustrates that, instead of all OSs, all Groups, all Policy Packs, and so on, just one OS, one Policy Pack, and so on have been selected for display in the Compliance Summary. (Note that the Control Family dropdown becomes active only after the admin selects a policy pack because the control families are specific to a Policy Pack.) The gear icon lets the admin toggle between a bar graph and stacked bar graph display of compliance data.

In addition to focusing the summary, these criteria can be saved as a display template (see upper-right corner of next figure). The next section, "Creating and Applying Templates for Compliance Summary Displays," describes the compliance display templates.

 

Creating and Applying Templates for Displays in the Compliance Summary

By default, an admin sees compliance assessments for all operating systems, resources groups, and policy packs. (Control families are included only when the admin selects a policy pack for display.) However, the admin can filter the compliance summary by any of these categories, for example, by one OS (Ubuntu 16.04), group (docker-host), and policy pack (Cavirin Docker Image).

So that an admin does not have to repeat the filter choices each time he or she wants these specifics, the Platform supports user-specified display templates. Thereafter, upon loading a template, the UI immediately displays the summary for only the categories in the template. Platform supports as many templates as the admin wants.

To create a template, the admin first selects the Compliance Summary filters to show what he or she wants in the template. When the Compliance Summary is showing the desired filter criteria, the admin clicks the roster-with-checkmark icon (upper-right corner in preceding figure) to get the following popup, which shows that a meaningful name and optional description have been typed. When ready, the admin clicks Save. In this example, the Trial Docker Ubuntu 16.04 template exists and can be applied whenever needed.

 

 

Subsequently, to apply the template to the display, the admin displays the Load Template popup by clicking the roster-with-redraw icon. See next figure. After clicking the blue icon for a template, as the next figure illustrates, the admin clicks the Load button. The Compliance Summary is immediately reloaded with the specified selections. (The red icon is for deleting a template.)

 

 

Compliance Summary

The Compliance Summary occupies the upper part of the Dashboard. The example below shows the use of two of the display filters, for a policy pack and one of its control families. In this example, the policy pack is CIS, and the control family is Advanced Audit Policy Configuration.

 

 

 

Current Score

The current score is the most recent scoring of compliance (or security for a CIS pack), so the higher the number, the better.  Calculation of the current score is as follows:

100 x weighted average of rule weights

The Current Score area also shows a percent change since the last scale-value – day, week, month, and do on.

Number of Tests

The Number of Tests area breaks down the assessment results for the number of policies that passed and the failed policies. The impact or seriousness of a failed policy is low, medium, or high. Therefore, looking at the severity along with the number of failures is important. In this part of the Dashboard, only summaries are displayed. The details, meaning, significance, and remediation advice become available through drilldown into different parts of the Cavirin Platform, starting with the Dashboard area called Results Details (next section). (The Reports screen also lets the admin drill down into the assessment and export an executive-level report in PDF or a detailed report in an Excel spreadsheet.) 

Results Details

This section introduces each category in the Results Details at the bottom of the Dashboard. Each category is a view with greater detail and insight into the content of the summaries. 

The Results Details takes the admin to the next level of detail available in the Dashboard. This information can to lead to even more precise isolation of non-compliant components in the environment. The next figure shows the dropdown and the default selection, "Show me where the devices are contributing the most security violations."

The sections that follow introduce each category in the dropdown.

Where Are the Most Security Violations?

Starting with the default choice in Results Details ("Show me where devices are contributing to the most violations"), a look at each of the three pie charts described in this section and the tabular list of results (subsequent figures) help the admin prioritize the needs for investigation and remediation.

Note: The shaded table over the pie chart lists the top offenders.

The figure below is the first pie chart is "By Policy Pack." The policy pack with the highest number of failures is Patches_And_Vulnerabilities. The number of failures is 196, and the color this policy pack is blue. The next category (and subsequent figure) shows assessment results for the control families.


The control family identified within the Patches_And_Vulnerabilities policy pack is for Ubuntu 14.04. Right away, this indicates the resource that needs attention, Ubuntu 14.04. The numbers here show high severity fails, but a filter also lets the admin select low/medium/high severity.

 


 


At the bottom of "Show me where devices are contributing to the most violations" are colored icons for High Severity, Medium Severity, and Low Severity. Clicking a severity icon opens a table with details about that severity. For the next figure, the admin clicked on the Medium Severity icon. The following figure shows the details.

 

The admin clicks the Select Action dropdown and chooses what happens next. In this case, the choice is notification through PagerDuty. For this choice to be available (and link active), PagerDuty must have already been integrated in the Risk Signaling Engine (RSE) area. 

 

 

Compliance State by Severity

"Show me my compliance state by severity level." Each row-entry illustrates the following: one policy pack, the number of failures (violations) for each control family in the policy pack, and the numbers for each severity for each control family. Each entry also has a table of numbers of passed and failed tests for each control family. The Results Details entry can show every policy pack in the assessment.

 



Security Risk Across All Operating Systems

This selection from Results Display shows all tested operating systems, but this section continues the focus on Ubuntu 14.04. The display in this case is showing the total number of failed policies for Ubuntu 14.04, not just those related to the control family Ubuntu 14.04 Patches and Vulnerabilities. The total number of Ubuntu issues (17234, below) in this case is higher (13488) than for the one control family (preceding figure).

 

 

Show Risk Exposure for Devices that Failed a Specific Policy

Upon selecting "Show me where I have a risk exposure (devices failed X policy)," the admin sees a map illustrated in the figure below. This map can be very large, so a very narrow portion is illustrated. The focus begins with a policy pack. Following one strand of connections in this map, this portion shows:

  • One policy pack is the European Union's General Data Protection Regulation (GDPR).
  • The highlighted control family is Personal Data Transfer Security.
  • The failed policy is "Ensure 'Network Security Allow: PKU2U authentication requests to this computer to use online identities' is set to 'Disabled'." (In other words, it is enabled.)
  • The IP address of the asset that failed this policy test is 52.14.131.10.

For more information, Cavirin provides different approaches:

  • To read details about just the policy that 52.14.131.10 failed and the remediation for this failure, the admin can go the Policy Packs screen and, through the GDPR description and the control family, locate the policy. This approach is described in the "Policy Packs" section.
  • To see important context in addition to the policy and remediation, the admin drills down through the report for the specific assessment date, OS, group, the severity of the issue (low, medium, or high), and so on. This approach is described in the "Reporting on the Assessments" section. 

 

 

 

Infrastructure: for Discovering Resources and Assessing Security and Compliance Risk

The main mission of the Cavirin Platform–discovering vulnerabilities by assessing security compliance–is set up, scheduled, and launched in the Infrastructure screen. The most complicated interactions an admin has with the Platform are in the Infrastructure area and its various screens.

The context of this section on Infrastructure is a new Platform installation, so no customer resources have been discovered, and not even the organization's computing deployment has been defined for the Platform. Here, the fundamentals of starting the use of the Platform are emphasized. (For detailed descriptions about the extensive use of the Platform, refer to the Cavirin Platform Operations Guide.)

First-time use of the Platform entails crucial set-up steps in a series of wizards in the Infrastructure's Discover & Assess screen. Subsequently, as an organization's computing environment changes, admins can return to Discover & Assess to accommodate changes and immediately (or later) initiate new resource discovery and assessment.

NOTE: Where the organization's computing environment is in a cloud, some vital prerequisite configuration is necessary in in Cloud Management–outside the Infrastructure area–and must be complete before the admin can do initial resource discovery on a cloud.

Another configuration described in this section is for the resource credentials that the Platform must offer to customer resources for those resources to authenticate the Platform. 

The topics in "Infrastructure: for Discovering Resources and Assessing Security and Compliance Risk" are:

  • Introduction to Discover & Assess
  • Adding cloud accounts as needed
  • Definition of resource credentials
  • Using the Discover & Assess wizards:
    • Discover Resources on-prem, in the cloud, or in a Docker image
    • Select Policy Packs
    • Schedule Tests
  • All Resources
  • My Groups
  • Credentials
  • Schedule and Notifications (templates)

The following figure shows the selections available to an admin upon selecting Infrastructure in the navigation pane.

 

  • If the organization's assets are in a cloud, at least one cloud account is necessary before the Platform can discover the organization's resources.
  • If resources are on-prem or in a Docker container, go to "The Credentials" section.

After adding one or more cloud accounts, the admin can specify resource credentials. The resource credentials are what the Platform must present to the organizations resources before it can assess those resources.

An admin specifies most of the required information–the resource details and configuration data–that feeds into a compliance assessment within the Infrastructure pages. Some necessary information also comes from other functional areas (other screens) of the Cavirin system.

Specify the organization's computing environment in the Discover Resources Wizard (the first of three wizards in Discover Resources & Assess Risk, Security, & Compliance). The choices are cloud, on-prem, and Docker image. If the environment is a cloud, a cloud account must be added in another screen before the Platform can discover the cloud resources. That screen is Add Cloud Account, and the description of how to add a cloud account is in the forthcoming 'How to Add a Cloud Account' section.

The Infrastructure screen supports two ways of setting up, scheduling, and launching a compliance assessment. The admin can select a way at the top of the Infrastructure screen:

  • The first-time resource discovery must use the Discover Resources & Assess Risk, Security, & Compliance screen that the admin opens by clicking the Discover & Assess button, at right in the figure below. It presents a series of wizards for specifying mandatory configuration details and eases the early performance of the tasks of discovering resources, selecting the policy packs to apply in the assessments, and scheduling the assessment.
  • All Resources, My Groups, Resource Credentials, and Schedule and Notifications support tasks for setting up and starting assessments.

 

 

Introduction to Discover Resources & Assess Security, Risk, & Compliance

The Discover Resources & Assess Risk, Security, and Compliance screen (or Discover & Assess for short, which is the label on the button) provides access to major Platform tasks, some of which are both mandatory and unique in the Discover Resources wizard.  Its use is essential for a new Platform installation and a convenience thereafter because: 

  • Some tasks are essential for a new install.
  • Some tasks are possible only in Discover Resources.

The figure below identifies the major functional areas at the top of the screen after the admin clicks the Discover & Assess button.

Except for the tasks that are possible only in Discover Resources, all the tasks are available in the rest of the Infrastructure screen but with greater granularity and flexibility than in the wizards. (After the Discover & Assess description, using the All Resources, Credentials, and Schedule and Notifications screen is described.)

 

The bulk of configuration activity in Discover Resources is for the admin to characterize the cloud, on-prem, or Docker image. At the end of Discover Resources, the admin can do one of the following:

  • Initiate discovery of the organization's resources
  • Proceed to selecting policy packs in preparation for assessing compliance in the organization's computing ecosystem

A short section follows to describe credentials and network settings. 

Introduction to User Credentials, Resource Credentials, and Docker Credentials

Setting up a Cavirin Platform and using it for assessments entail the use of different types of credentials:

  • User credentials (including administrator) are required for logging into the Platform. These credentials first come from Cavirin as defaults; the admin must change the password before using the system. Subsequently, user accounts can be added in the User Management screen that is accessed through the administrative area dropdown.
  • Resource credentials are credentials that the Platform must provide to each resource in the organization's computing environment before the Platform can start a compliance assessment. The resource that authenticates the Platform can be on-prem, in the cloud, or hybrid. The Platform must have credentials to offer when a resource requests them.

    NOTE: For first-time use of the Platform, resource credentials are initially configured in the Discover Resources wizard in the Discover Resources & Assess for Security Risk and Compliance feature. 

  • Cloud credentials from the Platform are required by AWS, but the screen for specifying them is in the Cloud Management part of the Discover Resources & Assess Risk, Security, and Compliance rather than the Infrastructure area. (In addition to the cloud's requiring credentials from the Platform, the customer's resources within the cloud also require the Platform's resource credentials.

Resource Credentials for Clouds and On-Prem Deployments

The Platform must present its own credentials to each resource it targets for a compliance assessment. These credentials are called resource credentials.

Resource credentials are what the Cavirin Platform presents to a resource it is attempting to assess; each resource authenticates the Cavirin Platform before it allows the SSH connection for the assessment.

Admins can configure multiple resource credentials for different assets and then select a credential set by name in the Discover Resources wizard before discovering or assessing resources. For example, IT can specify different credentials for different areas (for example, special PCI credentials.); different micro services can have different credentials; and in the cloud, the user name is different in different OSs.

  • The credential type is Linux Servers or Windows Administrator.
  • The label is information-only for the admin to recognize the content of the credential.
  • The usage is a binary value: global or restricted. Global means the credentials are applied to all devices. For restricted, other factors let the admin determine the group of devices that use the credentials to authenticate the Platform.
  • Username is internal, for use between a device and the Platform.
  • The authentication is internal, between a device and the Platform. The choices for authentication depend on the credential type:
    • For Windows Administrator, just a password
    • For Linux Servers, password or key-pair

Docker Credentials

For a container in the Docker hub, a username and password are required only when the Docker image is private.

In the current release, if the Docker image is in a cloud:

  • For assessing the image contents, the admin must provide the fully-qualified URI from AWS, username, and password.
  • For assessing the Docker repository, only the fully-qualified URI from AWS is necessary.

How to Add a Cloud Account

This section describes how to add a cloud account and specify the necessary cloud credentials so that the Platform has permission to communicate with the cloud. (Recall that after the Platform gets access to the cloud, the Platform must also present resource credentials to the resources in the cloud it seeks to assess.) The next figure illustrates the clicks that take the admin to the window for adding a cloud account–first the dropdown in the administrative area, then Cloud Management, and then Add Cloud Account.

 

Cloud Type AWS

The cloud accounts for AWS come in different flavors. The differentiator between these flavors is the type of Cloud Credentials. This section describes the differences for each one of the credentials and also described the purpose of the Enable Monitoring checkbox. The account addition screen is divided into the Platform steps at left and the steps performed in the cloud itself at right. Some values the admin enters in the cloud are also added into the Platform configuration.

The credentials are:

  • Use IAM Role.
  • An Amazon Resource Name (ARN) uniquely identifies an AWS resource. AWS needs an ARN if a resource is to be specified unambiguously across all of AWS. An ARN apply to IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls, for example.
  • Use Access and Secret Keys.

Enable Monitoring

This enable is for AWS account-related alerting in the Platform's Risk Signaling Engine (RSE). An example of an alert reason is excessive login attempts to the AWS account. For AWS alerting to work:

  • An alert rule must be configured in RSE and name the AWS account.
  • The Enable Monitoring checkbox must be marked (lower-left corner of each variation of AWS cloud specification). 

An alert is attached to one account. Put another way, Enable Monitoring is per account, not global, so for each AWS account that is to have alerting, a unique alert rule must be specified. See the forthcoming "Configuring Alert Rules" section for details about specifying alerting rules.)

Use IAM Role

 

Amazon Resource Name (ARN)

 

Access and Secret Key

First-time Discovering and Assessing Resources in the Whole Environment

Before starting the first-time use of Discover Resources & Assess for Risk, Security, and Compliance, the admin should:

  • Understand the resource credentials (described in this section) if the resources to assess are on-prem or in a cloud
  • Know the IP address range if the resources to assess are on-prem
  • Already added a cloud account if the environment is in a cloud
  • Have access to the Docker repository/image names and:
    • For private images in the Docker hub, the username and password
    • For a Docker repository in a cloud, the fully-qualified URI and, for the testing the image's contents, username and password

The following figure shows the names of the three wizards that the admin sees upon clicking the Discover & Assess button in Infrastructure.

 

The first-time use of Discover Resources & Assess for Risk, Security, and Compliance (or just Discover & Assess) includes:

  • Discovering of all resources in the environment. The boundaries of the environment are an IP address range on-prem, the cloud account, or the specified Docker image. These resources belong to an all-inclusive, user-named group, for the first-time Discover Resources. 
  • Specify a name for the group of all discovered resources. All security assessments are performed on logical groups of resources. The admin does not directly make an explicit selection of a resource and then assess it. (To test one resource, the admin creates a group with just that resource.) Subsequently, the admin creates multiple groups in the My Groups screen for specific purposes by selecting resources from the list in All Resources.
  • Creating a resource credential for first-time resource discovery. (See description of resource credentials in the section "The Credentials" if necessary.) A prerequisite for the use of resource credentials is to have a set of supporting network parameters. The organization's network administrator must ensure the network is set up to support the resources' authentication of the Platform. (Although the network details are not specified in the Discover Resources popup, they can be viewed by clicking the 'i' icon next to RESOURCE CREDENTIALS. These parameters are also listed in the section "The Credentials"/"Resource Credentials.") Subsequently, admins can create more resource credentials in the Infrastructure/Credentials screen as needed.
  • Selecting one of more Policy Packs to apply to resources for the assessment. (See "Select Policy Packs.")
  • Scheduling and starting the assessment. (See "Schedule Tests.")

NOTE: The next few sections describe the specification in the Discover Resources wizard for Docker image, cloud, and on-prem. Subsequently, at least one new resource credential must be specified. Then, at the end of Discover Resources, the admin can do one of the following:

  • Continue to the next wizard and select one or more policy packs for the assessment.
  • Immediately start discovering resources; later the admin can set up assessment by using the My Groups screen and the Schedule and Notifications screen.
  • Exit Discover Resources & Assess Risk, Security, & Compliance by clicking the X at upper-right

Selecting and Assessing a Docker Image

This section describes the two general approaches to assessing Docker images: images in the Docker hub and Docker images in an AWS cloud (for the current release).

NOTE: Regardless of whether the image resides in the Docker hub or the cloud, the admin needs to specify precisely the image to scan:

  • In Docker, the admin types the image name, colon, and the version as a tag in the Image Name box (for example, as "example:3.2").
  • In the organization's cloud account, the admin copies the fully qualified URI and pastes it into the Image Name box and then appends the colon and tag by typing them.
  • Without a tag, the default is the latest version of the image.

NOTE: For the scope of Docker cloud accounts in this document, it is assumed the admin knows how to obtain the cloud username and password that must be entered in the Platform.

In the current release of Platform, two policy packs are applicable to Docker. The Cavirin Docker Image Hardening Policy Pack has a small set of policies for checking the image. Cavirin Docker Patches & Vulnerabilities is a much larger policy reaches across many types of platforms for Docker images. As the information popups for these policy packs say:

  • Cavirin Docker Image Hardening Policy Pack is a comprehensive series of automated checks to audit the settings of Docker images. This policy pack was created using general hardening settings that are vitally important for all container images. Primary goal of this policy pack is to ensure the Docker images are safe with respect to these checklists of settings.
  • Cavirin Docker Image Patches & Vulnerabilities Scanning Policy Pack is a comprehensive series of automated checks to assess the vulnerabilities of Docker images. This policy pack contains patches and CVE references for RHEL 7, CentOS Linux 7, Debian GNU/Linux 8 (jessie), and Alpine Linux 3.6. By using this policy pack, the admin can scan Docker images for missing security patches. This policy pack supports public images, private images hosted on Docker Hub, and images hosted on private repo such as AWS ECS.

Docker Hub

For the Docker installation, the user account defaults to hub.docker.com, so when the admin enters an image name, the Platform automatically uses its connection with Docker Hub. (If the Platform detects a URI, it looks for the cloud credentials.) Customers are assumed to have the name of their own repositories and images and, for private images, the Docker account username and password.

If the repository/image is public, the Platform accepts the name of the image as input, so the admin can then proceed to selecting policy packs by clicking Next Step. If the image is private, the admin must enter a valid Docker account username and password before continuing to select policy packs and do an assessment.

The first figure below illustrates the detail for a public image at hub.docker/Debian (and defaults to latest version). For a valid image, when the admin clicks Next Step, the Platform proceeds to Select Policy Packs. (For a private image, the admin cannot progress from this screen without entering credentials.)

If the image cannot be found, the Platform displays “Image does not exist.”

 

 

Assessing a Docker Image in the AWS ECR

To scan the resources in a Docker image in AWS:

  1. The admin logs into the organization's AWS account and navigates to the repository with the image to be assessed–cavirin_demo in this example. See next figure.
  2. After copying the URI, the admin returns to the Platform and the Discover Resources screen for Docker.

3. Admin pastes the URI into the Image Name box (full URL with : and proper image tag), types a user name (for the AWS ECR, this is always 'AWS'), and pastes the password acquired from the AWS account into the Password box.  Note that this is the password obtained via the AWS CLI command: aws ecr get-login --no-include-email --region <regionID>. It is not the password for the AWS console.   

4. Admin clicks the Next Step button at the bottom of the Discover Resources screen (not shown in the figure). The Policy Packs window opens with the appropriate policy packs available for selection. See subsequent figure.

 

 

5. The admin chooses one or all of the highlighted policy packs and then clicks Start Assessment at the bottom of the Policy Packs wizard (not shown in the following figure). Assessment begins.

 

6. After the discovery and assessment finish, the admin can view the full cloud image name, overall risk score, and other details in the All Resources > Images Page (see next figure).

7. Subsequently, the admin can go to the Reports screen and examine and export the results of the assessment.

Selecting a Cloud, Regions, and Optional VPCs

A pre-requisite to discovering resources in a cloud is for the Platform to have information about the organization's cloud account. After a cloud account has been added in the Cloud Management screen (through the administrative task dropdown, as described in the "How to Add a Cloud Account" section), it be selected in the Account Name dropdown, as seen in the figure bellow. The cloud details are:

  • Cloud type (AWS in the current release)
  • Account name (specified through the Add Cloud Account page in Cloud Management)
  • Region, an AWS-only option, with multiple regions supported
  • Virtual private cloud (VPC)
  • Group name can be new or existing group

 

Specifying the On-Prem Deployment

Upon marking the On-Prem radio button, the admin sees the figure below. Two ways are available for specifying the IP address range. Entering the starting and ending IP addresses is supported, or the CIDR form of the range can be entered in CIDR format. When the admin marks the Fit to CIDR checkbox, the starting and ending IP addresses populate those fields, as the figure below illustrates. It also shows a descriptive group name and optional description.

 

First-time Resource Credential 

At the bottom of the Discover Resource wizard is the Add New Credential area. In the dropdown, the admin selects Linux or Windows Administrator. This choice opens the appropriate configuration options.

NOTE: The resource credential is required if an organization resources are in the cloud or on-prem. If the resources are in the cloud, the Platform first must present cloud credentials for the cloud to authenticate the Platform, and then the Platform presents credentials to the customer's resources.

Windows Administrator

The first figure, below, illustrates the Windows Administrator options. Security credentials are just username and password for Windows Administrator.

Note the Usage choices. Global means that the Platform uses this resource credential for all resources in the environment when it requests a connection with a resource. Restricted means the targets where this resource credential is offered is in a specific group. Because this first-time discovery applies to all resources, the resource credential should be global.

 

After the admin clicks Add, the new option buttons at the bottom of the wizard are: 

  • Discover Resources Now – Clicking this bottom causes the Discover & Assess screen to close; discovery begins; and the results appear in Infrastructure → All Resources.
  • Next Step – Clicking this button causes the Select Policy Packs wizard to open. See 'Select Policy Packs.'

Linux Servers

The figure below illustrates the Linux server resource credentials. Note the Usage choices: Global means the Platform uses this resource credential for all resources in the environment when it requests a connection. Restricted means the targets where this resource credential is offered is in a specific group. Because this first-time discovery applies to all resources, the resource credential should be global. For the description of using a restricted resource credential, refer to the Cavirin Platform Operations Guide.

Authentication for Linux Authentication can be password or key-pair. Clicking the radio button for one choice activates that area and deactivates the other authentication choice. For key-pair, the activated option lets the admin browse to the PEM key file.

 

 

After the admin clicks Add, the new option buttons at the bottom of the wizard are: 

  • Discover Resources Now – Clicking this bottom causes the Discover & Assess screen to close; discovery begins; and the results appear in Infrastructure → All Resources.
  • Next Step – Clicking this button causes the Select Policy Packs wizard to open. See "Select Policy Packs."

Select Policy Packs

If the admin clicked Next Step at the bottom of the Discover Resources wizard, the Select Policy Packs wizard opens. The following figure illustrates the selection of the AICPA SOC2 Type II policy pack (with thousands of policies for all OSs) and the OS selection that narrows the scope of policies to a couple hundred: CentOS Linux 7. It also illustrates part of the control families in this policy pack.

After selecting the policy packs, the admin clicks Next Step at the bottom of the screen (not shown) to go to the Schedule Tests screen.

 

Schedule Tests

In the Schedule Tests wizard, the admin can:

  • Select a Schedule and Notification template that consists of schedule details–if a template exists.

NOTE: A schedule and notification template is created in the Infrastructure's Schedule and Notification screen. Admins can use it repeatedly for various future assessments and create more templates as needed.

  • Start the assessment immediately (by eventually clicking Done at bottom-right corner of the Schedule Tests wizard.
  • Schedule tests for a later window of dates and time.
  • Specify how to receive notification of a change in assessment status (begin, end, fail, abort).
  • Provide a name for the assessment's report or let the system generate the report's name and specify that emailed reports are attached as a PDF or Excel spreadsheet. (Reports are available in the Reports area and described later in this User Guide.)

The Schedule Tests wizard is divided into two figures for this description:

  • The figure below is for scheduling the test. The admin specifies whether the assessment runs now or according to a schedule with the following parameters: start date and time; end date; and recurrence (daily, weekly, or monthly).
  • The subsequent figure shows where the admin specifies how to notify stakeholders of changes in an assessment's status–start, stop, fail, abort–and the name for the report that every assessment produces.

 

 

After setting up the schedule (immediate or otherwise), the admin:

  1. Specifies the assessment events that trigger a notification (begins, ends, failed, aborted).
  2. Specifies the notification to be delivered by email, Slack, or PagerDuty. Slack, PagerDuty, or other third-party requires an integration configuration in the RSE screen (described later in the User Guide).
  3. Specifies the assessment report to be an executive report in PDF or detailed in an Excel spreadsheet.
  4. Clicks Done to start the assessment now or according to a schedule.

 

After the assessment, the security risk and compliance scores and other views of the results can be viewed in the Dashboard.  Also, the report is available in the Reports screen, where it can be:

  • Displayed as HTML in a browser window
  • Exported as an executive summary in PDF or as a detailed report in an Excel spreadsheet

All Resources

After initial discovery, all of the discovered resources appear in the All Resources screen. This screen provides a wide variety of information columns. The following figure shows the default information columns and the gear icon at upper-right for hiding or displaying the columns. Use the numbered annotations in the figure to locate the following:

  1. The IP address of the resource, listed in descending order by default.
  2. Checkbox for selecting the resource. The action that follows selection is to add this resource to a new or existing group or to rediscover the resource (after a change in the resource).
  3. The total number of discovered assets, the numbers of accessible assets and inaccessible assets.
  4. The names of groups to which this resource belongs, as the section 'My Groups' describes.
  5. The option for hiding or displaying columns.

 

For this example, the admin selects the resource (same resource in the previous figure) and then clicks Add to Group, with the intention of adding it to an existing group. The Create Group popup in the following figure appears, and then the admin:

  1. Clicks the Add to existing group radio button.
  2. Sees the list of existing resource groups.
  3. Selects two groups in this example.
  4. Clicks Done.

My Groups

A group is a logical entity. It contains the organization's computing resources that an admin adds to the group. With the first-time resource discovery, all resources are discovered. From the totality of resources, the admin selects resources to add to a group. Characteristics of the groups:

  • To assess resources, the Platform accepts groups (by their user-specified name) as the target.
  • A group has only one environment, such as an AWS cloud, on-prem data center, or a hybrid.
  • A resource can belong to multiple groups.

When the admin selects a group by marking its checkbox, the options to edit, scan, delete, and rediscover its contents become visible. In addition, the contents of the entire group can be displayed. As the figure below illustrates, a small icon between the checkbox and group name ('Nikko') is active. Clicking that icon opens a page in a separate browser window that lists all the members of the group along with details about each resource. The subsequent figures a small portion of the resources in the Nikko group.

NOTE: To refresh the screen, for example the Test Status of an assessment in progress, click the circular arrows, upper-right.

 

 

Creating or Adding to a Group

Creating (or augmenting) a group starts in the All Resources screen. The admin starts by selecting one or more sources to add for creating a new group or add to an existing group. When ready, the admin clicks Add to Group. The subsequent illustrates the popup that appears.

 

In the figure below, the admin keeps the default radio button Add to new group, types a name for the new group and an optional description for the group, and clicks Done when ready. Platform creates the group with all the resources the admin selected in All Resources.

 

 

To add a resource to an existing group, the admin selects Add to existing group. The figure below illustrates two groups and the group selected to receive the two highlighted resources. When ready, the admin clicks Done.

 

Editing a Group

Editing a group means editing the group's configuration, not the resources in the group. To edit a group, the admin marks its checkbox in My Groups and clicks the Edit option that becomes active. The following figure pops up and shows that the admin can modify the group name, description, or associated template from the Schedule and Notification screen. Clicking Done saves the changes.

 

 

Policy Packs

The Policy Packs area is for administrators and security-focused personnel to examine the compliance policies and make decisions about applying them in the assessments of their computing and data storage environments. 

NOTE: No selections, filtering, and modifications in the Policy Packs area are saved, so changes do not apply to an assessment. The policy pack selections for an assessment are set up in the Infrastructure screen, where the admin schedules or initiates the tests on-demand. For the description of applying the policy packs, see "Infrastructure: for Discovering Resources and Assessing Security, & Compliance Risk."

The figure below shows the screen an admin sees upon selecting Policy Packs in the navigation pane. This screen illustrates the hierarchy of policy packs to profiles, control families, their children, and individual polices. Subsequent sections describe the policy packs.

 

 

Looking into a Policy Pack, Control Group, Policy, and Remediation

This section starts with an introduction to a NIST policy pack and concludes with an example of one of its policies (and the suggested remediation for a failed policy test). 

After clicking Select Policy Packs Now, the admin sees the list of all policy packs, as in the truncated figure below.

 

 

The admin selects a pack by marking the checkbox next to the name. To illustrate, the next figure highlights a NIST policy pack. For all operating systems to which the policies can apply, the subsequent figure shows the total number of policies for that pack.

Upon clicking the "i" icon, the admin sees information about the security or compliance standard and where to start looking at its documentation.

 

 

The All OS default shows all operating systems to which this policy pack can apply:

 

The number of policies is reduced if the admin selects one OS, as the next figure illustrates. The figure also illustrates one NIST control family (1–Access Control), one of its children (2–Access Enforcement), and an individual policy (3). Note also that the number of policies has been narrowed by the selection of Red Hat Enterprise Linux Release 6 instead of All OSs.

If an arrowhead is at the end of the row, more layers exist, but an "i" icon shows that is the lowest level, and clicking that icon pops up information about the policy (subsequent figure).

 

 

At the bottom of each information popup is recommended remediation or the location of remediation information on the Internet.

 

Policy Pack Profiles and Editable Policies

The Cavirin Platform supports additional choices in a growing number of its policy packs:

  • Choice of profiles, displayed upon selection of the radio button for Level 1 or Level 2 (default)
  • Selections in profiles that are editable

Profiles: Level 1 or Level 2

The effect of policy profiles at Level 1 and Level 2 fall into the general categories described in this section. The figure in the next section shows the location of the radio buttons for displaying policies with the selected Level.

Items in a Level 1 profile intend to:

  • Be practical and prudent
  • Provide a clear security benefit
  • Not inhibit the utility of the technology beyond acceptable means

The Level 2 profile extends the Level 1 profile. Items in a Level 2 profile exhibit one or more of the following characteristics:

  • Are intended for environments or use cases where security is paramount
  • Act as a defense-in depth-measure
  • Can negatively inhibit the utility or performance of the technology

Policy Packs with Editing Choices

A growing number of policies are editable. In the Policy Packs screen, a policy pack with editable policies shows how many out of the total number of policies can (or must) be edited, as the figure below illustrates (see policy pack at the bottom of the figure). Editable policies support values that an admin can specify. The figure also shows that all policies–whether editable or not–have a Level 2 profile and, therefore, zero Level 1 profiles.

Behaviors to note are:

  • The actual edit choices are visible only when the admin is selecting policy packs in the Infrastructure screen.
  • If a policy is editable, the admin must choose one of the options, otherwise the Platform does not test the resource for compliance with that policy. The only exception to this is if the option has a default. In this case, the admin can keep the default option and still get action on the policy.

 

 

Reports for the Assessments

The Cavirin Platform Reports facility provides reports in the following forms:

  • Multi-level report in a browser window: This format lets the response team drill into the details for each device and study each applied policy (and remediation in case of failure).
  • Details in an Excel spreadsheet: The spreadsheet includes the policies applied to a device and the recommended fix for a policy failure.
  • Summaries in PDF: The admin can download a summary in PDF for a specific policy pack or a PDF for all policy packs in sequence.  Although the PDFs provide fewer details than the spreadsheet, the sequence with all policy packs that were applied in the assessment can be hundreds or even thousands of pages.
  • Through an API created by the customer organization.

This section provides a description and example of each format of the reports.

Before examining the report examples and understanding their contents, understand the following behaviors and characteristics of the Reports facility:

  • When an assessment (test) begins, the reporting process also begins, and the name of the report-in-progress appears in the All Reports screen. (For the report name, the admin has already entered a name or let the system generate a name in the Discover Resources popup of the Discover Resources & Assess Risk, Security, & Compliance facility.)
  • Just as the Platform identifies the test target by group name, a report is distinguished by the group.
  • However, in the current release, the way an admin exports a PDF determines if the report covers just one policy pack or all the policy packs applied in an assessment.
  • In the spreadsheet, each sheet contains a report per policy pack and per asset (for example, one sheet for 13.70.121.9 and HIPPA, one sheet for 13.70.121.9 and CIS, and so on).
  • The status of running is visible in the Reports screen. Status is also visible in the Infrastructure > My Groups screen (which also shows the test's percent of completion).
  • If a test seems to be taking too much time or for any other reason, the admin can stop the test in the Reports screen or the My Groups screen. (If the admin stops the test, the resources continue to run.) The option for aborting a test appears only if the selected test is running. Regardless of where the admin stops the test, the status shows up in a report as 'Aborted.'

NOTE: If an admin stops (shuts down) the operation of an asset in the organization's environment, the Platform reporting continues, the status of the asset in a report is Stopped.

The All Reports Screen

This section uses example report screens to illustrate the Reports facility from the highest level (All Reports) down to one policy applied to one asset.

The next figure shows samples from the All Reports page and one selected report (dave-aws-ubuntu-test). When a report is selected, the following options appear:

  • Generate the report for export–the admin chooses between downloading it in PDF or as an Excel spreadsheet. When the admin exports a PDF through Generate Report, this is the much larger of two summaries, and the report contains all applied policy packs in sequence.
  • Repeat assessment starts the test again (using the assessment's existing configuration) to get the current security posture.
  • Show the report in HTML in a new browser window. Through the browser window, the admin or security team can drill deep into the details. The next section describes the drilldown through the HTML version. The screen also has an Export option for outputting the report in PDF or Excel. The PDF exported from this screen is for the policy pack selected in this report. 
  • Delete the report.

 

 

Showing a Report in a Browser and Drilling Down to a Specific Asset and Policy

An assessment can apply multiple policy packs. However, the report selected in a browser window is for one policy pack at a time, as the next figure illustrates. In this window:

  • The admin selects the CIS Policy Pack (CISPP) in the upper-left corner.
  • The security score (reflecting security benchmarks defined by CIS) is 44, so the state is ALERT because the score is low.
  • Half-way down the screen, the Issues Count per Control Family shows pass/fail numbers and severities for the control families that are specific to this policy pack. Control families are categories of similar policies within a policy pack. For the CIS policy pack, some example control families are Access Authentication and Authorization, Initial Setup, and Local Policies. Each of these control families has many individual policies that the admin can examine in detail.
  • Near the bottom of the figure is the number of resources tested, which leads to the next level of drilldown (bottom of the figure--this figure shows only one of five resources, ip-172.31.18.17).

 

 

The next figure is a closer look at the Resources part of the browser display but for a different assessment.

 

`

 

After clicking on a resource name, the admin sees a list of all policies applied to the resource and the results, as the next figure illustrates. The figure also shows filter options in the upper-right corner. The State filter is for Pass, Fail, N/A, Warning, Informational, Not Selected (means not evaluated), and Error. (This figure shows the default of all is states.) The following states might not be self-evident, so an explanation follows:

  • Error: The assessment engine could not complete the evaluation; therefore the status of the target’s compliance with the <xccdf:Rule> is not certain. This could happen, for example, if a testing tool ran with insufficient privileges and was not able to gather the necessary information.
  • N/A (Not Applicable): The <xccdf:Rule> was not applicable to the target of the test. For example, the <xccdf:Rule> might have been specific to a different version of the target OS, or it might have been a test against a platform feature that was not installed.       

The Severity filter is for High, Medium, and Low-severity policies, as well as Unknown and Info–selected to be just the high-severity policies in this example. The content for the Control Family filter dropdown depends on the policy pack applied to the resource.

When the admin clicks the "i" icon at left, the policy description pops up (subsequent figure).

 

 

When the admin clicks the "i" (highlighted in the preceding figure), details about the failed policy and its remediation open in a popup. Note that in the policy popups, the severity is shown regardless of whether the asset passed or failed. Severities are defined by the Cavirin security team; the Cavirin severity definitions follow the definitions from the Defense Information Systems Agency (DISA).

The example of a policy in the next figure illustrates how large a policy description can get. Not all policies have every field populated with information. For example, some policies do not show a CVE number or an audit, and in some cases, the remediation is merely pointed to on the Internet instead of described in the popup.

 

 

The next two figures show a variation on the policy display. In the first figure, the admin filtered for the high-severity failures and displayed the Remediation Steps column, an option available through the gear icon. When the admin hovers the cursor over the policy in the Remediation Steps column, the remediation part of the whole policy is displayed in case the admin immediately wants to see the remediation. The subsequent figure shows the policy in its entirety, after the admin clicks the "i" icon.

 

 

The Summary Report in PDF

The admin gets the choice between PDF and Excel spreadsheet through either of the following approaches:

  • The Generate Report option in the upper-left corner of the All Reports screen (when a completed report is selected). This PDF includes all applied policy packs.
  • The Export option in the upper-right corner of the HTML version of the report. This PDF is for the policy pack selected in the browser window.

The following example shows the first page of the 1671-page PDF:

The Excel Spreadsheet

The admin gets the choice between PDF and Excel spreadsheet through either of the following approaches:

  • The Generate Report option in the upper-left corner of the All Reports screen (when a completed report is selected).
  • The Export option in the upper-right corner of the HTML version of the report.

The following example shows a segment one sheet in the Excel spreadsheet. The details in the upper-left corner shows that this page represents one policy pack and one asset:

Risk Signaling Engine

Risk Signaling Engine (RSE) currently supports the following functional areas:

  • Triggering alerts for events in cloud environments 
  • Integration of the Platform with third-party, alert-notification products, such as PagerDuty

The following figure illustrates the tabs for RSE's current offerings.

 

Configuring Alert Rules

The admin can choose among a list of reasons for generating an alert. For example, if the rule specifies a maximum number of failed logins within a period of time and that threshold is reached, an alert appears in the RSE's All Alerts screen for the admin to examine, and an optional notification can be sent to user-specified recipients. Notification by email does not involve or require an integration.

Important behaviors to note are:

  • In the current release, alerting is available to AWS only, and the only supported notification tool is PagerDuty.
  • An alert rule can apply to only one cloud account.
  • One cloud account can have multiple alert rules associated with it. This supports rules for different metrics for a cloud and also means that a metric can be checked at more than one threshold, for example, where one rule triggers an alert when a high threshold is reached and another rule (for the same metric) is triggered when a low threshold is reached.
  • If the organization wants the optional notification delivered by a third-party messaging service, such as PagerDuty, that service must be integrated with the Platform in the RSE's Integration screen before the admin can select it in the Notification field.
  • Monitoring must be enabled in Cloud Management's Add Could Account screen. Without this enable for the account, the alert rules for that account are ignored. The figure below shows the part of the cloud account window for enabling the monitoring. In addition to the checkbox enable, it illustrates the selection of an S3 bucket and optional prefix. Some older versions of S3 bucket names have a prefix, and if present in the bucket name, must be in the Prefix box.

 

 

Alert Details

The admin:

  • Types a descriptive name for the alert, such as 'Too many failed logins.’
  • Selects low, medium, or high severity for the importance of the alert.
  • A description elaborates on this alert.
  • The rationale is some security information that goes into the alert. An example of a rationale is:

"Enforcing a sufficiently long password history increases the efficacy of password-based authentication systems by reducing the opportunity for an attacker to leverage a known credential. For example, if an attacker compromises a credential which then expires, this control prevents the user from reusing the compromised credential."

 

 

In the Add Metric section, the admin:

  • Specifies a configuration (threshold in the current release)
  • Chooses a metric type from a dropdown list of available metrics, such as Failed Console Login, API Authorization Error, Modification of VPCs, and so on
  • Selects a condition of greater than or less than
  • Types an integer for the threshold, for example, a number of login failures (3 in this example)
  • Selects a time frame of measurement (1, 4, 8, or 16 hours or 1 day in the dropdown)

 

 

Notifications, Accounts, and Advanced Settings for Alerting Behavior

In this bottom area of the alert specification, the admin:

  • As needed, selects a notification mechanism–email or an integrated service (which must be enabled before the admin can select it). For alerting by email, a box opens for typing one or more email addresses.
  • Selects the cloud account name that was created in Cloud Management (reached through in the administrator's dropdown).
  • As needed, specifies advanced settings that relate to reducing the number of alerts if, for example, their numbers become too large:
    • Stopping the alerts after a number of repetitions
    • Preventing alerts from appearing in the Dashboard
    • Reducing the number of alerts per hour
    • Disabling alerts for some purpose until this checkbox is cleared (the alert rule continues to exist while disabled)
  • Clicks on Done after completing the rule configuration.

 

Integrating the Platform with Third-party Incident Alerting Services

An integration enables the Platform to send alerts to third-party services, such as Slack, JIRA, PagerDuty, or ServiceNow.

Upon going to the RSE screen and clicking the Integrations link, the admin can choose the integration to specify. 

PagerDuty Integration

The admin's organization must have an account before beginning this task and following the directions for adding this integration. Clicking any of the circled "i" icons opens helpful guidance for the associated step. When ready, the admin clicks Save. Subsequently, the admin can specify this service in the alert rules for transmission of alert notifications.

 

 

This concludes the Cavirin Platform User Guide.

Have more questions? Submit a request

Comments