2

I've finally gotten the networking team to start sharing data on the devices they manage (routers, firewalls, VPN, NAC, etc), so we can get better insight into our network and focus more on detection.

In a best effort to not create a fire-hose of discarded logs. I want to approach this in the most efficient manner possible.

I wanted to seek advice from the community as this is a new-ish topic for me.

We are in the process of getting a SIEM, and my first thought is to work with the networking team to determine what syslog from said networking devices above (sent to the SIEM) would be useful for our needs.

I was wondering how everyone else approaches this area? Is it normal for security personnel to have direct access to firewalls, NAC interfaces, etc? or is a syslog output for what we actually want more appropriate?

2

When starting an SEIM project, a step-wise approach to security events management is a good approach EG inventory and prioritize your infrastructure, and rate each device according to its security impact/exposure. For example, you will get more detailed security event information from a firewall than from a router. Likewise with web access logs, OS level event logs and HIDS.

Is it normal for security guys to have direct access to firewalls, nac interfaces, etc

That depends on the organization and security processes. Firewall configuration may be left to network administrators, while security operations may be responsible for monitoring logs and auditing policy changes, while having no direct access to their configuration.

is syslog output for what we actually want more appropriate?

At this step in your process, yes logs represent the main data source for your SEIM implementation. The biggest challenge in aggregating logs for use in SEIM is filtering out noise, and focusing on real security event signatures, in order to eliminate false positives, and avoid the "firehose" effect you mention.

As a suggestion, at this step, consider log aggregating services like PaperTrail and Splunk. You quickly get a view of all your log events and formats in realtime, and can begin to define filters, and generally understand what log data will be critical for your SEIM implementation.

  • Thank you for the insight. I agree with you on multiple points here, I'm perfectly ok with the networking team doing the implementation but yes auditing policy change is crucial for us. I'm all about filtering out the noise, not sure what approach we'll take but I like the idea of sending all syslog to one point then filtering from there. Regarding PaperTrail vs Splunk, both look expensive and not sure how I feel about syslog in the cloud yet. We've evaluated ELK but to much tinkering to work right. Looking into Graylog now. thanks – estudiante Oct 23 '15 at 20:50
1

Security architecture is essential in this scenario. As Rodrigo said, you should prioritize. Especially when there's a budget involved. Identify ingress/egress points, identify critical infrastructure that you NEED to monitor without question and try to deploy sensors around that.

You also need to keep data retention in mind. In a perfect world, we'd log full packet capture all day every day but in reality, most networks generate way too much traffic to keep full packet capture for a decent amount of time. Consider solutions such as NetFlow v5 which is much easier on data storage and still provides the data you need to correlate logs and investigate incidents.

Also, the killer, identify where you have NAT to ensure you don't lose half of the logs to NAT. For example, if you have a sensor on either side of a load balancer that is not configured with X-Forwarded-For or Enhanced Logging, source IP addresses will be a lost and investigations will become painful.

When it comes to access to logs, I personally believe that network security analysts in particular should have access to any/all logs available to help correlate logs from various sources and speed up investigations. Not necessarily admin access but, read-only access would suffice. So you'd have logs from your sensors, firewalls, syslogs from routers/load balancers etc. If you only have access to logs originating from sensors, once again, life can get tough.

Final point is to identify all log sources, choose a suitable SIEM and centralize/forward all logs to the SIEM. Jumping to different devices to search a specific IP address between X and Y date is tedious and horribly time consuming when there's a lot of powerful SIEM solutions out there.

When it comes down to it, you mentioned that you didn't want to create a "fire-hose of discarded logs", I personally feel the above is the best way to go about it. Redesigning the network infrastructure from a security perspective will take a lot of work but in the end, you'll be working with what you need and hopefully, noise will be minimal.

Ran over time a little, apologies.

  • Thank you for the input. Will definitely identify our most critical points as a good start. I've thought about retention and yes we have a huge network so the data will grow quick, good to note. Totally didn't think about NAT yet but will keep this in mind when we do our design. Now just need to decide on a SIEM solution. Thank you! – estudiante Oct 23 '15 at 20:56
1

Most network devices can be configured to only send specific kind of logs to a Syslog. Also I do not think that you are looking for the information from the Routing and Switching Protocols that exist in L2 and L3. So, Except for logs from certain Security devices and certain key Routers, I do not see the value in collecting logs from all of the network devices.

My advise is to start from shipping the IDS logs first and then gradually identify the other key areas/protocols/devices and then ship logs from them.

  • 1
    Thank you for the input this definitely helps keep what were trying to achieve in perspective! – estudiante Oct 23 '15 at 20:57
  • Hey following up with this, what kind of data from a "key" router would I want? Also what could I get? According to my networking team, the key router wouldn't have any info of my need/use. Thank You – estudiante Oct 30 '15 at 19:38
  • I was referring to the Core Switches and Routers where an attack on STP could be paralyzing. logging BPDU messages and also logging changes to these devices can be of interest. more info about STP - tomicki.net/attacking.stp.php – JOW Nov 2 '15 at 11:04
  • Then there are Backbone routers, where attacks on routing protocols are possible. refer to the Attack Detection Section in this paper. ijcnwc.org/papers/vol3no32013/7vol3no3.pdf – JOW Nov 2 '15 at 13:53
  • 1
    Hey, yup I knew you probably meant core routers and thats what I inquired about with my networking team. Thank you for the info, this helps! – estudiante Nov 3 '15 at 23:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.