Enhance QA content

docs/xdr/FAQ/Detection_qa.md

@@ -1,63 +1,106 @@
-## Documentation
+# Sekoia.io Detection Strategy
 
-**A [Sekoia.io](http://Sekoia.io) rule was changed, where could I get the information of any change in the rules catalog?**
-
-We created a rules changelog page where you can get this information: https://docs.sekoia.io/xdr/features/detect/rules_changelog/. For the new rules added to the catalog, you can active a notification in our platform directly.
+## A Sekoia.io rule was changed, how can I be notified when there is any change in the Rules Catalog?
 
-**I want to map the EventIDs with the rules from [Sekoia.io](http://Sekoia.io) to know which ones I need to collect or not, where can I find this information?**
-
-This information can be found here: https://docs.sekoia.io/xdr/features/detect/built_in_detection_rules_eventids/. Please read the page carefully, note that the page is generated **automatically**.
+You can easily stay informed about changes in the Rules Catalog. We provide a [dedicated Rules changelog page](https://docs.sekoia.io/xdr/features/detect/rules_changelog/) where you can find details about what changes were made to existing rules.
+
+For new rules, you can directly enable notifications within the Sekoia.io platform to receive alerts. Go to the Notifications tool, create a new notification and select `A new rule is added to the Rules Catalog by Sekoia.io` as the trigger. 
+
+
+## I want to map the EventIDs with the rules from Sekoia.io to know which ones I need to collect or not, where can I find this information?
+
+Easily find the mapping between EventIDs, rules, and EventProviders in our comprehensive guide: [Built-in detection rules, EventIDs and EventProviders relations](https://docs.sekoia.io/xdr/features/detect/built_in_detection_rules_eventids/). This page provides a clear overview of which EventIDs are associated with specific rules and their corresponding sources.
 
-**In the documentation I can see rules mapped to intakes which make no sense, and sometimes rules are not mapped, could you fix that please?**
+Please note that this information is automatically generated, so double-check for any discrepancies.
 
-These pages are generated automatically from the fields present in the rules and the fields present in the intakes. 
+## In the documentation, I see incorrect rule-to-intake mappings, and some rules are missing. Could you fix this please?
 
-Furthermore there’s still some work in progress to include rules with Sekoia tags and Correlation rules.
+We understand your concerns. The rule-to-intake mappings and rule listings you see in the documentation are automatically generated based on the fields present both in the rules and the intakes. This means any inconsistencies in this data can be reflected in the documentation.
 
-## Detection strategy
+We are actively working on improving the documentation by:
 
-**Which Detection perimeter?**
+- Adding support for **Sekoia tags**: This will allow for more accurate rule categorization and mapping.
+- Including **Correlation rules**: These rules will be displayed alongside other detection rules for a complete picture.
+
+## What is the focus of your detection perimeter?
 
-In 2024 the ideal detection perimeter should monitor at least the following areas: 
+In 2024, the ideal detection perimeter should monitor at least the following areas: 
+
 - Endpoint for workstations and servers
 - Network outbound/inbound connections
 - Cloud office applications
 - Identity management
 
-**Have you created rules for the last CVE-XXXXXX? Why not?**
-
-We don’t create rules for CVEs because they often depends on the customer’s environment (so it’s not really generic) and it would be highly time consuming, especially since they are not the most useful rules in our opinion. Most of the time when an attacker exploits a vulnerability, he would still need to perform the actions he usually does: lateral movement, persistence, etc.
-
-For that reason, we would rather focus instead of the common TTPs to detect actions perform by attackers whether there’s a vulnerability exploited or not.
-
-That said, if a new vulnerability like ZeroLogon (allows directly from user to domain admin in an AD environment) is published, we will look if there’s a way to detect it. In that case, it directly impacts most of our customers and also allows the attacker to bypass most of the commonly used TTPs.
-
-**Can you change the similarity strategy for the rule X? (grouping of events into Alerts)**
-
-We always try to find the best similarity strategy that enables efficiency and productivity for the SOC analysts handling alerts.
+## Have you created rules for specific vulnerabilities (CVEs)? Why not? 
 
-That being said, not all SOC teams have the same workflow and needs on how to group events into Alerts. So if the existing similarity strategy is not well suited for your context, we recommend you to duplicate the detection rule, via copy/pasting the detection pattern and the different rule parameters, and applying the similarity strategy you like.
-
-**Could you create a rule for "this detection use case"?**
-
-Thank you for the suggestion. Please note that you can create your own rules in Sekoia.io.
+We prioritize detection based on common Tactics, Techniques, and Procedures (TTPs) employed by attackers, rather than focusing solely on individual vulnerabilities (CVEs). Here's why:
+
+- CVEs often depend heavily on a customer's specific environment, making detection rules based solely on them less broadly applicable.
+- Continuously creating and maintaining rules for every new CVE is resource-intensive and inefficient.
+- Attackers, regardless of the specific vulnerability exploited, often exhibit similar behaviors during lateral movement, persistence, and other stages of an attack. By focusing on these common TTPs, we can achieve broader and more efficient threat detection.
+
+**Exceptions for High-Impact Vulnerabilities**
+
+We do make exceptions for highly impactful vulnerabilities that pose a significant threat and potentially bypass standard security controls. In such cases, we prioritize developing specific detection rules to address risks associated with these vulnerabilities. For instance, if a vulnerability like [ZeroLogon](https://app.sekoia.io/intelligence/objects/vulnerability--f0cce579-8483-4839-9da2-14bb266928a8) is published, we will look if there’s a way to detect it since it directly impacts most of our customers. 
 
-That said if you want the rule to be managed by Sekoia.io, we will ask our detection engineering team which will come back to you in two weeks to assess whether they will perform the rule or not, and when will they deliver the rule.
-
-**Why did this phishing email go undetected by your cybersecurity product?**
-
-It's important to understand that our product is not primarily an anti-phishing tool. While we do incorporate IOCs related to phishing during our investigations and from reports, our main focus is not on phishing detection but rather on what's happening afterwards. Therefore, our database is not exhaustive in terms of phishing threats. We recommend using a dedicated anti-phishing tool in conjunction with our product for comprehensive protection against phishing attempts.
-
-**Why doesn't the Sekoia Intelligence feed rule detect all the scanner IPs that appear on my firewalls? (Why my firewall linked to internet doesn't raise any alerts)**
-
-The Sekoia Intelligence Feed rule is designed to identify threats based on a specific set of Indicators of Compromise (IOCs) collected by Sekoia's Threat and Detection Research team . Our approach is to focus on the most significant threats, and as such, we have chosen not to classify scanner IPs as IOCs. Indeed, we consider these scanning activities as reconnaissance, which do not inherently pose a direct threat on their own and risk to generate a lot of alert noise. However, information about these scanner IPs can be valuable in certain contexts, such as correlation with other alerts or during threat hunting activities.
-
-To facilitate this, we categorize scanner IPs as observables and tag them with scanner rather than treating them as IOCs. This approach allows you to search for these scanner IPs on the events page easily. Additionally, we offer two master rules, named `Internet Scanner`and `Internet Scanner Target`, which utilize these tags. 
 
-**Be careful with those rules tough**, as they are master rules, they might raise a lot of alerts.
+## Can you change the similarity strategy for a rule? (Grouping events into alerts)
 
-## How [Sekoia.io](http://Sekoia.io) builds rules / does detection engineering
+While we strive to define optimal similarity strategies that promote efficiency and productivity for security analysts, we recognize that different SOCs have unique workflows and needs for grouping events into alerts.
 
-**What is your processus for creating rules? Are they tested?**
+If the existing similarity strategy doesn't align perfectly with your context, you can create a **custom rule**: 
+
+- Select the rule you want to edit 
+- Copy the detection pattern and the different rule parameters 
+- Create a new custom rule using the previously copied settings 
+
+This lets you create a new rule where you can freely adjust the similarity strategy to match your specific requirements.
+
+Please note that we have received a lot of requests for improvements concerning this part of the product and we will be working on enhancing this feature in the coming year. 
+
+## Could you create a rule for a specific detection use case?
+
+We appreciate all your suggestions! Sekoia.io empowers you to create your own custom rules to address your unique detection needs.
+
+If you want the rule to be managed by Sekoia.io, you can submit a request to the support. The Threat Detection and Research team will then have around two weeks to evaluate your request and provide a timeline for potential rule development and delivery. 
+
+
+## Why did this phishing email go undetected by Sekoia.io?
+
+It's important to understand that our product is not primarily an anti-phishing tool. While we do incorporate IOCs related to phishing during our investigations and from reports, our main focus is not on phishing detection but rather on what's happening afterwards. 
+
+As a result, our database of known phishing threats is not exhaustive.
+
+For comprehensive protection against phishing attempts, we strongly recommend using a dedicated anti-phishing tool alongside Sekoia.io.
+
+## Why doesn't the Sekoia Intelligence Feed rule detect all the scanner IPs showing up on my firewall? (Why my firewall linked to internet doesn't raise any alerts)
+
+The Sekoia Intelligence Feed rule focuses on identifying high-risk threats based on specific IOCs compiled by our Threat and Detection Research team. Since scanner activity is considered reconnaissance and not inherently indicative of a direct threat, we have opted not to classify scanner IPs as IOCs to avoid generating excessive alerts (often referred to as "alert noise").
+
+However, we recognize the potential value of scanner IPs in specific contexts, such as correlation with other alerts or threat hunting activities. Therefore, we:
+
+- Categorize scanner IPs as observables and tags them with "scanner" instead of treating them as IOCs. This allows you to easily search for them on the events page.
+- Offer two master rules: `Internet Scanner` and `Internet Scanner Target`, which leverage these tags.
+
+!!! note
+    Be careful with these rules as they are master rules and might raise a significant number of alerts. 
+
+## What is your processus for creating detection rules? Are they tested?
 
-Please check our blogpost on that matter: https://blog.sekoia.io/xdr-detection-rules-at-scale/
+Sekoia.io follows a specific process to build detection rules. This process is designed to ensure that the rules are high quality and do not cause false positives.
+
+Here are the main steps involved in crafting Sekoia.io's verified detection rules:
+
+- **Field normalization:** This is the first step in the process, and it involves converting all of the logs from different sources into a common format (ECS). This is important because it allows Sekoia.io to create rules that can be applied to all of the logs in its system, regardless of the source.
+- **Rule creation and review**: Once the logs have been normalized, Sekoia.io analysts create detection rules using Sigma. These rules are then reviewed by other analysts to ensure that they are correct and effective.
+- **Testing**: Once a rule has been reviewed, it is tested using test samples. These test samples are events (logs) that have already been classified as malicious or benign. The rule is considered to be successful if it correctly identifies the malicious events and does not generate any false positives on the benign events.
+- **Staging**: Once a rule has been successfully tested, it is moved to a staging environment. This is a production-like environment where the rule can be monitored for false positives before it is deployed to production.
+- **Approval**: If a rule performs well in staging, it is then approved for production deployment.
+
+Sekoia.io is constantly working to improve its detection engineering process. Some of the improvements that we are planning include:
+
+- Requiring all rules to be in staging for two weeks before being deployed to production.
+- Implementing an automatic check to ensure that rule mappings are up-to-date.
+- Allowing partners and customers to contribute to the rule creation process.
+
+For more insights on how we create rules and how we test them, check our blogpost on that matter: [XDR detection engineering at scale: crafting detection rules for SecOps efficiency](https://blog.sekoia.io/xdr-detection-rules-at-scale/).