[DOCS] Fixes title capitalization in security content

x-pack/docs/en/security/auditing.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[auditing]]
-== Auditing Security Events
+== Auditing security events
 
 You can enable auditing to keep track of security-related events such as
 authentication failures and refused connections. Logging these events enables you
@@ -40,7 +41,7 @@ events are pushed to the index by setting
 
 [float]
 [[audit-event-types]]
-=== Audit Event Types
+=== Audit event types
 
 Each request may generate multiple audit events.
 The following is a list of the events that can be generated:
@@ -81,11 +82,11 @@ The following is a list of the events that can be generated:
 
 [float]
 [[audit-event-attributes]]
-=== Audit Event Attributes
+=== Audit event attributes
 
 The following table shows the common attributes that can be associated with every event.
 
-.Common Attributes
+.Common attributes
 [cols="2,7",options="header"]
 |======
 | Attribute           | Description
@@ -103,7 +104,7 @@ The following table shows the common attributes that can be associated with ever
 The following tables show the attributes that can be associated with each type of event.
 The log level determines  which attributes are included in a log entry.
 
-.REST anonymous_access_denied Attributes
+.REST anonymous_access_denied attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -112,7 +113,7 @@ The log level determines  which attributes are included in a log entry.
 | `request_body`    | The body of the request, if enabled.
 |======
 
-.REST authentication_success Attributes
+.REST authentication_success attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -123,7 +124,7 @@ The log level determines  which attributes are included in a log entry.
 | `request_body`    | The body of the request, if enabled.
 |======
 
-.REST authentication_failed Attributes
+.REST authentication_failed attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -133,7 +134,7 @@ The log level determines  which attributes are included in a log entry.
 | `request_body`    | The body of the request, if enabled.
 |======
 
-.REST realm_authentication_failed Attributes
+.REST realm_authentication_failed attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -146,7 +147,7 @@ The log level determines  which attributes are included in a log entry.
                             consulted realm.
 |======
 
-.Transport anonymous_access_denied Attributes
+.Transport anonymous_access_denied attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -161,7 +162,7 @@ The log level determines  which attributes are included in a log entry.
                       pertains to (when applicable).
 |======
 
-.Transport authentication_success Attributes
+.Transport authentication_success attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -176,7 +177,7 @@ The log level determines  which attributes are included in a log entry.
 | `request`         | The type of request that was executed.
 |======
 
-.Transport authentication_failed Attributes
+.Transport authentication_failed attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -192,7 +193,7 @@ The log level determines  which attributes are included in a log entry.
                       pertains to (when applicable).
 |======
 
-.Transport realm_authentication_failed Attributes
+.Transport realm_authentication_failed attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -211,7 +212,7 @@ The log level determines  which attributes are included in a log entry.
                             consulted realm.
 |======
 
-.Transport access_granted Attributes
+.Transport access_granted attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -228,7 +229,7 @@ The log level determines  which attributes are included in a log entry.
                       pertains to (when applicable).
 |======
 
-.Transport access_denied Attributes
+.Transport access_denied attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -245,7 +246,7 @@ The log level determines  which attributes are included in a log entry.
                       relates to (when applicable).
 |======
 
-.Transport tampered_request Attributes
+.Transport tampered_request attributes
 [cols="2,7",options="header"]
 |======
 | Attribute         | Description
@@ -261,7 +262,7 @@ The log level determines  which attributes are included in a log entry.
                       pertains to (when applicable).
 |======
 
-.IP Filter connection_granted Attributes
+.IP filter connection_granted attributes
 [cols="2,7",options="header"]
 |======
 | Attribute           | Description
@@ -271,7 +272,7 @@ The log level determines  which attributes are included in a log entry.
                         the request.
 |======
 
-.IP Filter connection_denied Attributes
+.IP filter connection_denied attributes
 [cols="2,7",options="header"]
 |======
 | Attribute           | Description
@@ -283,14 +284,14 @@ The log level determines  which attributes are included in a log entry.
 
 [float]
 [[audit-log-output]]
-=== Logfile Audit Output
+=== Logfile audit output
 
 The `logfile` audit output is the default output for auditing. It writes data to
 the `<clustername>_access.log` file in the logs directory.
 
 [float]
 [[audit-log-entry-format]]
-=== Log Entry Format
+=== Log entry format
 
 The format of a log entry is:
 
@@ -318,7 +319,7 @@ The format of a log entry is:
 
 [float]
 [[audit-log-settings]]
-=== Logfile Output Settings
+=== Logfile output settings
 
 The events and some other information about what gets logged can be
 controlled using settings in the `elasticsearch.yml` file. See
@@ -336,7 +337,7 @@ file located in `CONFIG_DIR`. By default, audit information is appended to the
 
 [float]
 [[audit-log-ignore-policy]]
-=== Logfile Audit Events Ignore Policies
+=== Logfile audit events ignore policies
 
 The comprehensive audit trail is necessary to ensure accountability. It offers tremendous
 value during incident response and can even be required for demonstrating compliance.
@@ -414,7 +415,7 @@ xpack.security.audit.logfile.events.ignore_filters:
 
 [float]
 [[audit-index]]
-=== Index Audit Output
+=== Index audit output
 
 In addition to logging to a file, you can store audit logs in Elasticsearch
 rolling indices. These indices can be either on the same cluster, or on a
@@ -429,13 +430,13 @@ xpack.security.audit.outputs: [ index, logfile ]
 ----------------------------
 
 For more configuration options, see
-{ref}/auditing-settings.html#index-audit-settings[Audit Log Indexing Configuration Settings].
+{ref}/auditing-settings.html#index-audit-settings[Audit log indexing configuration settings].
 
 IMPORTANT: No filtering is performed when auditing, so sensitive data may be
 audited in plain text when including the request body in audit events.
 
 [float]
-==== Audit Index Settings
+==== Audit index settings
 
 You can also configure settings for the indices that the events are stored in.
 These settings are configured in the `xpack.security.audit.index.settings` namespace
@@ -451,7 +452,7 @@ xpack.security.audit.index.settings:
 ----------------------------
 
 [float]
-==== Forwarding Audit Logs to a Remote Cluster
+==== Forwarding audit logs to a remote cluster
 
 To index audit events to a remote Elasticsearch cluster, you configure
 the following `xpack.security.audit.index.client` settings:

x-pack/docs/en/security/authentication/active-directory-realm.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[active-directory-realm]]
 === Active Directory user authentication
 

x-pack/docs/en/security/authentication/anonymous-access.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[anonymous-access]]
-=== Enabling Anonymous Access
+=== Enabling anonymous access
 
 Incoming requests are considered to be _anonymous_ if no authentication token 
 can be extracted from the incoming request. By default, anonymous requests are rejected and an authentication error is returned (status code `401`). 

x-pack/docs/en/security/authentication/built-in-users.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[built-in-users]]
 === Built-in users
 

x-pack/docs/en/security/authentication/custom-realm.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[custom-realms]]
-=== Integrating with Other Authentication Systems
+=== Integrating with other authentication systems
 
 If you are using an authentication system that is not supported out-of-the-box
 by {security}, you can create a custom realm to interact with it to authenticate
@@ -7,7 +8,7 @@ users. You implement a custom realm as an SPI loaded security extension
 as part of an ordinary elasticsearch plugin.
 
 [[implementing-custom-realm]]
-==== Implementing a Custom Realm
+==== Implementing a custom realm
 
 Sample code that illustrates the structure and implementation of a custom realm
 is provided in the https://github.com/elastic/shield-custom-realm-example[custom-realm-example]
@@ -70,7 +71,7 @@ part of the `SecurityExtension` interface, it's available as part of the elastic
 . Bundle all in a single zip file.
 
 [[using-custom-realm]]
-==== Using a Custom Realm to Authenticate Users
+==== Using a custom realm to authenticate users
 
 To use a custom realm:
 

x-pack/docs/en/security/authentication/file-realm.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[file-realm]]
 === File-based user authentication
 

x-pack/docs/en/security/authentication/internal-users.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[internal-users]]
 === Internal users
 

x-pack/docs/en/security/authentication/ldap-realm.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[ldap-realm]]
 === LDAP user authentication
 

x-pack/docs/en/security/authentication/native-realm.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[native-realm]]
 === Native user authentication
 

x-pack/docs/en/security/authentication/overview.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[setting-up-authentication]]
 == User authentication
 

x-pack/docs/en/security/authentication/pki-realm.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[pki-realm]]
 === PKI user authentication
 

x-pack/docs/en/security/authentication/realms.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[realms]]
 === Realms
 

x-pack/docs/en/security/authentication/saml-guide.asciidoc

@@ -1,6 +1,7 @@
+[role="xpack"]
 [[saml-guide]]
 
-== Configuring SAML single-sign-on on the Elastic Stack
+== Configuring SAML single-sign-on on the {stack}
 
 The Elastic Stack supports SAML single-sign-on (SSO) into {kib}, using {es} as
 a backend service. In SAML terminology, the Elastic Stack is operating as a

x-pack/docs/en/security/authentication/saml-realm.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[saml-realm]]
 === SAML authentication
 {security} supports user authentication using SAML Single Sign On.

x-pack/docs/en/security/authentication/user-cache.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[controlling-user-cache]]
-=== Controlling the User Cache
+=== Controlling the user cache
 
 User credentials are cached in memory on each node to avoid connecting to a
 remote authentication service or hitting the disk for every incoming request.
@@ -34,7 +35,7 @@ setting the `cache_hash_algo` setting to any of the following:
 |=======================
 
 [[cache-eviction-api]]
-==== Evicting Users from the Cache
+==== Evicting users from the cache
 
 {security} exposes a
 {ref}/security-api-clear-cache.html[Clear Cache API] you can use

x-pack/docs/en/security/authorization/alias-privileges.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[securing-aliases]]
-=== Granting Privileges for Indices & Aliases
+=== Granting privileges for indices and aliases
 
 Elasticsearch allows to execute operations against {ref}/indices-aliases.html[index aliases],
 which are effectively virtual indices. An alias points to one or more indices,

x-pack/docs/en/security/authorization/custom-roles-provider.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[custom-roles-provider]]
-=== Custom Roles Provider Extension
+=== Custom roles provider extension
 
 If you need to retrieve user roles from a system not supported out-of-the-box
 by {security}, you can create a custom roles provider to retrieve and resolve
@@ -7,7 +8,7 @@ roles. You implement a custom roles provider as an SPI loaded security extension
 as part of an ordinary elasticsearch plugin.
 
 [[implementing-custom-roles-provider]]
-==== Implementing a Custom Roles Provider
+==== Implementing a custom roles provider
 
 To create a custom roles provider: 
 
@@ -62,7 +63,7 @@ part of the `SecurityExtension` interface, it's available as part of the elastic
 . Bundle all in a single zip file.
 
 [[using-custom-roles-provider]]
-==== Using a Custom Roles Provider to Resolve Roles
+==== Using a custom roles provider to resolve roles
 
 To use a custom roles provider:
 

x-pack/docs/en/security/authorization/field-and-document-access-control.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[field-and-document-access-control]]
-=== Setting Up Field and Document Level Security
+=== Setting up field and document level security
 
 You can control access to data within an index by adding field and document level
 security permissions to a role. Field level security permissions restrict access
@@ -23,7 +24,7 @@ document level permissions per index. See <<multiple-roles-dls-fls>>.
 =====================================================================
 
 [[field-level-security]]
-==== Field Level Security
+==== Field level security
 
 To enable field level security, specify the fields that each role can access
 as part of the indices permissions in a role definition. Field level security is
@@ -235,7 +236,7 @@ The resulting permission is equal to:
 
 
 [[document-level-security]]
-==== Document Level Security
+==== Document level security
 
 Document level security restricts the documents that users have read access to.
 To enable document level security, specify a query that matches all the
@@ -292,7 +293,7 @@ For example, the following role grants read access only to the documents whose
 NOTE: `query` also accepts queries written as string values.
 
 [[templating-role-query]]
-===== Templating a Role Query
+===== Templating a role query
 
 You can use Mustache templates in a role query to insert the username of the
 current authenticated user into the role. Like other places in {es} that support
@@ -358,7 +359,7 @@ based on the `group.id` field in your documents:
 --------------------------------------------------
 
 [[set-security-user-processor]]
-===== Set Security User Ingest Processor
+===== Set security user ingest processor
 
 If an index is shared by many small users it makes sense to put all these users
 into the same index.  Having a dedicated index or shard per user is wasteful.
@@ -416,7 +417,7 @@ to the `user` field for all documents that are processed by this pipeline:
 --------------------------------------------------
 
 [[multiple-roles-dls-fls]]
-==== Multiple Roles with Document and Field Level Security
+==== Multiple roles with document and field level security
 
 A user can have many roles and each role can define different permissions on the
 same index. It is important to understand the behavior of document and field

x-pack/docs/en/security/authorization/mapping-roles.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[mapping-roles]]
-=== Mapping Users and Groups to Roles
+=== Mapping users and groups to roles
 
 If you authenticate users with the `native` or `file` realms, you can manage
 role assignment by using the <<managing-native-users, User Management APIs>> or
@@ -24,13 +25,13 @@ you are able to map users to both API-managed roles and file-managed roles
 (and likewise for file-based role-mappings).
 
 [[mapping-roles-api]]
-==== Using the Role Mapping API
+==== Using the role mapping API
 
 You can define role-mappings through the
 {ref}/security-api-role-mapping.html[role mapping API].
 
 [[mapping-roles-file]]
-==== Using Role Mapping Files
+==== Using role mapping files
 
 To use file based role-mappings, you must configure the mappings in a YAML file
 and copy it to each node in the cluster. Tools like Puppet or Chef can help with
@@ -56,10 +57,10 @@ You can change this default behavior by changing the
 this is a common setting in Elasticsearch, changing its value might effect other
 schedules in the system.
 
-==== Realm Specific Details
+==== Realm specific details
 [float]
 [[ldap-role-mapping]]
-===== Active Directory and LDAP Realms
+===== Active Directory and LDAP realms
 
 To specify users and groups in the role mappings, you use their
 _Distinguished Names_ (DNs). A DN is a string that uniquely identifies the user
@@ -113,7 +114,7 @@ PUT _xpack/security/role_mapping/basic_users
 
 [float]
 [[pki-role-mapping]]
-===== PKI Realms
+===== PKI realms
 
 PKI realms support mapping users to roles, but you cannot map groups as
 the PKI realm has no notion of a group.

x-pack/docs/en/security/authorization.asciidoc → x-pack/docs/en/security/authorization/overview.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[authorization]]
-== Configuring Role-based Access Control
+== Configuring role-based access control
 
 {security} introduces the concept of _authorization_ to {es}.
 Authorization is the process of determining whether the user behind an incoming
@@ -8,7 +9,7 @@ successfully authenticated and the user behind the request is identified.
 
 [[roles]]
 [float]
-=== Roles, Permissions and Privileges
+=== Roles, permissions, and privileges
 
 The authorization process revolves around the following 5 constructs:
 
@@ -49,7 +50,7 @@ then assign users to the roles. These can be assigned to users in a number of
 ways depending on the realms by which the users are authenticated.
 
 [[built-in-roles]]
-=== Built-in Roles
+=== Built-in roles
 
 {security} applies a default role to all users, including
 <<anonymous-access, anonymous users>>. The default role enables users to access
@@ -164,7 +165,7 @@ stats.
 
 
 [[defining-roles]]
-=== Defining Roles
+=== Defining roles
 
 A role is defined by the following JSON structure:
 
@@ -276,14 +277,14 @@ see <<custom-roles-provider, Custom Roles Provider Extension>>.
 
 [float]
 [[roles-management-ui]]
-=== Role Management UI
+=== Role management UI
 
 {security} enables you to easily manage users and roles from within {kib}. To
 manage roles, log in to {kib} and go to *Management / Elasticsearch / Roles*. 
 
 [float]
 [[roles-management-api]]
-=== Role 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
@@ -292,7 +293,7 @@ see {ref}/security-api-roles.html[Role Management APIs].
 
 [float]
 [[roles-management-file]]
-=== File-based Role Management
+=== File-based role management
 
 Apart from the _Role Management APIs_, roles can also be defined in local
 `roles.yml` file located in `CONFIG_DIR`. This is a YAML file where each
@@ -338,12 +339,12 @@ click_admins:
 {security} continuously monitors the `roles.yml` file and automatically picks
 up and applies any changes to it.
 
-include::authorization/alias-privileges.asciidoc[]
+include::alias-privileges.asciidoc[]
 
-include::authorization/mapping-roles.asciidoc[]
+include::mapping-roles.asciidoc[]
 
-include::authorization/field-and-document-access-control.asciidoc[]
+include::field-and-document-access-control.asciidoc[]
 
-include::authorization/run-as-privilege.asciidoc[]
+include::run-as-privilege.asciidoc[]
 
-include::authorization/custom-roles-provider.asciidoc[]
+include::custom-roles-provider.asciidoc[]

x-pack/docs/en/security/authorization/run-as-privilege.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[run-as-privilege]]
-=== Submitting Requests on Behalf of Other Users
+=== Submitting requests on behalf of other users
 
 {security} supports a permission that enables an authenticated user to submit
 requests on behalf of other users. If your application already authenticates

x-pack/docs/en/security/ccs-clients-integrations.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[ccs-clients-integrations]]
-== Cross Cluster Search, Clients and Integrations
+== Cross cluster search, clients, and integrations
 
 When using {ref}/modules-cross-cluster-search.html[Cross Cluster Search]
 you need to take extra steps to secure communications with the connected

x-pack/docs/en/security/getting-started.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[security-getting-started]]
-== Getting Started with Security
+== Getting started with security
 
 To secure a cluster, you must enable {security} on every node in the
 cluster. Basic authentication is enabled by default--to communicate

x-pack/docs/en/security/how-security-works.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[how-security-works]]
-== How Security Works
+== How security works
 
 An Elasticsearch cluster is typically made out of many moving parts. There are
 the Elasticsearch nodes that form the cluster, and often Logstash instances,
@@ -64,7 +65,7 @@ For more information on user authentication see <<authorization>>
 
 
 [float]
-=== Node/Client Authentication and Channel Encryption
+=== Node/client authentication and channel encryption
 
 {security} supports configuring SSL/TLS for securing the communication channels
 to, from and within the cluster. This support accounts for:

x-pack/docs/en/security/index.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[xpack-security]]
-= Securing the Elastic Stack
+= Securing the {stack}
 
 [partintro]
 --
@@ -100,7 +101,7 @@ include::how-security-works.asciidoc[]
 
 include::authentication/overview.asciidoc[]
 
-include::authorization.asciidoc[]
+include::authorization/overview.asciidoc[]
 
 include::auditing.asciidoc[]
 

x-pack/docs/en/security/limitations.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[security-limitations]]
 == Security Limitations
 

x-pack/docs/en/security/reference.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[security-reference]]
 == Reference
 * <<security-privileges, Security Privileges>>

x-pack/docs/en/security/securing-communications.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[encrypting-communications]]
-== Encrypting Communications
+== Encrypting communications
 
 Elasticsearch nodes store data that may be confidential. Attacks on the data may
 come from the network. These attacks could include sniffing of the data,
@@ -21,7 +22,7 @@ include::securing-communications/setting-up-ssl.asciidoc[]
 //TO-DO: These sections can be removed when all links to them are removed.
 
 [[ciphers]]
-=== Enabling Cipher Suites for Stronger Encryption
+=== Enabling cipher suites for stronger encryption
 
 See {ref}/ciphers.html[Enabling Cipher Suites for Stronger Encryption].
 

x-pack/docs/en/security/troubleshooting.asciidoc

@@ -1,3 +1,4 @@
+[role="xpack"]
 [[security-troubleshooting]]
 == {security} Troubleshooting
 ++++

x-pack/docs/en/security/using-ip-filtering.asciidoc

@@ -1,5 +1,6 @@
+[role="xpack"]
 [[ip-filtering]]
-== Restricting Connections with IP Filtering
+== Restricting connections with IP filtering
 
 You can apply IP filtering to application clients, node clients, or transport
 clients, in addition to other nodes that are attempting to join the cluster.
@@ -92,7 +93,7 @@ transport.profiles.client.xpack.security.filter.deny: _all
 NOTE: When you do not specify a profile, `default` is used automatically.
 
 [float]
-=== HTTP Filtering
+=== HTTP filtering
 
 You may want to have different IP filtering for the transport and HTTP protocols.
 
@@ -106,7 +107,7 @@ xpack.security.http.filter.deny: _all
 
 [float]
 [[dynamic-ip-filtering]]
-==== Dynamically updating ip filter settings
+==== Dynamically updating IP filter settings
 
 In case of running in an environment with highly dynamic IP addresses like cloud
 based hosting, it is very hard to know the IP addresses upfront when provisioning