mamouth white paper

Mammoth, Inc. White Paper (DRAFT)

Prepared for:Medsoft Medical Systems, Inc.

• This is the first draft of a “living document” representing Mammoth’s input to Medsoft. It includes the following sections:

Requirements Compliance Matrix Proposed System Architecture Concept of Operations (CONOPS) Proposed Privacy Policy (Exhibit A) Proposed Security Policy (Exhibit B) Draft Risk Analysis – TBD Attack Tree – TBD


Requirements Compliance Matrix

The matrix below describes Mammoth’s proposed compliance with customer (Medsoft) provided system requirements. Note that details, including a technical explanation of compliance with these requirements are included in the System Architecture, Concept of Operations and other sections of this White Paper. Requirements will be referred to, in subsequent sections, by the Requirement ID in the matrix below.

RequirementID

Requirement Text Explanation of Mammoth Compliance

R1. The system shall provide secure end-to-end communications.

All communications, including those between computers in controlled areas, are encrypted using the Advanced Encryption Standard algorithm implemented in hardware on Mammoth’s Security Cards (SCs). SCs include PCMCIA cards for user devices, a PCI version for desktop PCs and Servers and a PCI Server Security Card (SSC) for secure servers.

R2. The system shall provide an easy to use interface.

Users will access the system via a web-based interface.

R3. The system shall provide connectionless integrity.

As stated in our response to R2, above, a web-based interface will be used to support ease of use for users. The encrypted connection provided by the SCs will ensure the integrity of communications over the underlying connectionless IP network.

As explained in detail in the response to Requirement R5, below, users are authenticated by the SC, and an AES encrypted session is established between the SC on the user’s device and the SSC on the Security Server.

In addition, SCs and SSCs provide the function of a simple yet effective firewall. As explained in detail in later sections, Mammoth proposes to use the Internet as a ubiquitous (but un-trusted) communications medium. However, since access to the Medsoft applications software is limited to a small set of users and not offered to the public on the Internet, SSCs only “listen” on non-standard TCP ports. Accesses from a browser on

Mammoth, Inc. White Paper (DRAFT)the user’s device to the URL for secure Medsoft servers (which will be directed to port 80) are translated in the SC to a non-standard port number. Port numbers are changed daily. Each SC knows the correct port number to use based on a Mammoth algorithm similar to that in a SecureID® Card. The SC uses the AES hardware to generate a new port number each day.

The SSC converts HTTP messages on this private port number back to port 80 before sending the http request to the web server. When a Medsoft web server responds to the user’s browser request, as with most web servers, another port number will be assigned. This port number is mapped by the SSC to yet another port number (other than the daily number) for use in the session. This port number is also established using an AES cryptographic exchange between the user’s SC and the SSC.

R4. The system shall provide Non-repudiation.

As explained in the response to R5, below, user identity is authenticated by the SC at the point of origination. All messages between SCs (and SSCs) are check-summed using AES and this check sum is included in every message. This ensures that messages originate from (and responses are delivered to) authorized users with any tampering detected. (See response to R6 below). Furthermore, SSCs log all transactions to in an encrypted form on disk on Mammoth Security Servers at Medsoft.

Thus, users may not repudiate transactions, which they execute.

R5. The system shall provide data origin authentication.

User identity is authenticated at the point of origination by the SC using a biometric fingerprint scanner integral to the SC. In addition, a login with User ID and password is required.

Once user identity is verified, an AES encrypted session is established between the SC on the user’s device and the SSC.

Each message includes the serial number of the

Mammoth, Inc. White Paper (DRAFT)originating SC/SSC to verify the point of origin of the message. Distribution of SCs is controlled. User SCs are distributed only to authorized users using authorized couriers. The serial number of each SC and the identity of the user the SC has been provided to are recorded in a protected database at Mammoth. This same information, for Medsoft and Medsoft customers with SCs is cached on a Security Server at Medsoft.

R6. The system shall provide Protection against replay attacks.

Each SC and SSC has an internal date time clock. The date and time of day (to the nearest millisecond) and Time Zone for the Date/Time, are included in the message, which is check-summed along with a message sequence number ant the message text using AES and then AES encrypted for transmission.

Thus, if an attacker attempts to replay a transaction, it will be rejected (and logged) by the SSC that receives it. If an attacker attempts to replay a message from an SSC to a user, the SC at the user end will also reject the transaction. Rather than passing such a message to the user’s handheld device (or laptop/desktop PC), the message will be sent instead to an SSC for logging and will not be passed to application software in the user device.


System Architecture

Doctors will be provided with a special hand held terminal (we’ll use the photo Steven sent around). This device will be COTS (running Windows or Linux as we decide later). It will be provided with a PCMCIA Security card which is made by Mammoth, Inc. and available as COTS (note that the handout says Mammoth is a large electronics manufacturer). A laptop or palmtop with the appropriate software and PCMCIA card will also work. Because the PCMCIA Security Card (SC) is produced in large volumes for Mammoth’s other corporate and Government customers, the cost is only $450.

Connection from a doctor’s device to the applications server will be via the Internet. However, we will consider the Internet a hostile communications medium and our

architecture protects against exposure from the public Internet. Since wireless operation is needed the SC provides IEEE 802.11b and wireless Internet from AT&T or Sprint (depending on which has better coverage in an area).

Doctor

Hospital

Independent Laboratory

Outsources Tests to

Patient

Outpatient at

Inpatient at

Primary Care Provider of

Specialist Care Provider of

Is Tested by

Medical Group

Member of

Practices at

Patient of

Outsources Tests to

Referred to


To ensure security is maintained when the user device is connected to a LAN, the SC also includes an Ethernet port. All communications between the user hand held unit and the outside world is mitigated by the SC. The applications software on the user device includes a monitor which reports if any other connections (via dial up, parallep port, or another Ethernet port, for example). This status is reported every 10 seconds to the SC. Once per minute the SC checksums all the Medsoft application software in RAM and disk and compares the cryptographically generated signature to that in EEPROM on the SC. All Medsoft applications software is loaded to disk on the user device using the SC. In the process, the validity of the software is verified cryptographically (verifying the checksums in the new download using the on board AES chip).

The Mammoth Security Card (SC) for user devices is a PCMCIA card as illustrated below. The software in the SC totals less that 50,000 lines, which includes a 5000 line Micro-Kernel (a Reference Monitor) and other software modules. About 35,000 lines of code are “trusted” software (developed under strict rigor at Mammoth Labs in White Plains, NY). However, all software functions, including hardware drivers, executes in restricted mode under the control of the Micro-Kernel.

The original code for the Micro-Kernel was obtained when Mammoth bought out a computer security company in Urbana, IL in 1986. The “Urbana Kernel”, as it was known, had been developed for a highly classified Government project as a Secure Network Front End and successfully passed the very strict verification process of the classified customer. While it was not placed on the Evaluated Products List associated with the Orange Book, it passed all the requirements for A1 certification. Of course, it would have been much more difficult to pass this verification if the Urbana Kernel had been more than a Real-Time Executive. For example, no file system is included in the


Kernel (or any software in the SC). All disk storage is provided by untrusted host computers. All data on the such untrusted hosts includes a security label which, along with the data itself, is cryptographically check summed before being written to disk.

Depending on the type of data, it may be stored in encrypted form or in the clear on the host’s disk. If only the data is

The Mammoth PCMCIA SC includes:• On card 802.11b Ethernet (with unique Ethernet MAC address). This will be used when doctors are on site at equipped hospitals or doctor’s offices.

• On card RJ-45 10/100MB Ethernet interface (with a separate MAC address).• On card wireless Internet access via either, AT&T or Sprint. The selection of wireless carrier is made based on best coverage in the area the doctor resides and works. The doctor selects AT&T or Sprint when signing up for the card (see procedure below).

• The SC protrudes about 1 inch from the PCMCIA slot. This portion of the card contains:

o The antenna portion of the SC, o The external Ethernet connector, o A status LED ando A biometric fingerprint scanner (whenever an SC is powered up a

fingerprint scan is required to authenticate the user)• On card AES encryption, in hardware• Date/Time clock (preset at factory, battery life 1.5 years)• 4K of Volatile (battery powered) Random Access Memory (RAM) which is preprogrammed at the factory with:

o A unique (per card) 256 bit AES key for use for remotely administering the PCMCIA card.

o A unique (per card) 2048 bit RSA key for the doctor to whom the card is assigned

• Flash EEPROM (Electronically Erasable, Programable Read Only Memory) which:

o Is preprogrammed with a unique serial number for each PCMCIA card This serial number keys into a database at Mammoth that contains:

The card model The card hardware revision level The card firmware revision level The date of manufacture

o Contains the firmware for the card


Notes: • None of the information from the EEPROM or Battery powered RAM are made directly accessible to software on the hand held device. Some information can be accessed, but this is done via a transaction with the Security Server.

• Except for battery replacement, the card is sealed to prevent physical tampering. Any tampering (such as trying to remove the metal case around the SC will cause all volatile information (keys) to be lost and will likely destroy the card.

\All desktop PCs that will access information protected by Mammoth’s technology will use a PCI version of the SC. Actually this unit merely provides a PCI to PCMCIA physical interface with the PCMCIA SC inserted. An external biometric fingerprint scanner is included which interfaces to the PCI board to allow easy access for operations personnel. This interface is to the PCMCIA SC and not directly to the PCI bus.

All servers that will access and manipulate information protected by Mammoth’s security technology will use an enhanced server version of the PCI based SC called the Server SC (SSC). The SSC does not use the PCMCIA SC, but includes:

The same tamper proof design as the SC An interface to an external biometric fingerprint scanner No RF interfaces An on board Pentium CPU and 100MB RAM (expandable to 1Gbytes)

This CPU is totally under control of the SC’s internal CPU and does not interface directly to the server’s PCI bus. The operation of the Server SSC is explained elsewhere.


Mammoth provides a minimum of two redundant Security Servers, which provide the only external access from the client’s LAN to the Internet. These servers control access to all:

External user clients (doctor’s hand held units, etc.) Other databases (such as those in hospitals) Mammoth’s Network Management Center All server racks (using biometric fingerprint scanners)


Concept of Operations (CONOPS)

Since Mammoth has been successfully providing secure systems based on its SC technology for several years, Mammoth has obtained insurance protection, which it offers to its clients who use the SC. So long as the client contracts for continuing management and support services from Mammoth and submits to random security audits by Mammoth to verify security conformance by the client (Medsoft), Mammoth’s insurer will indemnify the client and the client’s customers against security breaches caused by a failure of Mammouth’s security technology. Coverage is up to $1 million per incident, with a maximum exposure of $10 million.

As part of Mammoth’s on-site interactions with Medsoft, Mammoth does the following: Obtains background checks of Medsoft personnel who will support customers

using the SC Verifies that adequate physical security is provided for SC related operations at

Medsoft Provides SC’s for designated operations personnel Ensures that Medsoft’s Applications Servers are on a separate LAN which is in a

physically controlled area and which only communicate using Server SCs (see below)

Ensures that servers are in Mammoth certified racks with front and rear doors that prevent unauthorized access (access to racks is controlled by biometric fingerprint scanner and then logon via User ID/ password)

Exhibit A

Privacy Policy

No automated access to any information will be provided to any unauthorized person.

Individual client organizations (Doctors’ Offices) may exercise their own Privacy Policy.

Individual users, who are certified by the procedures and mechanisms described elsewhere in this document, are at liberty to reveal or protect information obtained from automated systems just as they are with existing paper and automated records. However, as with existing personal or otherwise confidential information to which these authorized individuals have access, the individual is responsible personally for protecting such information.

A-1

Mammoth, Inc. Proprietary Information

Doctor

Hospital

Independent Laboratory

Outsources Tests to

Patient

Outpatient at

Inpatient at

Primary Care Provider of

Specialist Care Provider of

Is Tested by

Medical Group

Member of

Practices at

Patient of

Outsources Tests to

Referred to

Exhibit B

Security Policy

All access to and modification to information secured under this Security Policy will:

• Be limited to authorized individuals and procedures protected under the Security Mechanisms, which implement this Security Policy.

Be in accordance with the Clark-Wilson Integrity Model, which is restated belowClark-Wilson Integrity Model

Definitions

Acronym Expansion MeaningCDI Constrained

Data ItemA set of data items that have been validated (by a TP) and are in accordance with specifications.

IVP Integrity Verification Procedure

An integrity verification procedure is used to demonstrate that CDIs are valid and are in accordance with specifications. IVPs can be computer code or they can be manual procedures. Audit work programs are classic examples of IVPs, as are input validation programs.

TP Transformation Procedure

A transformation procedure transforms a set of valid data items (CDI) into another valid set. It may also transform non-validated data items (UDI) into valid data (CDI). This means that a transformation procedure must itself have the properties of a CDI.

UDI Unconstrained Data Item

A UDI is a set of data items that have not been validated or proved to comply with specifications.

B-1


http://www.chi-publishing.com/isb/backissues/ISB_2001/ISB0601/ISB0601KL.pdf

Exhibit B

Security Policy

Clark-Wilson Integrity ModelThe Five Certification Rules

Rule Number RuleC1 All IVP’s must properly ensure that all CDI’s are in a valid state at

the time the IVP is run.

C2 All TP’s must be certified to be valid. That is, they must take a CDI to a valid final state, given that it is in a valid state to begin with. For each TP, and each set of CDI’s that it may manipulate, the Security Officer must specify a “relation”, defines that execution. A relation is thus of the form: (TPi, (CDIa, CDIb, CDIc...)), where the list of CDI’s defines a particular set of arguments for which the TP has been certified.

C3 The list of relations in E2 must be certified to meet the separation of duty requirement.

C4 All TP’s must be certified to write to an append-only CDI (the log) all information necessary to permit the nature of the operation to be reconstructed.

C5 Any TP that takes a UDI as an input value must be certified to perform only valid transformation, or else no transformations, for any possible value of the UDI. The transformation should take the input from a UDI to a CDI, or the UDI commercial is rejected.

B-2


Exhibit B

Security Policy

Clark-Wilson Integrity ModelThe Four Enforcement Rules

Rule Number RuleE1 The system must maintain the list of relations specified in rule C2,

and must ensure that the only manipulation of any CDI is by a TP, where the TP is operating on the CDI as specified in some relation.

E2 The system must maintain a list of relationships of the form: (UserID, TPi, (CDIa, CDIb, CDIc.)), which relates to a user, a TP, and the data objects that TP may reference on behalf of that user. It must ensure that only executions described in one of the relations are performed.

E3 The system must authenticate the identity of each user attempting to execute a TP.

E4 Only the agent permitted to certify entities may change the list of such entities associated with other entities: specifically, the list of TP’s associated with a CDI and the list of users associated with a TP. An agent that can certify an entity may not have any execute rights with respect to that entity.

B-3


mamouth white paper

Engineering