STIG - 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.

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.

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!

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.

See Built-in users | Elasticsearch Reference [7.11] | Elastic

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

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.

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

From Defining roles | Elasticsearch Reference [7.11] | Elastic

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.