Security features in ShipView are inherited from the TopView product container, which goes like this:

TopView security considerations

You can run an AllView based product, like the TopView web application products, in one of these hosting scenarios:

1. NetStorm Internet hosting - Select from 10 levels
2. Internet hosting by a third party
3. Installed on your own network and managed by your own organization
4. Installed on your own network and managed by NetStorm

The selected hosting scenario will affect security issues in the following.

You are covered by our security policy implicitly by our license agreements, service agreements og hosting agreements or consulting agreements. This page explains in detail how we have profiled our services, to carry out our responsibilities in the agreements mentioned.

We define the security issue to include:

1. Security against disclosure
   Consists of security against:
   
   1. Unauthorized or accidental disclosure
   2. Data theft
2. Security of system in production
   Consists of security against:
   
   1. Interruption
   2. Loss of data

Security against disclosure

Unwanted disclosure is a horror scenario. Accidentally having an "open door" may harm your company severely even if no sensitive data is given away. The simple demonstration of unwanted disclosure, maybe showing that there's "little to hide" in some aspect, will be most unfavorable.

Knowing this, and knowing of the skepticism to place one's data with an ASP (Application Service Provider), made us decide to make an painstaking effort in securing both the system and convincing our customers that we have succeeded in this issue.

The most important principle to achieve the trust of our customers, was to have a single software system that operated equally well as a customer's local server as with a multiple licensee hosting server, ensuring:

• A licensee can have all data moved from a hosting server to a local server within minutes or hours.
• A licensee can have all data moved from a local server to a hosting server equally fast and easy.

Then, an organization can at all times decide have the extra security by hosting the application locally behind a firewall. Although not accessible from elsewhere, it leaves your IT-department in full control of all security aspects.

If your company does not have a firewall while being exposed to the Internet, a local solution may not be a good idea for medium to high security requirements. Instead, consider our hosting offer (or from a third party).

On the other hand, it will be likely that your company already have a ready firewall. The AllView application will then be just as safe as any application.

Of course, the IT-department may perform explicit operations to make the AllView application accessible from outside your intranet. If this is the case, you should also read the following.

The disclosure issue on an Internet host

The issues related to unwanted disclosure with AllView is in summary:

1. Theft or loss of user name and password, making unwanted login possible
2. Unwanted access to parts of the system without having to log in
3. Unwanted access to the system by a hacker
4. The system accidentally allows a logged in user of one company see another company's data
5. Physical theft

After considering and working with each and every issue, we claim that either we, a thorough IT-department or a reliable 3rd party ASP will be able to deliver hosting with an overall security that will be adequate for most businesses.

Here's our comments to the above issues:

1. We will never offer hosting without encrypted login (SSL), so it is practically impossible to steal a users password during login. On the other hand, a company must have administrative routines that limit the possibility of, for example, an user loosing a paper note with user name, password and application address out on the street.
2. Trying to access a part of the application directly without logging in will always redirect one to the login page. This is an inherited property throughout the application. Additionally, an programming error in this regard will make the application unable to return data, so the element of human errors is really no threat here.
3. There's more threats with this issue than we already have pointed out in the previous remarks. Banking applications use the same secure techniques of access (SSL).
4. To make hosting services affordable, several licensees share the server resources. This could be a threat with a poorly designed system, allowing embarrassing access to others data. But we have what we consider to be an fail-safe way of dealing with this issue. First, the system tags every tiny bit of information in the database with an universally unique identification that corresponds to the company of the logged in user. Then, like in comment 2., we have an inherited application-wide ownership property with fall trough mechanism that ensures no data in case of a human programming error.
5. Our server rooms are behind alarmed doors locked with several doors in separate shells. An determined burglar may later hack into a server computer and its data in a whole lot easier way than over the Internet. Still, we don't think this is a big threat.

External (Internet) Hosting options

Normally, standard hosting options will be more than sufficient for security. This involves a multi-barrier security model that allows economic sharing of computer resources. Put in short, the security is the same as the best web based banking applications, but still, you may want to read more.

With extreme security needs, you may want to have physically isolated computer(s) for your hosting, as a special solution with NetStorm Hosting or a third party.

Security of system in operation

The description of our hosting services will indicate the level of production security.

For locally managed installations your IT-department will be entirely responsible the level of production security, exept for NetStorm's responsibility through agreements of system maintenance and so on. Your IT-department should compare the contents of the NetStorm hosting service to their own plans and specifications.

For even more details please read on to see the security features of AllView, our application framework upon which we based TopView.

AllView security basics

Isolation of a customer's data in a hosting scenario

We call it licensedata, the data that users produce over time, owned by the licensee. (which in turn is most often the user's employing organization)

A set of licensedata can be stored as the only set of licensedata in a database, and the database may be installed on a computer without concurrent databases. That is, the licensee is the only company storing data on the computer. This approach has always been safe with "old style" applications, errors cannot cause systems to mix different companies' data.

Unfortunately, the "old approach" has been quite expensive, specially with Internet hosting, a quite unneccessarily high cost as you will read in the following. Our AllView products has a neat and cost/benefit effective design, with extreme safety built in.

License dataspace separation

AllView makes it possible for one single AllStore database to keep the data for several licenses, or companies. The rationale behind this is to enable a single database server or cluster to host the data for several licenses, thus keeping the cost of hosting AllView products such as ShipView low. This document explains how the system ensures that the data of two different licenses are never mixed, and that a user of one license can never see any data from another license unless explicitly permitted by an administrator of the other license.

The 2-layer storage security

2-layer security is accomplished by hierarchy and enitity isolation.

Hierarchy isolation

The license ID uniquely stored with your user login starts the hierarcy of the license datastore. The hierarchies of other dataspaces within the same datastore cannot be mixed, neither intentionally nor accidentally.

Enitity isolation

The smallest data storage entities in relational databases, the table records, are all by design tagged with the globally unique ID number of your license.

Login

All access to an AllView-system like ShipView is through a secure login screen. When a user logs on to the system, the user's session is given a secure token that holds the license id that the user belongs to. This token is passed to the system for every subsequent request, and if the token expires (which it does after a configured time) or is lost (for instance if the browser is closed) the user must log on again in order to access any data. The system redirects all requests that do not contain the secure token back to the login screen.

Data access

First, the only access to system data is through an application server that resides behind a firewall. After logging in, the user is allowed to select objects through the application's navigation system, and the available objects are restricted to the license in the secure token passed with the request. This restriction is carefully programmed and tested in the user interface and business layer, and can not be easily bypassed even by a skilled "hacker". But as yet another line of defense, all access to data in the database passes through a business layer that builds on a set of generated data access classes. For all the database tables that contain user data (i.e. licensed data as opposed to system tables like lists of country codes, currency types etc.) the system only allows access to clients that pass the secure token created during login. And, crucially, since the token contains the user's license id, the system can restrict access to data that is owned by the license that the user belongs to.