STIG - The DBMS must isolate security functions from non-security functions

[Dan_Bitter]

The DBMS must isolate security functions from non-security functions.

I have a list of STIGs to implement for Elasticsearch, and I'm not sure how to verify the needs of this one. I read about the keystore, which I think helps, but I don't think it covers all the points.

I found setup passwords, but haven't found docs on where the password is stored.

There's also authentication realms, which are configured in elasticsearch.yml under xpack, but again, where are the passwords stored?

Finally, user roles and authorization are useful, but the docs don't mention where this info is stored.

Details of the STIG:

1. An isolation boundary provides access control and protects the integrity of the hardware, software, and firmware that perform security functions.

2. Security functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based.

3. Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles.

4. Database Management Systems typically separate security functionality from non-security functionality via separate databases or schemas.

5. Database objects or code implementing security functionality should not be commingled with objects or code implementing application logic.

6. When security and non-security functionality are commingled, users who have access to non-security functionality may be able to access security functionality.

[TimV (Tim Vernum)]

This is a bit more complex than we can easily cover on a forum. We have a team of specialists with practical experience and knowledge about compliance with DOD requirements.
Do you have an existing contact at Elastic that could connect you with that expertise?

If not, I'm happy to try and walk you through it here, but it's the sort of thing that's going to get to a faster answer if you can have a chat with an expert in this area.

[Dan_Bitter]

Hi Tim, thank you for the fast reply!

We don't have such a contact. We took this project on a bit suddenly and are working it as we go. I'd definitely appreciate any comments you have on this STIG.

Thank you!

[TimV (Tim Vernum)]

I'll do what I can, but I do recommend that you get in touch directly, so that we can point you at specific guidance for securing Elasticsearch in accordance with US-Fed / DoD specs.

@Dan_Bitter

I found setup passwords, but haven't found docs on where the password is stored.

See Built-in users | Elasticsearch Guide [8.11] | Elastic

@How the built-in users work

These built-in users are stored in a special .security index, which is managed by Elasticsearch. If a built-in user is disabled or its password changes, the change is automatically reflected on each node in the cluster. If your .security index is deleted or restored from a snapshot, however, any changes you have applied are lost.

This section from the Native Realm docs is also applicable to built-in users:

@Configuring a native realm

To limit exposure to credential theft and mitigate credential compromise, the native realm stores passwords and caches user credentials according to security best practices. By default, a hashed version of user credentials is stored in memory, using a salted sha-256 hash algorithm and a hashed version of passwords is stored on disk salted and hashed with the bcrypt hash algorithm. To use different hash algorithms, see User cache and password hash algorithms.

@Dan_Bitter

There's also authentication realms, which are configured in elasticsearch.yml under xpack, but again, where are the passwords stored?

It depends on the realm. If you configure an LDAP or Active Directory realm, then the password is stored in the remote directory, it is never stored within Elasticsearch, other than for caching purposes

The file realm stores all users in files local to each node, and the native realm stored users (and their password hashes) in the same index as the built-in user.

@Dan_Bitter

Finally, user roles and authorization are useful, but the docs don't mention where this info is stored.

Roles can be stored in a File or in an internal Elasticsearch index, or generated by custom Java code.

From Defining roles | Elasticsearch Guide [8.11] | Elastic

@Role management API

The Role Management APIs enable you to add, update, remove and retrieve roles dynamically. When you use the APIs to manage roles in the native realm, the roles are stored in an internal Elasticsearch index.