Severity level is used to determine the message's importance. (See "Syslog Message Severity") You can set the severity level for each device based on the impact a compromise would have on the organization and how quickly someone would need to react. Many organizations make the mistake of not properly defining severity levels and therefore don't get the full benefit of using syslog. For example, if my pager is going off all the time with emergency-level alerts, after a few hours

I am just going to ignore it. However, if it is tuned and I hardly ever receive emergency level alerts, I'm going to react immediately when it goes off.

If the severity levels are set correctly, syslog performs basic functions much like a host-based intrusion detection system (HIDS). Using syslog or a contemporary HIDS/IPS product that uses a centralized syslog server, you can address several key security issues:

• Single sensor. If you think of each device as an HIDS sensor, a centralized syslog server can correlate data from multiple hosts.



• Network IDS limitations. One of the problems with a network IDS (NIDS) is that it doesn't see what the host sees. Fragmentation and other TCP-based attacks could trick the NIDS into thinking it is one type of traffic when in reality the host will process it differently. A centralized syslog server will see what the host actually processed. This becomes critical as more traffic is encrypted, since a host logs its information after the data is decrypted.



• Validation for tuning HIPS. As HIDS technology becomes more accurate, a natural evolution is for the software to not just detect, but prevent attacks. However, organizations have no tolerance for HIPS false positives and need a way to validate an attack before blocking it. Syslog can function in that role not only for a single host, but across an entire network.



• Monitoring firewall rule sets. A key principle in tuning a firewall is to adhere to a principle of least privilege, but this can be difficult. Since a syslog server can log information on each individual service, this could be tracked back to each port that is allowed through by the firewall. Now, you can map the firewall rule set back to each host and use syslog to validate whether that port or service really needs access through the firewall.