SOC for beginners. SOC objectives: monitoring
We continue to talk about the everyday life of the Security Operations Center — about responding to massive cyber attacks , curious cases with customers, and rules for correlating events that allow us to detect attacks on customers, etc.
Today we want to open a new cycle of articles, the task of which is to demonstrate what tasks and difficulties all novice (and not so) SOCnounters face, and the main thing is to share our experience in solving them.
In these articles we will deal with various issues of a technical and methodological nature, and as much as possible to separate commercial and marketing positioning from real tasks. In our plans to complete the first cycle of articles in time for the SOC-Forum , so that the platform becomes one of the places to discuss these issues.
')
Let's start with the most popular task, without which it is difficult to imagine SOC, - monitoring of incidents.
Is security monitoring a real challenge or a new marketing reality?
Any experienced Bezopasnik during his career experienced a lot of trends for new beautiful abbreviations. The next NG-technologies, artificial intellectual systems, “golden” and “silver” bullets of protection against hackers and targeted attacks, etc. Now one of these popular areas has become monitoring information security incidents. At the same time, experts sometimes state that security does not require monitoring, but only requires active blocking. However, we think differently - for two reasons.
The first reason: the dynamics of the development of companies
There are two global changes that are becoming more aggressive in the life of each company, possessing at least some kind of IT infrastructure:
Therefore, the “drag and not let go” approach no longer just seems outdated, it is not applicable. Accordingly, it remains only to try to “lead the process”: monitor connections to the system and actions performed on it, fix anomalies and incidents.
Reason Two: Intelligence Attacks and Remedies
A hacking attempt, repulsed or blocked by a means of protection, is no longer a reason for reassurance, since the tools of intruders, and consequently, the attacks themselves, are constantly evolving.
We give two simple examples.
1. The company uses NGFW. Such systems can detect not only external attacks, but also potentially harmful activity within the network (for example, bot activity). And then one day NGFW blocked an attempt by one of the hosts to connect to the botnet control center of the malicious family / sending information to servers controlled by intruders.
Is it possible to say that the incident was settled on this? At first glance, yes. Our protection has successfully blocked the connection, the bot has not contacted the control center, and as a result, malicious activity on the network has not started. But let's dig deeper: 90% of the company's employees have been using laptops for a long time. And if an employee decides to work from home or from a cafe, the bot will successfully reach the control center, because there, outside the enterprise network, there is neither NGFW nor a vigilant security officer. Where it leads? At the first stage - to the compromise of all data of this laptop. On the second, to update the protocols or addresses of the bot's control center, which will not allow NGFW to successfully block the attack.
2. Already for quite a long time, anti-virus agents learned to detect and block hacker tools, for example, the infamous mimikatz. And so we set up the appropriate policy in our company and fixed the block. On one of the hosts of IT administrators, mimikatz was started and blocked.
This example is similar to the previous one - on the one hand, there was no compromise of accounts, the incident was settled. But even if we leave aside the abnormality of the situation itself and the desire to figure it out (whether the IT administrator himself launched the utility and for what), nothing will prevent the attacker from trying to gain access again. He will try to “nail down” the antivirus process, using a version that is not detected by the antivirus, for example, when using powershell analogues. In the end, just find a host without antivirus and get the information of interest to it there.
As a result, ignoring the analysis and analysis of the blocked attack, we leave the actions of the attackers without control . And instead of stopping their attempts to seize our infrastructure, we leave them with our hands untied, allowing us to come up with a new method of attack and return to it from previously captured positions.
These two examples prove that operational monitoring and thorough analysis of information security events can not only help in identifying and analyzing incidents, but also make life difficult for intruders.
Some time ago, an equality sign was placed between the SOC theme and the monitoring, and then it arose between the concepts of “monitoring” and “SIEM”. And, although many copies are broken around this topic, I want to return to this issue so that it does not confuse us further.
In world practice and even on the territory of Russia, approaches to solving problems of monitoring and building SOC are known without using SIEM at all. One of the largest and most successful SOCs of the past decade was built entirely on the operational regular work of employees: on a highly regular basis, the shift duty analyzed antivirus logs, proxies, IPS and other means of protection - where the hands, where the basic scripts, where the smart reports. This approach made it possible to close 80% of the baseline monitoring tasks (for example, the basic tasks and the initial approach, I’ll go further in the next section).
So why really need a SIEM / Log Management platform in the plane of monitoring tasks? Let's try to make out examples.
Use case 1. Collect all incidents "in one pile."
At first glance, this task may seem useless, but, in fact, it is difficult to overestimate the need of customers to solve it. Especially when their goal is not to handle each detector with a means of protection, but to search for certain patterns. For example, identifying repetitive events / incidents (when the problem has not been methodically resolved), fixing strange activities from one host to one host (the first tentative steps to the modular word kill chain), analyzing the frequency of triggers.
Of course, to solve such utilitarian tasks, SIEM, honestly, is not needed. The service desk with regard to applications and correct work with reports from it (analysis of patterns with eyes) can become a completely acceptable option here.
But, nevertheless, when the company launches SIEM, it is usually motivated by the desire to collect all the incidents in a single window, so we include this use case in our list.
Use case 2. Splitting incidents of the same type.
When it comes to evolving and long-term activity of the attacker, if the scenario is configured incorrectly, you can encounter a phenomenon called “incident storm”. For example:
And in this stream of events it is very easy to miss an incident other than the specified activities. Therefore, a proper SIEM will always allow these activities to be glued together across key fields in order to sort them out as one common incident.
Use Case 3. Enrich the investigation with information from additional systems.
After identifying an incident, the analyst usually has a very large amount of work to find its causes and consequences. Consider the following example: one of the basic rules for monitoring and control in many international standards is to prohibit the use of system non-personalized accounts in the infrastructure. And here we faced the task of controlling the login under the root account on the Unix operating system. Do I need to solve this problem SIEM? Certainly not; Any administrator who knows the basics of scripting will easily create a two-line script that will allow you to detect such activity.
But now let's see what we, as the SOC operator, need to do further with this event.
What is the difference between these two events? Which connection is legitimate and which is not? Now we have only the ip-address from which the connection was made. This, of course, does not allow us to localize the user. Here is how we would act:
Only after receiving all this information, we can assume that in the first approximation identified the perpetrator.
After that, it is necessary to evaluate the impact on the system after logging in as root. With a properly configured audit we, in principle, will have enough server logs, but there is one “but”: the attacker himself with these rights could easily modify them. Which leads us to the task of storing logs in an independent source (one of the tasks that are often put under the SIEM). As a result, the analysis of these logs allows to assess the problem and its criticality.
Of course, most of this work can be done without SIEM, but then it will take much more time, and the analyst will face serious limitations. Therefore, although SIEM is not strictly necessary, it has significant advantages in conducting investigations.
Use Case 4. Simple and complex correlation.
Hundreds of articles and presentations have already been written on this topic, so I don’t want to dwell on this example for a long time. I will say the main thing again: today, in order to effectively detect and repel attacks, you need to be able to identify correlations between IS events. Whether it will be the creation and deletion of an account in Active Directory for a suspiciously short interval or the identification of long vpn-sessions (longer than 8 hours) on the firewall is not important. Either way, the basic scripts or tools of the security tool itself do not solve this problem due to the huge amount of security events passing through it. To solve such problems and designed platform SIEM.
Total: the approach to monitoring tasks at the first stage does not necessarily require a SIEM platform, but it significantly simplifies the life of SOC and its operators. In the long term, as we deepen in the task of identifying incidents, the presence of the SIEM ceases to be a recommendation and becomes a prerequisite.
Monitoring - where to start?
Answering the question in the title of this section, the majority of customers fall into one of two misconceptions.
The only task of SOC and information security in general is to combat APT or targeted attacks . Our practice shows that prior to building up the basic monitoring processes, restoring order in the infrastructure and combing the response processes, we should not set ourselves such an ambitious task.
It is possible to think about monitoring only after the entire infrastructure has been covered with a tight cap of protection means and the most modern information security systems . According to our observations, a good first result on increasing the level of information security can be obtained with a minimum set of protection tools. This is confirmed by statistics that we collect on a regular basis: for example, in the first half of 2017, about 67% of events from customers were recorded using basic IT infrastructure services and basic security tools — firewalls and network equipment, VPN gateways, controllers domains, mail servers, antiviruses, proxy servers and intrusion detection systems.
So, the process of monitoring events and incidents can start with enough basic things:
As you can see, no magic, and even a SIEM system is not needed. But at least fulfilling these simple rules and launching basic monitoring can be one of the first fairly simple steps to your movement to expert monitoring tasks and building your own Security Operations Center.
Today we want to open a new cycle of articles, the task of which is to demonstrate what tasks and difficulties all novice (and not so) SOCnounters face, and the main thing is to share our experience in solving them.
In these articles we will deal with various issues of a technical and methodological nature, and as much as possible to separate commercial and marketing positioning from real tasks. In our plans to complete the first cycle of articles in time for the SOC-Forum , so that the platform becomes one of the places to discuss these issues.
')
Let's start with the most popular task, without which it is difficult to imagine SOC, - monitoring of incidents.
Is security monitoring a real challenge or a new marketing reality?
Any experienced Bezopasnik during his career experienced a lot of trends for new beautiful abbreviations. The next NG-technologies, artificial intellectual systems, “golden” and “silver” bullets of protection against hackers and targeted attacks, etc. Now one of these popular areas has become monitoring information security incidents. At the same time, experts sometimes state that security does not require monitoring, but only requires active blocking. However, we think differently - for two reasons.
The first reason: the dynamics of the development of companies
"The world has changed, I feel it in the air, I feel it in the water."
Galadriel, CSO Lothlorien
There are two global changes that are becoming more aggressive in the life of each company, possessing at least some kind of IT infrastructure:
- Infrastructure is changing at a frantic pace. On average, a month in the company may appear 2-3 new public services. In a week, up to 40-50 new server virtual resources can be created, which within a couple of days can from test development without critical data acquire PD, cards and trade secrets and go to the expansion of mission critical application clusters.
- Users are less and less willing to put up with such restrictions as blocked flash drives, closed access to the Internet, a ban on their own devices in the office, etc. And the management usually takes the side of just such users, and not the security officer.
Therefore, the “drag and not let go” approach no longer just seems outdated, it is not applicable. Accordingly, it remains only to try to “lead the process”: monitor connections to the system and actions performed on it, fix anomalies and incidents.
Reason Two: Intelligence Attacks and Remedies
“Wait, Gretel, soon the moon will rise, and bread crumbs will be visible.”
Hansel, 1 level Security Analyst
A hacking attempt, repulsed or blocked by a means of protection, is no longer a reason for reassurance, since the tools of intruders, and consequently, the attacks themselves, are constantly evolving.
We give two simple examples.
1. The company uses NGFW. Such systems can detect not only external attacks, but also potentially harmful activity within the network (for example, bot activity). And then one day NGFW blocked an attempt by one of the hosts to connect to the botnet control center of the malicious family / sending information to servers controlled by intruders.
Is it possible to say that the incident was settled on this? At first glance, yes. Our protection has successfully blocked the connection, the bot has not contacted the control center, and as a result, malicious activity on the network has not started. But let's dig deeper: 90% of the company's employees have been using laptops for a long time. And if an employee decides to work from home or from a cafe, the bot will successfully reach the control center, because there, outside the enterprise network, there is neither NGFW nor a vigilant security officer. Where it leads? At the first stage - to the compromise of all data of this laptop. On the second, to update the protocols or addresses of the bot's control center, which will not allow NGFW to successfully block the attack.
2. Already for quite a long time, anti-virus agents learned to detect and block hacker tools, for example, the infamous mimikatz. And so we set up the appropriate policy in our company and fixed the block. On one of the hosts of IT administrators, mimikatz was started and blocked.
This example is similar to the previous one - on the one hand, there was no compromise of accounts, the incident was settled. But even if we leave aside the abnormality of the situation itself and the desire to figure it out (whether the IT administrator himself launched the utility and for what), nothing will prevent the attacker from trying to gain access again. He will try to “nail down” the antivirus process, using a version that is not detected by the antivirus, for example, when using powershell analogues. In the end, just find a host without antivirus and get the information of interest to it there.
As a result, ignoring the analysis and analysis of the blocked attack, we leave the actions of the attackers without control . And instead of stopping their attempts to seize our infrastructure, we leave them with our hands untied, allowing us to come up with a new method of attack and return to it from previously captured positions.
These two examples prove that operational monitoring and thorough analysis of information security events can not only help in identifying and analyzing incidents, but also make life difficult for intruders.
We say monitoring - we mean SIEM?
Some time ago, an equality sign was placed between the SOC theme and the monitoring, and then it arose between the concepts of “monitoring” and “SIEM”. And, although many copies are broken around this topic, I want to return to this issue so that it does not confuse us further.
In world practice and even on the territory of Russia, approaches to solving problems of monitoring and building SOC are known without using SIEM at all. One of the largest and most successful SOCs of the past decade was built entirely on the operational regular work of employees: on a highly regular basis, the shift duty analyzed antivirus logs, proxies, IPS and other means of protection - where the hands, where the basic scripts, where the smart reports. This approach made it possible to close 80% of the baseline monitoring tasks (for example, the basic tasks and the initial approach, I’ll go further in the next section).
So why really need a SIEM / Log Management platform in the plane of monitoring tasks? Let's try to make out examples.
Use case 1. Collect all incidents "in one pile."
At first glance, this task may seem useless, but, in fact, it is difficult to overestimate the need of customers to solve it. Especially when their goal is not to handle each detector with a means of protection, but to search for certain patterns. For example, identifying repetitive events / incidents (when the problem has not been methodically resolved), fixing strange activities from one host to one host (the first tentative steps to the modular word kill chain), analyzing the frequency of triggers.
Of course, to solve such utilitarian tasks, SIEM, honestly, is not needed. The service desk with regard to applications and correct work with reports from it (analysis of patterns with eyes) can become a completely acceptable option here.
But, nevertheless, when the company launches SIEM, it is usually motivated by the desire to collect all the incidents in a single window, so we include this use case in our list.
Use case 2. Splitting incidents of the same type.
When it comes to evolving and long-term activity of the attacker, if the scenario is configured incorrectly, you can encounter a phenomenon called “incident storm”. For example:
- Scenario for an attempt to select a password (more than 100 failed entries). When trying to enter a password 900 times, SIEM will create, at best, 9 incidents / cases in the accounting system (or 9 letters in the mail / sms on the phone - underline).
- Scenario for scanning the network (at least 10 hosts on 5 different ports) - when the internal scanner is in operation, several hundreds of cases / letters / sms will be created.
And in this stream of events it is very easy to miss an incident other than the specified activities. Therefore, a proper SIEM will always allow these activities to be glued together across key fields in order to sort them out as one common incident.
Use Case 3. Enrich the investigation with information from additional systems.
After identifying an incident, the analyst usually has a very large amount of work to find its causes and consequences. Consider the following example: one of the basic rules for monitoring and control in many international standards is to prohibit the use of system non-personalized accounts in the infrastructure. And here we faced the task of controlling the login under the root account on the Unix operating system. Do I need to solve this problem SIEM? Certainly not; Any administrator who knows the basics of scripting will easily create a two-line script that will allow you to detect such activity.
But now let's see what we, as the SOC operator, need to do further with this event.
What is the difference between these two events? Which connection is legitimate and which is not? Now we have only the ip-address from which the connection was made. This, of course, does not allow us to localize the user. Here is how we would act:
- Determine the segment and name of the machine, as well as the name of its owner - (nslookup, DHCP logs, information from the CMDB, memory).
- Using local machine logs and a domain controller, determine the list of users who were active on it during session initiation.
- Ideally, from the process / application start-up logs, find out which of the active users initiated the ssh client process on the host (screenshot) and whether there was a remote work with this machine at this time, for example, via remote administration utilities (RAT).
Only after receiving all this information, we can assume that in the first approximation identified the perpetrator.
After that, it is necessary to evaluate the impact on the system after logging in as root. With a properly configured audit we, in principle, will have enough server logs, but there is one “but”: the attacker himself with these rights could easily modify them. Which leads us to the task of storing logs in an independent source (one of the tasks that are often put under the SIEM). As a result, the analysis of these logs allows to assess the problem and its criticality.
Of course, most of this work can be done without SIEM, but then it will take much more time, and the analyst will face serious limitations. Therefore, although SIEM is not strictly necessary, it has significant advantages in conducting investigations.
Use Case 4. Simple and complex correlation.
Hundreds of articles and presentations have already been written on this topic, so I don’t want to dwell on this example for a long time. I will say the main thing again: today, in order to effectively detect and repel attacks, you need to be able to identify correlations between IS events. Whether it will be the creation and deletion of an account in Active Directory for a suspiciously short interval or the identification of long vpn-sessions (longer than 8 hours) on the firewall is not important. Either way, the basic scripts or tools of the security tool itself do not solve this problem due to the huge amount of security events passing through it. To solve such problems and designed platform SIEM.
Total: the approach to monitoring tasks at the first stage does not necessarily require a SIEM platform, but it significantly simplifies the life of SOC and its operators. In the long term, as we deepen in the task of identifying incidents, the presence of the SIEM ceases to be a recommendation and becomes a prerequisite.
Monitoring - where to start?
Answering the question in the title of this section, the majority of customers fall into one of two misconceptions.
The only task of SOC and information security in general is to combat APT or targeted attacks . Our practice shows that prior to building up the basic monitoring processes, restoring order in the infrastructure and combing the response processes, we should not set ourselves such an ambitious task.
It is possible to think about monitoring only after the entire infrastructure has been covered with a tight cap of protection means and the most modern information security systems . According to our observations, a good first result on increasing the level of information security can be obtained with a minimum set of protection tools. This is confirmed by statistics that we collect on a regular basis: for example, in the first half of 2017, about 67% of events from customers were recorded using basic IT infrastructure services and basic security tools — firewalls and network equipment, VPN gateways, controllers domains, mail servers, antiviruses, proxy servers and intrusion detection systems.
So, the process of monitoring events and incidents can start with enough basic things:
- Perimeter monitoring - emerging new perimeter hosts, exploiting critical vulnerabilities, connecting to personal accounts and administrative interfaces from unknown addresses.
- Internet access control - attempts to use RAT, visiting malicious / phishing resources and accessing botnet control centers (as a rule, they are listed in proxy categories).
- Anti-virus protection - infection of a server segment or critical machines of a user segment, multiple infections of machines, virus outbreaks, etc.
- The use of hacker and malware (often information about it is in the logs of antivirus software and downloaded by a simple report or database request).
- Connection analysis within the framework of remote access - simultaneous connection from several points, connection from foreign ip, etc.
- User Account Control in Active Directory - creation / deletion, elevation of privileges for previously existing accounts, creation of new administrative groups, etc.
As you can see, no magic, and even a SIEM system is not needed. But at least fulfilling these simple rules and launching basic monitoring can be one of the first fairly simple steps to your movement to expert monitoring tasks and building your own Security Operations Center.
Source: https://habr.com/ru/post/340386/
All Articles