Typo/Grammar fixes from internal workshop feedback

exercises/ansible_security/1.1-explore/README.md

@@ -84,7 +84,7 @@ Let's open a file in VS Code. In the menu bar, click on **File**, **Open File**.
 
 ![VS Code - VS Code file picker](images/1-vscode-filepicker.png)
 
-Pick **lab_inventory**, this will immediately update the file list. In the new file list, pick **hosts**. This will open the inventory of you environment.
+Pick **lab_inventory**, this will immediately update the file list. In the new file list, pick **hosts**. This will open the inventory of your environment.
 
 As you see, the inventory of your environment is provided in a static, ini-type file. It looks like the following listing. Please note that the IP addresses provided here are just an example and will be different in your lab environment:
 
@@ -119,7 +119,7 @@ Ansible is already configured to use the inventory specific to your environment.
 
 > **Note**
 > 
-> Not all hosts in your lab can be reached via SSH or WinRM. Some are accessed via REST API, RDP or web browser. During the exercises, each node type will be explained in detail and the means how to access the resources will be shown step by step.
+> Not all hosts in your lab can be reached via SSH or WinRM. Some are accessed via REST API, RDP or web browser. During the exercises, each node type will be explained in detail and how to access the resources will be shown step by step.
 
 ## Step 1.6 - Working the Labs
 

exercises/ansible_security/1.2-checkpoint/README.md

@@ -42,7 +42,7 @@ Press the **Login** button. Afterwards you need to verify the server fingerprint
 
 > **Note**
 >
-> In a production environment, you would first figure out the fingerprint of the server and would only proceed after you confirmed that the fiungerprint shown is identical with the one from the server. In our demo setup with the short lived instances we can assume that the fingerprints are good.
+> In a production environment, you would first figure out the fingerprint of the server and would only proceed after you confirmed that the fingerprint shown is identical with the one from the server. In our demo setup with the short lived instances we can assume that the fingerprints are good.
 
 You are now viewing the Check Point SmartConsole management interface. There might be a Internet Explorer Warning visible upon start. This can safely be closed and is due to limitations in the way IE works.
 

exercises/ansible_security/1.3-snort/README.md

@@ -313,7 +313,7 @@ snort  : ok=3  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored
 
 The last task outputs the rule which was found by the role. As you can see, it is the rule we previously added.
 
-Congratulation! You have completed the first steps of automating Snort with Ansible. Head back to the exercise overview and continue with the next step.
+Congratulations! You have completed the first steps of automating Snort with Ansible. Head back to the exercise overview and continue with the next step.
 
 ----
 

exercises/ansible_security/1.4-qradar/README.md

@@ -8,7 +8,7 @@ The SIEM can be accessed via web UI and via REST API. In this lab the playbooks
 
 ## Step 4.2 - Access the web UI
 
-Have a first look at the SIEM, and verify that it is actually working. Point your web browser towards `https://<qradar-IP>`, where `<qradar-IP>` is the IP address for the `qradar` entry in your `siem` section of your inventory. Next you will be faced with a warning that the vertificate is unsecure since it is self-signed. Please accept this and proceed.
+Have a first look at the SIEM, and verify that it is actually working. Point your web browser towards `https://<qradar-IP>`, where `<qradar-IP>` is the IP address for the `qradar` entry in your `siem` section of your inventory. Next you will be faced with a warning that the certificate is unsecure since it is self-signed. Please accept this and proceed.
 
 > **Note**
 >
@@ -57,7 +57,7 @@ Now that you had a very first glance at QRadar, it is time to look how it can be
 
 On the most basic level, Ansible automation performs tasks. Those tasks execute modules, which usually work on the corresponding targets, like an API endpoint of a special device or program.
 
-Ansible comes along with a lot of modules included. But as time of writing Ansible does not ship QRadar modules out of the box. Instead, those modules are provided as [Ansible collections](https://docs.ansible.com/ansible/devel/dev_guide/collections_tech_preview.html):
+Ansible comes with a lot of modules included, but as of the time of writing, Ansible does not ship QRadar modules out of the box. Instead, those modules are provided as [Ansible collections](https://docs.ansible.com/ansible/devel/dev_guide/collections_tech_preview.html):
 
 > *Collections are a distribution format for Ansible content. They can be used to package and distribute playbooks, roles, modules, and plugins. You can publish and use collections through Ansible Galaxy.*
 

exercises/ansible_security/2.1-enrich/README.md

@@ -48,7 +48,13 @@ The stage is set now. Read on to learn what this use case is about.
 
 Imagine you are a security analyst in an enterprise. You were just informed of an anomaly in an application. From within a terminal in your VS Code online editor, ssh to the snort machine. Remember that you can look up the IP of the Snort server from the inventory file at `/home/student<X>/lab_inventory/hosts`.
 
-Open a new terminal in your VS Code online editor to connect to the Snort server via SSH. Note: As the login user for the Snort server, you need to use `ec2-user`! After login, grep for the anomaly log entry:
+Open a new terminal in your VS Code online editor to connect to the Snort server via SSH. 
+
+> **Note**
+>
+> As the login user for the Snort server, you need to use `ec2-user` 
+
+After login, grep for the anomaly log entry:
 
 ```bash
 [student<X>@ansible ~]$ ssh [email protected]
@@ -80,7 +86,7 @@ So let's write such a playbook which first configures the log sources - Snort an
 
 As usual, the playbook needs a name and the hosts it should be executed on. Since we are working on different machines in this workflow, we will separate the playbook into different "[plays](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#playbook-language-example)":
 
-> *The goal of a play is to map a group of hosts to some well defined roles, represented by things ansible calls tasks. At a basic level, a task is nothing more than a call to an ansible module.*
+> The goal of a play is to map a group of hosts to some well defined roles, represented by things ansible calls tasks. At a basic level, a task is nothing more than a call to an ansible module.
 
 This means that the "host" section will appear multiple times in one playbook, and each section has a dedicated task list.
 
@@ -342,7 +348,7 @@ Leave the Snort server again and come back to your control host.
 
 Note that so far no logs are sent from Snort to QRadar: Snort does not know yet that this traffic is noteworthy!
 
-But as a security analyst, with more data at our disposal, we finally have a better idea of what could be the cause of the anomaly in the application behaviour. We see the logs from the firewall, see who is send traffic to whom, but still not enough data to dismiss the event as a false positive.
+But as a security analyst, with more data at our disposal, we finally have a better idea of what could be the cause of the anomaly in the application behaviour. We see the logs from the firewall, see who is sending traffic to who, but there's still not enough data to dismiss the event as a false positive.
 
 ## Step 1.7 - Add Snort signature
 
@@ -493,7 +499,7 @@ Run the playbook to remove the log sources:
 [student<X>@ansible ~]$ ansible-playbook rollback.yml
 ```
 
-Also, we need to kill the process which simulates the attack. For this we will use a so called Ansible ad-hoc command: a single task executed via Ansible, without the need to write an entire playbook. We will use the shell module because it supports piping, and can thus chain multiple commands together. In a terminal of your VS Code online editor, run the following command:
+Also, we need to kill the process which simulates the attack. For this we will use an ad-hoc Ansible command: a single task executed via Ansible, without the need to write an entire playbook. We will use the shell module because it supports piping, and can thus chain multiple commands together. In a terminal of your VS Code online editor, run the following command:
 
 <!-- {% raw %} -->
 ```bash

exercises/ansible_security/2.3-incident/README.md

@@ -225,7 +225,7 @@ Run the playbook, to effectively blacklist the IP:
 [student<X>@ansible ~]$ ansible-playbook incident_blacklist.yml
 ```
 
-In your QRadar UI, verify in the Log Activity tab that you do not receive any more alerts from Snort. Note that, if you would have connected the firewall to QRadar, theere would actually be logs coming in from there.
+In your QRadar UI, verify in the Log Activity tab that you do not receive any more alerts from Snort. Note that, if you would have connected the firewall to QRadar, there would actually be logs coming in from there.
 
 Also, let's quickly verify that the new rule was added to Check Point: Access the Windows workstation and open the SmartConsole interface. On the left side, click on **SECURITY POLICIES** and note that the access control policy entry changed from **Accept** to **Drop**.
 

exercises/ansible_security/README.md

@@ -2,7 +2,7 @@
 
 Ansible is a simple yet powerful IT automation engine for application deployment, configuration management, and orchestration that you can learn quickly. Ansible Security Automation is our expansion deeper into the security use case. The goal is to provide a more efficient, streamlined way for security teams to automate their various processes for the identification, search, and response to security events.
 
-In this workshop shows you will learn - step by step - how you can use Ansible to orchestrate 3 security investigation and response activities involving multiple security tools: an enterprise firewall (CheckPoint Next Generation Firewall), an intrusion detection system (Snort) and a SIEM (IBM QRadar).
+In this workshop you will learn - step by step - how you can use Ansible to orchestrate 3 security investigation and response activities involving multiple security tools: an enterprise firewall (CheckPoint Next Generation Firewall), an intrusion detection system (Snort) and a SIEM (IBM QRadar).
 
 **Read this in other languages**: [![uk](../../images/uk.png) English](README.md).