Add a new table to list and describe supported log types for detector…

… creation (#4946) (#5110)

* fix#4945 add log types table



* fix#4945 add log types table



* fix#4945 add log types table



* fix#4945 add log types table



* fix#4945 add log types table



* fix#4945 add log types table



* fix#4945 add log types table



* fix#4945 add log types table



---------


(cherry picked from commit 8ee9554)

Signed-off-by: cwillum <[email protected]>
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

_security-analytics/index.md

@@ -12,63 +12,58 @@ redirect_from:
 
 # About Security Analytics
 
+
 Security Analytics is a security information and event management (SIEM) solution for OpenSearch, designed to investigate, detect, analyze, and respond to security threats that can jeopardize the success of businesses and organizations and their online operations. These threats include the potential exposure of confidential data, cyber attacks, and other adverse security events. Security Analytics provides an out-of-the-box solution that installs automatically with any OpenSearch distribution. It includes the tools and features necessary for defining detection parameters, generating alerts, and responding effectively to potential threats.
 
+
 ### Resources and information
 
 As part of the OpenSearch Project, Security Analytics exists in the open source community and benefits from the feedback and contributions of that community. To learn more about proposals for its development, options for making contributions, and general information on the platform, see the [Security Analytics repository](https://github.com/opensearch-project/security-analytics) at GitHub.
 
 If you would like to leave feedback that could help improve Security Analytics, join the discussion on the [OpenSearch forum](https://forum.opensearch.org/c/plugins/security-analytics/73).
 
+
 ---
 ## Components and concepts
 
 Security Analytics includes a number of tools and features elemental to its operation. The major components that compose the plugin are summarized in the following sections.
 
+
 ### Detectors
 
 Detectors are core components that are configured to identify a range of cybersecurity threats corresponding to an ever-growing knowledge base of adversary tactics and techniques maintained by the [MITRE ATT&CK](https://attack.mitre.org/) organization. Detectors use log data to evaluate events occurring in the system. They then apply a set of security rules specified for the detector and determine findings from these events.
 
 For information about configuring detectors, see [Creating detectors]({{site.url}}{{site.baseurl}}/security-analytics/sec-analytics-config/detectors-config/).
 
+
 ### Log types
 
-Log types provide the data used to evaluate events occurring in a system. OpenSearch supports several types of logs and provides out-of-the-box mappings for the most common log sources. Currently supported log types include the following:
-* Network events
-* DNS logs
-* Apache access logs
-* Windows logs
-* AD/LDAP logs
-* System logs
-* AWS CloudTrail logs
-* Amazon S3 access logs
-* Google Workspace logs
-* GitHub actions
-* Microsoft 365 logs
-* Okta events
-* Microsoft Azure logs
-* VPC Flow logs
+Log types provide the data used to evaluate events occurring in a system. OpenSearch supports several types of logs and provides out-of-the-box mappings for the most common log sources. See [Supported log types]({{site.url}}{{site.baseurl}}/security-analytics/sec-analytics-config/log-types/) for a list of log types currently supported by Security Analytics.
 
 Log types are specified during the creation of detectors, including steps for mapping log fields to the detector. Security Analytics also automatically selects an appropriate set of rules based on a specific log type and populates them for the detector.
 
+
 ### Detection rules
 
 The security rules, or threat detection rules, define the conditional logic applied to ingested log data that allows the system to identify an event of interest. Security Analytics uses prepackaged, open source [Sigma rules](https://github.com/SigmaHQ/sigma) as a starting point for describing relevant log events. But with their inherently flexible format and easy portability, Sigma rules provide Security Analytics users with options for importing and customizing the rules. You can take advantage of these options using either OpenSearch Dashboards or the API.
 
 For information about configuring rules, see [Working with rules]({{site.url}}{{site.baseurl}}/security-analytics/usage/rules/).
 
+
 ### Findings
 
 Findings are generated every time a detector matches a rule with a log event. Findings do not necessarily point to imminent threats within the system, but they always isolate an event of interest. Because they represent the result of a specific definition for a detector, findings include a unique combination of select rules, a log type, and a rule severity. As such, you can search for specific findings in the Findings window, and you can filter findings in the list based on severity and log type.
 
 To learn more about findings, see [Working with findings]({{site.url}}{{site.baseurl}}/security-analytics/usage/findings/).
 
+
 ### Alerts
 
 When defining a detector, you can specify certain conditions that will trigger an alert. When an event triggers an alert, the system sends a notification to a preferred channel, such as Amazon Chime, Slack, or email. The alert can be triggered when the detector matches one or multiple rules. Further conditions can be set by rule severity and tags. You can also create a notification message with a customized subject line and message body.
 
 For information about setting up alerts, see [Step 4. Set up alerts]({{site.url}}{{site.baseurl}}/security-analytics/sec-analytics-config/detectors-config/#step-4-set-up-alerts) in the detector creation documentation. For information about managing alerts in the Alerts window, see [Working with alerts]({{site.url}}{{site.baseurl}}/security-analytics/usage/alerts/).
 
+
 ### Correlation engine
 
 The correlation engine gives Security Analytics the ability to compare findings from different log types and draw correlations between them. This facilitates understanding of the relationships between findings from different systems in an infrastructure and increases confidence that an event is meaningful and requires attention.
@@ -77,6 +72,7 @@ The correlation engine uses correlation rules to define threat scenarios involvi
 
 To learn more about defining threat scenarios for correlation rules, see [Creating correlation rules]({{site.url}}{{site.baseurl}}/security-analytics/sec-analytics-config/correlation-config/). To learn more about using the correlation graph, see [Working with the correlation graph]({{site.url}}{{site.baseurl}}/security-analytics/usage/correlation-graph/).
 
+
 ---
 ## First steps
 

_security-analytics/sec-analytics-config/correlation-config.md

@@ -2,7 +2,7 @@
 layout: default
 title: Creating correlation rules
 parent: Setting up Security Analytics
-nav_order: 16
+nav_order: 17
 ---
 
 # Creating correlation rules

_security-analytics/sec-analytics-config/detectors-config.md

@@ -12,7 +12,7 @@ Security Analytics provides the options and functionality to monitor and respond
 ---
 ## Step 1. Define a detector
 
-You can define a new detector by naming the detector, selecting a data source and detector type, and specifying a detector schedule. After defining a detector, you can also configure field mappings and set up alerts. Follow the steps in this section to accomplish all three of these setup tasks.
+You can define a new detector by naming the detector and then selecting a data source and detector type. After defining a detector, you can also configure field mappings, create a detector schedule, and set up alerts. Follow the steps in this section to accomplish all of these setup tasks.
 
 1. On the **Threat detectors** page, choose **Create detector**. The **Define detector** page opens.
 1. In **Detector details**, give the detector a name. Adding a description for the detector is optional. 
@@ -21,7 +21,9 @@ You can define a new detector by naming the detector, selecting a data source an
     When multiple data sources are selected, the logs must be of the same type. We recommend creating separate detectors for different log types.
     {: .note }
 
-1. In the **Log types and rules** section, select the log type for the data source from the dropdown list. The system automatically populates the detection rules associated with the log type.
+1. In the **Log types and rules** section, select the log type for the data source from the dropdown list. You can find a list of supported log types in the [Supported log types]({{site.url}}{{site.baseurl}}/security-analytics/sec-analytics-config/log-types/) topic.
+
+   After the log type is selected, the system automatically populates the detection rules associated with the log type.
 
    For information about creating your own detection rules, see [Creating detection rules]({{site.url}}{{site.baseurl}}/security-analytics/usage/rules/#creating-detection-rules). To create your own log types, see [Creating custom log types]({{site.url}}{{site.baseurl}}/security-analytics/sec-analytics-config/custom-log-type/).
    {: .note }
@@ -33,16 +35,15 @@ You can define a new detector by naming the detector, selecting a data source an
     When you select **network**, **cloudtrail**, or **s3** as the log type, the system automatically creates a detector dashboard. The dashboard offers visualizations for the detector and can provide security-related insight into log source data. For more information about visualizations, see [Building data visualizations]({{site.url}}{{site.baseurl}}/dashboards/visualize/viz-index/).
 
     You can skip the next step for applying select rules if you are satisfied with those automatically populated by the system. Otherwise, go to the next step to select rules individually.
-    {: .note }
-
+
 1. Expand **Detection rules** to show the list of available detection rules for the selected log type. Initially, all rules are selected by default. The following image illustrates this.
-
+    
     <img src="{{site.url}}{{site.baseurl}}/images/Security/select_rules.png" alt="Select or deselect rules that the detector will use for findings" width="85%">
-
+    
     * Use the toggle to the left of **Rule name** to select or deselect rules.
     * Use the **Rule severity** and **Source** dropdown lists to filter the rules you want to select from. 
     * Use the **Search** bar to search for specific rules.
-
+    
     To quickly select one or more known rules and dismiss others, first deselect all rules by turning off the **Rule name** toggle, then search for your target rule names and select each individually by turning its toggle on.
     {: .tip }
 

_security-analytics/sec-analytics-config/log-types.md

@@ -0,0 +1,29 @@
+---
+layout: default
+title: Supported log types
+parent: Setting up Security Analytics
+nav_order: 16
+---
+
+
+# Supported log types
+
+Logs contain raw data about events that happen throughout a system and in its separate parts. The following table shows the log types that are currently supported by Security Analytics for ingestion, mapping, and monitoring.
+
+| Log type | Description |
+| :--- |:--- |
+| **Network events** | A log that records events that happen in a system's network, such as login attempts and application events. |
+| **DNS logs** | A log that stores Domain Name System (DNS) activity. <br> <br> Security Analytics supports [Open Cybersecurity Schema Framework](https://docs.aws.amazon.com/security-lake/latest/userguide/open-cybersecurity-schema-framework.html) (OCSF) log and event data, which includes the Security Lake log type Route 53. Given that Route 53 is a log that captures DNS activity, its log type should be specified as DNS logs when defining a detector. |
+| **Apache access logs** | A log type that is responsible for recording data for all requests processed by an Apache HTTP server. 
+| **Windows logs** | Logs that record events that have happened in the operating system, applications, and other system services for Windows.
+| **AD/LDAP logs** | Active Directory logs that track such things as LDAP queries, errors from the LDAP server, time-out events, and unsecure LDAP binds.
+| **System logs** | Logs that record events happening in the operating system.
+| **AWS CloudTrail logs** | Logs that monitor events for an AWS CloudTrail account. OpenSearch can ingest CloudTrail log data from both [AWS Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) (S3) accounts and [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) service accounts.  
+| **Amazon S3 access logs** | These logs track requests for access to an Amazon S3 bucket.
+| **Google Workspace logs** | Logs for Google Workspace that can monitor log entries such as admin actions, group and group membership actions, and events having to do with logging in.   
+| **GitHub actions** | Logs that monitor workflows created by [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions).
+| **Microsoft 365 logs** | Microsoft 365 audit logs collect a range of data for Microsoft 365 including records from call details, performance data, SQL Server, security events, and access control activity.
+| **Okta events** | These logs record Okta events from a range of actions such as downloading an export file, requesting an application access, or revoking privileges. 
+| **Microsoft Azure logs** | Logs that monitor log data for cloud applications managed by Microsoft Azure Cloud Services.
+| **VPC Flow logs** | [VPC Flow Logs](https://docs.aws.amazon.com/prescriptive-guidance/latest/logging-monitoring-for-application-owners/vpc-flow-logs.html) capture information about the IP traffic going to and from network interfaces in your VPC.
+