Medical sites and portals collect sensitive information about individuals, and can provide collective profile information as well as profile disease trends. However, this information could be misused by an adversary. Therefore special attention must be given to the operational sensitivity of data and network integrity. This kind of sensitive data mandate that the given medical system’s security level is “high,” according to FISMA and HIPPA regulations.

RDMAX rigorously follows NIST 800-60 recommendations according to a given information type and impact level recommendations and examples of recommendations for agency-specific and mission-related information of given medical applications.

Modifications to the applications, new changes and significant maintenance actions need to be reviewed using FIPS 199 (for security impact on organization and application) and NIST 800-60 (to identify security impact levels by information type, following recommendations on treating appropriately these impact levels from administrative, maintenance, change management and support levels).

RDMAX and its development team lead has experience with systems, database management and reporting systems described above supporting medical records operation and management. The federal PKI system local authority to the system itself (at the client) issues the PKI keys, which are generated once on the server side, but stored on the client's side, or stored on a user’s smart card. If Smart Card technology is used in combination, it materializes a secure connection from point–to-point, while the communication path is encrypted to prevent an adversary from tapping into the data stream. It is the highest protection possible, as a result of combined security of link encryption and point-to-point encryption mechanism.

The user key (keep in mind a pair of private and public keys are issued and used) generated by the authority (however the authority does not have a knowledge of the private keys, nor stores them) is used to encrypt, for example, selected 4 fields (last name, first name, DOB, and SSN), and none of the records is identifiable without decrypting these keys using a private key. All records entered would use this issue dedicated key to protect record confidentiality, enhance system security, enable data masking and prevent an active attack by an adversary. In reality such an encryption and procedural mechanism would prevent security leaks and compromises in the event of a direct database breach by an insider. If a private key is lost, a new key can be generated by the system issuing authority.

A system administrator never has knowledge of the decrypted content of the encrypted fields, but upon an approval (as a result of the review) can prevent access to the system and “fake-identity” request(s). It is up to the particular implementation system security policy how encrypted records encrypted with previous and old keys are visible and what action takes place with the records when a private key is lost. For a very large system, there is a possibility to retain private keys centrally by an issuing certificate authority as long as it does not compromise any of the security policies in place. 

Nevertheless, it is necessary to say that the certificate keys can be generated only for the user by an "action" on the user side after the user is logged into the system and obtained initial authentication and authorization to receive such a key by a given system authority. The user’s public and private keys are not stored on the server at all (those are stored on a user’s secure system locally or with a key authority), and therefore the server side has no knowledge of the keys to prevent data insider leaks (especially by ICT personnel).

Such a system prevents adversaries from compromising all records retained in the system and allows for a mechanism of data masking. It is well reported that most security breaches are caused by insiders rather than an external adversary (or by an adversary helped by an unsuspecting insider through social engineering). The commonly used key strength will be in the given system at least 256bit or higher (based on AES 256bit or RSA256bit) to make the encrypted value strong enough and also for the record’s ID unique (while the identity is hidden and not revealed, one still wants to prevent duplicates in the system as well as double entry of records; the special approach accomplished this mechanism).

The encryption algorithms usually chosen assist in accomplishing such a goal. Their management is driven by specifics of the medical enterprise and a particular mechanism can allow the key being sent only 1x to the client side workstation to perform a transaction (transactional oriented key), which after the transaction is completed is invalided and is limited in time.

Other types of keys can be issued only after a user is authenticated by the issuing system. If the user does not save it and closes the browser or closes a Web based application, then the key expires (is lost) and a new one would have to be regenerated. It is anticipated that any communication between a Web-based and a non-Web based sensitive system is done over HTTPS session (at least SSL-2). Only non-critical and low-security communication is done over HTTP. Each medical record can be stored using a unique record ID, which is generated by a different key mechanism and the key mechanism is “unknown” to the system administrator or user (and therefore to the adversary) – it is basically compiled by the authority only and not stored in the database at all.

RDMAX establishes on-going security policies (based on FIPS 199, 200, NIST 800-60, NIST 800-57, NIST 800-23) during information technology engagements so that all vulnerability and threat information has to be continuously assessed in regards to the risks at the organization resulting from the operation of information systems, introduced system changes, and changes in the operation and functional requirements. In order to prevent security breaches during software development engagement, RDMAX implements a stringent approach and methodology following Software Development Methodology (SDM) and Rational Unified Process (RUP) to guarantee transparency during development, meeting requirement criteria,  performing rigorous unit, system, integration and UI interface tests prior to every release to ensure system integrity, stability and resilience to active adversary attacks. Such an approach also facilitates a very consistent, comparable, and repeatable approach for selecting and specifying security controls for systems dealt with under the contact engagement.

Therefore any system change and modification is evaluated at all of its impact levels, which can be low or medium or high. For example, an application which does not collect any SSN (Social Security Numbers) could be considered medium risk, but as soon as the SSN field starts to be collected (even though it is just one field change in the whole system) the importance of the change is elevated to high and the system becomes a “high” risk system. Afterwards a special attention has to be given to all system application parameters; each aspect of the application has to be reviewed by the team, company and client security officers and any change has to be certified for an acceptance.

Written by Roman Vichr for RDMAX Inc.

RDMAX Copyright 2008

The RDMAX application “Security Assessment” also engages on the level of NIST 800-27 to enable more consistent, comparable, and repeatable evaluations of security controls applied to the medical information system as part of this engagement. It assists in evaluating and increasing understanding of enterprise-wide mission risks resulting from the operation of information systems and their modifications. This methodology helps to achieve more secure information systems within the medical information enterprise and facilitates more informed security authorization and authentication decisions. 

FIG 1: The following is a diagram of secure web-based portal information sharing of medical data following government regulations to protect privacy and designated data attributes: