One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 486691 |
| Date de publication | 2018-02-20 14:00:00 (vue: 2018-02-20 14:00:00) |
| Titre | How SIEM Correlation Rules Work |
| Texte |
SIEM is a powerful security tool when deployed properly. Network security appliances like IDS devices, IPS devices, and firewalls generate an awful lot of logs. A well-configured SIEM will alert security administrators to which events and trends they should pay attention to. Otherwise they’ll be too lost in event log noise to be able to effectively handle possible security threats to their network.
One of the key components that a functioning SIEM requires is good and sensible SIEM correlation rules. Let’s learn how SIEM correlation rules work! It’s actually pretty simple and easy to understand.
What is a correlation rule?
The various appliances in your network should be constantly generating event logs that are fed into your SIEM system. A SIEM correlation rule tells your SIEM system which sequences of events could be indicative of anomalies which may suggest security weaknesses or cyber attack. When “x” and “y” or “x” and “y” plus “z” happens, your administrators should be notified.
Here are some examples of SIEM correlation rules which illustrate this concept.
Detect new DHCP servers in your network by watching for inside or outside connections which use UDP packets (“x”), have port 67 as the destination (“y”), and the destination IP address isn’t on the registered IP list (“z”).
Warn administrators if five failed login attempts are tried with different usernames from the same IP to the same machine within fifteen minutes (“x”), if that event is followed by a successful login occuring from that same IP address to any machine inside the network (“y”).
The first example could indicate a cyber attacker establishing a DHCP server to acquire malicious access to your network. Any authorized DHCP server would use one of your registered IP addresses!
The second example could indicate a cyber attacker brute-forcing an authentication vector and then successfully acquiring authentication to your network. It could be a possible privilege escalation attack.
Both SIEM correlation rules could be triggered by honest mistakes and simple user errors or technical glitches. But they’re also key indicators of cyber attack and security administrators should check them out right away!
SIEM correlation in a nutshell
Your SIEM will analyze a whole lot of event logs which record endless seemingly mundane activities. They will look mundane to a human being if they just keep reading a list of thousands of events.
Connection established from some IP address and some TCP/IP port to another IP address and TCP/IP port! Some user changed their username on Tuesday and their password on Thursday! Some client machine downloaded 500MB and uploaded 200MB of network traffic one day, then downloaded 3.5GB and uploaded 750MB of network traffic the next day!
Properly designed SIEM correlation rules cut through all of the blah, blah, blah of your network event logs to detect which sequences of events are likely indications of cyber attack. So you should take great care in developing your SIEM correlation rules. SIEM is driven by computers and computers will just execute any instructions you give them. You as the clever human being with an organic brain should come up with practical SIEM correlation rules so your SIEM system can wake you up when there’s a possible cyber attack you should pay attention to.
What is normalization in SIEM?
Various different software, hardware, and networking component vendors use their own event log formats. An event log will have different information fields. A SIEM system will do its best to read the various event log formats in order to make sense of them. If you make Excel spreadsheets, imagine all of the different ways someone could d |
| Envoyé | Oui |
| Condensat | “gateway “ip “public 200mb 500mb 5gb 750mb able about access acquire acquiring activities actual actually address addresses administrator administrators alert alerts algorithm alike all also analyze anomalies another antivirus any appliances applicable application applied are attack attacker attacks attempts attention authentication authorized away awful balance being best between blah both box brain brute built but can care challenge challenges change changed check clever client column come component components computers concept concerned configured configuring connection connections constantly consuming correlation could cut cyber data day decide deciding deployed designed destination detect determine developing devices dhcp different disable downloaded driven easy effectively efficiently effort efforts endless errors escalation established establishing event events example examples excel execute execution factor failed false far fed fields fifteen filter filtered firewall firewalls first five followed forcing format formats from functioning generate generating get give glitches good great handle happens hardware has have here honest how human ids illustrate imagine impossible improperly improve indicate indications indicative indicators information inside instructions intelligence ips irrelevant isn’t it’s its just keep key labeled lead learn less let’s like likely list log login logs look lost lot machine make making malicious many may might minutes miss missing mistakes monitoring more mundane need network networking new next noise normalization not notified nutshell obviously occuring one order organic organize otherwise out outside own packets password pay pipeline plus port ports positive positives possible powerful practical pre pretty privilege properly read reading record recorded reducing registered relevant requires responding right rule rules same scratch second security seemingly sense sensible sequences server servers should siem siems simple slow software some someone sort specific spreadsheets strike successful successfully suggest system take tcp tcp/ip technical tells than them then there’s they’ll they’re thousands threat threats through thursday time too tool traffic trends tried triggered tuesday udp understand universal uploaded use user username usernames valuable various vector vendor vendors very wake warn wasting watching ways weaknesses well what when which whole will within work working would written your zero |
| Tags | Guideline |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.