Safeway, a company headquartered in Rosh-Haain, Israel, has recently released BackBox version 4.5. In this new version, BackBox includes “Application level monitoring”, capable of providing “insight regarding the devices’ health, and run preemptive scans to determine upcoming problems.”. Naturally, this has caused a handful of users to ask us how does indeni and BackBox compare. This is fantastic as more and more customers are looking to stay ahead of their issues and avoid the next outage.

The Origin of BackBox’s technology

Historically, BackBox was focused on backing up devices – as many as possible. BackBox’s claim to fame was its simplicity and the fact that it could cover an impressive range of devices. Included in the software were the instructions for how to automatically backup dozens of network devices, as well as the documentation for how to restore those backups. With release 4.0, BackBox received a UI face lift as well as a re-written infrastructure in Java.

The core of BackBox’s technology revolves around the ability to run commands and look for certain cues in the output (like “Success”, “Error”, etc.). This fits very well with the need to backup devices as you usually just need to run certain commands, save files and make sure it all occurred successfully (or alert if it didn’t). In version 4.5, this capability has been re-purposed to identify issues in devices (“Run command X and if you see text Y or number Z then it is a problem.”).

As we’ve seen in the market, BackBox is a fantastic product for backing up devices. With its ease of use, simplicity and broad coverage, it is a go-to backup tool for many organizations out there. In all honesty, BackBox’s coverage for backup is far wider than indeni’s, and we always recommend turning to BackBox if the need is focused around backup.

With version 4.5, BackBox includes this new “Application level monitoring” functionality. In recent conversations with a few individuals, we were asked to articulate the differences between BackBox’s “Application level monitoring” and indeni’s “machine-learning driven automated, preemptive root-cause analysis”. It sounds like marketing mumbo jumbo, but it’s not. It’s all down to the difference in the underlying technology.

indeni’s Technology

You see, at indeni, we took a radically different approach from the get-go. indeni is built from the ground up with the ability to understand the nature of the devices it is looking at – how they relate to one another, their features and functionality and, most importantly, how devices behave on a global basis. For example, a given type of firewall installed within a large financial services company will behave very similarly to the same type of firewall installed in a large telecommunications provider. Therefore, we need to ensure we learn from one environment, and apply in another. The indeni Insight service allows us to do that.

This resulted in the development of a technology that goes to great lengths to correctly model data and share it across organizations. indeni’s technology, is capable of:

• Parsing the configuration of one device, and using it to identify issues in another (for example, looking at the configuration in a management server and using it to identify a misconfiguration in a specific firewall).
• Comparing the configuration between a group of devices (for example, comparing two members of a cluster, or a device group).
• Identifying the relationships between devices of different types (like a loadbalancer connected to a switch).
• Reviewing the logs of devices on a global basis (for example, using logs collected from hundreds of customers to identify a specific log that can be leveraged to predict outages).

The crux of the difference

1. indeni’s software has an intimate understanding of the devices it supports – we have dedicated code for each product, we build strong technical partnerships with the manufacturers and their resellers and we invest heavily in generating knowledge for each product (see our recently launched community).
2. indeni is capable of identifying a whole range of issues (examples below) that BackBox cannot and won’t be able to for as long as it relies on its current technology.
3. At indeni, we look forward to seeing how BackBox’s technology evolves and welcome additional players in the rapidly growing market of preemptive maintenance solutions.

APPENDIX – Sample Issues indeni can identify and BackBox cannot

• Differences in configurations across a cluster and providing specific alerts as to what exactly is different:
  • Check Point: different static routing tables, .conf/.def files, SecureXL configuration, CoreXL configuration.
  • Cisco: differences in configurations across the running-config.
  • F5: differences in configurations that should match, but aren’t normally synced, like OS version, licenses, provisioning settings.
  • Palo Alto Networks: differences in configurations that should match, but aren’t normally synced, differences in anti-virus/wild-fire updates, OS versions, etc.
• Potentially severe issues visible only through logs that are documented in vendors’ knowledge bases and are difficult for users to track. For example, identifying issues with F5© BIG-IP©  systems based on the logs they are emitting. This is done through the collection of all of the SOLs listed on support.f5.com.
• Issues that are triggered by the use of a management server:
  • Check Point: when a policy installation results in a cluster failover that could have been avoided through the use of fwha_freeze_state_machine_timeout.
  • F5: when configurations pushed by F5 Enterprise Manager result in loss of sync at the device group level.
  • Palo Alto Networks: when someone logs directly into a firewall that is managed by a Panorama management server, and adds a rule locally instead of through the Panorama interface.
• Versions of software that are nearing end of support or are susceptible to potential issues.