The release of Indeni 7.2 advances our mission to automatically detect issues and triage them. We have provided a snapshot below of several new capabilities for security engineers and operations teams. If you are a customer, you can download and upgrade to 7.2, today. If you are new to Indeni, we would love to give you the chance to try the full version in your own environment.

1) Full workflow visualization

We’ve automated the world’s best practices to enhance your workflow and automatically triage issues after detection to reduce the chaos. Many of you have seen the ATE workflow diagrams that explain how we detected and diagnosed the cause of the specific issue. Now you can actually visualize the whole workflow, to understand our complete decision tree, our depth of coverage, and how we can help you beyond standard monitoring.

The workflow includes all the steps. The actual investigation for an issue is highlighted so you can easily follow the actual steps. You can see each command we issued along with the output of the commands. You can also see the result of the decision of each step.

While it’s great that you can see the workflow in its entirety, for other issues that have not been detected in your environment, you can now access these workflow diagrams from the Knowledge Explorer.

Simply navigate to Issues and select the Knowledge Explorer tab. Navigate to a rule with an Auto-Triage Element to see the workflow diagram. This is like a runbook for your operations teams!
For instructions on how to get the most out of Knowledge Explorer, visit here.

2) More Auto-Triage Elements

In addition to all these exciting automation enhancements, we have also added these new ATE’s for Check Point firewalls. 

• Firewall logging locally
• Cluster member no longer active
• High ARP cache 

Can’t find the ATE you’re looking for? You can always submit a request to our community here.

3) New Check Point CloudGuard Auto-Detect Elements

• ATE 1: Ensure CloudGuard Controller is running as a process on the management server.
• ATE 2: Check connectivity between CloudGuard Controller and AWS-DC. 
• ATE 3: Check errors on Data Center scanner. 
• ATE 4: Check the connection between CloudGuard Controller and CloudGuard instances.
• ATE 5: Check if Identity Awareness web API is running. 
• ATE 6: Check if CloudGuard Controller is updating CloudGuard instances. 
• ATE 7: Check for imported objects from Data Center.

4) Customize your Issues page

To keep your Issues page organized, simplify searching for issues, and group issues the way you would like to, we have made a few usability enhancements:

• Group issues by headline, devices, severity, status, assignee, or anything that makes sense to you. In this example, you can group issues by headline simply by dragging the Headline column to Drag here to set row groups.
  
  
• New filter Rule Categories. There are currently seven different rule categories:
  • Health Checks
  • High Availability
  • Ongoing Maintenance
  • Organization Standards
  • Regulatory Compliance
  • Security Risks
  • Vendor Best Practices

A rule can belong to multiple Rule Categories. Using the above new grouping feature, you can easily group alerts by their category.

Now that you have more flexibility to organize and view issues on your Issues page, we added a couple of indicators below to remind you that you have filters enabled. If you are not seeing the issues you want to see, you may have to clear the filters.

5) Newly interactive Dashboard to see your health posture at-a-glance

The out-of-the-box dashboard provides a high-level health posture of the network. The dashboard is interactive in nature. You can click on the widget to bring up the corresponding page with the context. For example, click on the “Symantec bar” of the “Issues per Vendor” widget, the system will bring you to the issue page showing Symantec devices with unresolved issues.

6) Early-Symptom to reduce non-actionable alert noise

We analyzed historical data collected by Indeni Insight across our installed base and found that there are a number of common issues that are transient, self-correcting before administrative action is necessary. To reduce the noise from transient or flapping issues, we are introducing the Early-Symptom feature. With Early-Symptom enabled, Indeni defers external alert triggers unless the issue clearly requires action by persisting beyond the timeframe specified by the user (e.g. set timeframe to 4 minutes).

When Indeni detects an issue, the issue will be in Early-Symptom status. The issue will be visible within the Indeni issue list, but will not immediately trigger a potentially unnecessary alert. Instead, it will wait for up to 4 minutes (user-defined). If the issue resolves during the next polling cycle one minute later, Indeni moves the issue to status Resolved. There is still a record of the issue, but in this example, the issue was never in Active state and an alert was never triggered. On the other hand, if the issue persists beyond the 4 minutes window, the issue moves to status Active and an alert will be triggered.

Based on the analysis of data from our Insight proactive support service, Indeni expects that there will be up to 12% reduction in non-actionable alerts if the window is 4 minutes, with little impact on critical issues. The side effect of this feature is that Indeni can potentially delay the generation of alerts by the user-defined period. It is a tradeoff between immediate notification versus noise reduction: fewer alerts, but with a higher trust value. To prevent workflow disruption for our established user base, this feature is disabled by default. For more information, visit here.

Notice

1) Migrating to Ubuntu 18

We would like to remind our customers and partners about the Ubuntu 18 dependency for this release. Starting with Indeni 7.1, older versions of Indeni will need to be migrated to Ubuntu 18.04. Newly installed Indeni instances, and all VM downloads starting with 7.0, are already running the required version, and require no additional action. Click here for more information about the migration.

2) Enable SNMP for PAN-OS

Indeni has discovered a minor defect for Palo Alto Networks devices with PAN-OS:  there is incorrect reporting of the management plane CPU usage from the following XML-API call:

/api?type=op&cmd=<show><system><resources></resources></system></show>&key=${api-key}

The impact is that Indeni is not able to detect issues for high CPU usage, and is subsequently not performing a back-off suspension to reduce the load on the device until it is safe to resume full health monitoring. We reported the problem to Palo Alto Networks and they are investigating. In the meantime, we are using SNMP to collect the metrics as a workaround. So if you have Palo Alto Networks devices in your environment, we recommend that you enable SNMP read access for an Indeni service account. Please follow the instructions here to enable SNMP on your Palo Alto Networks devices.

Learn More

We invite you to upgrade to Indeni 7.2 or, if you are new to Indeni, download a free trial today. For more details on this release, visit our documentation page.