SIEM and security is very broad and has many different context's depending on your individual and company goals as well as size and scope.
This is a good starter you can sign up for:
https://www.elastic.co/training/elastic-siem-fundamentals
We have lots of good blogs and series that go over a lot of different things as well:
Elastic Security does have a detection engine which can detect events a.k.a "important things happening in your logs" and we have a lot of prepackaged rules/content that can do detection as well as pre-packaged machine learning jobs. Lots of good info here:
And then our recently opened repo of content and rules here:
In a nutshell, SIEM or server side information event management is taking a bunch of log shippers/agents such as auditbeat, winlogbeat, endgame agents for endpoints, etc... and shipping these important log files and information to a central collection spot such as Elasticsearch in a structured manner in a common format called Elastic Common Schema (ECS).
Why this is important is if you imagine you have 10's or 100's of Linux servers, windows servers, routers, endpoint users, etc... where you want to search through the auditd logs, firewall logs, 3rd party product logs, vendor logs, etc... looking for intrusion attempts or intrusion successes or where someone is violating company policies such as using insecure versions of TLS ciphers how are you going to do it at scale? You don't want to go to each computer or remote log in each day into these computers. At this point you need a way to centrally collect them and be able to quickly search through them in near real time or historically and this what the log/agent/sensor shippers such as beats, endgame agents, etc... are used for. Detections is used for creating rules to where you can automate finding the things you are looking for and sending you an alert via email, slack instant messaging etc... in close to real time.
Beats and other security agents will use a normalized common schema for each of these. Lots of different log files from different vendor products will label things in their unstructured log files differently. It would be tricky if you have a type of firewall log file that wants to label a host name as "hostName" and then another elastic document from another firewall log file label it as "host.name" and then another just label it as "hName"
Then your KQL search for your host name of "foo" would be: "hostName: "foo" or host.name: "foo" or hName: "foo", and you begin getting an "OR" explosion of different ways of searching. So the best way to move forward is to normalize as much of this as possible from these different log files into one common format.
Good blog post on ECS:
Also reference information here:
https://www.elastic.co/guide/en/ecs/current/index.html
ECS goes beyond security to let you know. It is the common way to do observability and other domains so if you want to you can do both application monitoring and security but for security the ultimate goal is to be able to do simpler searches for things like hosts, users, processes, etc... to get to information you need across different log files that have been parsed by your agents.
Also to let you know, you are not limited by what we ship as far as agents go. Our agents such as beats, endpoint agents, etc... are there and available as taking as much of the heavy intensive engineering work from analysts so they can focus on what they enjoy doing best which is coming up with interesting analysis techniques for their organizations or threat hunting. But we make these agents "extensible" so you can write your own modules for your own log files or you can always put together your own ECS documents by parsing your own log files using whatever programming languages you want to. Nothing stopping anyone. And since we use ECS, it will just work with our UI and tooling as long as you adhere to the ECS documentation.
Now, to not get too much into the weeds as this is a very large broad topic, another component within our stack is usually a way to do analysis and then a way to begin incident response type workflows when you do see you have a security issue depending on your company policies and regulations.
For that we have timeline and cases:
https://www.elastic.co/guide/en/kibana/current/siem-ui.html#timelines-ui
https://www.elastic.co/guide/en/siem/guide/current/cases-overview.html
Both of those features give you ways to do investigations and integrations with existing investigation tools depending on how your organization decides to do these things. But those tools are there to help with the centralized tooling for analyzing your organizations logs in the simplest ways we can think of that puts the power, flexibility, creativity and ultimately the organizational security responsibility into the analysts hands.