\documentstyle[art10,epsf,npac_proto,palatino]{article}
\newcommand{\postscript}[2]
 {\setlength{\epsfxsize}{#2\hsize}
  \centerline{\epsfbox{#1}}}
\begin{document}
%\makeNPACtitle\newpage
\begin{project}
\begin{titlepage}
	\projtitle{FraudWire}
	\doctitle{FraudWire and Web Technologies:\\
                  The FSTC Fraud Project Proposal\\
                 }
		\author{Miloje S. Makivic}
		\date{December 12, 1995}
		\version{0.2}
		\summary{Delivered December 14, 1995}
	\id{FraudWire}
	\docauthor{M~S~Makivic}
%	\doccontributor{KAH}
	\security{Commercial in Confidence}
\maketitle
	\approval{NPAC,FSTC}
\vfill
	\begin{history}
		\release{
			\author{Miloje S. Makivic}
			\date{December 1, 1995}
			\version{0.1}
			\summary{Initial draft}
			}
	\end{history}
\end{titlepage}

\pagenumbering{roman}\setcounter{page}{1}
\begin{abstract}
This report describes the implementation of a scalable 
World Wide Web-based FraudWire
architecture.
The proposed implementation
employs World Wide Web and distributed client-server technologies to achieve the
following goals: 
(1) portability, (2) security, (3) scalability, (4) performance,
(5) low cost, and (6) ease of use.
The FraudWire server will be initially implemented as a
CGI-enhanced
HTTP server linked to an RDBMS server. Depending on subscriber
feed-back, additional functionality can be implemented using Java and/or
JavaScript. 
The server will be configured to accept incident reports via
an HTML browser interface or via archiving subscriber e-mail. It will
offer an HTML based interface to query the subscriber incident report database and to
access other resources on public or private networks
which may be beneficial to the FraudWire project.
The HTML interface will be configurable by users to offer
only textual information for those with low-bandwidth capabilities or
advanced visualization modules for the high-bandwidth subscribers. 

Scalability is an important design consideration
for the FraudWire server. It must be factored into the initial implementation
strategy in order to avoid costly reimplementation if
the service catches up.
The growth of the FraudWire service will be two-dimensional, characterized by an increase
in (1) the number
of subscribers, and (2) the complexity of the service.
To cope with the growth in either dimension, the FraudWire server
will be designed to operate either as a Standalone FraudWire Server 
or as a member
of a group of participating servers which constitute the Distributed
FraudWire Server. 
The initial mode of operation will be the Standalone Server, which
can be turned into the Distributed Server transparently to the users
as the service load increases.
In the standalone mode, the server will be able to access only local resources.
In the distributed mode, the server may access resources which exist on
remote participating servers.
This model provides a migration path
to a sophisticated environment to share and acquire knowledge
about fraudulent activities, which may include resources outside the
FraudWire project. It can also be adopted to private corporate networks
as an integration framework for both internal and external fraud prevention
resources. Eventually, data mining capabilities developed
as another component of the Fraud Project can be merged with the 
FraudWire Server.

It is most likely that the server will use a UNIX platform with an
attached Oracle database server.
Technical risks for non-security related functionality
are minimal, considering
that the server will rely upon the de facto standard Web and 
database technologies and open architectures. 
One can also be confident that the Oracle platform will be stable
in the foreseable future and that the Web interface they support is
stable and of high quality.
FraudWire software may use
security functions provided at the HTTP protocol level ( such as SHTTP) 
or below (such as SSL or SunScreen).
Technical uncertainty regarding security-related functions is considerable,
given that there are no agreed-upon standards yet. 
The implementation of
the server will separate security related functions from the rest
of its functionality as much as possible, so that security-related
implementation choices can be decide upon and configured
during the last stages of the development.

\end{abstract}

{\parskip=0pt   % hack to patch format of \tableofcontents
\tableofcontents
%\newpage
\medskip\hspace{2.0cm}\hrulefill\hspace{2.0cm}\bigskip
}

\pagenumbering{arabic}\setcounter{page}{1}

%=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
\section{Introduction}
The World Wibe Web is one of the most potent mediums for information exchange
and processing from private corporate networks to the global Internet.
The important property of the Web is the dynamic information content and delivery.
Since it is built on top of open architectures there is no danger of being trapped
in a sub-optimal proprietary solution which is enforced by a particular vendor.
Using a well planned and careful modular design approach, the information servers can
take advantage of new web capabilities as they become mainstream. There is no other
on-line technology that offers such an upscale mobility at such a low cost
and abundance of problem solution strategies. 

The only disadvantage of the Web is
its lack of security standards. However, on the bright side there are initiatives
supported by major players
to arrive at a single security standard which would include the best features of
present alternatives such as SHTTP and SSL. All present alternatives, including
the SHTTP protocol layer, provide a
degree of separation between the data (content) and security. At the extreme,
SunScreen offers IP protocol level security functions, transparently
to the HTTP and other application protocols. Therefore, by a careful planning
of the server design, it is possible to develop the server using unsecure
technology and then to implement security functions using the most prevalent
alternative at the latest stage of implementation.

The benefits of a World Wide Web based FraudWire Server far outweigh its
technical risks. On the contrary, a solution based on any other on-line
technology runs the risk of becoming obsolete in a matter of months.

\section{The Architecture of The Standalone FraudWire Web Server}

The server consists of a front-end HTTP server and a back-end SQL
RDBMS server (most likely Oracle 7). For performance reasons it may be better to have
the two servers on physically distinct machines, although it is not essential.
FraudWire subscribers may access all of the FraudWire functions using HTML browsers.
These functions
include: (1) creation and logging of incident reports, (2) search, query
and retrieval from the incident report database, (3) serach, query and
retrieval from non-local resources, (3) rudimentary data mining capabilities and 
(4) data visualization capabilities.

Security functions are assumed to be existing at the HTTP protocol level (SHTTP)
or below (Netscape Inc.'s SSL, Sun Microsystems Inc.'s SunScreen), so
that the development of FraudWire application software weakly depends on the 
actual implementation
of security features. Security functions between the HTTP server and the RDBMS server
can be implemented separately,
depending on the likelihood of compromise of the link between 
the two servers.

The server will support both batch and interactive modes for creating incident reports.
Reports can be created interactively using interfaces created by HTML forms 
or Java applets. The reports
are tagged, indexed and classified using the inputs from report creator and then
archived. In the batch mode, reports will be created and encrypted using 
standardized procedures
and then sent via electronic mail to the FraudWire webmaster. This may be the preferred
method for incident reporting since it consumes few resources. However, 
linking and cross-referencing of the
incident reports with existing reports in the archive will require interactive
report creation. E-mailed reports are archived
just like those created through the HTML interface. It is assumed that report
creation is done using local resources. The server provides only
an interface to deposit the report. 

Reports can also be retreived using batch and interactive modes.
By sending an appropriate E-mail
message to the webmaster, subscribers can retrieve incident reports in a batch mode. 
This may be the preferred
mode for low-bandwidth subscribers. The high-bandwidth subscribers will prefer
HTML interface with advanced graphics capabilities and more sophisticated ad-hoc
query
capabilities. The HTML interface will be configurable, so that a user can specify
whether he/she request textual only information. Initially, this can be presented
as a choice to the user to be made at each logon. However, this could be automatically
customized for each user using a Java interface.

It is important to include the E-mail mode {\it only} as an option and to develop the
FraudWire architecture using Web technologies. The Web based architecture can
accomodate subscribers 
with slow
modems, but it provides the migration path to a more versatile service
which will rely on advanced graphics capabilities of Internet browsers. Besides the
fact that the bandwidth is
becoming increasingly cheaper, the user interface can always be designed to offer
only textual information to the low-bandwidth subscriber, as described above.
As the user pool, their needs and their technological capabilities grow, so will
the demand for advanced functionality which can be easily added to the HTTP server.
Unlike any other messaging-based approach, the Web based approach offers upward
mobility.

The report database can be searched and queried using HTML browsers. This interface
will be also implemented using CGI forms and/or Java applets. Both will map user
requests onto SQL queries which are processed by the Oracle 7 (or other
SQL compliant RDBMS back-end). There are many possibilities to implement the
interface between the HTTP server and the database server, which include 
Web-Oracle-Web (WOW), Oraperl,
development of Java classes for the SQL interface etc. 
It will be necessary to evaluate advantages and
disadvantages of each mechanism, before selecting the initial implementation.
One should note, however, that the implementation choices are not exclusive. 

FraudWire
server will be designed to be easily extensible as requested by the users.
It is
likely that CGI forms will be the method of choice to support the basic functionality.
However, as the information content of the FraudWire database grows,
advanced interactive features will be demanded by users, including simple data mining and
visualization modules.  In this case,
Java will most likely become the method of choice. 

\section{Advantages}
The advantages offered by the Web based implementation of the FraudWire Server far
outweigh the disadvantages:
\begin{itemize}
\item {\bf Flexible and Extensible Architecture}: 
      The FraudWire Web Server developed for public networks,
      such
      as Internet, can 
      be implemented for private TCP/IP networks with minimal modifications. 
      Modular design and the separation of back-end processing from 
      front-end interface enables painless addition of new functionality
      without disturbing subscriber services, or requiring from subscribers to invest in
      new software or update their software to match the developments on the
      server side. For example, the server can be enhanced to include data mining
      capabilities, or offer visualization tools, and even be 
      reimplemented in a distributed fashion transparently to
      subscribers. 
\item{\bf Centralization of Resources}: Incident reports and tools to process
      the incident report database are bundled on the central server. This
      enables enhanced processing capabilities to all subscribers regardless
      of their local hardware resources. It is easier to manage and it reduces
      the exposure of incident reports, since subsribers do not need to mirror
      the archive on their site. It is cheaper and more convenient to browse
      the reports on the central site.
\item {\bf Flexible and Consistent Interface}: Subscribers access the FraudWire Server using
      their HTML browsers only, so they will have the same look and feel across
      different platforms. The interface can be configurable to accomodate large
      variations in bandwidth among the subscribers.
\item {\bf Open Standards}: There is no danger of being trapped in a 
      proprietary environment
      since the complete system will be built using publicly available
      protocols and open programming environments. 
\item {\bf Portability}: Development environments such as HTML, Perl, Java, SQL, and ODBC
      guarantee a high degree of portability
\item {\bf Easy entry}: Subscribers need only a freely available HTML browser to 
      access the server. They do not need to learn to use or install any software
      besides the tools they already are familiar with.
\end{itemize}

\section{Disadvantages}
\begin{itemize}
\item {\bf High Cost of Hardware}: The FraudWire Web Server will require one or two
      dedicated machines to host the Web Server and the RDBMS server. 
\item {\bf High Cost of Software}: The implementation of the FraudWire Web Server
      will require substantial effort to develop the CGI enhanced Web Server
      and the interface between the Web Server and the RDBMS Server.
      This is partially due to the flexible and scalable design requirements,
      which cannot be met in a plug-and-play approach using the existing
      components. Bulk of the software will have to be developed from scratch.
      The payoffs from this approach in the long run are worth the effort though.
\item {\bf Dynamic nature of Web technologies}: This can be viewed as both
      an advantage and a disadvantage. Web is a new medium and Web technologies
      are still rapidly developing. However, a number of technologies are becoming
      de facto standards with a large developer base and user following. It may
      happen that better technologies will become available during the development
      of the FraudWire server, but it is very unlikely that present  standards such as
      CGI, Java, Perl and SQL will be obsolete any time soon. Major developments are
      expected in the security area and careful design is required to prevent
      being overrun with new developments. Our solution is to try to separate
      security and non-security functionality as much as feasible
      and implement the security related
      functions ate the very latest stage using the most prevalent solution.
\end{itemize}

\section{WWW Technologies at the Northeast Parallel Architectures Center}

The FraudWire Server is quite similar to the
Enterprise Information System which is being developed at NPAC by integrating
RDBMS technology into Web systems. We are currently
prototyping an Email-based information retrieval system,
which is able to support searchable USENET newsgroups archive, mailing lists
archive and personal mailbox archive. Using the Oracle 7 database server as a backend
search
engine accessed from the World Wide Web,
various information entities can
be easily managed and quickly retrieved via SQL-based queries which are
accessible by the WOW mechanism from the WWW form-based front end.
Mail messages in the database are
always kept up-to-date and consistent. On the other hand, the WWW interface provides a
universal/global mechnism and a uniform GUI search interface to the
centralized data repository, regardles of end-user platforms and/or location.
Any security technique developed on top of the HTTP protocol can be easily
incorporated into the
system to ensure secure access and information protection.
This system demonstrates  the kind of powerful and flexible archive and search capability
required by the FraudWire Server.
In order to accomodate large amounts of data and a large number of concurrent
accesses we are upgrading to the parallel Oracle server on our IBM SP-2. This
may become necessary for the FraudWire server as well once the service
catches up.

At present NPAC has a production version of the
USENET newsgroups and mailing lists archive, {\bf AskNPAC}, which is
freely accessible on the Internet and running on a RS6000 AIX server.
{\bf AskNPAC}'s home page is located at URL {\bf http://asknpac.npac.syr.edu/}.

Furthermore, NPAC is at the frontier of deployment of Web computing technologies
based on Java and its derivatives. We are developing Web-based
GroupWare and other Web-top applications 
({\bf http://www.npac.syr.edu/factoring/overview/WebTools.html })
using standard langauge environments
such as Java, Perl, VRML and HTML, as well as NPAC's own WebScript and MOVIEscript.
Using Java, we have prototyped WebFlow,
a Web metacomputer analog of data-flow
environments such as AVS.

To demonstrate the possibilities offered by World Wide Web computing,
NPAC is attacking unsolved RSA challenge numbers, 130-digit integers for which there
exist no known factorizations, using massively parallel variation of either
the quadratic sieve or number field sieve factoring methods. The twist is that
our massively parallel resource is a collecton of computers on the Web, from
SLIP connected PCs to biggest supercomputers. Web's client/server model and
its standard HTTP protocol are used
to automatize all aspects of computation, including organizational ones (like
registering new volunteers who wish to contribute their resources to this
effort) and resource allocation. More information about this project can be found
at {\it http://www.npac.syr.edu/factoring.html}. This infrastructure is directly
relevant to the FraudWire implementation. Also, the important thing to keep in mind
is that this technology applies to the World Wide Web as well as an Organization Wide
Web.

\section{Costs}
It is possible to provide only a rough assesment of costs before the system
specification is agreed upon. The capabilities of the FraudWire Web Server can
range from basic functionality, which includes simple search, query, retrieval 
and filing of incident reports to
data mining and visualization enhancements. It is essential to obtain inputs
from prospective users what kind of functionality is deemed important and at
what price. We estimate that hardware requirements for basic functionality can be met
with two mid-range RISC machines at \$40,000 each. 

We envision the project as two phases: 
\begin{itemize} 
\item Pilot Phase:
\begin{enumerate}
\item  Duration: 6 months
\item  Evaluation of candidate implementation methodologies
\item  Selection of best implementation methodologies
\item  Building a prototype with basic functionality and support for a small number of subs       cribers
\item  NPAC may provide necessary hardware to support the development of the pilot. 
       We have the whole spectrum of platforms
       uncluding RS6000, Alpha, Sun and SGI uniprocessor and multiprocessor servers,
       as well as Oracle 7 standard and parallel query servers.
\item  Deliverable: the prototype will be demonstrated to the FSTC
       community. 
\item  Hardware costs: none
\item  A crude estimate of software development costs: 
       1 senior analyst and  2 software engineers for
       6 months at a total cost of \$180K
\end{enumerate}
\item Production Phase:
\begin{enumerate}
\item Purchase of dedicated server hardware
\item Implementation of additional functionality reflecting user feedback
\item Prototype developed into a robust commercial grade product capable of supporting
      a large number of subscribers 
\item Testing and Quality Assurance
\item Deliverable: Production grade server installed on dedicated hardware
\item Hardware costs: two mid-range RISC machines at a total cost of \$80,000
\item Duration: 6 to 9 months, depending on the extent of additional functionality
\item A crude estimate of software development costs: 
      1 senior analyst and 1.5 software engineer at a total cost between 
      \$130K (6 months) and \$195K (9 months)
\end{enumerate}
\end{itemize}

\section{The Architecture of the Distributed FraudWire Server}
\label{sec:edu}
The Standalone FraudWire Server architecture is simple but it lacks scalability.
As the number of users and the size of the FraudWire database grow, so will the
demands on the central server. Storage requirements will grow as well as CPU usage
for processing of database queries.
We also anticipate that the complexity of queries will grow.
As the information is accumulated in the database, it is likely that users will
demand more than simple retrieval of incident reports. The server should be able
to support rudimentary data mining capabilities and be flexible enough to grow
with the demands of the user pool. Furthermore, the server should be able to
link the FraudWire resources with other publicly available or proprietary
resources. This includes a possibility of generating revenue by reselling
the information supplied by non-FraudWire entities.
This can be accomplished in a scalable fashion
by implementing a
Distributed FraudWire Server.
The architecture of the distributed server is shown in Figure 1.

The distributed server will be implemented as a master/slave
architecture. Any server in a group of participating servers can be 
both a master and a slave, depending
whether it hosts an interactive user session (master) or not (slave).
The master server 
provides a transparent HTML interface to the archives, databases and
other resources localized on participating servers. The master server will
either broadcast a query to other servers if it needs to access their resources,
or it will forward the query to specific servers. The master server
may employ HTTP and/or other messaging protocols to query the other servers,
which are logically slave servers for that particular session.

It is expected that each server in the group is linked to local RDBMS servers
and local databases. There are no shared resources. 
It is possible that participating servers are maintained by some of the
FraudWire subscribers.
If an institution
operates a server, incident reports are archived directly on the local
database. 
The institutions without capability or desire to maintain an HTTP server
will archive their reports on a master server. 

From the subscriber perspective, 
there is not much difference between the Standalone and
the Distributed Server. In either case, subscribers will use their HTML browsers to
access a master server. Master server propagates subscriber requests to the
slave servers using CGI mechanism. This capability will be built in the CGI layer
of the Standalone Server from the very beginning, but will be used only if additional
resources are needed and supplied. This approach ensures scalability from bottom-up.
Both master and slave servers process requests
using their local RDBMS and return their results to the master server. Results are
concatinated and formatted into the final HTML document by the master server and
displayed using the subcsriber's browser. The advantage of this approach is that
the most CPU intensive portion is offloaded from the master server and performed in
a concurrent fashion on slave servers. 
This enables implementation of sophisticated data mining
capabilities without overwhelming the central site. Messaging between the master
server and the slave servers is done using security enhanced HTTP protocol.
In this model, communication occurs only between the master and a slave.
In principle, another messaging protocol such as PVM or MPI could be used
among the slaves to coordinate
their computations, but this may be needed only for the most sophisticated data mining
requests, and it may also cause security problems. Therefore, this capability will
not be considered at the moment for the Distributed FraudWire Server. 
We should stress though that the additional messaging layer could be effectively and
securely implemented on private corporate networks, where the FraudWire architecture
can be used as an integrated risk-management tool, including other sources of risk.


\begin{figure}[htp]
\postscript{get-post1.eps}{0.40}
\caption{The Architecture of Distributed FraudWire Server}
\label{fig:dist}
\end{figure}

\end{project}
\end{document}


