Cymphonix Powerful Engines

Visibility:

To manage application traffic, your Secure Web Gateway must be able to identify application traffic in the first place. That job falls to a part of the XLi OS called the Application Identification Engine (AIE).

AIE is responsible for scanning all the datagrams traversing your Internet connection and comparing them to the unique profiles in the Cymphonix library. AIE does the comparison to determine whether the packets represent application traffic, and, if so, which application it is. These signatures are unique to Cymphonix and represent a blend of high-level information, from the port and protocol used by the applications to specific Layer 7 signatures. 

The sheer speed at which comparison must be accomplished makes AIE one of the most complex and optimized processes in the XLi OS. All Cymphonix Network Composers run AIE. In the smallest Network Composer (with a 2 Mbps connection), a simple dual-core processor and 4 GB of RAM are sufficient to execute AIE in real time. For a 1 Gbps connection, the Network Composer hardware scales to 20 GB of RAM and two Quad-Core Intel processors running in hyper-threading mode to provide 16 virtual cores. This solution enables AIE to run with undetectable latency from the user's point of view.

Web Filtering:

Cymphonix uses three tools in parallel to manage its Web-filtering task. The first tool is a database of disallowed sites. It's simple and powerful but the problem with using this tool by itself as the main method of Web filtering is obvious: sites change on a daily or even hourly basis. A static defense against a dynamic threat will fail over time.  Though this type of tool is simple, fast and excellent at defending against known threats, it's only as good as the last update.

Ironically, many vendors go to great lengths to cite the size of their databases as a measure of their product's Web-filtering strength. We think numbers are important, but focusing on just one dimension is misleading. A more important number to consider is how many tools are working together to do the job. We use three. The database is just the first one.

The second tool we use is our Keyword Analysis Engine, which scans the URL for text strings that suggest an inappropriate site. This tool is dynamic and can help keep up with the changing environment of the Web. 

As you know, the limitation of only using keywords for Web filtering is the risk of false positives and false negatives. For example, someone going to visit Essex, Connecticut might want to visit the city's Web site at www.essexct.com beforehand to get information on attractions.  It's too bad, but filters using only keywords as their primary defense would block the site. On the other hand, if someone put up a site about the city that included offensive content and named the Web site something innocuous like www.bland.com, keyword filtering would not flag that site.

Solutions that rely too heavily on keyword analysis run into a lot of false positives that end up blocking legitimate sites. Lots of appliances use keyword analysis because it is efficient and has a small footprint. That's great if there isn't enough space to create a more sophisticated database with processor-intensive tools. Cymphonix Network Composers have plenty of room and processing power to run multiple tools.

That's why we add our third tool, the Real-Time Analysis Engine. This part of the XLi OS scans the actual content of the Web page, as well as the structure, the text, and other content. The Real-Time Analysis Engine then runs a set of heuristics to deduce whether a site that sounds naughty is actually innocent or an innocent site is really the naughty one.

Finally, because no single solution, or even the best-engineered trio of solutions, can be a hundred percent tailored to your organization a hundred percent of the time, we also provide an easy way to add, delete, or reclassify sites.  And because we know building and maintaining a site list is a lot of work, XLi keeps the list intact when you upgrade or change appliances.

Filter Avoidance:

There are many ways for users to bypass traditional filters. The simplest and easiest filters to detect and defeat are anonymous proxy sites. By acting as an intermediary, the anonymous proxy site makes it appear that the undesirable traffic is actually benign-that it comes from the anonymous proxy site and not from the blocked site. 

The good news is that anonymous proxy sites are easily added to a blocked site list if you know about them. The bad news is that it's tough to keep up with all the new anonymous proxy sites. 

The worst news is that there are powerful tools that do not rely on a browser to bypass traditional filters.  Determined users can download applications that use sophisticated techniques to avoid detection. Some applications can even be run from a USB drive so that the application does not ever appear on routine hardware scans.

Cymphonix Network Composer was designed to deal with the new threat categories by using an Avoidance Detection EngineTM. This portion of the XLi OS is designed to sniff out filter avoidance techniques and stop them.  It does so by taking advantage of the Network Composer in-line position and its deep-packet scanning capability.

If a user is running an application trying to bypass a filter by sending traffic on non standard ports, Network Composer can see the activity. Other solutions that only scan a subset of the network are much easier to fool. 

So, what happens when Network Composer sees this sort of traffic? The Avoidance Detection Engine breaks down the traffic to analyze the content. Because filter-avoidance sites and applications all behave in certain ways, the Avoidance Detection Engine looks for specific cues. Tell tale design elements, embedded tags, and certain application behavior suggest whether traffic is trying to bypass the filter. If the traffic sets off enough triggers, our Avoidance Detection Engine flags it.

Next, Network Composer does either of two things. It highlights the traffic for you or your designated administrators in the UI to see, and even sends an email alert if you want. 

Or, if your organization needs a more aggressive response, the Avoidance Detection Engine blocks the traffic and then informs you. Either way, you can rest assured that simple bypass techniques are not going to fool you or the Network Composer.

Performance:

Because Network Composer is designed and optimized to sit in-line, it has has unmatched visibility into what's traversing the Internet connection. It can also use this visibility to provide next-generation Web caching.

We call it True CacheTM technology. Here's how it works. Suppose a user on the network views a popular video clip on YouTube. A second user calls up the same video a few minutes later, but YouTube sends it from a different server at a different URL for load-balancing purposes. A traditional cache stores both URLs, wasting cache space, burning up bandwidth, and speeding up nothing.   

True Cacheuses the intelligence of Network Composer to examine the content of the cache. By "looking" at the video, True Cache stores the first copy and is smart enough to serve it to anyone else wanting to see it, regardless of the URL. This feat is only possible because Network Composer sees into the actual traffic and makes a decision based on information about the content, not just the origin. We know the "what" in addition to the "who" and the "where" of the converged Internet traffic.

Granular Reporting:

Powerful tools must be easy to use. Cymphonix Network Composer sees all the traffic in the network. The Dynamic Live Reporting Engine in XLitakes massive volumes of data and correlates and categorizes it. That way, the Network Composer user interface can present the information in a simple way that lets you or your delegated administrators quickly pinpoint issues and take precise action.

You can drill down through the organization to a department or even an individual-user level. You can see the top bandwidth users, the top traffic sources, the top sites visited, and cast back for history with which to develop trends and policies.

To make this process as efficient as possible, XLi uses another software process called Predictive Report Generation. Suppose you're looking at total converged Internet traffic and you notice a lot of HTTP traffic.  Predictive Report Generation sees what you are seeing and automatically pulls up the next layer of data you would most likely want to see.  For example, you'd probably want to look at information on the applications and the user or group generating the HTTP traffic requests.