RE: Air gap technologies

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

> What I should have said is that these dual-host systems implemented with a 
> physical air gap and dual-host systems implemented via some other type
> of point-to-point connection (such a a serial cable) have the same exact
> security properties. In particular the property that the internal host
> and network not be compromised if the external host is compromised.

> As an intelligent consumer of security products I am more likely to
> purchase a product from a vendor that does not use such gimmicks
> from among a set of equivalent products, and I would encourage others
> to do likewise.

I urge you to read my complete answer from several months ago 
(http://www.whalecommunications.com/fr_06000119.htm), where I go 
thorough the entire security design consideration of the e-Gap, including
answering your specific question. I know it is not a short response, but if 
the people on this group ("intelligent consumers") *really* want to
understand 
what we implemented and why is it different, they should at least spend the 
time reading it before concluding that we're peddling "gimmicks".
 
I'm quoting at length from that response (again, read the whole thing for
the right 
context):

********************

"...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."

********************

Elad Baron
http://www.whalecommunications.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards