SOC without SIEM - idiocy or future? Part 2

Part 2 – Architecture overview

 

Standard SOC

Let’s have a look at standard Security Operations Center on picture 1. This only simplistic representation of technology and organization domain. As you can see on in the Technology domain, there is usually a SIEM which is also often considered as a core component or the heart and soul of a SOC. Then we have Big data platform for multivariable historical searches. In some cases you can consider data lake or log management solution as a big data platform. More and more you can see incident response platform in the SOC for SOAR tasks. Ticketing tool is usually already utilized organization-wide ticketing system to issue tickets for IT and other departments and request changes. Very broad term is Enterprise Security Tools (EST) which includes antivirus, network firewalls, EDR, database protection tools, web application firewalls and many more security protection tools. Those are usually log sources for a SIEM platform. Last example is CTI platform which for our purpose we can simplify to providing threat information to other security tools. There might be many more tools like use case database, automation tools, customer portal, reporting tool etc. but for now we can be ok with this example.

From the Organization domain we can usually see a large number of L1 or Tier 1 staff. They are responsible for monitoring SIEM alerts, close false positives, enrich context, check duplicates, update severity and escalate. I am sorry to tell that, but those tasks are not very exciting and that’s why we see a high turnover rate in this role or bored people which lead to another problems. Then we have L2 role. Those guys should perform technical root cause analysis and decide if the alert was caused by a technical problem, mistake or it was an incident caused deliberately by an attacker. L3 role is responsible for business impact analysis and determine recovery priorities. The role description is very brief because it makes no sense to talk in detail about them, but if you want to know more, you can find some useful information for example in this article. Next we have SOC platform admins. Most of them are designated and responsible for maintaining the SIEM. And of course, Security Intelligence which in our case cover roles like cyber threat intelligence, threat hunting, forensics, use case developers and others.

Picture 1 - Standard SOC setup, technology and organization only

Different representation of a SOC organization could be seen on Picture 2. Statement within the parentheses means number of employees in each department and in SOC itself. This example could be considered as a mid/large sized SOC with 24/7 monitoring by L1 and L2 working on a shifts (3 shifts a day) and L3 covering 2 shifts.

Picture 2 - SOC organization example with employee numbers

Returning to technology layer, we have mentioned that Enterprise security tools are log sources for our SIEM platform. That means they are sending logs and alerts to SIEM which should correlate those events and produce SIEM alerts/offenses/incidents. In SIEM we can also check matches against our threat feeds that came from CTI platform. Then we can directly raise an incident in our IRP or after first level of investigation done by Tier 1 analysts. Both options have their pros and cons. After all the investigation, automation, orchestration tasks in IRP we can create ticket (if needed) outside of SOC to perform specific changes/tasks on the infrastructure that doesn’t fall under SOC responsibility. This straightforward and simplistic view is indicated on Picture 3 below.

Picture 3 - Information flow, standard SOC 

 

 SOC without SIEM

 

What would happen if we remove the SIEM? Nothing! Let’s do it!

It is not that easy. In that case we have to forget about sending logs and alerts to SIEM. Instead we have to send only alerts to IRP directly. That creates higher demand on the Enterprise Security Tools (EST). They must have the capability to create rules and generate alerts. But most of the current enterprise level tools can do this respectively their management module can. One can argue that he will rather manage one SIEM platform rather than 30 other tools to generate alerts. Agree, but you have to manage those tools anyway. It is usually easier to create rules directly on EST than trying to create them from logs in SIEM. Because this task is difficult, companies usually have very generic and simple rules based on logs in SIEM.

Removing SIEM increases demand on high quality rules with low false positive ratio that must be implemented directly on the EST. Also, the integration between EST and IRP is more complicated when no common security alerting format (CSAF) is present. But if you can achieve this you can focus on the automation and orchestration part in the IRP. In ideal scenario you can automate all the tasks done by the L1 staff. So let’s remove them and have only L2 and L3 for the investigation.

I have to admit that this is not directly related to removing SIEM. You can achieve full automation of L1 tasks even with SIEM and properly configured IRP, but the reality is that SIEM creates so much false positives and unpredictable situations for which you usually have L1 like eliminating false positives and filter out log source outages, parsing problems, decommissioning issues etc. In the end, removing SIEM will help you to eliminate L1 role significantly.

Next we can remove SIEM admins and focus on other tools, integrations, automation and orchestration. Sounds good, right? Finally, we can utilize SIEM use case developers to work closely with EST administrators to produce high quality, low false positive rules. In the end we can have half the people or even less in our SOC. This is great because finding good security people to work in our SOC is one of the most challenging tasks. How the structure can look like and what could be the impact on number of employees is illustrated on the Picture 4 below.

Picture 4 - SOC organization without SIEM

We should mention that in this scenario where we have removed SIEM we have new requirements for our Enterprise Security Tools. Not only they should be able to create rules and generate alerts that can be sent to IRP, but also they should be able integrate with CTI platform as you can see on the Picture 5. That means that EST should be able to send their internal threat feeds (indicators of compromise) to CTI platform or ingest central repository of IoCs. For some protection tools this is not a standard. That’s why the arrow on the picture bellow is dashed. To be fair, this feature is more important for tolls like firewalls, web and email gateways rather than identity and access management tool. And we could find more examples.

Picture 5 - Information flow, SOC without SIEM

At the end this setup is more complicated on the EST side, but if you invest slightly more in this area, you will have much better preventative mechanisms with detective capabilities. Also, the savings on SIEM technology and associated work force will be much more. If you move the detection on the Enterprise Security Tools you can directly block/stop the attack when detected. When SIEM is responsible for detection it creates a delay because SIEM is not usually capable to stop the attack. It is only passively processing incoming logs/flows. Typically, SIEM alerts analysts or Incident Response Platform and then the action can take place. But this delay can be fatal.

If you have a feeling that I am telling you to stop collecting logs, you are wrong. Please, don’t confuse log management tools with SIEM. It is very common mistake that SIEM is used primarily as a log management, but this is silly and expensive. I can definitely recommend collecting and keeping your logs. They are priceless. Continue using your log management solution, data lake or big data platform. Just try to forget about SIEM

So what is your experience with SIEM? If you think it is costly, complicated, high performance demand tool with little value added, would you consider trying to live without it? It seems that this setup has only advantages: cost savings, better prevention, simplified SOC organization structure. If you decide to remove SIEM or to design your SOC without it, let me know. I can offer free solution and support for the first one to try. I am kidding. The maximum you can get is minimal discount ;-)

SOC without SIEM - idiocy or future? Part 1

Part 1 – the idea

Are you using SIEM within your SOC or security department? What is the value added it brings to your organization? What is the effort needed to keep the SIEM up to date, running and creating new monitoring scenarios, searches and dashboards? If your answer is low value added and enormous effort, you may find this article interesting. In other cases, you can consider this article stupid and author pathetic.

Organizations are using SIEM as log management solution very often. This makes no sense, because there are log management solutions that are cheaper and perform log management tasks better/faster than SIEMs. Long story short, if you do not need real time correlation capabilities and you really only need a log storage and searching capabilities, do not buy SIEM.

Now let’s assume that you need SIEM and you have one. Perfect, but organizations often have problems to define monitoring scenarios for SIEM. And if they do, those scenarios are very basic ones. It is no surprise that for situations like audit log cleared or multiple login failures could be also easily monitored by other means than SIEM. You can configure your EDR solution or antivirus to inform/alert you in case such situation happens. Access to prohibited web sites? Phishing email? Your email or web gateway should alert you. Why to transfer all the logs from those devices to SIEM and integrate the threat feeds that are already available in you gateways? One can argue that this could be useful to verify gateways are working as intended. Really? This is similar approach to another funny monitoring scenario which is monitoring firewall denies. Again, you are basically verifying that FW works as intended. And if you argue that you can evaluate trends and number of FW denies in that case, fair enough, but you are not able to monitor this directly on the firewall or FW control center? If not, you should consider replacing your current firewalls. In the end it will be cheaper than the SIEM technology and improve you prevention mechanisms a lot.

You want to monitor organization internal policies? Unauthorized access, sharing of information, downloading of sensitive files? That’s why DLP exists and it can produce very nice alerts by itself. If you are trying to make your own DLP solution within SIEM, good luck.

What I have also seen in many cases that SIEM is used like centralized tool for alerting? What do I mean by that? IPS is producing alerts, NGFW is producing different alerts, DB protection tools with its own rules is producing another type of alerts. All those types of alerts are transferred to a SIEM solution and each of them is just one to one mapped to an SIEM alert? Does this make sense? Do you need powerful SIEM solution with all those correlation capabilities to make such a simple task? Isn’t this one of the reasons why do we have IR (incident response) tools?

Let’s remove SIEM and have everything in incident response platform! I wish it is so easy. One can argue that in SIEM you can eliminate false positives. Agree, but you should be trying to eliminate the generation of false positives as close to the source as possible. Actually, what you can see in many of the implemented SIEMs they are producing mostly false positives which leads to “alert fatigue”. Analysts are then bored with investigating the same alerts again and again. In the end true incident is often missed because of the flood of false positives so in that case SIEM is not our silver bullet either.

I can only recommend eliminating the false positives on the source itself either by the configuration change on the source directly or on the first security platform that protects the source. If you transfer the false positive to SIEM then you are paying for the license (EPS, storage) and for the time to analyze and close the case.

Often you will also find easier to implement monitoring scenario in EDR or NGFW because you usually have experienced administrators familiar with the technology and within few clicks you can have well defined, fine-tuned rule that will alert you in case conditions are met. When trying to implement the same in SIEM, you need to have specific logs from source. You need to understand those logs and know where the information is present. Then you should know how to implement the rule in SIEM and then you are praying logs are still flowing to your SIEM and format hasn’t changed after update/patch. This requires much more cooperation and knowledge, but the output is the same.

In previous paragraph we have touched the problematics of integrations. With SIEM it starts with log source integration. Format, transfer method, parsing, normalization. All of those needs to be monitored, updated, evaluated after updates/patches both on SIEM and log source side. Enormous effort with little value added and unavoidable problems/outages.

But the same will happen if we skip SIEM and send only alerts to incident response platform. Agree, that’s why I consider this setup as a future. Something like common security alerting format (CSAF) should be defined to ease up the implementation and more focus and investments need to be devoted to other prevention and detection technology.

How would SOC without a SIEM look like? How it will influence the SOC organization structure? Let’s try to imagine this in the next part of our article.

At the end I should give 2 valid arguments why organizations need SIEM solution.
One is that you need SIEM to correlate events from endpoints with firewall events, traffic flows and compare it against information from CTI platform. Yes, agree, but honestly, I have never seen an organization with such advanced monitoring scenarios. Usually, you define suspicious activity based on logs or flows itself. It is not a good practice to create complex scenarios where you chain activities to produce an alert. You may miss an alert in case of small deviation from the defined chain of actions. Also, you can check CTI information from IRP if integrated. But yes, in general, that is one valid argument.
Second is. WTF, we have 20+ people in our SOC. Majority of them put their blood, sweat and tears to make SIEM work. We are investing enormous money and effort to operate SIEM. We can’t simply get rid of it. We and CISO would look like idiots in front of the executives. And that I believe is the correct argument why you should keep the SIEM and consider SOC without a SIEM as a pure idiocy.

5 things you should know about SOC

before you decide to invest in it

 

We want to build our own SOC! This is usually first sentence I hear from customers when I ask them about the purpose of the meeting. The more I speak to them the more I have a feeling that they want to have SOC on one click, fully capable from tomorrow and with belief that their employees can do the job together with their current roles. Honor to the exceptions, but as a see SOC becomes trendy buzzword, lot of companies has the feeling that they need to be part of it, no matter what it means and what it costs.

I could be more than happy with this trend and approach. Being a SOC consultant during those days is pretty comfortable, but there is always a dark side of the moon. Customers have non-realistic expectations, we are trying to speed up the delivery as much as possible spending the days and nights on the customer side and the result is that at the end we are super tired, the SOC staff is angry to spend so many overtimes with us, they are usually unable to adopt new methodology in such a short time. At the end customer spends a lot of money and the outcome is some kind of mutated combination of our methodology and customer SOC staff habits and belief. This is usually far from what we had presented before and what customer expected.  

So, if you are considering building your own SOC or to bring some new capabilities into current one, let me share a few words and answer some questions that will help you to better understand the effort needed and align the expectations with reality.

What is SOC? You can find general terms like: “SOC detects, prevents and responds to cybersecurity threats that matter. SOC has the technology, processes, organization and governance needed to detect, prevent and respond to a wide range of cybersecurity threats.” But for me SOC is the last piece that help us to “close the security circle”. You can constantly control organizational policies and processes that is otherwise controlled only during audits. You can detect and respond early to an insider threats, effectively monitor your administrators and many more. In one sentence, SOC is a way how to make security better, smarter, detect faster and respond accurately.

Bellow you can find answers to the questions I usually receive when I talk with executives.

How long does it take to build basic capabilities? Well it differs from organization to organization and industry to industry, but usually it is from 6 to 12 months. We should mention what we consider basic capabilities. From the job roles it is L1, L2, L3 analysts (sometimes L1, L2+ ), Security intelligence and governance. From technology we count SIEM, ticketing system and some kind of use case library (usually Excel sheet at the beginning). And then use case development and incident response processes. One can argue that 12 months seems pretty long, because ticketing system is usually within the company and you can deploy the SIEM within a day. But the most important are people. If you have them they still need to adopt and adapt to new processes. Not only learn them but also gain experience. Analysts needs to undergo few offenses/incidents to understand what is expected from them. Security intelligence guys has to develop quite a lot of use cases for different technologies and applications so they can assign right urgency, priority and develop really valuable organization specific use cases.

If you want to know more about roles in mature SOC roles, please see the article in here: Does it make sense to build my own SOC

How much does it cost? A lot. But in case you are not able to detect incidents, it will cost you even more. To answer how much it cost you need to know your environment. If we start with the bare minimum that we mentioned above, we have 6-10 people (not 24/7 operations) and SIEM. Let’s do not count the cost of ticketing system to achieve better results :-). Calculate the monthly cost for a security professional in your country and the costs for a SIEM. In that case you need to know the expected number of EPS, FPM or number of indexed data to estimate the costs. If you don’t want to stop with the basic capabilities, you should count some more security professionals and tools like incident response and big data platform, automation tools, cognitive analytics, etc. In that case it is better to ask somebody who has made the calculation before.

Is it worth it? You have to decide if you take the risk or you try the SOC journey. But once you start the things will start to make sense and the “security circle closes”. All your policies and settings can be monitored, permanently and online, not once a year during audit. You will unveil “suspicious admin behavior”, configuration mistakes and many more. Over all it will help you to come up with better solutions, understand your complex environment thoroughly and create policies and security settings that make sense, are applicable and enforceable.

My own, outsourced or hybrid? There is no silver bullet or universal answer for this question. It depends if you are able to find the right people or not. How fast you need to start, which roles you want to keep in house and which you can outsource, but I quite like the hybrid solution. If you are able to define your use cases and describe the incident response steps that should be performed, you can outsource L1 analysts. If you are struggling with use case development bring some professionals from outside and help your people grow. If you have no experience and idea, start with fully outsourced SOC and observe what you don’t like and then bring the key roles and responsibilities in house. But to answer this question it is always better asking somebody with the experience to help with the strategy and roadmap.

When can I have mature and fully capable SOC? I don’t want to scare you too much, but in a standard organization it is not sooner than 3 years. To consider SOC mature you should use information about vulnerabilities and risks, network forensics, big data analytics and processing unstructured data, fraud management, predictive threat management and many more.  In fact, SOC is never ending story. If you have optimizing SOC, you are continuously looking for improvement in processes, new metrics, dashboards that will help you to decide, manage and respond to a threat. Also, the threat landscape is and will be evolving so once you start you will be never done. But is an amazing and exciting journey.

Bring Order to Chaos

By Building SIEM Use Cases, Standards, Baselining and Naming Conventions

Security operations centers (SOCs) are struggling to create automated detection and response capabilities. While custom security information and event management (SIEM) use cases can allow businesses to improve automation, creating use cases requires clear business logic. Many security organizations lack efficient, accurate methods to distinguish between authorized and unauthorized activity patterns across components of the enterprise network.

Even the most intelligent SIEM can fail to deliver value when it’s not optimized for use cases, or if rules are created according to incorrect parameters. Creating a framework that can accurately detect suspicious activity requires baselines, naming conventions and effective policies.

Defining Parameters for SIEM Use Cases Is a Barrier to SOC Success

Over the past few years, I’ve consulted with many enterprise SOCs to improve threat detection and incident response capabilities. Regardless of SOC maturity, most organizations struggle to accurately define the difference between authorized and suspicious patterns of activity, including users, admins, access patterns and scripts. Countless SOC leaders are stumped when they’re asked to define authorized patterns of activity for mission-critical systems.

SIEM rules can be used to automate detection and response capabilities for common threats such as distributed denial-of-service (DDoS), authentication failures and malware. However, these rules must be built on clear business logic for accurate detection and response capabilities. Baseline business logic is necessary to accurately define risky behavior in SIEM use cases.

Building a Baseline for Cyber Hygiene

Cyber hygiene is defined as the consistent execution of activities necessary to protect the integrity and security of enterprise networks, including users, data assets and endpoints. A hygiene framework should offer clear parameters for threat response and acceptable use based on policies for user governance, network access and admin activities. Without an understanding of what defines typical, secure operations, it’s impossible to create an effective strategy for security maintenance.

A comprehensive framework for cybersecurity hygiene can simplify security operations and create guidelines for SIEM use cases. However, capturing an effective baseline for systems can strengthen security frameworks and create order in chaos. To empower better hygiene and threat detection capabilities based on business logic, established standards such as a naming convention can create clear parameters.

VLAN Network Categories

For the purpose of simplified illustration, imagine that your virtual local area networks (VLANs) are categorized among five criticality groups — named A, B, C, D and E — with the mission-critical VLAN falling into the A category (<vlan_name>_A).

A policy may be created to dictate that A-category VLAN systems can communicate directly with any other category without compromising data security. However, communication with the A-category VLAN from B, C, D or E networks is not allowed. Authentication to a jump host can accommodate authorized exceptions to this standard, such as when E-category users need access to an A-category server.

Creating a naming convention and policy for VLAN network categories can help you develop simple SIEM use cases to prevent unauthorized access to A resources and automatically detect suspicious access attempts.

Directory Services and Shared Resources

You can also use naming convention frameworks to create a policy for managing groups of user accounts according to access level in directory services, such as Lightweight Directory Access Protocol (LDAP) or Active Directory (AD). A standardized naming convention for directory services provides a clear framework for acceptable user access to shared folders and resources. AD users categorized within the D category may not have access to A-category folders or <shared_folder_name>_A.

Creating effective SIEM rules based on these use cases is a bit more complex than VLAN business logic since it involves two distinct technologies and potentially complex policies for resource access. However, creating standards that connect user access to resources establishes clear parameters for strict, contextual monitoring. Directory users with A-category access may require stricter change monitoring due to the potential for abuse of admin capabilities. You can create SIEM use cases to detect other configuration mistakes, such as a C-category user who is suddenly escalated to A-category.

Username Creation

Many businesses are already applying some logic to standardize username creation for employees. A policy may dictate that users create a seven-character alias that involves three last-name characters, two first-name characters and two digits. Someone named Janet Doe could have the username DoeJa01, for example. Even relatively simple username conventions can support SIEM use cases for detecting suspicious behavior. When eight or more characters are entered into a username field, an event could be triggered to lock the account until a new password is created.

The potential SIEM use cases increase with more complex approaches to username creation, such as 12-character usernames that combine last- and first-name characters with the employee’s unique HR-issued identification. A user named Jonathan Doerty, for instance, could receive an automatically generated username of doertjo_4682. Complex usernames can create friction for legitimate end users, but some minor friction can be justified if it provides greater safeguards for privileged users and critical systems.

An external threat actor may be able to extrapolate simple usernames from social engineering activities, but they’re unlikely to guess an employee’s internal identification number. SIEM rules can quickly detect suspicious access attempts based on username field entries that lack the required username components. Requiring unique identification numbers from HR systems can also significantly lower the risk of admins creating fake user credentials to conceal malicious activity.

Unauthorized Code and Script Locations

Advanced persistent threats can evade detection by creating backdoor access to deploy a carefully disguised malicious code. Standard naming conventions provide a cost-effective way to create logic to detects malware risks. A simple model for script names could leverage several data components, such as department name, script name and script author, resulting in authorized names like HR_WellnessLogins_DoexxJo. Creating SIEM parameters for acceptable script names can automate the detection of malware.

Creating baseline standards for script locations such as /var/opt/scripts and C:\Program Files\<org_name>\ can improve investigation capabilities when code is detected that doesn’t comply with the naming convention or storage parameters. Even the most sophisticated threat actors are unlikely to perform reconnaissance on enterprise naming convention baselines before creating a backdoor and hiding a script. SIEM rules can trigger a response from the moment a suspiciously named script begins to run or a code file is moved into an unauthorized storage location.

Scaling Security Response With Standards

Meaningful threats to enterprise data security often fly under the radar of even the most sophisticated threat detection solutions when there’s no baseline to define acceptable activity. SOC analysts have more technological capabilities than ever, but many are struggling to optimize detection and response with effective SIEM use cases.

Clear, scalable systems to define policies for acceptable activity create order in chaos. The smartest approach to creating effective SIEM use cases relies on standards, a strong naming convention and sound policy. It’s impossible to accurately understand risks without a clear framework for authorized activities. Standards, baselines and naming conventions can remove barriers to effective threat detection and response.