OpenSearch Security for Security Analytics

Security Analytics indexes are protected as system indexes and treated differently than other indexes in a cluster. System indexes store configurations and other system settings and, for that reason, cannot be modified using the REST API or the OpenSearch Dashboards interface. Only a user with a TLS can access system indexes. For more information about working with this type of index, see System indexes.

As an administrator, you can use OpenSearch Dashboards or the Security REST API to assign specific permissions to users based on the specific APIs they need to access. For a list of supported APIs, see API tools.

OpenSearch Security has three built-in roles that cover most Security Analytics use cases: , security_analytics_read_access, and security_analytics_ack_alerts. For descriptions of these and other roles, see .

If these roles don’t meet your needs, mix and match individual Security Analytics permissions to suit your use case. Each action corresponds to an operation in the REST API. For example, the cluster:admin/opensearch/securityanalytics/detector/delete permission allows you to delete detectors.

You can use backend roles to configure fine-grained access to individual detectors based on roles. For example, backend roles can be assigned to users working in different departments of an organization so that they can view only those detectors owned by the departments in which they work.

Next, enable the following setting:

copy

Now when users view Security Analytics resources in OpenSearch Dashboards (or make REST API calls), they only see detectors created by users who share at least one backend role. For example, consider two users: and bob.

The following example assigns the user alice the analyst backend role:

copy

copy

Finally, this last example assigns both alice and bob the role that gives them full access to Security Analytics:

copy

However, because they have different backend roles, and bob cannot view each other’s detectors or their results.

When a trigger generates an alert, the detector configurations, the alert itself, and any notifications that are sent to a channel may include metadata describing the index being queried. By design, the plugin must extract the data and store it as metadata outside of the index. (DLS) and field-level security (FLS) access controls are designed to protect the data in the index. But once the data is stored outside the index as metadata, users with access to the detector and monitor configurations, alerts, and their notifications will be able to view this metadata and possibly infer the contents and quality of data in the index, which would otherwise be concealed by DLS and FLS access control.