Photo Credit: Pete Cruickshank via Compfight cc
What is a SIEM?
A Security Information and Event Management system is where all the systems in your business environment that can log anything about how they are operating should be sent to get aggregated and correlated in an effort to detect key events.
You can think of the SIEM as your central nervous system. Just as your brain receives sensory input from various parts of your body, so the SIEM receives input from the various devices operating in your network environment. Your brain takes in information about your environment via your senses: sight, hearing, scent, taste, touch and temperature. You are also able to develop an understanding of how you are interacting with your environment through your perception of balance, pressure, and weight. When you become ill, your sensory input from your body reaches your brain and you become aware that you aren’t feeling so good. A correctly configured SIEM can benefit your organization by helping to inform of security related events, and can help detect configuration problems that you’d otherwise be unaware of.
How Does a SIEM Benefit My Organization?
Imagine a room full of people and they are all talking to you at once, it can be quite overwhelming. If you had a way to filter out all of the voices except for specific ones that are saying things that are important to you, it would enable you to process that information more efficiently.
In a typical business environment there are multiple technologies and equipment in use. Security equipment, network equipment, servers that perform various functions, workstations all have the ability to log events and provide information to a SIEM. Imagine having to log into every device or multiple control panels/management consoles every day to attempt to determine if everything is operating optimally or to determine if the device is still secure. It would be quite inefficient.
The amount of time it takes to go around a room to listen to what everyone is telling you is time you could have spent being more productive just as time spent logging into various consoles/portals is just as time-consuming. A SIEM can take all of the input from the various logs across your environment and use correlation and alert rules, in order to alert you through a single interface to the many things going on in your network and on your systems
Example Scenario
A SIEM is not a turn-key solution. Many have correlation and alert rules built in, but you need to evaluate your environment and its logs to determine what is most important to you. This is a method called tuning.
Your brain does it every day. Imagine having an aquarium in your living room and if you listen you can hear the water being filtered. Now turn on your TV. If you couldn’t tune out the sound of the water being filtered, it might be more difficult to hear the TV unless you turn up the volume to drown out the sound of your aquarium. Your brain however, allows you to “focus” your attention on the TV and “tune out” the sound of the noisy water filter.
Now let’s imagine we have high-tech TV and aquarium filters that have a log functionality that is similar to your servers and appliances on your network. If your aquarium and your TV were sending logs to your SIEM, your TV would likely be sending notifications of what channel it was turned to, what the volume was turned up to, what show it was playing, whether the stream was HD or standard.
The aquarium would be sending you logs of how much water it was filtering per second, what its ammonia, nitrate, nitrite, and Ph levels are. If something were wrong with the water filter while you were watching TV you’d not be aware because you tuned out the water filter noise. Let’s say it stops filtering water. The noise level in the room decreases. Your brain will likely notice, but you won’t be immediately aware because you are focused on the programme you are watching. The filter begins sending events to the SIEM with messages like the following:
- 03-15-2015 01:15:25 SMARTAQUA [1591] Warning: flow rate has decreased by 20 L. Input line may be congested. Please inspect input tube.
- 03-15-2015 01:15:30 SMARTAQUA [1591] Warning: flow rate has decreased by 35 L. Input line may be congested. Please inspect input tube.
- 03-15-2015 01:15:35 SMARTAQUA [1591] Warning: flow rate has decreased by 47 L. Input line may be congested. Please inspect input tube.
- 03-15-2015 01:15:40 SMARTAQUA [1591] Warning: flow rate has decreased by 60 L. Input line may be congested. Please inspect input tube.
- 03-15-2015 01:15:45 SMARTAQUA [1591] Notice: Received signal to disable filter motor.
- 03-15-2015 01:15:55 SMARTAQUA [1592] Error: Filter motor disabled.
Once a SIEM receives the congestion messages, if appropriately configured, it can be configured to respond to the device using the device’s API to shut down the filter and to begin alerting you that something is wrong.
Let’s say your home SIEM sends you an SMS when it sends the command to disable the filter motor. Immediately, your phone goes off within seconds of receiving the above logs and disabling the motor. You check your phone and you look over at your aquarium to see the new plant you bought is wrapped around the input tube because it wasn’t secured via the substrate. You pause the TV programme, clear the input tube and turn the motor back on. This time you move the plant away from the input tube and secure it in the substrate, then you clear the alert in the SIEM so you can get back to watching the TV. You’ve saved your fish, and thankfully you spent the money on a smart filter and a SIEM!
Simple Monitoring vs SIEM
Many organizations would rather simply monitor for certain events than purchase a SIEM. A monitoring tool will generally work via SNMP, WMI, ping, heartbeats, or matching output to a request. Monitoring is exceptionally good to have. However, it cannot alert you to misconfigurations or security issues.
Imagine if you will that the only way to monitor your heart is by listening for its beat. The only things you could tell by the beat is how fast it’s beating. You can’t tell its pressure or physical status, except that it’s working. When you go to the doctor they put a cuff around your arm to enable them to determine the force of blood against your artery walls and between heartbeats. If they only took your pulse and listened to your heart, they may never detect if you have high/low blood pressure.
It is strongly advised to monitor your systems for more than a ping response. Monitor the key processes that enable each system to perform its function. For example, if the server is a database server, you want to ensure the database programs/processes are running. If they aren’t, then your monitoring program can alert you.
If you are only monitoring for ping responses, a database server can be up, but the database itself could be down and you’d never know it unless you logged in to look, or your applications that depend on the database stop working – at that point it could be too late and your customers or end users are aware of the failure. If you have a SIEM in conjunction with the process monitoring, you have event data to correlate with the failed process/program. You could possibly see that someone logged in and killed the process, or maybe the disk filled up and caused the process to die. Without the correlation piece, you’d have to log into the system and spend more time investigating why the process died manually.
Hopefully I’ve given you enough insight into why a SIEM is crucial for any networked environment, just as crucial as your central nervous system.
