Role-Based Access Control (RBAC)¶

The ability to restrict or grant specific privileges to a subset of users is covered by role-based access control, or "RBAC" for short. RBAC is an authorization technique in which users are assigned one of a small set of roles, and then the roles are associated to many low-level privileges. This provides the ability to build software with fine-grained access control, but without the need to maintain complex associations of users to large numbers of privileges. Users are traditionally assigned a single role, one which correlates closely with their role in the organization. However, it's possible to assign a user to multiple roles, if necessary.

RBAC in Security Onion covers both Security Onion privileges and Elastic stack privileges. Security Onion privileges are only involved with functionality specifically provided by the components developed by Security Onion, while Elastic stack privileges are only involved with the Elasticsearch, Kibana, and related Elastic stack. For example, Security Onion will check if a user has permission to create a PCAP request, while Elastic will check if the same user has permission to view a particular index or document stored in Elasticsearch.

Default Roles¶

Security Onion ships with the following user roles: superuser, analyst, limited-analyst, auditor, and limited-auditor.

See the table below which explains the specific Security Onion privileges granted to each role.

Superusers¶

After a new installation of Security Onion completes, a single administrator user will be created and assigned the superuser role. Additional users can also be assigned to the superuser role, if desired.

Adding a User With a Specific Role¶

In the Administration interface, navigate to the Users screen and click the + icon to add a new user. In the popup dialog you can check the roles you would like to assign to the new user.

Modifying User Roles¶

In the Administration interface, navigate to the Users screen and click the > icon to the left of the email address needing adjusting. Check or uncheck the desired roles.

Default Role Assignment¶

When a user is created, they can optionally be automatically assigned to a specific role. To enable this automatic assignment, locate the defaultRole configuration setting and specify the desired default role name. This automatic assignment will occur when the user logs into SOC for the first time.

Creating Custom Roles¶

These steps will guide you through an example where we wish to introduce a new role called eastcoast-analyst, which will inherit the same Security Onion permissions as a limited-analyst, but will be restricted to only view a subset of documents in the Elastic stack. We base this role on the limited-analyst instead of the analyst role so that the user does not have the ability to create arbitrary PCAPs on any sensor.

1. For the Security Onion role: Follow the instructions in the next section entitled "Defining Security Onion Roles" to create a new role named eastcoast-analyst.

2. For the Elastic stack role: Create a new json role file named eastcoast-analyst.json under /opt/so/saltstack/local/salt/elasticsearch/roles. In this example we will define the new role that only allows access to documents from sensors on the east coast of the United States. Specifically, the role will include a query filter that limits search results to only include documents originating from sensors having a name prefixed with nyc (New York City) or atl (Atlanta).

eastcoast-analyst.json :

{
  "cluster": [
    "cancel_task",
    "create_snapshot",
    "monitor",
    "monitor_data_frame_transforms",
    "monitor_ml",
    "monitor_rollup",
    "monitor_snapshot",
    "monitor_text_structure",
    "monitor_transform",
    "monitor_watcher",
    "read_ccr",
    "read_ilm",
    "read_pipeline",
    "read_slm"
  ],
  "indices": [
    {
      "names": [
        "so-*"
      ],
      "privileges": [
        "index",
        "maintenance",
        "monitor",
        "read",
        "read_cross_cluster",
        "view_index_metadata"
      ],
      "query": "{ \"bool\": { \"should\": [ { \"prefix\": { \"observer.name\": \"nyc\" }}, { \"prefix\": { \"observer.name\": \"atl\" }} ]}}"
    }
  ],
  "applications": [
    {
      "application": "Kibana-.Kibana",
      "privileges": [
        "feature_discover.all",
        "feature_dashboard.all",
        "feature_canvas.all",
        "feature_maps.all",
        "feature_ml.all",
        "feature_logs.read",
        "feature_visualize.all",
        "feature_infrastructure.read",
        "feature_apm.read",
        "feature_uptime.read",
        "feature_siem.read",
        "feature_dev_tools.read",
        "feature_advancedSettings.read",
        "feature_indexPatterns.read",
        "feature_savedObjectsManagement.read",
        "feature_savedObjectsTagging.read",
        "feature_fleet.all",
        "feature_actions.read",
        "feature_stackAlerts.read"
      ],
      "resources": [
        "*"
      ]
    }
  ],
  "run_as": []
}

sudo so-elasticsearch-query _security/privilege/kibana-.Kibana | jq '. | map_values(keys)'

1. Run so-checkin from the manager:

   sudo so-checkin
   

Defining Security Onion Roles¶

There are two ways to define a custom Security Onion role:

• Building it from scratch using the built-in permissions and default roles available as outlined later in this document, or
• Inheriting the permissions of another role, and optionally adding more permissions to the new custom role.

The common syntax for either method of defining a role is as such:

<existing role or permission>:<new role>

1. Creating the role for the above east coast analyst using the first method, building the custom role from scratch, would be written like so:

2. case-admin:eastcoast-analyst

3. event-admin:eastcoast-analyst
4. node-monitor:eastcoast-analyst
5. user-monitor:eastcoast-analyst

6. job-user:eastcoast-analyst

7. Alternatively, the eastcoast-analyst role could be created by inheriting the permissions of the analyst role:

8. limited-analyst:eastcoast-analyst

Security Onion Privileges and Default Roles¶

The available low-level Security Onion privileges are listed in the table below:

These discrete privileges are then collected into privilege groups as defined below:

† intended for use by Sensoroni agents only