Ulrica de Fort-Menares


While alerts help you stay ahead of problems with your security infrastructure, it can be challenging to create just the right amount of alerts to stay ahead of issues without also generating some level of noise. Not only do we alert you upon detecting an issue, but we also proactively notify you in advance of potential issues so problems can be avoided. Creating alerts that effectively signal potential issues without also producing a lot of noise was a difficult problem to solve. We are thrilled to announce the availability of Indeni 7.3 with noise reduction as the main theme for this release. 

Noise Reduction

1) Aggregate Policy

While the fine-grained measurement of metrics is extremely valuable during troubleshooting, often issues that are most actionable are identified not by a single metric, but by a combination of indicators. The most effective way to combine signals is to be context-aware. For example, we understand the clustering relationship among devices, upon detection of a cluster switchover event, we can chain together multiple issues from devices that belong to the same cluster and are relating to the same event. Instead of generating individual issues along with separate email notifications and creating multiple ServiceNow incident tickets, you will only receive one email and one incident ticket.

How does it work?

We analyzed data from many large customers to derive an algorithm to aggregate issues that are related to the cluster switchover event. The system pre-defines a set of High Availability rules that are potentially indicating an aggregation beginning.

  • Cluster down
  • Cluster member no longer active
  • (Clustered Virtual Devices) Cluster down
  • Firewall cluster problem
  • Management high-availability sync down
  • Virtual Firewall cluster member no longer sync down

When one of these rules hits the system, the aggregation begins. The system aggregates subsequent issues observed from all the devices belonging to the same cluster. At any one point in time, the system will not have concurrent aggregate policies outstanding for the same cluster. The list of rules to be included in the aggregation are:

  • All the High Availability issues
  • Two Indeni System rules: 
    • Device Not Responding 
    • Device Temporarily Suspended
  • Device restarted (uptime low)
  • Debug mode enabled
  • SecureXL disabled
  • Communication between management server and specific devices not working
  • Core dump files found
  • Critical process(es) down
  • Critical process(es) down (per VS)
  • Network port(s) down
  • Next hop inaccessible
  • Required interface(s) down
  • pnote(s) down
  • Device is logging locally
  • Repeated failed login attempts by a user

To enable Aggregation policy for Cluster switchover, enter the following in the browser’s URL:

https://<machine IP>/settings/application?agg_policy=true

Once you enable the feature, you will see a new column “Aggregation Policy” and issues will automatically be grouped on the Issues page. We encourage you to enable this new feature to start grouping multiple issues into a related event. This can be an effective way to reduce noise in your environment.

2) Rules Re-categorization and Re-prioritization

Indeni sends out various types of notifications based on the severity of the rule.  Default notification settings:

Adjusting the severity can reduce the number of email notifications. The introduction of rule categories provides an effective way to consume issues via reporting as opposed to individual email notifications. For example, many customers prefer to run a report to identify the list of devices with security risks. With this in mind, we adjusted the default severity of rules in the following categories (from Error to Warning) to minimize the amount of email notifications:

  • Center for Internet Security (new in this release, see here for a complete list of CIS rules)
  • Security risks
  • Ongoing Maintenance
  • Organization Standards
Related Article  Ensuring Availability of Check Point devices during COVID-19

Here is a complete list of rules that have been changed. Remember, you can always use Knowledge Explorer to change the severity setting of any rules that make the most sense for your environment.

Auto-Triage

1) Issue Items Enhancement

Prior to 7.3, when an issue with multiple issue items is detected, the system executes the ATE for each issue item. You can view the ATE results for all issue items. If another issue item is subsequently added, the system does not re-run the ATE for that new item. 

In Indeni 7.3, we introduced the re-run capability. When the new item is added to the parent issue, the system will re-run the ATE. This re-run will perform triage for every issue item, not just the newly added issue item provided the issue item(s) are still active and they have not been resolved.

Let’s take a look at a simple example. 

Sequence of events:

  1. Issue was created with issue item CPU1 added.
    Issue was created with issue item CPU1 added.
    The ATE was run automatically for the first time, labeled “Run #1” for CPU-1. 
  2. Next, CPU-1 issue item went to cooldown, exited cooldown and returned to cooldown.
    Next, CPU-1 issue item went to cooldown, exited cooldown and returned to cooldown.
  3. Meanwhile, a new item CPU-0 was added.
    3. Meanwhile, a new item CPU-0 was added
    Once again, the ATE was run automatically for the second time, labeled “Run #2” for CPU-0. During this run, only issue item CPU-0 was triaged since CPU-1 has been temporarily resolved and was in cooldown state.

    Result of Run #2 with CPU-0 being triaged:

  4. Eventually, the ATE was run for the last time because issue item CPU-2 was added.

    Once again, only one issue item was triaged because CPU-0 & CPU-1 have been resolved.

Let’s take a look at another more interesting example with multiple issue items being triaged.

In this example, six-issue items were being triaged since none of the issue items have been resolved. You can view the Auto-Triage result one by one for the six-issue items.

2) Re-run Auto-Triage

You can also manually trigger a re-run of any issue as long as the issue is active and it has not been resolved. To re-run an issue item, you have to re-run the parent issue. The manual re-run will trigger the ATE to run for the parent issue and every issue item that has not been resolved.
Re-Run Auto-Triage

3) Retain the history of every run

With the re-run capability, the system keeps the history of every run whether it’s manually triggered by a user or automatically triggered by the system as a result of a new issue item being added. The system will retain up to 20 copies. If the issue has multiple issue items, each copy will consist of results for every issue item.

New Auto-Triage Elements

Check Point:

  • RX packet overrun

Palo Alto Networks:

  • Auto-Triage if the web server hosting the External Dynamic Link is unreachable (7.2.4)
  • Added private cloud support to the “WildFire Cloud” ATE (7.2.4)

8 new Check Point & Palo Alto Networks ATEs in 7.2.1

Password Policy for local users only

A strong password policy is your first line of defense for your system. You can now define a set of rules for your password policies to increase security.

  1. Expire a password for an account including an admin
    To force the user to change password at the next login for the admin account, go to Settings -> Users, locate the user name admin, toggle the “Ask for a password change at the next login” button and turn on. This is a quick way to expire a password for the admin account.


    As a best practice, toggle on this button for every new user you create to enforce password change upon initial login. You can also choose to enforce a password change after you reset the user after a lockout.
  2. Generate password automatically
    The system can automatically generate a secure password on the user behalf. 

    The system-generated password will be sent via email to the user.
  3. Password must meet complexity requirements policy
    Set minimum password length, enforce the use of numbers and special characters.
  4. Enforce password history policy
    Set number of unique passwords before reuse. This policy discourages users from reusing a previous password, thus preventing them from alternating between several common passwords.
  5. Maximum password age policy
    Determines how long users can keep a password before they are required to change it. This policy forces the user to change their passwords on a regular basis.
  6. Lockout policy
    Locks users out after a certain number of incorrect passwords for greater security.
  7. Email notifications
    Create email notification prior to password expiry to remind users when it’s time to change their passwords before they actually expire.

  8. Password audit policy
    Allows you to track all password changes. This policy helps to ensure user accountability and provides evidence in the event of a security breach.
Related Article  Automation to enable security teams to do more with less

API Enhancements

Currently, API calls are limited to selecting one instance of an entity (e.g. devices, issues) of the entire set. This creates a dataset that is often a superset of the real data you are interested in. For example, if I only want to ingest issues relating to security risks, I don’t have a way to easily achieve that. 

With Indeni 7.3, you can use filters in the API calls so you would only be receiving the data which you are interested in.

Filters include the following:

  • Issues
    • Created before / after
    • Updated before / after
    • Severity
    • Category
  • Devices
    • Labels
    • Added before / after
    • Monitored / suspended
    • Vendor

For a complete list of filters, login to your Indeni server and view the built-in Swagger-based documentation in the link below: https://<indeni server ip>/documentation/

ServiceNow Enhancements

  • You can enable ServiceNow from the UI.
    • Settings -> Integrations -> Add New Integration -> ServiceNow

Knowledge – Auto Detect Elements

New Check Point ADE:

  • “Fake Tx hang detected” entries in /var/log/messages (7.2.2)
  • Track chassis total concurrent connections (7.2.3)
  • Track VS throughput (7.2.3)

New Palo Alto Networks ADE:

  • CVE-2020-1975: Missing XML Validation in PAN-OS Web Interface (7.2.4)
  • Alert when a firewall un-registers from the WildFire-500 (7.2.4)

New Palo Alto Networks ADE available in 7.3:

  • CVE-2020-2027 PAN-OS: Buffer overflow in authd authentication response 
  • CVE-2020-2028 PAN-OS: OS command injection vulnerability in FIPS-CC mode certificate verification
  • CVE-2020-2029 PAN-OS: OS command injection vulnerability in management interface certificate generator
  • CVE-2020-2032 GlobalProtect App: File race condition vulnerability leads to local privilege escalation during upgrade
  • CVE-2020-2033 GlobalProtect App: Missing certificate validation vulnerability can disclose pre-logon authentication cookie

Next Steps

As a next step, we encourage you to upgrade to Indeni 7.3. Once you’ve upgraded, enable Aggregate policy to reduce noise and enable Auto-Triage to take advantage of automated troubleshooting, so your team can stay focused on important issues. If you are interested in testing Indeni for yourself, you can access our trial download here.