Security Monitoring & SIEM Fundamentals Module
Last updated
Last updated
Crucial within the realm of computer protection, Security Information and Event Management (SIEM) encompasses the utilization of software offerings and solutions that merge the management of security data with the supervision of security events. These instruments facilitate real-time evaluations of alerts related to security, which are produced by network hardware and applications.
SIEM tools possess an extensive range of core functionalities, such as the collection and administration of log events, the capacity to examine log events and supplementary data from various sources, as well as operational features like incident handling, visual summaries, and documentation.
Dashboards in SIEM solutions serve as containers for multiple visualizations, allowing us to organize and display data in a meaningful way.
In this and the following sections, we will create a dashboard and some visualizations from scratch.
When visiting the Dashboard page again we will be presented with a message indicating that no dashboards currently exist. Additionally, there will be an option available to create a new Dashboard and its first visualization. To initiate the creation of our first dashboard, we simply have to click on the "Create new dashboard" button.
Now, to initiate the creation of our first visualization, we simply have to click on the "Create visualization" button.
Upon initiating the creation of our first visualization, the following new window will appear with various options and settings.
Before proceeding with any configuration, it is important for us to first click on the calendar icon to open the time picker. Then, we need to specify the date range as "last 15 years". Finally, we can click on the "Apply" button to apply the specified date range to the data.
There are four things for us to notice on this window:
A filter option that allows us to filter the data before creating a graph. For example, if our goal is to display failed logon attempts, we can use a filter to only consider event IDs that match 4625 – Failed logon attempt on a Windows system. The following image demonstrates how we can specify such a filter.
This field indicates the data set (index) that we are going to use. It is common for data from various infrastructure sources to be separated into different indices, such as network, Windows, Linux, etc. In this particular example, we will specify windows* in the "Index pattern".
This search bar provides us with the ability to double-check the existence of a specific field within our data set, serving as another way to ensure that we are looking at the correct data. For example, let's say we are interested in the user.name.keyword field. We can use the search bar to quickly perform a search and verify if this field is present and discovered within our selected data set. This allows us to confirm that we are accessing the desired field and working with accurate data.
"Why user.name.keyword and not user.name?", you may ask. We should use the .keyword field when it comes to aggregations. Please refer to this stackoverflow question for a more elaborate answer.
Lastly, this drop-down menu enables us to select the type of visualization we want to create. The default option displayed in the earlier image is "Bar vertical stacked". If we click on that button, it will reveal additional available options (image redacted as not all options fit on the screen). From this expanded list, we can choose the desired visualization type that best suits our requirements and data presentation needs.
For this visualization, let's select the "Table" option. After selecting the "Table", we can proceed to click on the "Rows" option. This will allow us to choose the specific data elements that we want to include in the table view.
Let's configure the "Rows" settings as follows.
Note: You will notice Rank by Alphabetical and not Rank by Count of records like in the screenshot above. This is OK. By the time you perform the next configuration below, Count of records will become available.
Moving forward, let's close the "Rows" window and proceed to enter the "Metrics" configuration.
In the "Metrics" window, let's select "count" as the desired metric.
As soon as we select "Count" as the metric, we will observe that the table gets populated with data (assuming that there are events present in the selected data set)
One final addition to the table is to include another "Rows" setting to show the machine where the failed logon attempt occurred. To do this, we will select the host.hostname.keyword field, which represents the computer reporting the failed logon attempt. This will allow us to display the hostname or machine name alongside the count of failed logon attempts, as shown in the image.
Suppose the SOC Manager suggested the following refinements:
Clearer column names should be specified in the visualization
The Logon Type should be included in the visualization
The results in the visualization should be sorted
The DESKTOP-DPOESND, WIN-OK9BH1BCKSD, and WIN-RMMGJA7T9TC usernames should not be monitored
Computer accounts should not be monitored (not a good practice)
Let's refine the visualization we created, so that it fulfills the suggestions above.
Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on "Dashboard".
The dashboard we previously created should be visible. Let's click on the "pencil"/edit icon.
Let's now click on the "gear" button at the upper-right corner of our visualization, and then click on "Edit lens".
"Top values of user.name.keyword" should be changed as follows.
"Top values of host.hostname.keyword" should be changed as follows.
The "Logon Type" can be added as follows (we will use the winlog.logon.type.keyword field).
"Count of records" should be changed as follows.
We can introduce result sorting as follows.
All we have to do now is click on "Save and return".
The DESKTOP-DPOESND, WIN-OK9BH1BCKSD, and WIN-RMMGJA7T9TC usernames can be excluded by specifying additional filters as follows.
Computer accounts can be excluded by specifying the following KQL query and clicking on the "Update" button.
The AND winlog.channel.keyword: Security part is to ensure that no unrelated logs are accounted for.
This is our visualization after all the refinements we performed.
Finally, let's give our visualization a title by clicking on "No Title".
1) Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on "Dashboard". Browse the refined visualization we created or the "Failed logon attempts [All users]" visualization, if it is available, and enter the number of logins for the sql-svc1 account as your answer.
Answer: 2
In this SIEM visualization example we want to create visualization to monitor failed login attempts against disabled users.
We mention "failed" because it is not possible to log in with a disabled user, so it will never be successful even if the correct credentials are provided. In a scenario where the correct credentials are provided, the Windows logs will contain an additional SubStatus value of 0xC0000072, that indicates the reason of the failure.
A filter option that allows us to filter the data before creating a graph. In this case our goal is to display failed logon attempts against disabled users only. We can use a filter to only consider event IDs that match 4625 – Failed logon attempt on a Windows system, like we did in the previous visualization example. In this case though, we should also take into account the SubStatus (winlog.event_data.SubStatus field) that indicates, when set to 0xC0000072, that the failure is due to a logon with disabled user. The following image demonstrates how we can specify such a filter.
1) Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on "Dashboard". Either create a new visualization or edit the "Failed logon attempts [Disabled user]" visualization, if it is available, so that it includes failed logon attempt data related to disabled users including the logon type. What is the logon type in the returned document?
I filtered the data by event code 4625 and substatus 0xC0000072 to identify disabled users with failed logon attempts.
He requested the logon type in the question, so let’s include it in the table.
Answer: Interactive
2) Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on "Dashboard". Either create a new visualization or edit the "Failed logon attempts [Admin users only]" visualization, if it is available, so that it includes failed logon attempt data where the username field contains the keyword "admin" anywhere within it. What should you specify after user.name: in the KQL query?
Answer: *admin*
In this SIEM visualization example, we aim to create a visualization to monitor successful RDP logons specifically related to service accounts. Service account credentials are never used for RDP logons in corporate/real-world environments. We have been informed by the IT Operations department that all service accounts on the environment start with svc-.
The motivation for this visualization stems from the fact that service accounts often possess exceptionally high privileges. We need to keep a close eye on how service accounts are used.
Our visualization will be based on the following Windows event log.
1) Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on "Dashboard". Browse the visualization we created or the "RDP logon for service account" visualization, if it is available, and enter the IP of the machine that initiated the successful RDP logon using service account credentials as your answer.
Certainly! Let’s begin by filtering events with either event code 4624 or 4625, and then add the necessary values to the table
We should filter by the logon type remote interactive. This type of logon session occurs when a user connects to a computer over a network using Remote Desktop Services (RDP).
Answer: 192.168.28.130
In this SIEM visualization example, we aim to create a visualization to monitor user additions or removals from the local "Administrators" group from March 5th 2023 to date.
Our visualization will be based on the following Windows event logs.
A filter option that allows us to filter the data before creating a graph. In this case our goal is to display user additions or removals from the local "Administrators" group. We can use a filter to only consider event IDs that match 4732 – A member was added to a security-enabled local group and 4733 – A member was removed from a security-enabled local group. We can also use a filter to only consider 4732 and 4733 events where the local group is the "Administrators" one.
For this visualization, let's select the "Table" option. After selecting the "Table", we can proceed to click on the "Rows" option. This will allow us to choose the specific data elements that we want to include in the table view.
One final addition to the table is to include some more "Rows" settings to enhance our understanding.
Which user was added to or removed from the group? (winlog.event_data.MemberSid.keyword field)
To which group was the addition or the removal performed? (double-checking that it is the "Administrators" one) (group.name.keyword field)
Was the user added to or removed from the group? (event.action.keyword field)
On which machine did the action occur? (host.name.keyword field)
Click on "Save and return", and you will observe that the new visualization is added to the dashboard.
As discussed, we want to monitor user additions or removals from the local "Administrators" group within a specific timeframe (March 5th 2023 to date).
We can narrow the scope of our visualization as follows.
1) Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on "Dashboard". Extend the visualization we created or the "User added or removed from a local group" visualization, if it is available, and enter the common date on which all returned events took place as your answer. Answer format: 20XX-0X-0X
First, let’s filter events with event codes 4732 and 4733 and narrow down the results by the group name administrators.
To monitor users being added to or removed from a local group in Windows, you should look for specific event codes in the Security event log:
4732: Indicates that a user was added to a security-enabled local group. The event will include details such as the name of the group and the account of the user who was added.
4733: Indicates that a user was removed from a security-enabled local group. This event will provide information about the group and the user who was removed.
Then let's add the necessary fields to the table:
(winlog.event_data.MemberSid.keyword field)
(group.name.keyword field)
(event.action.keyword field)
(host.name.keyword field)
Then let's save and return.
As discussed, we want to monitor user additions or removals from the local "Administrators" group within a specific timeframe (March 5th 2023 to date).
Answer: 2023-03-05
