Tag: log management
Enterasys, Juniper, and Nortel vs. Cisco…SIEM Handicap Match?
Well I’ve been holding onto this news FOREVER and I”m glad I can finally talk about it. You may know that I’m happily employed at Q1 Labs Inc at the Integration Services Program Manager. You may also have seen the press releases recently about Juniper and Nortel partnering with Q1 Labs to sell a best in breed SIEM solution to compete with Cisco MARS but you may not know all the details. Basically what this boils down to is a good old fashioned handicap match like in wrestling 🙂
A great article by Sean Michael Kerner at the InternetNews site explains some of those details.
Juniper comments of note from the article:
Juniper Networks has utilized the QRadar technology inside of its new Security Threat Response Manager (STRM) solution, which is being announced this week. Sanjay Kapoor, director of product management at Juniper explained that STRM provides correlation rules to help IT to understand the millions of events that can occur across and network and boil them down to actionable items.
Kapoor noted that network administrators using STRM’s advanced event correlation engine could more easily identify which assets were attacked as well as what should be done to mitigate the attack.
Juniper doesn’t just take Q1 Labs solution and use it ‘as is’ rather Kapoor noted that Juniper uses it as framework that is then further customized with the benefit of Juniper’s security expertise.
“We wanted to have a strong response to Cisco MARS and this product is very competitive,” Kapoor said.
Nortel comments of note from the article:
Nortel Networks also uses Q1 Labs technology as part of an OEM partnership deal. The fact that Juniper is also a Q1 Labs partner is not a problem for Nortel.
“This is not a problem for Nortel. On the contrary, this validates our choice of technology and choice of partner,” Shmulik Nehama, director of business development and strategic alliances at Nortel told InternetNews.com.
“We have thoroughly evaluated the QRadar technology and have great appreciation to its security management capabilities. Customers are looking for solutions and QRadar is an important building block of our security solutions,” said Nehama.
Nehama added that QRadar is an important component of Nortel’s solution offering for closed-loop security management and compliance. As such it is part of Nortel’s go to market strategy and is expected to remain as such in the foreseeable future.
Don’t count out Enterasys Networks either. They’ve been a ‘Powered by Q1 Labs’ partner for quite a while as outlined in this past press release.
Enterasys comments of note from the article:
“We are proud to be the first ‘Powered by Q1 Labs’ partner and have been very pleased with the growth of our Dragon Security Command Console (DSCC) business and multi-year engineering collaboration,” said Mike Fabiaschi, CEO of Enterasys. “Our partnership with Q1 Labs and resulting unique integration with DSCC has enabled Enterasys to enhance our Secure Networks(TM) architecture with multi-vendor log management, network behavioral analysis, and security information management capabilities. What this means for our customers is a practical, achievable way to efficiently and effectively sense and automatically respond to security incidents when DSCC is deployed in conjunction with Enterasys Dragon(R) and NetSight(R) network security management software.”
Let the games begin 🙂
The Launch of The Academy Website
The Academy (http://www.theacademy.ca) officially launches its web site today providing instructional videos for the information security community. For the first time ever, the average user to the most seasoned industry expert will be able to watch instructional videos on how to install popular products, address common configuration issues, and troubleshoot difficult problems. The Academy is a user driven community and videos are created at the request of its members. Vendors can also leverage the site to showcase the features and capabilities of their products. The Academy is an ideal place to find and share knowledge with others practicing or interested in the information security field.
Yours truly will be contributing as many log related videos as possible so that people understand how to properly make those crazy blinking boxes they have in their racks send logs.
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 🙂