[DOCS] Add ES security principles

docs/reference/redirects.asciidoc

@@ -3,6 +3,11 @@
 
 The following pages have moved or been deleted.
 
+[role="exclude",id="modules-scripting-other-layers"]
+=== Other security layers
+
+Refer to <<modules-scripting-security>>.
+
 [role="exclude",id="grok-basics"]
 === Grok basics
 

docs/reference/scripting/security.asciidoc

@@ -1,84 +1,31 @@
 [[modules-scripting-security]]
 == Scripting and security
-
-While Elasticsearch contributors make every effort to prevent scripts from
-running amok, security is something best done in
-{wikipedia}/Defense_in_depth_(computing)[layers] because
-all software has bugs and it is important to minimize the risk of failure in
-any security layer. Find below rules of thumb for how to keep Elasticsearch
-from being a vulnerability.
-
-[discrete]
-=== Do not run as root
-First and foremost, never run Elasticsearch as the `root` user as this would
-allow any successful effort to circumvent the other security layers to do
-*anything* on your server. Elasticsearch will refuse to start if it detects
-that it is running as `root` but this is so important that it is worth double
-and triple checking.
-
-[discrete]
-=== Do not expose Elasticsearch directly to users
-Do not expose Elasticsearch directly to users, instead have an application
-make requests on behalf of users. If this is not possible, have an application
-to sanitize requests from users. If *that* is not possible then have some
-mechanism to track which users did what. Understand that it is quite possible
-to write a <<search, `_search`>> that overwhelms Elasticsearch and brings down
-the cluster. All such searches should be considered bugs and the Elasticsearch
-contributors make an effort to prevent this but they are still possible.
-
-[discrete]
-=== Do not expose Elasticsearch directly to the Internet
-Do not expose Elasticsearch to the Internet, instead have an application
-make requests on behalf of the Internet. Do not entertain the thought of having
-an application "sanitize" requests to Elasticsearch. Understand that it is
-possible for a sufficiently determined malicious user to write searches that
-overwhelm the Elasticsearch cluster and bring it down. For example:
-
-Good:
-
-* Users type text into a search box and the text is sent directly to a
-<<query-dsl-match-query>>, <<query-dsl-match-query-phrase>>,
-<<query-dsl-simple-query-string-query>>, or any of the <<search-suggesters>>.
-* Running a script with any of the above queries that was written as part of
-the application development process.
-* Running a script with `params` provided by users.
-* User actions makes documents with a fixed structure.
-
-Bad:
-
-* Users can write arbitrary scripts, queries, `_search` requests.
-* User actions make documents with structure defined by users.
-
-[discrete]
-[[modules-scripting-other-layers]]
-=== Other security layers
-In addition to user privileges and script sandboxing Elasticsearch uses the
-https://www.oracle.com/java/technologies/javase/seccodeguide.html[Java Security Manager]
+In addition to user privileges and script sandboxing, {es} uses the
+https://www.oracle.com/java/technologies/javase/seccodeguide.html[Java Security Manager (JVM)]
 and native security tools as additional layers of security.
 
-As part of its startup sequence Elasticsearch enables the Java Security Manager
-which limits the actions that can be taken by portions of the code. Painless
-uses this to limit the actions that generated Painless scripts can take,
-preventing them from being able to do things like write files and listen to
-sockets.
+As part of its startup sequence, {es} enables the JVM to limit the actions that
+can be taken by portions of the code. Painless uses this to limit the actions
+that generated Painless scripts can take, preventing them from being able to do 
+things like write files and listen to sockets.
 
-Elasticsearch uses
+{es} uses
 {wikipedia}/Seccomp[seccomp] in Linux,
 https://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design[Seatbelt]
 in macOS, and
 https://msdn.microsoft.com/en-us/library/windows/desktop/ms684147[ActiveProcessLimit]
-on Windows to prevent Elasticsearch from forking or executing other processes.
+on Windows to prevent {es} from forking or executing other processes.
 
-Below this we describe the security settings for scripts and how you can
-change from the defaults described above. You should be very, very careful
-when allowing more than the defaults. Any extra permissions weakens the total
-security of the Elasticsearch deployment.
+The following sections describe security settings for scripts and how to alter
+the default settings. Take extreme caution when providing greater permissions
+to scripts beyond the default settings. Any extra permissions weakens the total
+security of your {es} deployment.
 
 [[allowed-script-types-setting]]
 [discrete]
 === Allowed script types setting
 
-Elasticsearch supports two script types: `inline` and `stored` (<<modules-scripting-using>>).
+{es} supports two script types: `inline` and `stored` (<<modules-scripting-using>>).
 By default, {es} is configured to run both types of scripts.
 To limit what type of scripts are run, set `script.allowed_types` to `inline` or `stored`.
 To prevent any scripts from running, set `script.allowed_types` to `none`.

x-pack/docs/en/security/es-security-principles.asciidoc

@@ -0,0 +1,55 @@
+[[es-security-principles]]
+== {es} security principles
+Protecting your {es} cluster and the data it contains is of utmost importance.
+There are numerous security practices and considerations for keeping your
+cluster safe, such as not saving passwords in plain text files or making sure
+that users have appropriate permissions (most users shouldn't be a superuser).
+These guidelines are important, but the following information provides something
+greater. These principles are foundational to running {es} in a secure manner.
+
+[discrete]
+[[security-dont-run-without]]
+=== Run {es} with security enabled
+Never run an {es} cluster without security enabled. This principle cannot be
+overstated. Running {es} without security leaves your cluster exposed to anyone
+on the internet, permitting anyone to download, modify, or delete any data in
+your cluster.
+<<configuring-stack-security,Start the {stack} with security enabled>> or
+<<manually-configure-security,manually configure security>> to prevent
+unauthorized access to your clusters and ensure that internode communication
+is secure. 
+
+[discrete]
+[[security-dont-expose]]
+=== Protect {es} from public internet traffic
+Even with security enabled, never expose {es} to public internet traffic.
+Using an application to sanitize requests to {es} still poses risks, such as
+a malicious user writing <<search,`_search`>> requests that could overwhelm an
+{es} cluster and bring it down. If you need to connect devices from the internet
+to {es}, use some combination of a proxy, firewall, and VPN. The best
+combination of these technologies depends on your security needs and risks.
+
+[discrete]
+[[security-dont-expose-to-users]]
+=== Implement a barrier between {es} and users
+While you absolutely shouldn't expose {es} directly to the internet, you also
+shouldn't expose {es} directly to users. The following configurations provide
+different methods of user interaction with {es}:
+
+* *Best*: Use an application to make requests on behalf of users.
+* *Better*: If the previous configuration isn't possible, use an application to
+sanitize requests from users.
+* *Good*: If either of the previous configurations isn't possible, implement
+some mechanism to track user behaviors, such as requests that are submitted to
+specific nodes in the cluster.
+
+[discrete]
+[[security-dont-run-as-root]]
+=== Create appropriate users to run {es}
+Never run {es} as the `root` user. Running as the `root` user provides an avenue
+to circumvent the other security layers and permit a user to do *anything* on
+your server. {es}  will refuse to start if it detects that it is running as
+`root`, but it's worth double (or triple) checking the user that {es} runs as. 
+<<defining-roles,Define roles>> for your users and
+<<security-privileges,assign appropriate privileges>> to ensure that users have
+access only to the resources that they need.

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

@@ -1,19 +1,21 @@
 [[secure-cluster]]
-= Secure the Elastic Stack
+= Secure the {stack}
 
 [partintro]
 --
 
-The Elastic Stack is comprised of many moving parts. There are the {es}
+The {stack} is comprised of many moving parts. There are the {es}
 nodes that form the cluster, plus {ls} instances, {kib} instances, {beats}
-agents, and clients all communicating with the cluster.
+agents, and clients all communicating with the cluster. To keep your cluster
+safe, adhere to the <<es-security-principles,{es} security principles>>.
 
-<<configuring-stack-security,Configure security for the Elastic Stack>> to
+<<configuring-stack-security,Start the {stack} with security enabled>> or
+<<manually-configure-security,manually configure security>> to
 secure {es} clusters and any clients that communicate with your clusters. You
 can password protect access to your data as well as enable more advanced
 security by configuring Transport Layer Security (TLS). This additional layer
 provides confidentiality and integrity protection to your communications with
-the Elastic Stack. You can also implement additional security measures, such as
+the {stack}. You can also implement additional security measures, such as
 role-based access control, IP filtering, and auditing.
 
 Enabling security protects {es} clusters by:
@@ -71,7 +73,7 @@ of your data against tampering, while also providing _confidentiality_ by
 encrypting communications to, from, and within the cluster. For even	greater
 protection, you can increase the <<ciphers,encryption strength>>.
 
-See <<configuring-stack-security,Configure security for the Elastic Stack>>.
+See <<configuring-stack-security,Configure security for the {stack}>>.
 
 [discrete]
 [[maintaining-audit-trail]]
@@ -90,6 +92,8 @@ See <<enable-audit-logging,Enable audit logging>>.
 
 --
 
+include::es-security-principles.asciidoc[]
+
 include::configuring-stack-security.asciidoc[]
 
 include::security-manual-configuration.asciidoc[]

x-pack/docs/en/security/security-manual-configuration.asciidoc

@@ -1,3 +1,4 @@
+[[manually-configure-security]]
 == Manually configure security
 ++++
 <titleabbrev>Configure security</titleabbrev>