AIE Home
A SDS 30-Sec Introduction
Products and Services
SDS Security Description
Directory Services and Policy Based Computing
Contacting Us
Our Privacy Policy
Client Login

Secure Document Service (SDS) System
Security and Availability Information

Security is an essential component of the SDS system. Providing an environment for assured access to those with permission, while hiding it from those without is a major feature designed and built into the SDS system from the ground up.

This page should provide you the essential information you need to understand the many security issues and how the SDS system addresses them.

Communications Diagram
The following communications diagram demonstrates the overall connectivity of the various components involved with SDS. The sections following will discuss the components and the security aspects involved with the handling of the patient and lab data.

Data flows between the system components as shown in the picture above.

Security of the Data Source
The SDS system receives the reports from the Cortex Gold system when the Cortex Gold system requests to send it. At no time does the SDS system attach or log into the Cortex Gold system. This decoupling guaranties the integrity of the data source providing the reports.

Reports generated by the Cortex Gold system to the SDS servers are sent in two parts; the report itself, and some associated description information used to describe the document.

This information is encrypted during its transfer over the Internet, using both the Secure Socket Layer (SSL) communication protocol and the Secure Shell (SSH) program. Using these standard facilities, the privacy of the information from the Cortex Gold system to the SDS servers is assured.

Data Storage Security
Once the data reaches the SDS Servers, it is encrypted and stored on the disk using RC4, a byte oriented symmetric encryption algorithm frequently used as an encryption standard. This further protects the data should the SDS servers themselves be compromised. Without the encryption keys, which are not stored on the servers, the data is unreadable.

SDS User Account Access Security
Access to the SDS system requires a pre-established account assigned to each individual that will be using the system. These accounts are protected by a password that must be composed of a variety of character types (Upper and lower case, and digits) and be at least 6 characters in length. By requiring a mix of these parts, account hacking programs are seriously thwarted from performing dictionary lookup attacks on the accounts. The Account holder has full access to change the passwords at any time.

In addition to the password protection, the users are required to enter the SDS system from a specific access URL. Logins will be unsuccessful if the user attempts to enter the SDS system from any other URL.

Login attempts with an incorrect account name, password combination cause the system to pause before the user can attempt another attempt. This slows down attempts to guess correct access information.

The Lab's SDS Administrator can create and destroy accounts as needed. Accounts can also be suspended (made 'Inactive') by the SDS Administrator for times when the account user is known to not be needing access to the system. When an account is inactive, no access is allowed even with the proper account name and password.

SDS user accounts cannot be shared. Each person with authorized access to the SDS system must have their own account, and no account can be authenticated to the system at the same time. (Individual user accounts is enforced through policy and single sessions is enforced by the SDS authentication system.)

All sessions employ an 'idle' timeout such that an unattended SDS session is automatically disabled requiring re-authentication when the user wants to access the system again. The default value for this time is 10 minutes.

SDS Document Security Provisions
While the SDS system can accept and deliver many document formats, the reports delivered by the Cortex Gold system are automatically converted to Adobe PDF style report documents. Documents in this format are not changeable by the receiver, so you can be assured that the document they have is the same as the original sent.

The Adobe PDF file reader application is free from Adobe and available for quite a number of user system platforms.

The SDS system was designed to accommodate most currently available browsers. The SDS system uses a feature of your browser called Cookies. This allows the system to keep track of your current session when using the SDS system. The manner in which the SDS system uses cookies poses no security concern for your browser or local system.

All user access to any SDS web page and displayed report is performed using the Secure Socket Layer (SSL) communication protocol which is supported by your browser. The SDS servers have all been fitted with a 128 bit digital certificate to support the transfer of the information to your browser securely.

The SDS reports are encrypted from, before the SDS receives them, until the report is displayed on your browser.

SDS Document Disposition
SDS report documents are maintained on the SDS server for a period of 90 days. Documents are then purged from the server and no copies are retained. Log entries showing the document's receipt, activity and disposition are retained indefinitely.

SDS Logging
Virtually all SDS activities, both user and system, are logged for internal reporting, auditing and system and user activity tracing. This provides the ability to audit any system activity should there be a need. Some samples of logging include:

  • User login attempts (failed and successful). The user's IP (Internet) address is recorded such that the user can be traced to the origin of the session.
  • Document receipt, viewing, status changing and deletion,
  • System Administrator activities causing changes to user account configurations,
  • Internal 'housekeeping' functions performed by the SDS system.

System Monitoring
We have implemented a number of monitoring functions to keep our support team informed on the health of our servers. This provides the ability to respond quickly should a problem be detected. Our monitoring includes:

  • System Access - Are the servers correctly responding to valid access requests?
  • Functionality - Are the servers functioning correctly?
  • Availability - Can the servers be reached? Are they on-line?
  • Security - Are there any security issues to be dealt with?
  • General System Health such as: Processing and disk space availability.

Important information will be provided as neccessary. If we have some important message we need to convey, we will use the email addresses as found in the Account Profiles, and/or post a message on the SDS Authentication page.

SDS Server Physical Security and Availability

We use dedicated servers for the SDS system application. These systems are not used for any other purpose, or by any other company.

The servers are running a current commercial version of Linux, which is kept up-to-date to defend against security issues when they are discovered by the computer security industry.

The physical SDS servers are located in secure 'Server Farms' which provide for the 'care and feeding' of the physical boxes. The building is accessible through card key access. Power is delivered to the servers only after passing through power conditioning equipment and is backed up by both battery and gas generators. The network sits behind redundant firewalls setup in a failover array for redundant protection from Denial of Service (DoS) attacks and other hacker activities.

Multiple connections to the internet backbone are provided to increase availability and up-time should a major carrier have problems.

Technical staff members are available 24x7x365 with spare part availability should there be an issue with an SDS server.