Missing metadata objects

Siren Investigate keeps the information necessary to control access to saved objects (such as graphs and dashboards) in special metadata objects that are stored separately from the saved objects themselves.

For Investigate up to version 16, metadata objects were generated depending on whether the ACL (Access Control) plugin was enabled or not. When ACL was enabled, metadata objects were created and kept in sync with saved objects at all times. When ACL was disabled, saved objects were created without any corresponding metadata object.

In order to enable the transition when enabling the ACL plugin for the first time, it was intended that saved objects without an accompanying metadata object should be considered public. While this approach worked when enabling the ACL plugin, it poses a security risk in the case that metadata objects were to somehow be lost — for example, as a result of a mishap in index backup and management — as objects that were intended to be private/with restricted access would become completely public.

In Siren Investigate 16.0, we are updating the metadata storage rules:

  • Migrating from 15.x to 16.0 will automatically repair any missing metadata objects using a suitable heuristic (more below).

  • When ACL is disabled, metadata objects are still created and kept in sync with saved objects.

  • Saved objects without an accompanying metadata object will henceforth be considered inaccessible — except by system administrators, auditors and dataspace owners to see and repair them.

Migration

If the upgrade to Siren Investigate 16.0 finds missing metadata objects, it will automatically repair them by recreating them appropriately.

The newly created metadata will set the ACL properties according to the following rules:

  • All object types that can’t be created as private in the normal UI will be considered fully public. For example, Data Model entities, relations and similar items will be considered public.

  • Graphs and dashboards that appear in the public section of the dashboards sidebar will be considered fully public.

  • All other objects will be made inaccessible, by marking them as private but without an owner.

After the migration has run, a warning will be printed in the logs with the full outcome of the migration, including lists of object ids and their determined resolution.

Verifying access control rules

Administrators should verify that the automatically determined resolutions for the objects listed in the migration logs are acceptable:

  • Objects made inaccessible should be reviewed individually. It’s important to identify their owner by looking at logs and audit data, if active at the time.

    From the Investigate audit low level dashboard, you can add a filter matching savedObject.action to create and savedObject.id to the object id. The principal field will contain the username that created the object.

  • If your ACL setup involved assigning role-based access to individual objects (e.g. specific Entity Tables viewable only by certain user roles), then you need to reconstruct those rules as they will have been lost in the affected objects.

Change the ACL properties of an object

First, go to the same dataspace as the object you are trying to look up.

You can open the Management > Saved Objects page to see a list of all known saved objects in a given dataspace, partitioned by type. Select the object type and paste the object id or title in the search box to automatically filter the list to that object.

Click on the lock icon to open the ACL settings for the object. An object repaired automatically will have no Owner and have General access set to either Dataspace for fully public objects or Private for inaccessible objects.

  • To make an inaccessible object public, you can change the General access setting to Dataspace.

  • To assign a private object to a user, you can assign their username to the Owner box, leaving the General access set to Private.