Wednesday, June 1, 2011

Huge impact on the Security/Privacy Audit Log - unless you are organizationally fully ATNA compliant

There is a new Notice of Proposed Rulemaking (NPRM) out this week, formally published today. Robin Raiford (Allscripts) has inserted bookmarks into the NPRM text from the Register. It is available from google docs at:


I have not yet fully read it, but what I have seems to coincidence with what others are picking out as the important changes. I will be reviewing this and preparing comments. Until then, read:

Of concern is that this NPRM proposes to create a new report that the Patient can get that has all USES and DISCLOSURES that the EHR is involved in. First, the old rule gave the right to an ‘accounting of disclosures’ which had a huge list of exceptions, so much so that it really was rather useless. This new change removes these exceptions. It is not clear just how many exceptions will still exist, for example required government reporting, this use to be an exception under ‘normal operations’, but does beg the question of 'who' is reported for this one.

Also of concern is the use of the term ‘EHR’ which HHS/ONC expanded the definition late last year to basically include any medical record with interoperability. It is not clear what the boundaries of the new definition of EHR is. As Wes points out this could include all of the departmental IT, and possibly all the medical devices that feed those.

If the EHR, that is all systems involved in the new definition of EHR, were using the IHE ATNA profile fully; then this report would be a simple report from the Audit Record Repository. The ATNA Profile can inform an Accounting of Disclosures. This would mean that each access to data was fully described using IHE ATNA, something the standard does support. Including who, what, where, when, and WHY (purposeOfUse).  See also: Accountability using ATNA Audit Controls


The original Press Release: HHS announces proposed changes to the HIPAA Privacy Rule
No comments:

IHE - Privacy and Security Profiles - Document Digital Signature

Most of the time a Document can be considered complete and authentic simply because it was stored, received or retrieved via trusted pathway. A good example of this is the secure communications built into the IHE ATNA profile which includes three different solutions: Mutually-Authenticated-TLS, WS-Security, and S/MIME.  Another good example is the XDS Metadata attributes of 'hash' and 'size' that are built into the XDS family of profiles. These metadata values are carried independent of the document it-self; and thus there is a moderate level of assurance provided.

A Document Digital Signature is needed when these infrastructural mechanisms are not sufficient. This is usually only critical cases of  high value or concern. Some example use-cases:
  1. Attesting a document as true copy - to verify that the document being used is the same as the original document and has not been modified by error or intent. Also important to establish the signer and the reason for signature
  2. Attesting clinical information content - a physician may choose to review a document and apply a signature to attest the report is complete and correct.
  3. Attesting to a diagnostic report - a doctor may verify a diagnostic report and apply a signature across both the source data and the diagnostic report. This provides a proof that the original data has also not changed since the diagnosis was made.
  4. Co-Signatures and Counter-Signatures. This functionality allows for complex workflows that might need to have signatures in a specific order.
  5. Signing multiple documents. This functionality produces one signature that signs multiple documents.
The Document Digital Signature profile uses a detatched signature to allow for the clinical document (the document being signed) to be manipulated independent from the signature. The Digital Signature is not specific to transport, nor does it rely on the signed document being in a specific transport. If the clinical document is managed in XDS, then an EHR will see the clinical document just like any other document. If this EHR needs to validate the signature it can detect the signature through the Metadata, and pull the Document Digital Signature as a document.

The Digital Signature document is an XML document following the W3C XML Signature specification using a W3C profile for signatures (XadES). IHE further profiles this to add a Purpose Of Signature, and Timestamp. Thus the Digital Signature document includes the signer credentials (X.509 certificate), timestamp of signing, purpose of signature, and a manifest of all the documents that are being signed with their individual hash value.

Given that these Digital Signatures are potentially going to need to be validated 10-20 years later and thus need to be self contained and self describing. It is this reason that IHE has mandated that the Digital Signature include the  reason why the signature was done. These "Purpose of Signature" values come from a vocabulary defined in ASTM E1762 as show here. This allows for simple author signatures, but also more complex relationships to the signature such as validation signature, witness signature, addendum signature, and timestamp signature.

The result looks a little like this. The original document is mostly unmodified except that it has an association type "Signed".

The Signature Document contains the Who, When, and Why; along with the list of items that are signed with their individual hash codes. The whole thing is signed to protect it over time. In the case where these documents are managed in XDS, they both are registered as independent documents with the specific associations. This same mechanism is used for XDM, XDR, and XCA. Where the transport is some other method, the profile does not define how the two documents are managed.

References
Additional Comments
DSG - A profile of XML-Digital Signatures to provide long-term signature across a 'document'
  • Can sign any document type. Not limited to XML type documents such as CDA
  • Signature document is created that is an XML-Digital Signature blob
    • Original document to be signed is signed by 'reference'.
      • Encapsulation is not a bad thing, but it does make the original document harder to get at. Especially if that original document is not XML based
      • Signature by reference allows the original document to continue to be accessed normally by applications that don't need to validate he signature. While having the signature present for those applications that do need it.
    • The digital signature includes the Date/Time of the signature. Assuming trustable date/time
    • The digital signature includes the certificate of the signer
      • Note that signatures need to be valid for decades. Which brings up interesting certificate management issues not addressed.
    • The digital signature includes the reason for the signature. Why was it signed? What does the signature mean?
  • XDS Metadata shows that the signature document is in a 'signs' relationship to the original document
    • This allows for finding the signature from a document, and finding the document from the signature
  • Works for XDS, XDM, XDR, XCA
    • Might work for other environments as well. The main thing that must happen is for there to be a way to dereference the document ID number found in the digital signature document to get to the document that is being signed.
  • Might be future work to have an encapsulated flavor
  • USA Regulation from FDA that explains Digital Signature from Electronic Signature - 21 CFR Part 11
    • (a) The regulations in this part set forth the criteria under which the agency considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper.
    • (b) This part applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in agency regulations. This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not specifically identified in agency regulations. However, this part does not apply to paper records that are, or have been, transmitted by electronic means.
  • USA (DEA) Regulation update for electronic prescribing of Schedule II drugs 
    • Clearly a high value use-case that should be able to justify the overhead of digital signatures infrastructure.
  • See: Signing CDA Documents
1 comment:

Tuesday, May 31, 2011

US Audit of Healthcare security concludes that Meaningful use does not mean secure use

I could have told them that Meaningful Use didn't include core security needs, actually I did on this blog Meaningful Use clearly does not mean Secure Use. That blog post was January 2010, and is my 3rd highest hit article overall.

Executive Summary

The Department's Office of the National Coordinator (ONC) provides leadership for the development and nationwide implementation of an interoperable health information technology (HIT) infrastructure. ONC is charged with guiding the nationwide implementation of interoperable HIT to reduce medical errors, improve quality, produce greater value for health care expenditures, ensure that patients' individually identifiable health information is secure and protected, and facilitate the widespread adoption of electronic health records (EHR). 
Our review found that ONC had application information technology (IT) security controls in the interoperability specifications, but there were no HIT standards that included general information IT security controls. General IT security controls are the structure, policies, and procedures that apply to an entity's overall computer operations, ensure the proper operation of information systems, and create a secure environment for application systems and controls. At the time of our initial audit, the interoperability specifications were the ONC HIT standards and included security features necessary for securely passing data between EHR systems (e.g., encrypting transmissions between EHR systems). These controls in the EHR systems were application security controls, not general IT security controls. 
We found a lack of general IT security controls during prior audits at Medicare contractors, State Medicaid agencies, and hospitals. Those vulnerabilities, combined with our findings in this audit, raise concern about the effectiveness of IT security for HIT if general IT security controls are not addressed. 
We recommended that ONC (1) broaden its focus from interoperability specifications to also include well-developed general IT security controls for supporting systems, networks, and infrastructures; (2) use its leadership role to provide guidance to the health industry on established general IT security standards and IT industry security best practices; (3) emphasize to the medical community the importance of general IT security; and (4) coordinate its work with the Centers for Medicare & Medicaid Services and the Department's Office for Civil Rights to add general IT security controls where applicable. ONC concurred with our recommendations.
More
Both reports are available with the following titles:

  1. Nationwide Rollup Review of the Centers for Medicare & Medicaid Services Health Insurance Portability and Accountability Act of 1996 Oversight
  2. Audit of Information Technology Security Included in Health Information Technology Standards
An excellent summary is "Audit report hit HHS on digital security" by Joseph Conn
No comments:

IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion

With the growth of communications between organizations there is a strong need to provide user identity, role assignment, and other claims about the context of the communication. These transactions are happening between different organizations that are otherwise competitors, and thus not likely that they will be able to agree on a centralized user identity system like EUA. This communications between organizations is the space that the Cross-Enterprise User Assertion (XUA) profile fills by using Federated Identity.

The initial use-cases that drove the creation of XUA is the Health Information Exchange built on the XDS and XCA profiles;  A Health Information Exchange model using a Discover and Retrieve exchange model needs the user identity inside the query or retrieve transaction to assure that the organization holding the data can get a detailed audit log and could enforce policies through access controls.

This diagram shows a typical implementation of an EHR (in white) accessing an HIE based XDS Registry (in black). The XUA Profile provides the orange functionality: X-Identity Provider creates the SAML Assertion given the User Authentication identity and EHR security context, the X-Service User inserts this SAML Assertion into the normal XDS Query Transaction, and on the XDS Registry the X-Service User (not shown) uses the SAML identity and includes that identity in the Audit log.

The XUA profile is not limited to clinical users, it includes use-cases where the patient is participating in a Health Information Exchange, for example this diagram is identical for a PHR as a peer on the HIE. The XUA profile is also not limited to XDS profile, but is generic to Web-Services and thus can enable any  Web-Services transaction.

The XUA profile is a very thin profile that simply indicates that the SAML 2.0 standard includes a specification for an identity Assertion. These SAML Assertions are self-contained XML objects that can contain claims about the identity, attributes about the identity, and claims about the context.

The XUA Profile explains how to add a SAML identity assertion to a Web-Services (SOAP) transaction, in this way the XUA profile can be used to enable any Web-Services transaction. The method of adding SAML assertions to Web-Services is well known and already profiled by the WS-I, a general IT industry consortium that do profiling.  The SAML protocol does include transactions for retrieving and validating SAML assertions, but IHE recognized that these protocols are not the only legitimate way to obtain a SAML assertion for example the WS-Trust standard is more commonly used.

The XUA profile has had a few additional use-cases added to it as named options.
  • User Role -- To support Role Based Access Control
  • Consent / Authorization -- To support use-cases where the requesting party has explicit consent that they want to point at to assist the service
  • Purpose Of Use -- Carry an indicator of what the reason for the transaction is and what will be done with the result
The SAML assertion does not carry a simple attribute, Level Of Assurance, such as described in NIST SP800-63 “Electronic Authentication”. This is because although the NIST specification identifies 4 levels there is still a need for specific Policy and Vocabulary definition.  The SAML assertion does carry an identifier of the method that was used to authenticate the user, outlined by oval in this diagram. From this identifier, of the method used to authenticate, the relying party can determine the relative Level of Assurance in the view of the relying party organization. The future might provide a Level Of Assurance vocabulary, but we don't have this right now.

Resources
Additional Comments
XUA - Very thin profile that simply says to use SAML Identity Assertions for authenticating users on Cross-Enterprise transactions

No comments:

Monday, May 30, 2011

IHE - Privacy and Security Profiles - Enterprise User Authentication

The oldest of the IHE Security Profiles is still a useful and foundational one. The Enterprise User Authentication (EUA) Profile addresses the issue of user authentication for the multitude of users in healthcare: a doctor, nurse, technician, etc; across the multitude of systems they need to login to; and in a way that does not result in 'post-it' notes plastered all over the computer screen.

The use of a single user authentication across a hospital or clinic would simplify the user experience as they would then only need to remember one username and password, thus 'single sign-on'. Given that in healthcare the users tend to need to use many different systems, the only way to get single sign-on is to have all systems use the same standard for user authentication. If this is not coordinated centrally, the users will simply use the same password at all systems; resulting in poor password handling. The solution is the IHE EUA profile.

The EUA profile doesn't just enhance the user experience, but it also enhances the overall security of an organization as it enables much quicker provisioning of user accounts when someone is added, including in catastrophic disasters, but it also enables the quick disabling of user login when someone is suspected of wrongdoing. The single user account also simplifies audit log analysis as it is easy to see all the events that a specific user caused.

The EUA profile needs to support many different platforms, as there are many different systems used in healthcare (EHR, X-Ray, Ultrasound, EKG, etc). The workflows in healthcare systems and applications tend to  to be different than a desk environment. There is a  need to enable workflows such as an exam-room where the registration clerk brings the patient into the room, thus needing to setup the patient on the EHR but clearly needing to logout when leaving. The nurse then arrives to take vital measurements and interview the patient, thus needing to login to the EHR but eventually also logout before leaving. The doctor then continues with the workflow. This workflow is Patient centered and thus the typical desktop login session would be very cumbersome, and slow. Thus the login workflow is radically different, but still needs to be secure.

The solution is to point at the Kerberos protocol. This protocol is very well suited for use within an organization and at the time had been successfully integrated into the Windows platforms as the default authentication. This protocol had been a stable user authentication model in Unix and Linux for decades. Therefor the choice was not a hard one for IHE to make.

The kerberos protocol is commonly used for authenticating users via password, and has a strong protocol for assuring that the password is correct without exposing the password.  The protocol is not specific to passwords and could be used with a pluggable authentication including tokens, biometrics, and smart cards. These technologies however do require pluggable software and hardware which is not fully defined in the Kerberos standards realm.  The user authentication step is the first transaction of the EUA profile. The EUA profile, because of Kerberos requirements, does require that the Consistent Time profile is used to keep all systems relatively synchronized to a time source.

The EUA profile and Kerberos are not just about user authentication, but also support methods of passing the user identity to services in a secure way. This functionality is what the second and third transactions are used for. Once the user is authenticated using a Kerberos Authentication Server, the Client Authentication Agent can request "Service Tickets". These Service Tickets can then be passed to a Service that supports Kerberized Service actor in a way that the Service can trust and use the identity. This Kerberized Service functionality is defined for Web services using Kerberized HTTP Authentication. Other transactions can also be defined as to how they can use Kerberos Service Tickets, the IHE Retrieve Information for Display (RID) profile uses this grouping for user identity.

References
  • Status: Final Text
  • IHE ITI Technical Framework
    • Vol 1: Section 4
    • Vol 2a:  Section 3.2, 3.3, 3.4
  • Standards Used
    • Kerberos v5 (RFC 1510)
    • Stable since 1993, 
    • Widely implemented on current operating system platforms
    • Successfully withstood attacks in its 10-year history
    • Fully interoperable among all platforms
Additional Comments:
EUA - Very thin profile that simply says to use Kerberos protocol for safely authenticating users

  • Kerberos is a pluggable protocol, but really is only used for username/password
  • Kerberos is the standard that Windows ActiveDirectory uses for authenticating users.
  • Kerberos is the standard that Windows uses at windows login (with minor Microsoft extensions)
  • Kerberos is very common in Unix as it was invented at Berkely
  • Kerberos is really good for within an organization, but has real problems that prevent it from being useful on the internet
  • There are also Kerberos ways to pass authentication 'tickets' between an application and server
  • See: Kerberos required in 2011 then forbidden in 2013
1 comment:

Sunday, May 29, 2011

IHE - Privacy and Security Profiles - Audit Trail and Node Authentication

This is the prime security profile in the IHE toolbox. Prime in so many ways, but it wasn't the first. The Audit Trail and Node Authentication (ATNA) profile is composed of three things.

The first part of ATNA is not found in the name, that is that the profile expects that the system functionally includes reasonable access controls. Because this is a functional requirement, IHE doesn't further define it. This has more to do with the purpose of IHE than the need. The expectation is that product suppliers will do the right thing, and that operational environments will inspect their systems before they grant them network access. The other two parts of ATNA: Audit Controls and Network Controls will be further explained below.


The Actor/Transaction diagram looks complex, but it isn't as complex as it appears. The diagram includes the actors from the Consistent Time profile. The diagram complexity comes from the practical fact that our original Actors were more monolithic and reality is more plug-and-play. IHE had originally defined a Secure Node as complete hardware and software system that is considered in whole to be one, although it may be made up of multiple computers, but it is one distinguishable system.
Examples:

  • MRI – made up of many components and computers, may even be made up of discrete physical cabinets
  • EHR – whole system considered as one including all workstations and supporting servers
  • EKG device – single small medical device

The concept of a Secure Node is ultimately the configuration desired, but we had to recognize that software components and services are being developed and they need to be responsible for what they control. Thus IHE had to define Secure Application – a software component that is expected to be integrated into a larger system. Where this software component is responsible for securing any communications it is controlling, initiating, receiving; responsible for any controlling access that it is responsible for; and responsible for logging any security events that it is in control of. This means that a Secure Application is simply not responsible for something that is out of it’s control (for example: auditing of the system startup event, or user-login event) Example:

  • A network service, such as a eMPI, that requires to be integrated into a database farm
  • A software application that must be installed onto a workstation

The other Actor shown is  the Audit Record Repository – Receives the Record Audit  Event transaction. A system implementing this actor will typically process, report, record, alert, forward, and in any other way process the security events. More on this later.

Secure Nodes and Secure Applications are expected to use secure communications, specifically the "Authenticate Node" transaction. This transaction is not really a transaction but an augmentation of transaction in a way that both sides of the transaction can be assured of mutual-authentication, and that the communications between them are protected against risks to confidentiality and integrity.  The easy part of this to understand is that the network communications is encrypted. The thing that I usually need to emphasize is that this communications is mutually-authenticated. 
On the Internet we are getting use to using a web-browser to connect to a web-server, normally this has no security. For sensitive sites we are using HTTPS, which adds authentication of the server and encryption. This would mean that the browser user knows which server they are connecting to with high assurance (not as much trust as you would think). But the problem with this model is that the web-server has zero knowledge of the client. For healthcare we want to not only make sure we are connecting to the server we wanted to connect to, but the server wants to make sure it is only connecting with clients that it can trust. It is this client authentication that is special, and allows for a trusted network to develop.

The most simple protocols profiled in ATNA is Transport Layer Security (TLS). This is what is otherwise referred to as SSL. The difference is that TLS is defined in an IETF standard, where as SSL is defined by Netscape. Ultimately they are now the same, and advancements are being made to TLS. TLS has advantages that it is very easy to deploy, has built in protocol negotiations, built in certificate discovery, and is built into many toolkits and platforms. 
Sometimes other configurations are called for, so IHE ATNA also recommends end-to-end security with Web-Services Security, and S/MIME for e-mail. In both of these cases the certificate discovery and management is not automated, thus they are more complex to deploy.

Audit logging is the final component of the ATNA profile. The idea of the Audit logging in ATNA is that ultimately the use of an audit log is a specialized functionality that needs to have all events that happened on all the various systems in the organization. This is a specialty that has been developing in the general IT market around Firewall, Intrusion Detection, Routers, Databases, and Operating system audit log analysis. Given that specialty exists, we felt it was better for healthcare specific products to simply note that a security relevant event happened and send the details off to an Audit Record Repository for this analysis. So we followed the general IT market architecture. Here is some history and the relationship of the standards:
  1. ASTM E2147 – Setup the concept of audit logs for healthcare including accounting of disclosures
  2. IETF RFC 3881 – Defined the Information Model (IETF rule forced this to be informative)
  3. DICOM Supplement 95 – Made the information model Normative, defined Vocabulary, Transport Binding,  and Schema
  4. IHE ATNA – defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
  5. NIST SP800-92 – shows how to do audit log management and reporting – consistent with our model
  6. HL7 PASS – Defined an Audit Service with responsibilities and a query interface for reporting use
  7. ISO 27789 – is defining the subset of audit events that an EHR would need 
The goal of the Audit log is to support security surveillance to look for abuse of policy, abuse of systems, and to inform an accounting of disclosures. The ATNA audit log is not intended to be used to track changes made to the medical records, this would be the responsibility of the medical records systems.

This diagram shows a use-case where there are multiple Audit Record Repositories distributed across an XDS environment. This would be a common configuration where each organization in an Health Information Exchange (HIE) has decided to maintain their own Audit Record Repository independent from the HIE. In this way the Audit Record Repository in any one organization would manage the audit log entries for that organization and would forward copies of any audit log entry that is a result of a transaction with the HIE (the dotted orange lines).

A good example of why this is important is the basic XDS Document Retrieve transaction. If this transaction does not force an user assertion (discussed later) then the Document Repository can only record the document unique ID that was requested and the system identity that requested it. This is not enough information for the organization hosting the Document Repository to fully report an account of disclosures, but is sufficient information to trace the specific event back to a specific Document Consumer system where the further details can be found.

When this transaction includes an XUA assertion the audit log on the Document Repository would include the user identity and likely purpose of use, but would require extra processing to determine the patient (this extra processing could take place during the transaction, could be known through other means, or could be looked up during audit analysis and reporting)

References:
  • Status: Final Text
  • IHE ITI Technical Framework
    • Vol. 1 - Section 9
    • Vol. 2a - Sections 3.19, 3.20
  • Standards Used
  • “Security Considerations” section found in other Profiles may specialize how ATNA is applied
  • The Audit Event Message typically specialized in Vol 2 at the Transaction level
    • PIX QueryTransaction : See section Vol 2a:3.9.5.1
    • XDS Register Document Set-b: See section Vol 2b:3.42.7.1
Additional Information:
ATNA - This is a comprehensive profile that indicates that Access Control, Audit Control, and Network Controls are important

  • Access Control
    • There is no standards pointed to by ATNA here. There is simply a statement that a system needs to have access controls that can be shown to a local authority are sufficient to protect the systems resources according to the local policies
    • If this can't be demonstrated, then the system should not be authorized to be used. Specifically it should not be given a network identity (see network controls)
  • Audit Controls
    • Specifically Security Audit logging
    • This is a very thin profiling of the commonly used SYSLOG protocols for communicating that an auditable event has occurred
      • There is statements that relax size limits
    • This is a FULL PROFILE of the content of that auditable event into an XML encoded message
    • There is a set of 'auditable events'. That is events that when they happen an audit log should capture what happens
    • The audit log message is fully describing: Who, What, Where, When, How, and Why.
    • This requires that the audit event time be kept consistent. Which is why the CT profile exists. The CT profile says use common NTP protocol to keep clocks synchronized to about 1 second, which is generally good enough for security audit logs
    • See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures
  • Network Controls
    • There are a set of standards specific to the type of network communications. They all address three aspects of network communications of protected information. Not all network communications are protected, for example DNS is not generally needing to be protected as it is not communicating protected information (mostly)
    • Authentication of both sides of all communications that include protected information
      • This is consistently done using machine/service-end-point identities using public/private keys (certificates)
      • Certificates can be directly trusted. One-by-one
      • Certificates can be trusted because they 'chain' to a known authority (certificate) that is trusted directly
      • Caution: the method used on the internet with SSL certificates is technically the same, but not administratively the same. In the internet browser world the 'known authorities that are trusted' are authorities that your internet browser decides should be trusted.
      • ATNA wants a deliberate decision of trust to be done, not a decision by a vendor.
    • Encryption of the communications that include protected information
      • AES is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least AES needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
    • Integrity control of the communications that include protected information
      • SHA1 is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least SHA1 needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
      • Note also that the communications is transitory, not long-term-storage, so the use of SHA1 is acceptable. SHA1 tends to not be acceptable for long term signature (See DSG below)
    • TLS is the general mechanism when no other mechanism is used. TLS is the 'standardized' protocol that is more commonly called SSL. (mostly)
      • IHE profiles that BOTH sides of the communication need to be authenticated
      • Whereas common SSL only authenticates the server. This is not sufficient as it allows any client to connect. In healthcare we want to know where the data is coming from and where it is going. Not just the server
    • S/MIME is used for e-Mail
    • WS-Security mechanisms are allowed for Web-Services that want to use end-to-end security. Note that none of the IHE profiles leverage this as they are all profiles defining endpoints that need access. But this is specified because there may be deployments where someone puts in the middle of an IHE transaction some form of intermediary that needs partial access
    • See Also
  • Open Source Implementations
1 comment:

Saturday, May 28, 2011

IHE - Privacy and Security Profiles - Consistent Time

This Profile is one of the most simple profiles in the IHE toolbox. Indeed it should take absolutely no development by anyone as the protocol has been incorporated into operating systems since the early 2000s. Windows XP enables it by default and connects to the internet to get the time. This is similar with the various flavors of Linux as well. This need to have a reasonably synchronized clock is universal and not specific to healthcare. But in IHE we leverage this profile in a couple of ways. First ATNA (defined later) profile leverages the Consistent Time profile to assure that audit logs are all timestamped with a comparable time-stamp. In this way a security officer can look at the audit logs coming from different machines and be able to know which things happened at the same time, which things happened first and what happened next. This profile is also used by EUA (defined later) as it is important to the authentication protocol that the client, authority, and servers all have a clock that is pretty closely synchronized. This profile has been leveraged in Patient Care Devices to assure that events that are recorded by medical devices have a reasonably accurate clock, and identify some use-cases where higher accuracy is needed.

The profile simply shows some of the use-cases and indicates that the Network Time Protocol (NTP) with it's simplified Simple Network Time Protocol (SNTP) be used. There really are no restrictions on these protocols, besides some emphasis of things that the standard it-self says.
One should note that this Profile does not say what system must be a time source, it is possible that a large hospital wants to run their own isolated time-clock. Another organization may choose to utilize one of the time-sources on the internet such as pool.ntp.org (see http://www.pool.ntp.org/en/). Although the concept is simple, the practice of actually keeping clocks synchronized even within 1 second is quite complex.

Resources

Back links

No comments:
Subscribe to: Posts (Atom)