Re:airgaps

[Jonathan Squire <jsquirelists () crosswinds net>]

At 02:38 PM 10/19/00 -0400, you wrote:
> > At what level is the "e-gap" unidirectional?  If it is truly unidirectional
> > then how would I verify that the information was received correctly or even
> > at all?  I should think that if I were to use it for storage of credit card
> > transactions, it would behoove me to be able to guarantee that it was
> > received/processed.  If I can't even do some level of confirmation across
> > the gap how can I trust it except blind faith?  If I'm counting on that
> > transaction for $$ I want to KNOW that it is saved safely.

When used in a truly unidirectional method... you can't get a transaction 
confirmation back... plain and simple.

There are some situations where it may be of some use though... to further 
on my previous example of receiving credit cards/personal information from 
a customer.

If we had the following scenario:
                                           |---------------------------------------|
                                          V 
|
registration web server --> egap --> SQL Server               |
                                                          | 
|
                                                          |     filtered 
       |
                                                         V      output 
    |
External SQL server <--------------------- egap                       |
       ^ 
|
       | 
|
      V 
|
Order Web Server  -->----------------------------------------------------|

User input could be taken by the registration web server and forwarded to 
the internal SQL server... Things like their credit card number, address, 
phone number, etc... would be stored in here, a series of stored procedures 
could operate on this data on the inside and then push information that 
would be ok to have public out to the external SQL server (such as last 4 
of the credit card and a  confirmation that the needed information was sent 
in (address, telephone number, etc, etc)
The order web server would then interact with the external database 
whenever it needed to display the information currently on file to the 
user, and when an order was placed it would send a transaction ticket to 
the internal sql server (or better yet an internal transaction server that 
would also verify the "application data" is correct), a confirmation would 
then be pumped out, the order server would just poll the external database, 
waiting for that confirmation, if it's not received in a time out, it would 
send a cancel transaction message inbound.

The above scenario  better mimics the paper pushing method of placing an 
order... you go to a store, you pick out an item, you take it to the cash 
register, you present your credit card, they swipe your card, they present 
you with a receipt.



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