One of the major challenges in Enterprise Log Management is “What to Collect and How much to Collect?”. The How to collect is the easy part with several Enterprise as well as open source tools available in the market that help with this. Source Device themselves have several log forwarding mechanisms and features which we can leverage to collect logs.
Most of the times, Log Collection and Management is driven by Standards, Compliance Requirements and other external drivers. Good Security Practice calls for Log Collection and Management to be driven by Enterprise Policy. So in order to implement a Log Management Program, the need to have a strong Enterprise Policy is paramount. This policy once defined should be implemented thoroughly right from the OS Build, Application Certification, IT Infrastructure Design to Solution Approval, Change Approval, and other Operations Process.
What to Collect:
“Never start Log Management Program without knowing your IT Infrastructure”. This is what I would suggest to anyone who wants to start Log Management Program. Knowledge of the network is important to decide on Log Collection Scope and Volume. Generally, we collect logs for several reasons ranging from Troubleshooting IT Issues to Forensic Investigation. My focus in this blog post is of course on Security Specific Log Collection. I would like to mention here that there is no right or wrong way in approaching Security Log Collection and hence what I am trying to catalogue here are my experiences of what has been useful in Security Investigations in my career.
- Core Router– Though Router Logs are chatty, collection of Core Router Logs are important because, if your enterprise Core Router is over-run/compromised then your enterprise is wide open. These router logs can be heavily filtered to identify only DoS/DDoS attack scenarios as well as Exploit Scenarios (By exploiting a vulnerability and owning the router).
- Network Firewall– Firewall Logs are the most helpful in identifying Security Incidents involving Malware, Compromised Hosts, Spam Relays and several other Network based Attacks and Compromises. Keep in mind that the logs don’t directly tell you that a Malware is found in the network, but it gives a great corroborating evidence (In terms of when and what connection was made) to any of your Security System Alerts.
- Network IDS/IPS– Intrusion Detection Systems are a crucial part in the Security Incident Detection and Investigation process. The alerts received from the IDS/IPS gives a lot of information. This when combined with Firewall Logs help to identify the entire Attack Scenario.
- Authentication Servers– In a Network there are several Authentication mechanisms for users to access IT Infrastructure. Most of them go off a Directory service or Database service. Most famous of the these Authentication servers are Active Directory/LDAP, RADIUS, TACACS, Internal User Database etc. From a Log collection perspective, in order to identify the User, his machine and the Authentication time stamp, we would need logs from Authentication Servers.
- Endpoint Security Solutions– The last line of defense in any organization is the Security Systems put on the Servers or the End User machines. These tools can be of great help in a Security Investigation by providing information on whether the Host Defense system detected an intrusion or not.
- Application Servers– Application servers are the main reason one has to protect the network. The application servers be it Web or Database are critical to an Enterprise. We would need to monitor these systems closely for any kind of breach of compromise by collecting logs from Operating System Level as well as Application Level
- Misc Logs – In addition to the above critical log Sources, Enterprises may choose to collect Logs from other supporting IT Infrastructure as well. This however is an all-inclusive list of devices like Proxies, DHCP, DNS, Other Security Tools in the environment, Switches, WAN Devices etc
How much to Collect:
One of the oft ignored aspects of Log Management is Standardization of the Logging Infrastructure. This means that the format should be standardized so that all the Logs can be collected in a Centralized fashion and used for normalization, integration with SIEM Solutions, etc. Almost all the solutions support Syslog as a Logging Format. Network Devices and Unix Devices have Syslog daemons running natively and can be used to send logs to a Central Logging Infrastructure. As far as I know, most of the Security Appliances/Servers also have Syslog capability. Microsoft Windows servers don’t have the capability to send Event Logs through Syslog and hence we would need to use Third-Party tools like Snare, Syslog-NG, WinLogD, Kiwi etc.
Syslog has several levels as highlighted below in the diagram and one should carefully chose the level appropriate to the Organization.
From a Security Perspective, recommendation would be to choose either Level 5 or Level 6. Level 5 mostly covers all Security related incidents logging. Level 6 gives detailed incident logging but will be very voluminous. Level 6 enabled Syslog setting would need extensive filtering to ensure the Syslog Infrastructure is not overwhelmed in volume and subsequently Storage space.
To summarize, More and More information collection through Logs would be invaluable in Security Investigation. Many would say that Log Collection is a “Reactive Approach” to Security Management but remember “Logs Don’t Lie”
I would be writing a detailed Blog post very soon to give details on What Logs to keep and What Logs to Filter. I will try to do it by device type so that it will be easy to read.
Please visit the follow-up post – What Logs to Keep and What to Filter
