Merge pull request #7911 from wazuh/enhancement/edr3551-update-AR_mod…

…ule-naming

Capitalize Active Response module  references

source/compliance/hipaa/active-response.rst

@@ -1,23 +1,23 @@
 .. Copyright (C) 2015, Wazuh, Inc.
 
 .. meta::
-  :description: The active response module assists in meeting HIPAA compliance. Learn more about it in this section of the Wazuh documentation.
+  :description: The Active Response module assists in meeting HIPAA compliance. Learn more about it in this section of the Wazuh documentation.
 
 Active response
 ===============
 
-The Wazuh active response module is configured to automatically execute scripts when events match specified rules in the Wazuh ruleset. These scripts may perform a firewall block or drop, traffic shaping or throttling, account lockout, or any other user defined action.
+The Wazuh Active Response module is configured to automatically execute scripts when events match specified rules in the Wazuh ruleset. These scripts may perform a firewall block or drop, traffic shaping or throttling, account lockout, or any other user defined action.
 
-The active response module assists in meeting the following HIPAA section:
+The Active Response module assists in meeting the following HIPAA section:
 
 - **Security Incident Procedures §164.308(a)(6)(i) - Response and Reporting**: *“Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.”*
 
-  The goal of this section is to make sure that you detect and respond to security incidents in your environment. The active response module assists in meeting this HIPAA section by responding to intrusions and unauthorized file changes. For more information on configuring active response, see the :doc:`active response  </user-manual/capabilities/active-response/index>` section of our documentation.
+  The goal of this section is to make sure that you detect and respond to security incidents in your environment. The Active Response module assists in meeting this HIPAA section by responding to intrusions and unauthorized file changes. For more information on configuring Active Response, see the :doc:`Active Response  </user-manual/capabilities/active-response/index>` section of our documentation.
 
 Use case: Block an IP address
 -----------------------------
 
-In this use case, you configure the active response module to block an IP address when someone attempts to log in to an Ubuntu 22.04 endpoint with a non-existent user via SSH. To implement this, follow the steps below:
+In this use case, you configure the Active Response module to block an IP address when someone attempts to log in to an Ubuntu 22.04 endpoint with a non-existent user via SSH. To implement this, follow the steps below:
 
 #. Add the following block to the Wazuh server configuration file (``/var/ossec/etc/ossec.conf``).
 
@@ -30,7 +30,7 @@ In this use case, you configure the active response module to block an IP addres
           <timeout>100</timeout>
         </active-response>
 
-   This configures the active response to execute the ``firewall-drop`` command when there is an attempt to log in to a non-existent user (rule ``5710``).
+   This configures the Active Response to execute the ``firewall-drop`` command when there is an attempt to log in to a non-existent user (rule ``5710``).
 
    .. note::
 
@@ -40,14 +40,14 @@ In this use case, you configure the active response module to block an IP addres
 
    .. include:: /_templates/common/restart_manager.rst
 
-   When you attempt to SSH with a non-existent user, rule ``5710`` generates an alert followed by an active response event.
+   When you attempt to SSH with a non-existent user, rule ``5710`` generates an alert followed by an Active Response event.
 
    .. thumbnail:: /images/compliance/hipaa/08-active-response.png    
-      :title: Rule 5710 generates an alert followed by an active response event 
+      :title: Rule 5710 generates an alert followed by an Active Response event
       :align: center
       :width: 80%
 
    .. thumbnail:: /images/compliance/hipaa/09-active-response.png    
-      :title: Rule 5710 generates an alert followed by an active response event 
+      :title: Rule 5710 generates an alert followed by an Active Response event
       :align: center
       :width: 80%      

source/compliance/nist/active-response.rst

@@ -1,27 +1,27 @@
 .. Copyright (C) 2015, Wazuh, Inc.
 
 .. meta::
-  :description: The active response module performs autonomous actions on endpoints to mitigate security threats. Learn more about it in this section of the documentation.
+  :description: The Active Response module performs autonomous actions on endpoints to mitigate security threats. Learn more about it in this section of the documentation.
 
 Active response
 ===============
 
-The Wazuh active response module performs autonomous actions on endpoints to mitigate security threats. You can  configure the module to automatically execute scripts when specific alerts trigger. These scripts execute actions, such as a firewall block or drop, traffic shaping or throttling, and account lockout.
+The Wazuh Active Response module performs autonomous actions on endpoints to mitigate security threats. You can  configure the module to automatically execute scripts when specific alerts trigger. These scripts execute actions, such as a firewall block or drop, traffic shaping or throttling, and account lockout.
 
-The Wazuh :doc:`active response </user-manual/capabilities/active-response/index>` module assists in meeting the following NIST 800-53 controls: 
+The Wazuh :doc:`Active Response </user-manual/capabilities/active-response/index>` module assists in meeting the following NIST 800-53 controls:
 
 - **AC-7 Unsuccessful logon attempts**: *“The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically released after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need.”*
 
 - **SC-5 Denial-of-service protection**: *“Denial-of-service events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of denial-of-service events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of denial-of-service attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to denial-of-service events.”*
 
-The Wazuh active response module assists in meeting the above controls by responding to brute force and denial of service attacks. Wazuh includes out-of-the-box active response commands that drop traffic from a malicious IP address or disable a user account that is a victim of brute forcing.
+The Wazuh Active Response module assists in meeting the above controls by responding to brute force and denial of service attacks. Wazuh includes out-of-the-box active response commands that drop traffic from a malicious IP address or disable a user account that is a victim of brute forcing.
 
 Use case: Automatically disable an account
 ------------------------------------------
 
 This use case shows how Wazuh helps meet the NIST **AC-7 Unsuccessful logon attempts** requirement by identifying and taking precautionary responses to failed login attempts.
 
-In this scenario, the Wazuh active response module automatically disables a user account on a monitored Ubuntu 22.04 endpoint when events analysis detects multiple failed terminal login attempts. You can then track the alerts for these events and actions on the Wazuh dashboard.
+In this scenario, the Wazuh Active Response module automatically disables a user account on a monitored Ubuntu 22.04 endpoint when events analysis detects multiple failed terminal login attempts. You can then track the alerts for these events and actions on the Wazuh dashboard.
 
 Wazuh server
 ^^^^^^^^^^^^

source/compliance/pci-dss/active-response.rst

@@ -1,30 +1,30 @@
 .. Copyright (C) 2015, Wazuh, Inc.
 
 .. meta::
-  :description: Active response allows the execution of scripts when an event matches certain rules in the Wazuh ruleset. Learn more about it in this section.
+  :description: Active Response allows the execution of scripts when an event matches certain rules in the Wazuh ruleset. Learn more about it in this section.
 
 .. _pci_dss_active_response:
 
-Active response
+Active Response
 ===============
 
-Active response allows the execution of scripts whenever an event matches certain rules in your Wazuh ruleset. The actions executed could be a firewall block or drop, traffic shaping or throttling, or account lockout, among others.
+Active Response allows the execution of scripts whenever an event matches certain rules in your Wazuh ruleset. The actions executed could be a firewall block or drop, traffic shaping or throttling, or account lockout, among others.
 
-The active response module helps to meet the following PCI DSS requirement:
+The Active Response module helps to meet the following PCI DSS requirement:
 
 -  **Requirement 11 - Test Security of Systems and Networks Regularly**: Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. 
 
-This requirement aims to ensure that you test your systems and networks regularly. Testing allows you to detect and respond to security status and possible intrusions. With the active response module, you can respond to intrusions and unauthorized file changes. You can find more details on configuring the active response module in the :doc:`active response </user-manual/capabilities/active-response/index>` documentation section.
+This requirement aims to ensure that you test your systems and networks regularly. Testing allows you to detect and respond to security status and possible intrusions. With the Active Response module, you can respond to intrusions and unauthorized file changes. You can find more details on configuring the Active Response module in the :doc:`Active Response </user-manual/capabilities/active-response/index>` documentation section.
 
 
 Use cases
 ---------
 
 -  PCI DSS 11.5 requires that you detect and respond to network intrusions and unexpected file changes. You can configure scripts to run when specific actions occur to respond to these intrusions. Wazuh comes with preconfigured active response scripts. Refer to the :doc:`Default Active response scripts section </user-manual/capabilities/active-response/default-active-response-scripts>` to access these scripts.
 
-   Using the steps below, we configure the active response module to execute an IP block when an attempt to log in with a non-existent user via SSH occurs.
+   Using the steps below, we configure the Active Response module to execute an IP block when an attempt to log in with a non-existent user via SSH occurs.
 
-   #. Configure the active response to execute the ``firewall-drop`` command when the rule for attempts to log in to a non-existent user is triggered (rule 5710) by adding the following block in the manager configuration file (``/var/ossec/etc/ossec.conf``):
+   #. Configure the Active Response to execute the ``firewall-drop`` command when the rule for attempts to log in to a non-existent user is triggered (rule 5710) by adding the following block in the manager configuration file (``/var/ossec/etc/ossec.conf``):
 
       .. code-block:: xml
          :emphasize-lines: 4

source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-agent-class.rst

@@ -18,7 +18,7 @@ This contains variables that can be used to configure the Wazuh agent.
 Active-Response variables
 -------------------------
 $configure_active_response
-  Enables active response on this host.
+  Enables Active Response on this host.
 
   `Default true`
 

source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-manager-class.rst

@@ -1230,7 +1230,7 @@ $active_response_rules_id
   `Default []`
 
 $active_response_timeout
-  Usually active response blocks for a certain amount of time.
+  Usually Active Response blocks for a certain amount of time.
 
   `Default undef`
 

source/getting-started/use-cases/file-integrity.rst

@@ -89,13 +89,13 @@ The Wazuh FIM module supports various integrations, including but not limited to
 
 -  **File integrity monitoring and YARA**: By combining the Wazuh FIM module and the YARA tool, it is possible to detect malware when suspicious file additions or modifications are identified. The YARA rule files contain samples of malware indicators that are downloaded to the monitored endpoints. When the FIM module detects a change in the monitored file or directory, it executes a YARA scan using a script to determine if it is malware. If the YARA rule finds a match with a file, it will send the scan results to the Wazuh server for decoding and alerting. This would be reported according to the custom rule and decoder configurations configured on the Wazuh server. Check this documentation for more information on :doc:`how to integrate the Wazuh FIM module with YARA </user-manual/capabilities/malware-detection/fim-yara>`.
 -  **File integrity monitoring and VirusTotal**: The Wazuh :doc:`Integrator module </user-manual/reference/ossec-conf/integration>` connects to external APIs and alerting tools such as VirusTotal. The :doc:`VirusTotal integration </user-manual/capabilities/malware-detection/virus-total-integration>` uses the VirusTotal API to detect malicious file hashes within the files and directories monitored by the FIM module. Once enabled, when FIM generates alerts, Wazuh initiates the VirusTotal integration to extract the hash value associated with the flagged file from the alert. The VirusTotal API is then used to compare these hashes against its scanning engines for potentially malicious content.
--  **File integrity monitoring and active response**: The :doc:`Wazuh active response </user-manual/capabilities/active-response/index>` module automatically responds to threats identified in a timely manner. This combination enables the FIM module to not only detect but also respond to malicious activities. You can configure active response scripts to execute when the FIM module detects file changes in your monitored environment.  Additionally, it also generates alerts for the response performed. This reduces the Mean Time To Respond (MTTR) as malicious changes detected are remediated in a timely manner.
+-  **File integrity monitoring and Active Response**: The :doc:`Wazuh Active Response </user-manual/capabilities/active-response/index>` module automatically responds to threats identified in a timely manner. This combination enables the FIM module to not only detect but also respond to malicious activities. You can configure active response scripts to execute when the FIM module detects file changes in your monitored environment.  Additionally, it also generates alerts for the response performed. This reduces the Mean Time To Respond (MTTR) as malicious changes detected are remediated in a timely manner.
 
-   In the image below Wazuh triggers when a file is added to the monitored endpoint. The VirusTotal API scans the file and identifies it as malicious content on 55 engines. Then the Wazuh active response module acts immediately to remove the threat from the monitored endpoint.
+   In the image below Wazuh triggers when a file is added to the monitored endpoint. The VirusTotal API scans the file and identifies it as malicious content on 55 engines. Then the Wazuh Active Response module acts immediately to remove the threat from the monitored endpoint.
 
    .. thumbnail:: /images/getting-started/use-cases/fim/fim-ar-virustotal-alerts.png
-      :title: FIM and active response using VirusTotal alerts
-      :alt: FIM and active response using VirusTotal alerts
+      :title: FIM and Active Response using VirusTotal alerts
+      :alt: FIM and Active Response using VirusTotal alerts
       :align: center
       :width: 80%