Gravwell Permissions Best Practices

Gravwell permissions help manage access to the resources provided in Gravwell and has three primary methods for managing permissions: Default, Capability Based Access Control (CBAC), and Single Sign-On (SSO). Gravwell implements a system of users and groups very similar to Unix’s. Each user is assigned a unique user ID number (UID), and each group has a unique group ID number (GID). A given user may belong to zero or more groups. Resources, dashboards, search results, and other things within Gravwell are typically owned by a user and optionally shared with a list of groups or with everyone.

No matter which method used the recommended best practice:

• Role-Based Grouping: Create groups based on job functions or roles to simplify permission management.
• Principle of Least Privilege: Limit group membership and resource access to ensure users only have the access necessary for their tasks

TABLE OF CONTENTS

• Gravwell Permissions: Default
• Gravwell Permissions: CBAC
• Gravwell Permissions: Multi-Factor Authentication
• Gravwell Permissions: SSO

Gravwell Permissions: Default

Gravwell default permissions are only advisable for small installations with a limited number of users. For larger environments, CBAC and SSO offer more robust tools for finely tuning permissions and enhancing access control.

Resources:

• Gravwell Docs: Managing Users and Groups

Administrator Role

Users with the administrator role have the ability to read, modify, or delete anything within Gravwell. Therefore, it is essential to exercise caution and discretion when granting this role. A user can be granted the Administrator Role in the Account Information for the individual user.

Groups

Groups are used to control access to resources, dashboards, search results, etc in Gravwell. This is generally managed when a resources is created and can be found in either a `Sharing & Ownership` element or an `Access` element.

Gravwell.conf

Additional permission setting can be defined in the gravwell.conf configuration file. Configuration Parameters:

• Webserver-Ingest-Groups:  is a list parameter which specifies groups whose users are allowed to ingest entries directly via the Gravwell web API. This setting is ignored if CBAC is enabled.
• Insecure-User-Unsigned-Kits-Allowed: If set allows all users to install unsigned kits. We strongly recommend against enabling this option.

Gravwell Permissions: CBAC

Gravwell provides Capability Based Access Control (CBAC) as a method to manage access to various Gravwell features. Permissions can be managed on an individual user basis or through groups and can be set based on Gravwell capabilities or Tags.

CBAC has a deny-all default policy, if this is the first time enabling CBAC, all non-admin users will begin with no capabilities or tag access.

Resources:

• Gravwell Docs: Capability Based Access Control (CBAC)

CBAC Groups

In practice, it is less common to grant capabilities to individual users; instead, administrators create groups with specific roles and assign users to those groups. For example, creating a group named “IT Users” that has access to IT-related tags (syslog, router logs, firewall logs, etc.), and a group named “Incident Response Users” that has access to IDS and other security related data, allows the admin to grant access to users based on their role. Users that need access to both IT and Incident response data in this example can simply be added to both groups.

When granting permissions, remember that additional permissions may be necessary to actually use the resource. For instance, to give a user the ability to read a dashboard they will need to be granted read access to all resources used in that dashboard which may include any or all of the following:

• Capabilities:
  • Dashboards: DashboardRead
  • Search: Search, AttachSearch
  • Query Library: LibraryRead
  • Extractors: ExtractorRead
  • Templates: TemplateRead
  • Resources: Resource Read
  • Macros: MacroRead
• Tags
  • Access to all Tags used by queries in the dashboard.
• Read access granted either through user, group or everyone will need to be set for each resource:
  • Dashboard, Searches, Queries, Extractors, Templates, Resources, Macros

Gravwell Permissions: Multi-Factor Authentication

Resources:

• Gravwell Docs: Multi-Factor Authentication

Gravwell supports Multi-Factor Authentication, also known as Two-Factor Authentication, for added security on local (non-SSO) accounts. When enabled, users must provide their password and a valid additional factor (either a TOTP “authenticator app” code or a recovery code) to login.

MFA can be required by adding "MFA-Required=true" to the webserver's gravwell.conf configuration file followed by restarting the webserver.

Gravwell Permissions: SSO

Resources:

• Gravwell Single
• Configuring SSO for Azure Active Directory
• Configuring Keycloak SSO with Gravwell
• Configuring OKTA SSO with Gravwell

Gravwell’s GUI supports single sign-on using SAML. In theory, any SAML-compliant Identity Provider can be used to log in a few examples are listed in the resources. 

A few notes for setting up SSO

• The 'admin' user does not use SSO so make sure to change the admins user's password. Also be aware that the admin user can create new non-SSO user accounts if needed.
• If 'Admin-Attribute=isAdmin' is used in the SSO configuration then SSO will manage if a user should be an administrator.
• Filter group claims to only ones that are necessary (currently limited to 4096); see.