up

Author: buixor

crowdsec-docs/docs/appsec/alerts_and_scenarios.md

@@ -6,33 +6,33 @@ sidebar_position: 5
 
 ## Generated Events Layout
 
-When HTTP Requests trigger _InBand_ or _OutOfBand_ AppSec/WAF rules, an event is generated. Events can be used to create scenarios that will react (ban, alerts etc.) when AppSec/WAF rules are matched. 
+HTTP requests that trigger _In-Band_ or _Out-Of-Band_ AppSec/WAF rules generate events. These events can trigger scenarios that react by banning or alerting when rules are matched.
 
-The [`crowdsecurity/appsec-logs` parser](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-logs) is used to parse those events and turn them into events that are easier to process with scenarios. 
+The [`crowdsecurity/appsec-logs` parser](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-logs) is designed as a general-purpose tool to convert events into a format that is easier to process with scenarios.
 
 
-The generated event looks like:
+The generated event looks like this:
 
  - `evt.Meta.service` is set to `appsec`
  - `evt.Meta.log_type`:
-    - `appsec-block` for blocked requests (_InBand_ rule matched for ex)
-    - `appsec-info` for reuqests that triggered _OutOfBand_ rule (not blocked)
+    - `appsec-block` for blocked requests (_In-Band_ rule matched, for example)
+    - `appsec-info` for requests that triggered _Out-Of-Band_ rule (not blocked)
  - `evt.Meta.source_ip` is set to the source (client) IP
  - `evt.Meta.target_host` is set to the FQDN if present (`Host` header in the HTTP request)
- - `evt.Meta.target_uri` is set to the full URI of the HTTP request
+ - `evt.Meta.target_uri` is set to the complete URI of the HTTP request
  - `evt.Meta.rule_name` is set to the name of the triggered rule
  - `evt.Meta.remediation_cmpt_ip` is set to the IP of the Remediation Component (Bouncer) that sent the HTTP request.
 
 :::info
-The [`crowdsecurity/appsec-logs` parser](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-logs) is already part of the generic AppSec/WAF collections, and doesn't have to be manually installed.
+The [`crowdsecurity/appsec-logs` parser](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-logs) is already part of the generic AppSec/WAF collections and doesn't have to be manually installed.
 :::
 
 
 ## Creating Scenario Based on AppSec/WAF Events
 
-### Triggering on InBand Rules
+### Triggering on _In-Band_ Rules
 
-A simple yet effective example is the [`crowdsecurity/appsec-vpatch` scenario](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-vpatch) that will ban IPs triggering two distinct _InBand_ rules:
+A simple yexample is the [`crowdsecurity/appsec-vpatch` scenario](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-vpatch) that will ban IPs triggering two distinct _In-Band_ rules:
 
 ```yaml title="/etc/crowdsec/scenarios/appsec-vpatch.yaml"
 type: leaky
@@ -49,14 +49,14 @@ groupby: evt.Meta.source_ip
 The [`crowdsecurity/appsec-vpatch` scenario](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-vpatch) is already part of the generic AppSec/WAF collections, and doesn't have to be manually installed.
 :::
 
-### Triggering on OutOfBand Rules
+### Triggering on Out-Of-Band Rules
 
 Let's try to solve an imaginary scenario:
 
-> We want to block users enumerating some URLs (`/foobar/*`) when a specific HTTP header is set (`something: *test*`). However, we only want to block/ban users that will try to access 2 or more distinct `/foobar/*` URLs while having this header set.
+> We aim to prevent users from enumerating certain URLs (specifically, those that begin with `/foobar/*`) when a particular HTTP header is present (`something: *test*`). However, we want to impose this restriction only on users attempting to access two or more distinct `/foobar/*` URLs while this header is set.
 
 :::info
-Keep in mind that _OutOfBand_ rules will  generate an event instead of blocking the HTTP Request.
+Keep in mind that _Out-Of-Band_ rules will  generate an event instead of blocking the HTTP Request.
 :::
 
 #### The AppSec/WAF Rule
@@ -85,7 +85,7 @@ rules:
       value: test
 ```
 
-Let ensure it's loaded as an _OutOfBand_ rule, first by creating a new appsec-config:
+Let ensure it's loaded as an _Out-Of-Band_ rule, first by creating a new appsec-config:
 
 ```yaml title="/etc/crowdsec/appsec-configs/appsec-oob.yaml"
 name: crowdsecurity/appsec-oob
@@ -127,7 +127,7 @@ labels:
 ```
 
 :::info
-The `filter` ensures only OutOfBand events generated by our scenario are picked up, while the `capacity: 1` and `distinct: evt.Meta.target_uri` will ensure that the IP has to trigger the rule on at least 2 distinct URLs to trigger the scenario.
+The `filter` ensures only _Out-Of-Band_ events generated by our scenario are picked up, while the `capacity: 1` and `distinct: evt.Meta.target_uri` will ensure that the IP has to trigger the rule on at least 2 distinct URLs to trigger the scenario.
 :::
 
 #### Testing

crowdsec-docs/docs/appsec/benchmark.md

@@ -33,8 +33,8 @@ The benchmarks cover the following tests:
 Each test has been run with multiple cases:
 
 - Application Security Component enabled but without any rules
-- Application Security Component enabled with 100 vpatch rules (in inband)
-- Application Security Component enabled with all the CRS (in inband)
+- Application Security Component enabled with 100 vpatch rules (in in-band)
+- Application Security Component enabled with all the CRS (in in-band)
 
 On the system, we deployed:
 

crowdsec-docs/docs/appsec/configuration.md

@@ -10,7 +10,7 @@ Configuring the AppSec Component usually requires the use of multiple files:
 
  - [AppSec rules](/appsec/rules_syntax.md) allow you to write a signature to detect and/or block malevolent requests. [You can find more information about the syntax here](/appsec/rules_syntax.md)
  - [acquisition configuration](/data_sources/appsec.md) indicates which port is the AppSec Component listening on, and which AppSec configuration it will use.
- - AppSec configuration tells which rules are loaded in inband (blocking) and out-of-band (non-blocking)
+ - AppSec configuration tells which rules are loaded in in-band (blocking) and out-of-band (non-blocking)
   phases. [it as well allows you to tweak the behavior of the component via the powerful expr bindings](/appsec/rules_syntax.md)
 
 
@@ -40,11 +40,11 @@ A supplementary list of rules can be loaded during the out-of-band phase. These
 
 ### `inband_rules`
 
-An optional list of rules to be loaded in inband phase. In band rules are blocking and evaluated before answering the remediation component. Useful for virtual patching, rules with no/low false positives.
+An optional list of rules to be loaded in in-band phase. In band rules are blocking and evaluated before answering the remediation component. Useful for virtual patching, rules with no/low false positives.
 
 ### `default_remediation`
 
-An optional remediation for inband rules, defaults to `ban`. If set to `allow`, remediation component won't block the request (even if it matched rules). Any other value (including `captcha`) is passed as-is back to the remediation component.
+An optional remediation for in-band rules, defaults to `ban`. If set to `allow`, remediation component won't block the request (even if it matched rules). Any other value (including `captcha`) is passed as-is back to the remediation component.
 
 ### `default_pass_action`
 
@@ -84,6 +84,6 @@ See the [dedicated doc](/docs/appsec/hooks.md#on_match)
 
 ### `inband_options` and `outofband_options`
 
-Subset of options that can be applied to the inband/outofband rules:
+Subset of options that can be applied to the in-band/out-of-band rules:
  - `disable_body_inspection` : boolean, allows to disable HTTP body inspection
  - `request_body_in_memory_limit` : a number of byes indicating the maximum body size to be loaded in memory

crowdsec-docs/docs/appsec/installation.md

@@ -24,7 +24,7 @@ To have a functional AppSec Component, you need:
 Before diving into the practical steps, it's crucial to familiarize yourself with the core configuration aspects of the AppSec Component:
 
 - **acquisition configuration**: Specifies how to acquire the AppSec Component stream of data
-- **AppSec Component configuration**: Tells which rules are loaded in inband (blocking) and out-of-band (non-blocking)
+- **AppSec Component configuration**: Tells which rules are loaded in in-band (blocking) and out-of-band (non-blocking)
   phases, [and allows tweaking the behavior of the component via the powerful expr bindings](/appsec/hooks.md). <!--@sbl we need anchor for the on_whatever and expr helpers -->
 - **rules** allow writing a [signature to detect and/or block malevolent requests](/appsec/rules_syntax.md).