Custom Rules (#38)

* Add API Documentation

* Other Changes

* Custom Rules

Author: alaynsn

Correlation Rules/CustomizableRules.md

@@ -7,10 +7,32 @@ nav_order: 3
 
 # Customizable Rules
 
-UTMStack allows users to define customizable rules to enhance the monitoring and alerting based on specific requirements of their network environments. Below are a few examples of such customizable rules, each tailored for different use-cases:
+UTMStack allows users to define customizable rules to enhance the monitoring and alerting based on specific requirements of their network environments. 
 
-## Rule 1: Whitelist of Internal IPs
-Users can define a whitelist of internal IPs that are considered safe. Any activity detected from IPs not in this whitelist will trigger an alert.
+## Follow these steps:
+
+1. Access the directory where the system correlation rules are located.
+<img title="Menu Correleation Rules" alt="Menu Correleation Rules" src="../Images/menu_custom_rules.png">
+
+2. Select the folder named "custom", intended for custom rules.
+<img title="Directory Correleation Rules" alt="Directory Correleation Rules" src="../Images/directory_custom_rules.png">
+
+3. Add, copy, paste or move your customized rules to this folder.
+<img title="Create Correleation Rules" alt="Create Correleation Rules" src="../Images/new_custom_rules.png">
+
+4. Check that they are correctly placed and that their names match the system rules you want to modify.
+
+## Modifying system rules:
+
+If you need to adjust a system rule, simply create a new custom rule with the same name as the system rule you wish to modify. This will allow your custom rule to take precedence over the original system rule.
+
+## Rule Priority:
+
+Remember that if there is a custom rule and a system rule with the same name, the custom rule will be used instead of the system rule. This ensures that your settings take priority and are applied by the system instead of the default rules.
+
+Below are a few examples of such customizable rules, each tailored for different use-cases:
+
+## 1. Windows: Activity detected from non-whitelisted internal IPs
 
 ### YAML Configuration:
 ```yaml
@@ -19,7 +41,8 @@ Users can define a whitelist of internal IPs that are considered safe. Any activ
   description: "Activity has been detected from an IP that is not on the whitelist of allowed internal IPs"
   solution: "We recommend carefully reviewing the logs to verify activity from an IP that is not on the whitelist of allowed internal IPs"
   category: "Connection from non-whitelisted"
-  tactic: ""
+  tactic: "Exfiltration"
+  dataTypes: ["wineventlog"]
   reference: 
     - "https://en.wikipedia.org/wiki/Whitelist"
   frequency: 60
@@ -36,26 +59,31 @@ Users can define a whitelist of internal IPs that are considered safe. Any activ
       save:
         - field: "logx.wineventlog.event_data.SubjectUserName"
           alias: "SourceUser"
+        - field: "logx.wineventlog.host.name"
+          alias: "DestinationHost"
+        - field: "logx.wineventlog.event_data.IpAddress"
+          alias: "DestinationIP"
+        - field: "logx.wineventlog.event_data.IpPort"
+          alias: "DestinationPort"
         - field: "logx.wineventlog.event_data.TargetUserName"
           alias: "DestinationUser"
-        - field: "logx.wineventlog.host.name"
-          alias: "SourceHost"
 ```
 
 ###  Example
-In this rule, an alert is generated if there is any activity detected from IPs not listed in the whitelist 10.0.2.27,192.168.22.128,fe80::97d1:5df4:10fe:7b8d.
+In this rule, users can define their whitelist of internal IPs. As an example, you have the internal IPs whitelist 10.0.2.27,192.168.22.128,fe80::97d1:5df4:10fe:7b8d Which you can change to your list
+
 
-## Rule 2: Whitelist of Allowed Applications
-Users can define a whitelist of applications that are permitted to run on the servers. Any activity detected from applications not in this whitelist will trigger an alert.
+## 2. Windows: Detected application that is not in the white list of allowed applications
 
 ### YAML Configuration:
-``` yml
+```yaml
 - name: "Windows: Detected application that is not in the white list of allowed applications"
   severity: "High"
   description: "This alert is generated when an application that is not on the white list of allowed applications is detected."
   solution: "We recommend carefully reviewing the logs to verify applications that are not whitelisted"
   category: "Connection from non-whitelisted"
   tactic: ""
+  dataTypes: ["wineventlog"]
   reference: 
     - "https://en.wikipedia.org/wiki/Whitelist"
   frequency: 60
@@ -78,28 +106,30 @@ Users can define a whitelist of applications that are permitted to run on the se
       save:
         - field: "logx.wineventlog.event_data.SubjectUserName"
           alias: "SourceUser"
+        - field: "logx.wineventlog.host.name"
+          alias: "DestinationHost"
+        - field: "logx.wineventlog.event_data.IpAddress"
+          alias: "DestinationIP"
+        - field: "logx.wineventlog.event_data.IpPort"
+          alias: "DestinationPort"
         - field: "logx.wineventlog.event_data.TargetUserName"
           alias: "DestinationUser"
-        - field: "logx.wineventlog.host.name"
-          alias: "SourceHost"
 ```
 
-### Example
-In this rule, an alert is generated if any application other than svchost.exe, services.exe, or poqexec.exe is detected running on the servers.
-
-## Rule 3: Whitelist of IPs for Microsoft 365 Logins
+###  Example
+In this rule, users can define their whitelist of applications that are allowed to be on the servers and have activity. As an example, you have the whitelist of applications (svchost.exe|services.exe|poqexec.exe), which you can change to your list
 
-Users can define a whitelist of IPs from which logins to Microsoft 365 are allowed. Any login attempts from IPs not in this whitelist will trigger an alert.
+## 3. Microsoft 365: Login detected from non-whitelisted IP
 
 ### YAML Configuration:
-
-``` yml
+```yaml
 - name: "Microsoft 365: Login detected from non-whitelisted IP"
   severity: "High"
   description: "A user is trying to login from an IP that is not on the whitelist"
   solution: "We recommend carefully reviewing the logs to verify users attempting to login from an IP that is not on the whitelist"
   category: "Connection from non-whitelisted"
   tactic: ""
+  dataTypes: ["o365"]
   reference: 
     - "https://en.wikipedia.org/wiki/Whitelist"
   frequency: 60
@@ -124,57 +154,51 @@ Users can define a whitelist of IPs from which logins to Microsoft 365 are allow
 
 ```
 
-### Example
-In this rule, an alert is generated if a user tries to login to Microsoft 365 from any IP other than 163.225.184.79, 92.22.1.40, 19.144.24.179, 37e4:dd49:a173:02f4:3164:1df0:8849:6ef9.
-
-
-## Rule 4: Whitelist of Allowed Users for Microsoft 365 Activity
+###  Example
+In this rule, you can define their whitelist of IPs. As an example, you have the ips whitelist 163.225.184.79,92.22.1.40,19.144.24.179,37e4:dd49:a173:02f4:3164:1df0:8849:6ef9 which you can change to your list
 
-Users can define a whitelist of user accounts that are allowed to have activity in Microsoft 365. Any activity from user accounts not in this whitelist will trigger an alert.
+## 4. Microsoft 365: Detected user activity that is not in the white list of allowed users
 
 ### YAML Configuration:
-
-``` yml
-- name: "Microsoft 365: Activity detected from non-whitelisted user"
+```yaml
+- name: "Microsoft 365: Detected user activity that is not in the white list of allowed users"
   severity: "High"
-  description: "Activity has been detected from a user that is not on the whitelist"
-  solution: "We recommend carefully reviewing the logs to verify activity from a user that is not on the whitelist"
+  description: "This alert is generated when a user is detected that is not on the white list of allowed users."
+  solution: "We recommend carefully reviewing the logs to verify users who are not whitelisted."
   category: "Connection from non-whitelisted"
   tactic: ""
+  dataTypes: ["o365"]
   reference: 
     - "https://en.wikipedia.org/wiki/Whitelist"
   frequency: 60
   cache:
-    - allOf:
+    - allOf: 
         - field: "logx.o365.UserId"
           operator: "not in"
-          value: "john.doe@example.com,jane.doe@example.com"
-        - field: "logx.o365.ResultStatus"
-          operator: "in"
-          value: "Success,PartiallySucceeded,True"
+          value: "cafroixeunnouxe-7608@yopmail.com,bineppohuno-6676@yopmail.com,keven_mohr@gmail.com"
       minCount: 1
       timeLapse: 60
       save:
         - field: "logx.o365.UserId"
           alias: "SourceUser"
-```
-
-### Example:
-In this rule, an alert is generated if any activity is detected from user accounts other than john.doe@example.com or jane.doe@example.com in Microsoft 365.
+        - field: "logx.o365.ClientIP"
+          alias: "SourceIP"
 
-## Rule 5: Windows User Activity Outside Whitelist Detected
+```
+###  Example
+In this rule, you can define your whitelist of users who can have activity. As an example, you have the whitelist of users cafroixeunnouxe-7608@yopmail.com,bineppohuno-6676@yopmail.com,keven_mohr@gmail.com which you can change to your list
 
-In this rule, you can define a whitelist of users who are authorized to carry out activities on the Windows environment. For instance, the whitelist of users is specified as cafroixeunnouxe-7608@yopmail.com, bineppohuno-6676@yopmail.com, and keven_mohr@gmail.com, which can be tailored to match your list of authorized users. Users should be delineated by commas.
+## 5. Windows: Detected user activity that is not in the white list of allowed users
 
 ### YAML Configuration:
-
-``` yml
+```yaml
 - name: "Windows: Detected user activity that is not in the white list of allowed users"
   severity: "High"
   description: "This alert is generated when a user is detected that is not on the white list of allowed users."
   solution: "We recommend carefully reviewing the logs to verify users who are not whitelisted."
   category: "Connection from non-whitelisted"
   tactic: ""
+  dataTypes: ["wineventlog"]
   reference: 
     - "https://en.wikipedia.org/wiki/Whitelist"
   frequency: 60
@@ -188,12 +212,14 @@ In this rule, you can define a whitelist of users who are authorized to carry ou
       save:
         - field: "logx.wineventlog.event_data.SubjectUserName"
           alias: "SourceUser"
+        - field: "logx.wineventlog.host.name"
+          alias: "DestinationHost"
+        - field: "logx.wineventlog.event_data.IpAddress"
+          alias: "DestinationIP"
+        - field: "logx.wineventlog.event_data.IpPort"
+          alias: "DestinationPort"
         - field: "logx.wineventlog.event_data.TargetUserName"
           alias: "DestinationUser"
-        - field: "logx.wineventlog.host.name"
-          alias: "SourceHost"
-
 ```
-
-### Example:
-In this rule configuration, an alert is triggered whenever user activity is detected from accounts other than those listed in the whitelist: cafroixeunnouxe-7608@yopmail.com, bineppohuno-6676@yopmail.com, and keven_mohr@gmail.com. The aim is to promptly identify and respond to potential unauthorized access or malicious activities by unlisted users within the Windows environment.
+###  Example
+In this rule, you can define your whitelist of users who can have activity. As an example, you have the whitelist of users cafroixeunnouxe-7608@yopmail.com,bineppohuno-6676@yopmail.com,keven_mohr@gmail.com which you can change to your list