Local and shared content


Local and shared content


When a user of the Finder adds new content to an Engine, some types of items are created locally in the Engine. These items belong exclusively to the user that created them, meaning that only that particular user can see the items, use them or modify them when connecting to the same Engine.

Other types of items are directly added to a centralized content manager instead. The content manager lives in the same Appliance as the Portal and has access to all the Engines managed by the Portal. Items added to the content manager are instantly shared by all Engines after their creation in the Finder. For that reason, content shared in this fashion is also called centralized content. As a result, any user can see the items, use them or, if the user has enough privileges, modify them from their own instance of the Finder, as long as they are connected to the same Portal.

Finally, a few types of items are neither stored in the Engine nor in the content manager of the Portal, but in the computer that runs the Finder. You can think of these items as a kind of Finder preferences.


The following table shows the lists of items that are created locally and those which are shared:

Local to the Finder Local to the Engine Shared (centralized in the Portal)
  • Sessions
  • Custom actions
  • Investigations
  • Investigation-based alerts
  • One-click investigations
  • Web API investigations
  • Tags
  • Categories and keywords
  • Metrics
  • Services
  • Campaigns
  • Scores

Sharable content

Local and centralized content

Even if some content is created locally in the Engine, you can still share it manually by exporting items to the clipboard or to a file.

Manually export and import your investigations, one-clicks, alerts, categories, metrics, and services from the Finder.

Custom actions

Although local to the Finder, custom actions are also exportable. Share your custom actions with Finders installed in other computers by exporting them to XML files:

  1. Click the sprocket icon in the top right part of the Finder window.
  2. Select Custom actions... to display the list of available custom actions.
  3. Select one or more entries in the list by clicking on them. Use Ctrl+click to select more than one entry, Shift+click to select a group of consecutive entries, or Ctrl+A to select them all.
  4. Right-click your selection and choose Export... from the menu.
  5. Type in a name for the XML file.
  6. Click Save.

To import custom actions into a Finder, click the Import... button at the bottom of the list of custom actions and select the file to import. If an imported custom action exists already in the list, it is duplicated.


As a final remark, note that tags are neither centralized nor shareable. Tags are the result of applying a keyword to an object either manually, automatically, or with the help of text files. Objects (devices, destinations, etc) live in the database of each Engine; therefore, objects are local to an Engine, and so are the tags applied to an object. The locality of tags has some important implications that we explain with the following example.

Suppose that you have a setup with two Engines and one Portal, and in both Engines there is a destination with the same IP address. In fact, even if it is logically the same destination, there are two destination objects: one per Engine. If you create a category and a keyword to automatically tag the destinations with that IP address as, for instance, a Mail server, both Engines will tag the destination identically, though separately. Indeed, categories and keywords are centralized, so the auto-tagging condition on the IP address applies to all Engines.

Let us imagine that you connect to one of the Engines and that you manually tag the mentioned destination as a Proxy server, overriding the auto-tagging rule. Now you find that the same destination is tagged as Mail server in one Engine and as Proxy server in the other, which is probably not what you want. Therefore, be careful when you apply tags manually to objects, because tags are not shared among Engines.

Centralizing local content via roles

Administrators can assign investigations, one-click investigations, and investigation-based alerts to other users by making them role-based. Once linked to a role, the items are seen by all the users playing that role. To add investigations, one-clicks, or alerts to a role, administrators use the method seen above for exporting their content to the clipboard.