# STIG - The DBMS must isolate security functions from non-security functions **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-security\ **Created:** [March 19, 2021, 3:41am UTC](https://discuss.elastic.co/t/stig-the-dbms-must-isolate-security-functions-from-non-security-functions/267744 "2021-03-19T03:41:22Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Dan\_Bitter](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dan_bitter/32/85780_2.png) [@Dan\_Bitter](https://discuss.elastic.co/u/Dan_Bitter)\ **Post date:** [March 19, 2021, 3:41am UTC](https://discuss.elastic.co/t/stig-the-dbms-must-isolate-security-functions-from-non-security-functions/267744/1 "2021-03-19T03:41:23Z")
> **[The DBMS must isolate security functions from non-security functions.](https://stigviewer.com/stig/database_security_requirements_guide/2020-12-16/finding/V-206571)** > > Security Technical Implementation Guides (STIGs) that provides a methodology for standardized secure installation and maintenance of DOD IA and IA-enabled devices and systems. 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](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-passwords.html), but haven't found docs on where the password is stored. There's also [authentication realms](https://www.elastic.co/guide/en/elasticsearch/reference/current/realms.html), which are configured in elasticsearch.yml under xpack, but again, where are the passwords stored? Finally, [user roles and authorization](https://www.elastic.co/guide/en/elasticsearch/reference/current/authorization.html) 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. ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [March 19, 2021, 6:03am UTC](https://discuss.elastic.co/t/stig-the-dbms-must-isolate-security-functions-from-non-security-functions/267744/2 "2021-03-19T06:03:56Z")
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. ---
**Author:** ![Dan\_Bitter](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dan_bitter/32/85780_2.png) [@Dan\_Bitter](https://discuss.elastic.co/u/Dan_Bitter)\ **Post date:** [March 19, 2021, 4:07pm UTC](https://discuss.elastic.co/t/stig-the-dbms-must-isolate-security-functions-from-non-security-functions/267744/3 "2021-03-19T16:07:35Z")
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! ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [March 22, 2021, 2:28am UTC](https://discuss.elastic.co/t/stig-the-dbms-must-isolate-security-functions-from-non-security-functions/267744/4 "2021-03-22T02:28:01Z")
I'll do what I can, but I do recommend that you [get in touch](https://www.elastic.co/contact?storm=global-header-en#questions) 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](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-passwords.html), but haven't found docs on where the password is stored. See [Built-in users | Elasticsearch Guide [8.11] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/built-in-users.html#built-in-user-explanation) > [@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](https://www.elastic.co/guide/en/elasticsearch/reference/current/native-realm.html) 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](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#hashing-settings). > [@Dan\_Bitter](#): > > There's also [authentication realms](https://www.elastic.co/guide/en/elasticsearch/reference/current/realms.html), 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](https://www.elastic.co/guide/en/elasticsearch/reference/current/controlling-user-cache.html) 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](https://www.elastic.co/guide/en/elasticsearch/reference/current/authorization.html) 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](https://www.elastic.co/guide/en/elasticsearch/reference/current/defining-roles.html#roles-management-api) > [@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. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 19, 2021, 2:28am UTC](https://discuss.elastic.co/t/stig-the-dbms-must-isolate-security-functions-from-non-security-functions/267744/5 "2021-04-19T02:28:38Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.