Air Gap info from Whale's founder

[Elad Baron <elad () whale-com com>]

As the founder of Whale Communications, and the original architect of the
e-Gap System, I would like to share with you some of the design
considerations we had while developing the product.

But before I dive into the technical issues, let me just briefly comment on
the definition issue that keeps popping up in this discussion. I do not
believe marketing issues such as names of categories should be a major
concern in a technical newsgroup as this one but let me assure you that the
differences from a security standpoint between the e-Gap System and a
typical (lets say Check Point) firewall are much greater than the
differences between such a firewall and a router. So if you agree on the
distinction between the firewall category and the router category, you
should have no problem accepting the Air Gap category.

I certainly agree with all of you who wrote that a secure transport
mechanism is not enough i.e. as long as you are passing bits from anywhere
to anywhere it can be used to tunnel everything else even if your transport
is based on carrier pigeons.   ***The secure transport mechanism we have is
a means to achieve our goal; it is not the goal!*** 
The goal is to achieve a higher level of security by reducing the domain of
the problem. Instead of attempting to solve all perimeter security issues
(i.e. general purpose firewall), we have chosen to concentrate on a specific
business demand, and provide a superior solution for it. The specific issue
we felt deserves greater attention is the inbound traffic from untrusted
users to applications in the back office. We are focused only on access from
the outside to your applications - we do not deal with your internal users'
traffic to/from the Internet. Your internal users will still browse out
through an Internet firewall.

This answers one of the repeated arguments in this discussion: the system
*cannot* be used to tunnel everything, since insiders cannot initiate
outbound connections - the only data flow that goes through the system is
initiated by outside users to pre-defined servers in the back office. The
outside user cannot even specify a destination address!
To assure that, we needed a physical gap. TCP/IP by its definition
contradicts this mode of operation. In TCP/IP the originator decides where
the data will go. Security products then try to enforce a legitimate route.
TCP/IP is very complex, very flexible, and very robust - all factors that
make security enforcement much harder, if not impossible (needs to handle
compatibility issues, fragmentation at different layers, etc.). We wanted to
separate the TCP/IP front end from the security policy enforcement. With the
Air Gap design, we can have all the flexibility of the TCP/IP as a front end
(on the external e-Gap server) without compromising security. In the above
argument, for example, the configuration holding the real destination of the
inbound data is stored on the internal e-Gap server. Even if the external
front end is compromised, the hacker cannot send data to other destinations.
 
Destination servers, however, are not the only things protected by the air
gap. The private key, used to decrypt and authenticate the transaction
(whether it is an encrypted URL using SSL or encrypted file using PGP), is
also stored on the internal e-Gap server. This allows you to get the
assurance level that SSL theoretically provides, without compromising it by
running it over unsecured layers. In a traditional design, the private key
and related cryptographic information must reside on the DMZ, which is
definitely not a secure enough environment to protect your PKI
infrastructure.

The third element that is hidden behind the air gap is the application level
content inspection. There were many remarks in this discussion whether it is
feasible to protect against application level attacks. The answer is very
clear (albeit unsatisfying): there is no solution that can detect
automatically all poorly written application flaws. Some can be detected
automatically, some will always require manual intervention. Our approach
was to create a platform that will let the security officer have the tools
to enforce application level rules if known, and to integrate with other
technologies that find some of those vulnerabilities automatically. It will
not always be possible to use the maximum granularity that the e-Gap allows,
but you can mix and match. Use fine granularity for sensitive parts of the
application (e.g. a shopping cart plug-in you bought from a third party -
you have the spec and you cannot check or fix the source code. In this case
the e-Gap will verify the parameters match the spec) and use courser
granularity for other parts (allow only .gif in the images area; disallow
the parameter "DEBUG" from all URLs, etc.). In addition, in our new release,
we offer a tool that helps you create this rule set per specific web based
application. Even with all of the above in place, I would always recommend
to make every effort to address as many application level issues as possible
at the application itself (whenever practical).

Going back to differences from firewalls - from a practical standpoint,
these content inspection properties can be seen as rich features (that in
theory could have been implemented on a firewall); however, from the
security standpoint, the difference is in the assurance level that those
features will not be bypassed, which is achieved by their separation from
the front end. 

Last, is the issue of the physical disconnect. Now that I have gone over the
reasons why we need to separate the TCP/IP front end from the security
policy enforcement, I can explain why we needed a physical disconnect. We
need some kind of a gap to implement the above separation and we need a safe
transport to shuttle data over that gap. For the transport mechanism, the
idea is to use an existing protocol for its communication properties (i.e.
bandwidth, industry support, wide choices of server compatibility, etc.) but
of course, not to use a protocol that is traditionally used for networking
(after all, we wouldn't want "smart" operating systems to bind it
automatically to their TCP/IP stack by any chance). Sounds pretty easy -
just pick a point to point protocol, such as RS232, SCSI, firewire, etc,
right? Wrong! The more throughput and communication features you want, the
more complex that P2P protocol is. And again, none of these protocols were
designed with security in mind (for example, SCSI protocol relies on the
"honesty" of the bus members when doing its negotiation - the lower SCSI ID
member should stop using the bus after it loses to a higher number). By
using such a protocol you would theoretically (and practically?) be
vulnerable to a staged attack that exploits vulnerability in the P2P
protocol itself. 

Of course we could have created a new P2P protocol, but who would assure you
that there are no vulnerabilities in this new protocol?

**The solution - use a standard protocol, but break it in the middle!**  We
use SCSI protocol, but this protocol is between the external e-Gap server
and a "dumb" device (the e-Gap appliance). When this conversation is over,
the dumb device is disconnected from the outside and physically connected to
the internal e-Gap server (using analog switches on the SCSI wires). Then, a
new SCSI conversation takes place between the dumb device and the internal
server, transferring the raw data. Even if a hacker tries to exploit a
weakness in the SCSI protocol, those attempts will not reach the inside. The
dumb device is hard coded to "speak native and honest SCSI," and cannot be
re-programmed or bypassed. It does not have a TCP/IP address, does not have
an operating system, and is not programmable. Just memory banks with a SCSI
interface, all solid state. So the only thing such a low level attack could
achieve is a manipulation of content data, and that is being handled in the
internal e-Gap server as explained in the previous section.

All of the above answers our basic requirement: even if the front end is
compromised and the hacker has root access to the system, all source code
and all hardware schemes, it should give the hacker no advantage in his/her
penetration attempt inside. I do not believe you can make that statement
regarding any other existing perimeter security product type. 

Now we can go back to categories, names, and evolution. We all know that
proxy firewalls can be (and were) more secure than packet filtering
firewalls (and its variants). From a security standpoint, you can look at
Air Gap technology as the next step after proxy architecture. Taking the
benefits of proxies and moving one step beyond. Making a complete separation
of all levels - not just the top layer, and creating a platform for easy
deployment of new applications and integration with content inspection.
Maybe a "reverse split proxy platform" would have been more correct
technically, but hey, Air Gap is catchier. :-) 

If we look back at firewall evolution, we see that proxy firewalls did not
win the firewall market (even though considered to be more secure) and had
to bend over and become hybrid firewalls. The reason is that proxies are not
suited for everything. If you try to superimpose it on all traffic,
including outbound users' traffic, you lose flexibility and, perhaps,
performance (you need customized client software, support in the protocols
themselves, etc). The reason we believe that Air Gap will thrive is that it
is focused only on transactions to back end applications - this traffic has
a much higher security requirement from a business perspective and is a
natural fit for proxying.  

NOTE: this is my personal philosophy, which has led to the establishment of
Whale Communications and the development of the e-Gap system. Recently,
other companies have been using "Air Gap" terminology to describe different
things - some not much different than a general purpose firewall. I strongly
oppose that, as it creates confusion in the market, and blurs the borderline
between firewalls and Air Gap technology. This was never our intention. 

Elad Baron, elad () whale-com com
CEO
Whale Communications
www.whalecommunications.com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards