« Home | Well , after a long time of thinking about it , an... »

UTM – Antithesis For The Current Concept Technology


The world of IT security technologies has evolved greatly for the last 5 years.
By understanding the structure of the current threats that threatens the IT environment of corporate infrastructure – security vendors have created very highly crafted technologies to deal with these threats. We had some major breakthroughs with IPS technologies that currently serves both signature based and proactive scanning methods, Antivirus and AntiSpam technologies can now inspect information to the deepest levels . and there are more than enough URL filtering mechanisms that serves about every major company that require these kind of services to be implemented on their users surfing habits.

UTM is something pretty fresh In that aspect, we’ve seen it growing In the last
couple of years as a major aspect for creating “All-In-One” solutions. The concept is
brought to life by taking one machine that is taking care of stateful firewalling , advanced routing ,IPSec connectivity, and giving it the extra edge by allowing it to connect to modules such as the IPS, AntiSpam, Antivirus and the URL Filtering mechanism to create a full blown inspection gateway that scans just about everything that passes through it, and decide based on scan results if to pass the traffic or rather stop and log it and that point of entry.
Now lets look at the problem. By the UTM concept – our IT should be “secured”
If we are using a UTM device at our core network environment . but – what about
blended threats ? , what about attack and code mutations?
In the second half of 2005 , many analysts and security engineers have faced new
types of attacks , the blended ones , and the mutated ones. These attacks were crafted to skip from one method to the other , from one technology to the other , and IT security measures where if you had a virus , an antivirus solution would have taken care of it, And if you had a DoS attack , the Firewall would have taken care of it , but when an attack would have begun as an Exploit that injects a virus that later on sends out spam and infects other entities via IM , or via SMB – systems are useless to these attacks.

The problem with the UTM concept today – is that companies that manufacture
these solutions , are applying OEM solutions with other vendors . one could OEM with
the best-of-breed antivirus company for his AV module , and OEM with the best-of-breed IPS company for the IPS module and pass the traffic through the both of them . but ! and here is the problem – the modules of different vendors , could not speak to each other . each module of its own honorable vendor is written as a closed source application and can receive traffic from one end , check it and pass it through , but when the IPS module and AV module co-exist but cannot take mutual decisions on the traffic that passes through – blended threats could not be inspected in any way . mutations of the traffic will pass as if there was nothing there to stop them.

Let me explain further more : when the UTM device is used to establish a layer 3
up to layer 7 connection between two entities , it inspects the traffic . now – if there is a mutation attack of some kind ( here is just an example ) – a session is being established
via VPN between two entities , and runs just http traffic between the two. The
termination of the IPSec is being done by the UTM device , which cannot see up until
now if there was an attack hidden in the traffic that came through the IPSec tunnel . then the data is getting into the http server with a 0day exploit on it , so the IPS does not know it. And sends a file that was previously accepted by the UTM device because of the tunnel access control rules. Contains a virus , and the attacker entity is passing it through an IM service . the new crafted virus is the populating itself not via IM , but via SMB , and when that occurs – the virus manipulates itself to attack the core switch via a simple DDoS attack. no UTM device would stop this attack , no single entity to take care of one module will stop this attack. The solution is being send from one or two vendors today , that have come to
mind that if they write their own antivirus , they can manipulate it , and if the IPS code is their proprietary code , they could manipulate is , and where the URL filter is a service which they own . modifications and alterations could be performed . the main issue here is that if you are the sole vendor for all modules inside your UTM device , you can ask them to speak to each other , you could take access control decisions based o blended results of the traffic that passes through your device , and because of stateful technologies, you could understand the deep behavior of your traffic , and so – have access control decisions done by the deepest analysis available.

By creating a single-vendor solution , one is able to interconnect the different
security modules and create a real UTM device , in my terms – “Real UTM” is applicable only if the device , and the different modules come from the same vendor , so it could sanitize the traffic using decisions based on a matrix check of each packet.

The following diagram ( D01 ) shows how a current concept UTM device actually passes
the traffic :



On current UTM environments , the packet actually has to go through each and every
module as a stage of inspection. What may happen is that one module might not be
certain if the packet contains an attack and so not mark it as attack and pass it on. The attack will pass between the different “Best Of Breed” modules and no decision will be taken to drop the packet , because no module found a specific attack in the mechanism and if it could , it wouldn’t be able to tell the following module about the attack because of different technologies , and vendor code confidentiality.

The following diagram ( D02 )shows exactly what happens to a packet that runs through
what is considered a real utm :



What is clearly visible from this diagram , is that a packet that runs through a real
UTM mechanism , runs through each and every one of the modules . note : if a packet is being intercepted by the IPS mechanism – it will ask for the antivirus to check it too , and so on for the AntiSpam and every UTM module. And later on , the UTM mechanism will decide based on scan checks from all of the modules , if to pass it on , or to drop the packet. It is not session based , but packet based.
Now , what is happening in that environment is that each module can give some
kind of grading to the packet , even if it is not sure it is an attack . next , the UTM consolidation engine can grade the packet based on all of the modules , and have a sophisticated decision to drop or to accept the packet , and that is after a real deep inspection.

A new UTM RFC/Protocol is required.

One cannot realize how major vendors will exchange code parts between them,
But maybe some kind of a consolidation protocol is needed here . we had ICAP in the
past to check for different traffic methods, maybe now is the time to write a new protocol that inspection modules could grade traffic by , and a consolidated decision could be made.

In conclusion , the UTM world is a wonderful and insightful world, the best of the
vendors are doing a great effort in order to give us the best practice results and the solutions we require. But because of misleading assumptions ,that “attacks may be more sophisticated but they still spread in the same ways” the UTM world will not be complete. What should be the concept is “an attack can come In different ways and
blended ways , check them all and never skip a phase”.


Labels: , , ,

Syndication : Digg It  Add to Technorati Favorites  Stumble It  Worth Reading 

Sounds very problematic.
You can't have logic that depends on higher layers.
at most, lower layers (IPSeq, Firewalls etc) can report (asynchronously) about possible threats to the unified logic.

אני לא בטוח שאני מבין מה שכתבת
אבל הרעיון הוא שכל מנוע היום פועל בצורה נפרדת ללא כל קשר לתוצאות שאר המנועים , אין קונסילידציה של בדיקות ולכן אי אפשר לתפוס איומים מרובבים.

I believe the integration has to occur at a lower layer. Instead of the module concept think of what it takes to properly do content security.

First you have to terminate VPN's (IPSec, SSL, whatever) Then you have to assemble all the packets into their *content*. Then you can apply various rules to the assembled content such as IPS, AV, URL filtering, Anti-spam. You can branch in this step because an email attachment has to be inspected for viruses but not by the URL filter.

iPolicy and Fortinet are the only companies I know who have taken this approach. Maybe Palo Alto Networks? Certainly any startup in the network security space must take this unified content inspection approach.


About

    My Name is Barry Shteiman, im a devoted tech junkie, and this is my blog.
    E: barry.shteiman -at- gmail.com
    Twitter : bshteiman

Tags & Categories

Mailing List & RSS

Stay Updated  
Add to Technorati Favorites