The Super Powers of Layer 7 Traffic Analysis at Wayne State

• By Dian Schaffhauser
• 09/26/08

The six-person information security office at Wayne State University faces the same challenge common to most institutions of higher education: limited resources and unlimited problems--especially when it comes to identifying problematic network traffic.

"We had so many different systems reporting so many different events, no one could really keep up with it," said Graydon Huffman, senior systems security specialist. "You'd have to have a dedicated security force with people reviewing these logs all the time."

With 33,000 students and 5,800 faculty and staff, 50,000 to 60,000 concurrent hosts with inbound connections to the campus, and an estimated 10,000 concurrent internal hosts hitting the network at any given moment, the firewalls themselves were generating between 600 and 700 events per second--each possibly a signal that something malicious was going on. "That sheer volume is humanly impossible to go through and correlate," said Huffman.

So, as IT Director Morris Reynolds explained, the university set about looking for a security information and event management tool that would act as the "eyes" of the security team "to help us make quick and informed decisions on the various traffic that was moving throughout the institution's network."

The evaluation process was managed by somebody no longer with the school, but Huffman said he believes products from ArcSight, Cisco, and Q1 Labs were under consideration. Attracted by the ability of Q1's QRadar to perform layer 7 application analysis and event correlation, the university purchased and deployed the system in June 2007. The purchase included hardware, software licensing, a maintenance contract, and support services. The applications run on Linux-based appliances. Although Wayne State declined to say what it paid, Huffman estimated the total in the six figures.

How QRadar Works
That original installation, done before Huffman joined the university, was deployed as a stand-alone model, which consisted of a console and a QFlow Collector. The console is a 2U server that provides the main interface for users. The collector is a 1U device that performs layer 7 network data flow analysis, by collecting traffic via a tap or mirror port on customer specified segments of their network. A QFlow is Q1's flow format, akin to Cisco's NetFlow and Juniper's JFlow.

Soon after he started, in November 2007, Huffman moved the school to QRadar 6.1 and reinstalled the system from scratch with the same basic setup. "Within the first half hour of being online with version 6.1," said Huffman, "We were able to detect upwards of 10 bot-controlled hosts. They're very difficult to detect because it looks like bona fide traffic, and the control hosts rapidly change."

After attending Q1 training in February 2008, Huffman proposed the campus move to a distributed model. "Our critical devices were sending events at 700 events per second, and we had 200,000 flows per minute to analyze. The console started to become slow when you're throwing as much data as we were at it. We outgrew our initial deployment once we realized what information it could provide," said Huffman. "We were having the console cranking away doing all this analysis."

The Distributed Model of Traffic Management
The distributed model enabled him to split the traffic management functionality among multiple servers. "The console, event processor, flow processor, and flow collectors are all separate severs located in different parts of our network for monitoring," explained Huffman. "One server is doing events--any events that are sent by firewall or wireless devices, authentication systems, Windows event logs, etc. Another server is doing traffic analysis provided by the flow collectors. Together, that's sending data up to the console, which is the main interface for users."

The application analysis capability of QRadar is valuable, said Huffman, because it can peer into disguised traffic. "Say somebody is doing peer to peer traffic, and they change their port to port 80 to do any of their traffic on. Most systems are going to say, 'They're running on port 80. It must be Web traffic.' With QRadar, it dives into the traffic and says, 'You're not doing Web traffic--you're doing peer to peer traffic.'"

In another instance, QRadar detected that something or someone was scanning certain servers, yet the firewalls didn't notice the deception. "Our firewalls were accepting the traffic. But devices were complaining: 'These people aren't authorized to request this information or login,'" said Huffman. Those devices generated security events picked up by QRadar, which then associated offenses with the bad password attempts.

QRadar prioritizes alerts based on multiple inputs. For example, through its layer 7 analysis, it would detect a malicious payload going through port 22 disguised as secure shell (SSH) traffic. Then, said Huffman, if the sender, such as a botnet, moves onto a network that knows a particular type of traffic isn't allowed; in that case, the firewall will generate a deny event. "And say you hit a server that's also denying that type of traffic that's tied to an event log in QRadar," Huffman explained. "You'd have three things that say, 'Something really fishy is going on here.' QRadar will take that information and combine it into an offense. Depending on how malicious this offense is, based on your security policies, as well as default settings, QRadar will notify you on a magnitude scale and allow you to deal with high priority offenses first." Those offenses will show up on the console or generate e-mail or text pages.

Huffman said he's configured QRadar quite a bit. "Everyone's network is different. Being in an educational institution, we have a completely different structure from a corporate environment. We have to keep an open environment for the free-flow of information where a corporate environment can lock more down. Even if we'd like to shut something down, it would hinder the research processes that fuel our university."

A next step is to expand the number of QFlow Collectors deployed to the campus. Although traffic coming into and leaving the campus is covered 100 percent, the next quarry will be internal traffic, what's traveling from building to building. "If someone's infected with something or scanning across our network from inside our network, the only way you'll see it is if a device complains: 'Hey somebody's trying to get into me,' said Huffman. "Without having QFlow Collectors internal to the campus, we'll never see that traffic, until it goes outside the network or reaches an internal QFlow Collector, where it's recorded."

Figuring out where to put those collectors, he said, is a matter of determining locations of greatest risk. "If a certain department is doing financial transactions or is responsible for student data or medical data, then we want to see what type of traffic [is being generated] and who's actually doing the traffic. We can now see things we never knew were happening."

Likewise, added Reynolds, "Depending on the introduction of a new service by the institution, traffic patterns may change from what they were yesterday to something different. If that new service offering hasn't been monitored, it becomes necessary for us put something in place to capture traffic, especially if it's going to impact overall network growth."

"For those areas on campus that may house personal, identifiable information, we need to ensure we have necessary safeguards in place to monitor any type of suspicious activity or attacks against holes that may exist in those networks, so we don't run the risk of security breach or compromise."

Should there be a compromise or data breach, said Huffman, "we'll have a record of exactly what happened and be able to recreate that and who may have gotten that data."

Looking to the Future
Huffman, who has been in IT for 15 years, said the technical support provided by Q1 is the best he's ever seen. "If I open up a support ticket online through their self-service portal, I usually have a response within 15 or 20 minutes. Usually the issue is corrected within the hour. I've noticed that 24 hours a day."

One request he made to the vendor was inspired by the recently passed Higher Education Reauthorization Act, which mandates that institutions have a plan to combat unauthorized distribution of copyrighted material, including peer to peer traffic. As the security administrator, Huffman can already be notified by e-mail when QRadar detects that kind of traffic crossing the network. He suggested to the company that it add a feature to automate the generation of an e-mail to the offender as well. "It knows the user name associated with that IP address," he said. "So send them an e-mail: 'We're not saying you're doing something wrong, but we are aware of the type of traffic you are producing, and, if you are doing something wrong, cut it out.'"

He could find out how successful the request is as early as the fourth quarter, when version 6.2 appears.

Even if it doesn't show up in the next release though, he's happy. "I would advise any university to have some type of product along the line of QRadar," Huffman said. "There's no way that a security staff can keep up with the sheer volume of events and traffic. You need something that can cut down and actually allow you to see the highest magnitude offenses rather than having to do the hit-or-miss find-the-needle-in-a-haystack deal."