This document provides a draft white paper from Mammoth, Inc. for Medsoft Medical Systems regarding a proposed secure system. It includes sections on requirements compliance, proposed system architecture, concept of operations, and draft privacy and security policies. The system would provide doctors with handheld devices integrated with security cards for encrypted and authenticated access to medical records and applications via the internet. All communications and access would be strictly controlled and monitored by the security cards and servers to ensure privacy, integrity and availability of patient data.

1. 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

2. Mammoth, Inc. White Paper
(DRAFT)
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.
Requirement
ID
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

3. 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

4. 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.

5. Mammoth, Inc. White Paper
(DRAFT)
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
Medical Group
Referred to
Member of
Doctor
Hospital
Practices at
Outsources Tests to
Outsources Tests to
Independent Laboratory
Is Tested by
Patient
Outpatient at
Inpatient at
Patient of
Primary Care Provider of
Specialist Care Provider of
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).

6. Mammoth, Inc. White Paper
(DRAFT)
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

7. Mammoth, Inc. White Paper
(DRAFT)
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 and
o 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

8. Mammoth, Inc. White Paper
(DRAFT)
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.

9. Mammoth, Inc. White Paper
(DRAFT)
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)

10. Mammoth, Inc. White Paper
(DRAFT)
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)

11. Exhibit A
Privacy Policy
No automated access to any information will be provided to any unauthorized person.
Practices at
Outsources Tests to
Outsources Tests to
Is Tested by
Medical Group
Referred to
Member of
Patient of
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
Patient
Outpatient at
Inpatient at
Primary Care Provider of
Specialist Care Provider of

12. 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 below
Clark-Wilson Integrity Model
Definitions
Acronym Expansion Meaning
CDI Constrained
Data Item
A 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
Mammoth, Inc. Proprietary Information

13. Exhibit B
Security Policy
Clark-Wilson Integrity Model
The Five Certification Rules
Rule Number Rule
C1 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
Mammoth, Inc. Proprietary Information

14. Exhibit B
Security Policy
Clark-Wilson Integrity Model
The Four Enforcement Rules
Rule Number Rule
E1 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
Mammoth, Inc. Proprietary Information