Tempest Creates a Secure Teapot
Tempest Software, Inc. today announced it is shipping Release 3.1.1 of
its flagship TMS (Tempest Messenger System) product. The enhanced capabilities
in this new release are said to "raise the standards of performance in
Internet enterprise application exchange." The new release includes a
feature referred to as "TSWEG", or Tempest Secure Web Gateway, which prevents
access to the internal corporate network completely.
TSWEG, the Web server(s) can be placed behind a firewall that allows no
incoming connections whatsoever, securing all database connections, passwords,
HTML and scripts. At the same time TSWEG allows developers and administrators
to distribute incoming traffic across multiple copies of the Web server,
which can run on different machines as needed. This leads to the question
"If the firewall allows no incoming traffic from the TMS server outside
the firewall, how do the internal systems get access to the data?" The
answer is that this is the subject of Tempest's newly patented technology,
and the vendor is not willing to discuss the methods employed.
features permit an increase in scalability, and also provide fail-over
support. TMS 3.1.1 has a set of features that can be deployed across a
wide range of environments and integrated seamlessly into existing internal
and third party systems. The product enables companies to rapidly develop
e-marketplace, e-business and e-commerce solutions, while meeting time-to-market
U.S. Patent No. 6,088,796 in July 2000, TMS places databases and database
connections behind a firewall that allows no incoming traffic. The product
physically eliminates a major security risk by permitting clients' enterprise
applications to interact with the applications and data of their trading
partner(s) without the "firewall holes" (TCP/IP ports which have been
made accessible to all or specific IP addresses or segments) normally
required for such Internet-based communication. By enabling secure and
rapid data transport, TMS facilitates the true integration of e-business
enterprise applications among partners across the Internet.
version of the product supports both the Netscape Server API and the Microsoft
IIS API, and fully supports Red Hat Linux 6.2 and 7.
One of the major challenges for Enterprise Application Integration vendors,
(and most of the vendors are relatively new to the market and privately
funded), is making sure that the transactions between corporations, suppliers,
and customers are secure (see Enterprise
Application Integration, the Latest Trend in Getting Value from Data).
vendor's method of achieving these secure transactions is common in many
messaging systems. It is basically designed as an asynchronous "store
and forward" system (the TMS server "accepts" the message and delivers
it at the proper time, while the sending application moves on as if everything
could eliminate a formerly common practice used by many corporations of
duplicating their databases outside the firewall and then keeping them
synchronized, so the suppliers and customers only "see" the copy. This
led to large additional expenditures in hardware, software, and replication
tools; any product that eliminates the need for this approach will be
If a company is moving into extended supply chain, e-commerce, B2B e-commerce,
or any other application requiring interaction with external sources,
TMS 3.1.1 should be considered. The tradeoff between explicit message
acknowledgement and the use of an asynchronous model should be carefully
considered in the context of available network bandwidth and the level
of confidentiality of the transactions. Synchronous (near real-time) communications
have their good and bad points also, and are very often not necessary
for the application's requirements.
other issue to question Tempest about is the scalability of the TMS server.
EAI products are very new and there are no established benchmarks to compare
to. Since the TMS server serves as the only point of entry to the entire
system from the outside, Tempest must address the issues of scalability
(number and complexity of transactions), load balancing, and fault tolerance.
They talk about what can be done in these areas on the inside of the firewall,
but not on the outside.