Tag: security
SANS Toronto 2008 Keynote Roundup
As most of you already know, yesterday I was involved in the SANS Toronto 2008 keynote along with Rob Lee, Bryce Galbraith, Peter Giannoulis, Dave Shackleford, Dr. Johannes Ullrich, Stephen Sims, and Guy Bruneau. This was the first keynote that I had the pleasure to be involved with but I hope it won’t be the last.
We had a full room with a mix of local and out of town students, all of whom were having a blast. “How do you know they were having a blast” you might ask? Even though we were talking about serious topics pertaining to security, my fellow panelists and I had the entire room laughing like crazy. In fact, I think I saw a few people whipping away tears from laughing too hard.
I think everyone had a good time, myself included, and the thing that set this keynote apart from previous keynotes that I’ve seen is how laid back and fun the talk was. There were questions about social media and the validation of identities, acceptance and rate of deployment for mainstream wireless infrastructure, the shaping of traffic to prevent P2P transmissions, and several others. All of the panelists were able to add their insight into the posed questions and I think the crowd appreciated how frank we were in our responses.
I think they also enjoyed the running joke about including www.theacademy.ca, in one way or another, in almost all of our responses. It was one of those “you had to be there” jokes but, trust me, it was hilarious. I didn’t get a chance to see the reviews filled out by the students but I hope they enjoyed the session as much as we all enjoyed presenting it.
Maybe SANS will let us do it again some time.
Presenting Keynote at SANS Toronto 2008
I guess I forgot to post this earlier but on Saturday, May 10th I’ll be presenting the keynote at SANS Toronto 2008 on Future Trends in Network Security with Rob Lee, Bryce Galbraith, Peter Giannoulis, Jason Lam, Dave Shackleford, Dr. Johannes Ullrich, Stephen Sims, and Guy Bruneau.
When not presenting I’ll be hanging out at the conference, talking with people, and defending my views on network security. If you’re attending the conference then please pull me aside and say hello.
Segregating Your Logging for Availability
Although not a new concept, I thought I’d remind people of the benefits of sending your security, system, and application logs across a segregated network to maintain availability. Consider the following scenario:
Your network is experiencing a horrible worm outbreak that is eating up critical bandwidth as it attempts to spread from host to host. All of this malicious traffic is causing your firewalls, intrusion systems, routers, switches, and servers to feverishly log every worm related event they possibly can. The corporate security policy dictates that all event logs are to be sent to a log management server so that no logs are lost.
This remote logging, although small when you consider the size of an individual log (A UDP syslog packet cannot exceed 1024 bytes), does impact available network bandwidth. This is especially true if thousands of logs per second are being transported to a log management or log storage solution through the same path as your regular traffic (1000 logs per second X 1024 bytes = 1,024,000 additional bytes per second — worst case of course). Similarly, a Denial of Service (DoS) or Distributed Denial of Service (DDoS) could also adversely impact the rate at which regular data, and associated logged events, flows through your network infrastructure.
You could investigate implementing QoS rules for your logs on your existing network but all this does is dedicate already sparse network resources to your logging traffic. This is a good solution if your main concern is the availability of your logs but it does nothing to help reserve bandwidth for your network traffic during the outbreak.
If you designate a separate and distinct network segment for the transmission of your logs, you can keep your critical network bandwidth available for regular operation while you mitigate the outbreak. This can be as simple as configuring an additional interface on your device for logging or as complex as creating distinct VLANs for the logging traffic (which, in all honesty, isn’t all that complex a task). Although this is a great solution for maintaining the availability of both your network traffic and your logging traffic, there is an associated infrastructure cost (switches, network interfaces, rack space, power, administration overhead, etc.). Hopefully you can see how this short-term investment will pay off in the long term.
I haven’t discussed the business case for segregating your logging for security reasons but I will in a future article. Segregating your logging for availability, however, is definitely something to think about when you’re planning your logging infrastructure 🙂