Securing data over the web within an O4W solution

There are three main areas of consideration when securing Linear Hash data over the web as part of an O4W based solution.  Those are the data that resides on the web server (or data server), the data whilst in transmission and then the data displayed within the browser.

Whilst these notes are written with an O4W solution in mind, it should be recognised that the provision for securing your data actually resides outside of the O4W system itself.

Liner Hash
It is worth mentioning that most hackers are familiar with relational data of the SQL type and understandably most people would prefer to work with data that they understand.  With MultiValue database driven solutions (like OpenInsight and O4W’s linear Hash) the data structure is usually unfamiliar to many hackers and therefore a lesser target in itself.

However, if you are running a high profile system, such as a bank with client financial details, a clinical system with patient data and the like, then you will still want to consider the security of your data and to do everything that you can to avoid those nightmare news headlines.

Data at rest
One of the first considerations that you will be faced with is where exactly should you house your data.  Locating it on the web server is usually fairly easy, it’s local, there are no networking (path) issues to consider and you can easily backup the whole system.  However, locating the data on the web server itself comprises a potential security risk in itself.

It is therefore recommended that a separate Data Server be used to locate the application’s data.  This server can then be hidden behind one or  more firewalls, so if your web server is compromised in anyway, the hacker will have more than one large hurdle to overcome.

Furthermore, with Revelation Software, you can utilise a Universal Driver between the web server and the data server and configure the system so that only access to the data is permitted through the Universal Driver.  Now that provides any external or internal hacker with yet another problem to overcome.

For those who need their data secure whilst it is residing on the data server, industry standard encryption tools can be used to encrypt the data to 128-bit encryption levels, for example.  A Google search for 128-bit encryption will provide you with plenty of information and solutions for  Advanced Encryption Standard (AES) and Data Encryption Standard (DES).

In addition, from OpenInsight 9.3, the toolset itself will support Data Encryption At Rest, making it even easier for Revelation developers to secure their data in single use, LAN, WAN and Web based solutions.

Data in transit
One of the weakest points before the data reaches the browser is during transmission.  Your precious data contained within one or more data packets is passed through countless networks, computers, hubs, etc. and at anytime these packets could be intercepted and interrogated.  If you have decrypted the data within the O4W application ready for it to be read by the user, then anyone could hijack it.

Fortunately, Hyper Text Transfer Protocol Secure (HTTPS) is your friend here.  HTTPS has been around for many years and it is well known as the industry standard for secure transmission of data over the web.  It has been supported since Internet Explorer 2 was around, so that really highlights that we are talking about a technology that is well tried and very well tested.

HTTPS is a secure version of the Hyper Text Transfer Protocol (HTTP) which allows for secure ecommerce transactions, such as online banking.  The technology effectively brings together HTTP and the SSL/TLS protocol to provide encrypted communication and secure identification of a network web server.

It is usually the System Administrator (or whoever has overall responsibility for the Web server) who configures the server to use HTTPS.  This is usually simply as case of acquiring a public key certificate for the web server from a trusted certificate authority.  This certificate must be signed by that authority for the web browser to accept and use the certificate.

It is also possible for the system to be configured for client authorisation.  Configuring a system in this way can limit access to a web server and thereby only permit authorised users.  This is achieved by the System Administrator creating a certificate for each user and this certificate is then loaded into the user’s browser during the session.  The certificate usually contains some identifying information (e.g. name and email address) and this is automatically verified by the server on each reconnect.

Web browsers such as Internet Explorer (IE) and Firefox display a padlock icon to indicate to the user that the website is secure.  In addition, the web address (URL) begins with https:\\, rather than http:\\.  When a user connects to a website via HTTPS, the site encrypts the session with a

digital certificate before any data is transmitted to the user’s browser.  O4W supports HTTPS, so transmitting your data using 128-bit encryption levels is super easy.  System Administrators can find a lot more information about the acquisition and use of public key certificates by running a Google search.

Data in the browser
So, we have our data encrypted at rest on our data server and we are using HTTPS to secure the data during transmission.  What about data in the browser?

Securing data in the browser is a tough one, mainly because the user needs to view the data in human readable format on the screen.  Or do they?

And herein lays the answer.

If the user needs to view the sensitive data in the browser, then you will have to revert to good old education.  Don’t leave your screen showing the data when you leave your desk, run your password protected screen saver before leaving your desk and, if you are near a customer facing position, make sure no unauthorised person can see your screen.

However, if the data does not need to be humanly read in the browser, why display it in the first place?  Leave the data on the data server and use some other form of key to interact with that sensitive data on the server, behind your firewall.  Many systems use this approach for user IDs.  The system maintains a cookie in the user’s browser and this contains some form of unique identifier – it could simply be a random number;  1234657684346846 (a session token of some kind).  It is this non-descript information that is then passed backwards and forwards over the web to identify the user.  When this key is received by your web application, you have code that takes the key, reads it and matches it to the user’s record.  Your program code can then use the sensitive login data to run the application on the web server as required.

To summarise
As an O4W web developer, you’ll want to concern yourself with protecting sensitive data within your specific application.  For example, credit card details; you will need to both protect a credit card field and audit who has access to the field and when it is accessed.  This is usually achieved by the developer including access controls to protect fields and the display of sensitive information.  As a conscientious developer, you may want to encrypt each record individually so that it can only be decrypted with a pin number that only the user knows and you’ll want to run a check to verify that user is legitimate.

This level of security in the application is good because it prevents an administrator from potentially stealing information from the system.  However, this does present new obstacles because the developer now has to code around the in ability to freely access all of the fields. How do you report on fields you can’t decrypt? What if the user forgets their pin, can the data be reset and re-encrypted or will the loss of data be irreversible?

The developer has to choose a balance in the application’s design between ease of access to data and the level of security. More security inevitably creates complexity so it’s important consider the risks and benefits of exposing the data.

The System Administrator should be responsible to ensure the underlying environment that the application runs on will be secure. If an attacker can gain administrator access in the operating system then the entire applications security protections could be rendered useless.  By protecting the environment (server, network, and client) at the operating system level the system administrator will be protecting the application.

Developers and administrators handle different levels of security that complement each other. The developer should be responsible for the application level access to the data while an administrator should be responsible for system level access.

But O4W helps . . .
Whilst you ‘could’ leave the question of data security up to someone else, effectively passing the problem on, there are ways that O4W can help.

From OpenInsight version 9.3, Revelation Software plan to introduce data encryption at rest.  This will be delivered through a new encryption service’ that system administrators can deploy to encrypt OpenInsight (OI) and O4W data on a field by field level.  The data will naturally be encrypted using industry standard encryption routines (DES, AES, TRIPLEDES, etc.).  This encryption service will use the Windows Communication Foundation (WCF) to communicate, thus ensuring that the data is also encrypted in transit.

In terms of protecting data in O4W ‘specifically’, O4W (in 9.2.1 and above) encrypts the user passwords when stored in OpenInsight, and never transmits any password information between the browser and the server.  When validating user information, O4W encrypts the user-entered password in the browser itself, and then returns only an impenetrable hash which the server then uses in its own calculations to determine if this is a valid logon.

In addition, the O4W programming paradigm is to ‘never’ send sensitive data to the browser if it can be helped.  Instead, temporary, unique records are created with the sensitive information, and stored on the server, and only the unique identifiers for these records are transmitted back and forth to the browser.

Of course, with the 9.3 release, the encryption service can apply encryption to any fields in the OpenInsight database, including those that are used by O4W, so by using https:// and the encryption service ‘any’ record and ‘any’ field can be protected all the way from “at rest” in the server,  through the engine server, through the web server, and to the browser.

My thanks to Bryan Shumsky (Revelation Software, Inc.) and Andrew McAuley (Sprezzatura) for their help and advice without which this posting would not have been completed.

Should you use the UD 4.7?

Earlier this week Revelation released OpenInsight version 9.2.1 and as part of that the Universal Driver 4.7 was released in both standalone and bundled configurations. But what does this mean for people running older Revelation Network Products or none at all?

Let’s begin with those of you not running a network product at all on your multi-user ARev or OpenInsight systems.

Multi-user applications written in OpenInsight versions prior to 9.0 or ARev 3.12 require the Universal Driver. It protects your data against corruption, increases speed performance and reduces downtime.  More details about the benefits of the Universal Driver can be found here.

If your application is based on OpenInsight 9 then there is no need to purchase the Universal Driver. The Universal Driver NUL (Network User License) is already included with OpenInsight 9 and later. The Universal Driver NUL edition is compatible with all existing database files but it is only forward compatible with the OpenInsight 9 development environment. For mixed environments with OpenInsight 9 and any prior Revelation Software development tool, the for-purchase Universal Driver is required since it is compatible with all supported versions of the Revelation Software development tool.

If you are an existing Universal Driver (UD) user then you should also take advantage of the new Universal Driver 4.7. Below is a list of what has changed since these older versions:

Using the UD 3.0 -

• Versions of the Universal Driver after 3.0 are compatible with all previous versions of Linear Hash files.

Using the UD 4.5 –

• NSIS replaces Install Shield as the installer.
• Support for unlimited-length record keys removed (click here for more details).
• FIX_LH routine has been enhanced. The “Fix GFEs” option on the Verify LH menu silently considers any records with keys greater than 50 characters long to be GFEs and data can be lost when running Fix GFEs. This enhanced routine removes the “50-character-throwaway” functionality and replaces it with the “552-character-save” functionality.

Using the UD 4.6 –

• The UD Manager (see note below) is now compatible with 64bit systems.
• The ability to select and unlock multiple records from the Universal Driver Manager is now available. Previous versions allowed only one record to be selected during each unlock.
• Server side install program now recognizes Arev 3.12 as a valid installation location.

Also included with the Universal Driver 4.7 is a console application (the UD Manager) that allows you to manage record locks without having to stop the Linear Hash Service, as well as view the active connections to your applications.

Some of the other great features of the Universal Driver include:

• Only one REVPARAM file no matter how many different subdirectories you have with .LK and .OV files.
• Support for files larger than 4 gigabytes.
• Support for large frame sizes up to 100K.
• You can ‘hide’ your .LK and .OV from your users.
• The LHVerify facility is integrated onto the server side, allowing much faster performance.
• Registry settings and REVPARAM file created automatically.

For those of you running the Universal Driver 4.x, the cost of the upgrade is FREE, although shipping and handling charges apply. If you are running an older version, please contact your local Revelation office and they will be pleased to provide you with local pricing to upgrade your current network product to the 4.7 version.

So in answer to the posting’s title – Yes, I think that the benefits afforded by the UD 4.7 means that everyone should be using the Universal Driver 4.7 wherever possible.

Long Record Keys and the UD4.6

Back in June of last year, I wrote a blog posting about the release of the Universal Driver 4.6. Within that announcement, was a note about a change in the way that long record keys were to be handled. However, some more information has come to my attention and this posting is therefore to provide that extra information.

We were recently approached by a client who had upgraded to the Universal Driver 4.6 and who subsequently ran a long key check against their database. This check reported a number of long keys, but a subsequent attempt to remove them from the system using the removal utility failed. As an example, the error message received when trying to delete the bad records was “Unable to delete “M*15607”, FS100, M*15607”. And the actual key was M*15607 15608 15607 15608 etc…. It exceeded 552 characters.

The reason for this failure is down to the removal utility being run under the UD4.6 is bound by the imposed maximum key length. The Linear Hash Service will also have been generating application event logs on the server’s event log when it attempts to read or delete a long key.

As per the installation guide for the Universal Drive 4.6, the system should have been checked for long record keys ‘prior’ to the installation of the Universal Driver 4.6. The installation of the utility is covered in its own installation guide (Network Driver Update for Large Keys) which is included, along with the file, within the Universal Driver installation zip file.

However, if this step is missed out and it is run after the installation of the Universal Driver and it results in long record keys being found, the following steps can be followed to correct the issue:

1) Ensure that everyone is logged out of the system (all OpenInsight applications).
2) Locate and rename the REVPARAM file/s to something other than REVPARAM.
3) Change the chosen driver back to the 4.5 driver using netdrv.exe, or the previously used driver if you are coming up from an older one.
4) Start the application/s and run the utility to report and remove all of the long keys.
5) Change the chosen diver back to the 4.6 driver using netdrv.exe.
6) Rename your name changed REVPARAM file/s back to REVPARAM.

These steps should allow you to access the application through a single user maintenance mode without using the 4.6 service. The utility can be installed into OpenInsight version 7.x and 8.x systems and it is included in OpenInsight from version 9.1.

Installing OpenInsight into Citrix and Terminal Server Environments.

From time to time I receive requests from VARs and end-users on Revelation’s recommended configuration on Citrix, Terminal Server and similar environments. Until now, there was no real recommended advice on where the various OpenInsight components should be installed and people were left to find what works best for them, their application, their environment and the users.

During my many conversations with people, I have learned that a configuration that works well for one client needed a rethink and modification for another. Putting together a recommendation for OpenInsight was therefore always going to be a tough call and Revelation would run the risk of documenting one configuration that people would follow to the letter and find that it was not the right, or even the best, solution for them, their application or their users.

However, following a typical ‘why does it work that way’ conversion about running OpenInsight and Citrix, I discussed the possibility of having a recommendation white paper with Jared (Revelation’s chief networking professional in the New Jersey office), along with the necessary this is a starting point only caveats.

I am please to announce that overnight Jared has released a white paper on the ‘Best Practices for Deploying OpenInsight on Terminal Services and Citrix Environments’.

This guide is Revelation’s best practice advice and it provides people with a welcome starting point when deploying OpenInsight based systems to these environments that are becoming more and more popular. The paper has been put together from Jared’s experience of working with OpenInsight 9.x on Terminal Services and Citrix and you can read the full article on the RevUS web site at http://tinyurl.com/2346d96.

Finally, I’d like to extend my thanks to Jared for taking the time to put together this hugely useful document.

Protecting your sensitive OpenInsight data.

Sometime ago, Kevin Ruane wrote an article on hiding your Linear Hash data from workstations, this prevented direct access to the data inside .LK and .OV files (Revelation’s Linear Hash data files).

At the time, this was just another useful benefit afforded the Universal Driver for users running Revelation based systems. However, in more recent times we have seen many headlines of high profile individuals and organisations loosing client and other sensitive data – headlines that no organisation can afford to deal with and that often lead to lasting damage to the organisation’s reputation.

If that was not reason enough to take data privacy seriously, organisations now have requirements to protect and audit access to data and this is becoming a more and more common request. For instance, compliance with industry security standards like the PCI DSS (Payment Card Industry Data Security Standard) is now a must have for anyone handling credit card information through their online systems or otherwise.

Revelation has published an update to the original article which covers one method to prevent unauthorised access to OpenInsight’s data held inside .LK and .OV files. Working with OpenInsight 9.2+ and the Universal Driver 4.6 over a Windows 2008 Server and Windows 7 workstation environment (so nice and contemporary) this new article details how to use strict NTFS permissions to achieve peace of mind for developers and end-users alike. After all, if your users can not directly read or change .LK and .OV files, you can audit and protect access to the data using controls that are internal to your application.

The full article can be found on http://www.revelation.com/ at http://tinyurl.com/32lhftq.

>Optimise your OI deployments!

>

There is a very useful discussion on the Revelation Discussion Boards at the moment with regards to Universal Driver and the use of revparam files. If you are involved with deploying application at any level, this is a posting that you’ll want to check out.

http://revelation.com/OIdiscuss.nsf/All+by+Date/159B2E4E0BFD3328852576D6001BF5FF?OpenDocument.

>Reauth.exe & Netdrv.exe Issues

>

Revelation have recently received a number of support calls and emails with regards to the reauth.exe and netdrv.exe programs failing. The reauth.exe file was introduced with OpenInsight version 8.0.3 and it is used to add additional users to an OpenInsight system and to also reset the license expiry date for Developer Class/Network User licenses. The netdrv.exe program has been around for a long time and it is used to set and change the network driver.

Two of the most common error messages that are being reported are:

1. “Authorization failed. Please contact Revelation software or you vendor for additional support.”
   This issue is primarily produced when a user is prompted for, and enters, a new 5×5 authorisation key. It is a result of the reauth.exe file failing to run owing to a file still being is use.
2. “Opening of the file failed. The process of changing drivers cannot be continued.”
   This issue is reported during the changing of the network driver using NETDRV.EXE. Again, this is a result of a file still being in use.

These programs require single user access to the entire OpenInsight system and for this reason ALL users must be logged out of the OpenInsight application and ALL services must be stopped, as they might well be using a user count or have files locked. In every case where a support issue has been raised, the problem was found to be an active OpenInsight session which was keeping the system locked. This situation can arise for several reasons, the two main reasons being a workstation with an open session and a hung engine that is still running in memory.

The obvious resolution to this issue is to ensure that all users are out of the system and all services are fully closed down before running the reauth.exe program – the UD 4.6 can be useful for this as it reports all locks on the system and provides Administrators with a way to release those locks gracefully. However, Revelation have released a script to automate the process of closing all connected sessions, killing running oinsight.exe programs and stopping the service. This script is a little overkill, but it is designed to be a “when all else fails” solution.

The script and further details can be found at Troubleshooting REVAUTH.EXE, NETDRV.EXE and OENGINE;DLL Upgrades.

>396% reduction in disk utilisation!

>One of the hottest IT topics that I am continuously asked about, is that of performance and reducing the load on system resources. It was therefore nice to hear from one of our UK clients who has achieved some stunning results.

Following the upgrade of an application server to a new one with Solid State Drives and using the Universal Driver 4.5 to split the data over two physical volumes, a leading financial institution in the UK recently reported “… Disk utilisation down from averaging at 400% down to 4% .. SSD’s are awesome for LH.. the low latency really helps.” This is a large OpenInsight system that is vital to the business and which is in daily use by several hundred concurrent users.

Whilst I don’t have any Solid States Drives for sale, I do have the new Universal Driver 4.6 and I’ll be happy to talk to anyone running an older Revelation Network Product about the benefits of the Universal Driver. In addition, I’ll forward a white paper to you which takes a look at splitting your data onto a different location.

>Revelation Releases Universal Driver 4.6

>

Despite a couple of premature announcements on the release of the Universal Driver 4.6 recently, I am now pleased to formally announce that the latest version of the popular Universal Driver is now available and, yes, I do have both full installation and upgrade files available.

The new version features a brand new installer and support for large key sizes and large records has also been greatly enhanced. There are an increasing number of occasions where more intelligence is being built into record keys and parts of the system sometimes handle the keys correctly and in other parts it treats them as a bug and this results in false errors being reported. This issue is addressed in this release.

However, this new version will not support unlimited length record keys. Record keys can now be a maximum of 512 characters long. Any keys that exceed this limit will now be ‘illegal’ and applications will be unable to either read or write them. The server event log will report Linear Hash Error 1016 for this condition. Since this will make the records unreadable, they will be treated as though there is a ‘group format error’ (GFE) in any table that contains them. For this reason, the Database Manager tools in OpenInsight 9.1 have been updated to report the errors (LH Verify) and the ‘Fix’ option has been enhanced to copy them to a new table called DUMP_FIX_SAVE.

Furthermore, there is a more critical fix to address the issue where the Fix GFE option on the current ‘Verify LH’ menu silently considers any records with keys greater than 50 characters long to be GFE’s. Anyone running the ‘Fix GFE’ option will lose any records that have keys longer than 50 characters. As a result of this issue, an RDK containing a FIX_LH routine is being included with the UD 4.6 release. This updated routine will remove the ’50-character-throwaway’ functionality and replaces it with the new ‘512-character-save’ functionality.

In addition to all of the above, the Universal Driver 4.6 now provides backwards compatibility with all previous versions of Linear Hash files, something that was lost from the Universal Driver 3.0 onwards. Plus, the client driver’s (not the service) internal file handle management has been enhanced for improved handling of open tables and the Universal Driver can now manage over 300 open and active tables from a single client – although the reasonable design of such an application would not be recommended.

The Universal Driver 4.6 is fully supported on the following servers: Windows 2000 SP1 and later, both 32-bit and 64-bit Windows 2003 SP1 and above and 32-bit Windows 2008. Please note that Novell and Linux servers are not supported at the present time. As with the earlier Universal Drivers, Windows 95/98 workstations are not supported, leaving Windows NT, 2000, XP and Vista Business or Ultimate as deployment options. The Universal Driver 4.6 currently supports ARev 3.12 and OpenInsight version 4.1 or later – 16-bit OpenInsight is not supported.

If you are a client in the EMEA region and you have previously purchased a license for the Universal Driver 4.0 or 4.5, then you are entitled to a free of charge upgrade – drop me a email with your UD serial number and I’ll gladly forward the upgrade files to you by return of email. The files are pretty large though, so a boxed version is available – shipping charges will apply in such cases.

This is an especially good release that addresses several long standing issues that have only just come to Revelation’s attention as deployed systems become larger and larger. I would therefore urge anyone running an ARev or 32-bit OpenInsight system on a Windows server and using an older Revelation Network product, to seriously consider this a necessary upgrade.