[Docs][SIEM]General proofing and editing

docs/en/siem/cases-kbn-actions-api.asciidoc

@@ -322,7 +322,7 @@ NOTE: You can only send cases to external system after you have
 
 ===== URL parts
 
-The URL must include the the ServiceNow connector ID. Call
+The URL must include the ServiceNow connector ID. Call
 <<cases-get-connector>> to retrieve the currently used connector ID, or
 <<cases-api-find-connectors>> to retrieve all connectors IDs.
 

docs/en/siem/cases-overview.asciidoc

@@ -6,7 +6,7 @@
 beta[]
 
 Cases are used to open and track security issues directly in the {siem-app}. 
-They list the original reporter and all users who contribute to a case
+All cases list the original reporter and all users who contribute to a case
 (`participants`). Comments support Markdown syntax, and allow linking to saved
 <<timelines-overview, Timelines>>. Additionally, you can send cases to external
 systems from within the {siem-app} (currently {sn}). <<cases-ui-integrations>>
@@ -56,7 +56,7 @@ To view a case, click on its name. You can then:
 * Close the case.
 * Reopen a closed case.
 * Edit tags.
-* Refresh cases to retrieve the latest updates.
+* Refresh the case to retrieve the latest updates.
 
 [float]
 [[case-permisions]]

docs/en/siem/cases-ui-integrations.asciidoc

@@ -5,8 +5,8 @@
 You can push new cases and case updates to {sn}. To do this, you need to create
 a connector, which stores the information required to push cases to {sn} via
 {sn}'s https://developer.servicenow.com/dev.do#!/reference/api/madrid/rest/c_TableAPI[Table API].
-After you have created a connector, you can set {siem-soln} cases to close
-automatically when they are sent to {sn}.
+After you have created a connector, you can set {siem-soln} cases to
+automatically close when they are sent to {sn}.
 
 NOTE: To create a {sn} connector and send cases to {sn}, you need the
 https://www.elastic.co/subscriptions[appropriate license].
@@ -27,8 +27,7 @@ image::images/cases-ui-sn-connector.png[]
 * _URL_: The URL of the {sn} instance to which you want to send cases.
 * _Username_: The username of the {sn} account used to access the {sn}
 instance.
-* _Password_: The password of the the {sn} account used to access the {sn}
-instance.
+* _Password_: The password of the {sn} account used to access the {sn} instance.
 . To represent a SIEM case as a {sn} incident, these SIEM case fields are
 mapped to {sn} incidents fields as follows:
 ** `Title`: Mapped to the {sn} `Short description` field. When an update to a
@@ -59,4 +58,4 @@ the connector used to send cases to {sn}.
 .. Select the required connector from the `Incident management system` list.
 . To update an existing connector:
 .. Click `Update connector`.
-.. Update the the connector fields as required.
+.. Update the connector fields as required.

docs/en/siem/detection-engine-intro.asciidoc

@@ -47,7 +47,7 @@ above a rule's defined threshold.
 
 Signals::
 Always refer to {siem-soln} produced detections. Signals are never received 
-from third-party systems. When a rule's conditions are met, the {siem-app} 
+from external systems. When a rule's conditions are met, the {siem-app} 
 writes one or more signals to an Elasticsearch `signals` index.
 +
 [NOTE]
@@ -62,7 +62,7 @@ Always refer to data the {siem-app} receives from external systems, such as
 Elastic Endpoint and Suricata.
 
 Actions::
-Used to send notifications via other systems when a signal is produced, such as
+Used to send notifications via other systems when a signal is created, such as
 email, Slack, PagerDuty, and Webhook.
 
 [float]
@@ -77,8 +77,8 @@ by a rule, you can:
 *Manage signal detection rules* -> rule name in the *All rules* table).
 
 NOTE: KQL autocomplete for `.siem-signals-*` indices is available on the 
-*Detections* and *Rule details* pages, and in timelines where `All events` or 
-`Signal events` are selected. 
+*Detections* and *Rule details* pages, and in Timeline when either `All events`
+or `Signal events` is selected. 
 
 To view alerts from external data shippers, click *External alerts*.
 
@@ -188,7 +188,7 @@ setting has not been added to the `kibana.yml` file.
 *`Detection engine permissions required`*
 
 If you see this message, you do not have the
-<<detections-permissions, required privileges>> to view the *Detections* page 
+<<detections-permissions, required privileges>> to view the *Detections* page, 
 and you should contact your {kib} administrator.
 
 NOTE: For *on-premises* {stack} deployments only, this message may be

docs/en/siem/installation.asciidoc

@@ -97,10 +97,10 @@ learn how to configure inputs.
 * *Packetbeat.* See {packetbeat-ref}/packetbeat-getting-started.html[{packetbeat} getting started].
 
 [float]
-=== Enable modules and configuration options
+==== Enable modules and configuration options
 
-For either approach, you need to enable modules in {auditbeat} and {filebeat}
-to populate the {SIEM-app} with data.
+No matter how you installed {beats}, you need to enable modules in {auditbeat}
+and {filebeat} to populate the {SIEM-app} with data.
 
 To populate *Hosts* data, enable these {auditbeat} modules:
 

docs/en/siem/overview.asciidoc

@@ -38,9 +38,6 @@ view, and interact with data stored in {es} indices. You can easily perform
 advanced data analysis and visualize your data in a variety of charts, tables,
 and maps.
 
-The {siem-app} in {kib} provides a dedicated user interface for analyzing and
-investigating host and network security events.
-
 [float]
 [[siem-integration]]
 ==== Additional Elastic components

docs/en/siem/privileges-api-overview.asciidoc

@@ -26,7 +26,7 @@ GET api/detection_engine/privileges
 --------------------------------------------------
 // KIBANA
 
-Gets user privileges the the {kib} `siem` space:
+Gets user privileges for the {kib} `siem` space:
 
 [source,console]
 --------------------------------------------------

docs/en/siem/rules-api-create.asciidoc

@@ -34,9 +34,9 @@ the `groups` field can be used to create rules:
 
 Additionally, you can set up notifications for when rules create signals. The
 notifications use the {kib} {kibana-ref}/alerting-getting-started.html[Alerting and Actions framework].
-Each action type requires its own connector, which store the information
-required to send the notification. These action types are supported for rule
-notifications:
+Each action type requires a connector. Connectors store the information
+required to send notifications via external systems. These action types are
+supported for rule notifications:
 
 * Slack
 * email

docs/en/siem/rules-ui-create.asciidoc

@@ -116,20 +116,21 @@ Winlogbeat ships Windows event logs to the SIEM app.
 ** _Custom query_: `event.action:"Process Create (rule: ProcessCreate)" and process.name:"vssadmin.exe" and process.args:("delete" and "shadows")`
 +
 Searches the `winlogbeat-*` indices for `vssadmin.exe` executions with 
-the `delete` and `shadow` arguments, used to delete a volume's shadow copies.
+the `delete` and `shadow` arguments, which are used to delete a volume's shadow
+copies.
 +
 [role="screenshot"]
 image::rule-query-example.png[]
 +
 TIP: This example is based on the
 <<volume-shadow-copy-deletion-via-vssadmin, Volume Shadow Copy Deletion via VssAdmin>> prebuilt rule.
 
-. Select the timeline template used when you send a signal created by the rule
-to the timeline (optional).
+. Select the timeline template used when you investigate a signal created by
+the rule in Timeline (optional).
 +
 TIP: Before you create rules, create and save relevant
 <<timelines-ui,timelines>> so they can be selected here. When signals generated
-by the rule are sent to the Timeline,
+by the rule are investigated in Timeline,
 <<signals-to-timelines, some query field values>> are replaced with their
 corresponding signal field values.
 
@@ -218,7 +219,7 @@ image::images/available-action-types.png[]
 +
 .. Select the required action type, which determines how notifications are sent (Email, PagerDuty, Slack, Webhook).
 +
-NOTE: Each action type requires its own connector. Connectors store the
+NOTE: Each action type requires a connector. Connectors store the
 information required to send the notification from the external system. You can
 configure connectors while creating the rule or on the {kib} Alerts and Actions
 page (*Management* -> *Alerts and Actions* -> *Connectors*). For more
@@ -249,8 +250,8 @@ You can clone, edit, activate, deactivate, and delete rules:
 . Go to *SIEM* -> *Detections* -> *Manage signal detection rules*.
 . Do one of the following:
 * Click the actions icon (three dots) and then select the required action.
-* In the *Rule* column, select all the rules you want to act on, and then the 
-required action from the `Batch actions` menu.
+* In the *Rule* column, select all the rules you want to modify, and then the 
+required action from the `Bulk actions` menu.
 . To activate or deactivate a rule, click the Activate toggle button.
 
 NOTE: For prebuilt rules, you can only activate, deactivate, delete, and edit
@@ -292,12 +293,12 @@ When a rule fails to run close to its scheduled time, some signals may be
 missing. There are a number of steps you can perform to try and resolve this 
 issue.
 
-If you are seeing `Gaps` in the All rules table or on the Rule details page
+If you see `Gaps` in the All rules table or on the Rule details page
 for a small number of rules, you can increase those rules'
 `Additional look-back time` (*Signal detection rules* page -> the rule's
 actions icon -> *Edit rule settings* -> *Schedule* -> _Additional look-back time_).
 
-If you are seeing gaps for a lot of rules:
+If you see gaps for a lot of rules:
 
 * If you restarted {kib} when many rules were activated, try deactivating them 
 and then reactivating them in small batches at staggered intervals. This 

docs/en/siem/tune-anomaly-results.asciidoc

@@ -29,8 +29,8 @@ The *Create new filter list* pane is displayed.
 . Enter a filter list ID.
 . Enter a description for the filter list (optional).
 . Click *Add item*.
-. In the *Items* textbox, enter the `process.name` field of the process for which
-you want to filter out anomaly results (`maintenanceservice.exe` in our example).
+. In the *Items* textbox, enter the name of the process for which you want to
+filter out anomaly results (`maintenanceservice.exe` in our example).
 +
 [role="screenshot"]
 image::filter-add-item.png[]
@@ -78,7 +78,7 @@ have completed all job rule changes.
 . Navigate to the job for which you configured the rule.
 . Optionally, expand the job row and click *JSON* to verify the configured filter
 appears under `custom rules` in the JSON code.
-. In the *actions* column, click the more (three dot) icon and select _Clone job_.
+. In the *actions* column, click the more (three dots) icon and select _Clone job_.
 +
 The *Configure datafeed* page is displayed.
 . Click *Data Preview* and check the data is displayed without errors.
@@ -89,31 +89,30 @@ name, such as `windows-rare-network-process-2`.
 +
 [role="screenshot"]
 image::cloned-job-details.png[]
-. Click *Next* and check the job validates without errors. Warnings about multiple
-influencers can be ignored.
+. Click *Next* and check the job validates without errors. You can ignore
+warnings about multiple influencers.
 . Click *Next* and then *Create job*.
 +
 The *Start <job name>* window is displayed.
 +
 [role="screenshot"]
 image::start-job-window.png[]
-. Select the point of time from which the job will analyse anomalies.
+. Select the point of time from which the job will analyze anomalies.
 . Click *Start*.
 +
 After a while, results will start to appear on the *Anomaly Explorer* page.
 
 [[define-rule-threshold]]
 ==== Define an anomaly threshold for a job
 
-Certain jobs use a high count function to look for unusual spikes in 
-process events. Some processes cause a burst of activity as a normal part of 
-their function, such as automation and housekeeping jobs running on server 
-fleets. However, sometimes a high-delta event count is unlikely to be the 
-result of routine behavior. In these cases, defining a minimum threshold for 
-when a high event count is considered an anomaly can be applied to the {ml} 
-jobs.
+Certain jobs use a high-count function to look for unusual spikes in 
+process events. For some processes, a burst of activity is a normal, such as
+automation and housekeeping jobs running on server fleets. However, sometimes a
+high-delta event count is unlikely to be the result of routine behavior. In
+these cases, you can define a minimum threshold for when a high-event count is
+considered an anomaly.
 
-Depending on your anomaly detection results, you may want to define a 
+Depending on your anomaly detection results, you may want to set a 
 minimum event count threshold for the `packetbeat_dns_tunneling` job:
 
 

docs/en/siem/tune-rule-signals.asciidoc

@@ -5,7 +5,7 @@ In the {siem-app}, prebuilt detection rules can be tuned to produce the best
 possible set of actionable signals. To reduce the noise level, you can:
 
 * Disable detection rules that rarely produce actionable signals because they 
-match local expected behavior, workflows, or policy exceptions.
+match expected local behavior, workflows, or policy exceptions.
 * <<manage-rules-ui, Clone and modify>> detection rule queries so they are
 aligned with local policy exceptions. This reduces noise while retaining
 actionable signals.
@@ -78,10 +78,10 @@ make `psexec` connections, and run WMI commands.
 * Applications that work with file shares, such as backup programs, and use the 
 server message block (SMB) protocol.
 
-To reduce signal noise for authorized activity, you can do any of the these:
+To reduce signal noise for authorized activity, you can do any of these:
 
 * Add a statement or filter to the rules that exclude specific servers, such as 
-the relevant host names, agent names, or other common identifier. 
+the relevant host names, agent names, or other common identifiers. 
 For example, `and not host.name : "server-name"`.
 * Add a statement or filter to the rules that <<filter-rule-process, exclude specific processes>>. For example, `and not process.name : "process-name"`.
 * Add a statement or filter to the rules that exclude a common user. 
@@ -105,7 +105,7 @@ names excluded in the first duplication
 [[tune-windows-rules]]
 === Tune Windows child process and PowerShell rules
 
-Normal user activity may sometimes trigger one or more of these these rules:
+Normal user activity may sometimes trigger one or more of these rules:
 
 * <<powershell-spawning-cmd>>
 * <<suspicious-ms-office-child-process>>
@@ -117,7 +117,7 @@ Normal user activity may sometimes trigger one or more of these these rules:
 * <<windows-script-executing-powershell>>
 
 While all rules can be adjusted as needed, use care when adding exceptions to 
-these rules. Exceptions could result in an undetected client side execution, or 
+these rules. Exceptions could result in an undetected client-side execution, or 
 a persistence or malware threat going unnoticed.
 
 Examples of when these rules may create noise include:
@@ -137,7 +137,7 @@ you can create duplicate rules with lower risk scores.
 === Tune network rules
 
 The definition of normal network behavior varies widely across different
-organizations, each network conforming to different security policies, 
+organizations. Different networks conform to different security policies, 
 standards, and regulations. When normal network activity triggers signals, 
 network rules can be disabled or modified. For example: