Industry Insights: Security Considerations for Today’s Electronic Lab Notebooks
Welcome to our latest Q&A session. For those of you not using ELNs, please don't run off! While this exchange nominally addresses concerns with various aspects of ELNs, the reality is that these concerns are valid for all types of informatics systems, both inside and outside the laboratory. The topics we examine range from options available for electronic signatures and verifiable time stamps to methods for reliably embedding external documents into an ELN. As before, we’ve gathered experts from some of the leading companies in the field to provide their take on these questions and explain why they feel that way. As the best way to do something — assuming such a thing actually exists — generally varies with circumstances, the wise reader will take this explanation of "why" and examine it in light of their own processes. Of course, our experts have provided high-level views and couldn't get into all of the potential caveats affecting their answers, the critical thing here is not to find the answer, but to point you in the right direction to ask additional questions.
— John R. Joyce, Ph.D
Q: ELN use in a regulated environment requires verifiable electronic signatures. Please describe the best available options and their relative benefits. Which do you recommend and why?
Robert Pavlis: There are three aspects to controlling electronic signatures: I recommend the following functionality:
- controlling access to data and controlling the ability to add data to any document in ELN. This is normally done with an e-sig system that requires users to enter their name and password. This is fairly standard in ELN.
- tracking additions and changes in an audit trail system. It is important that the audit trail tracks before and after values for any change. Many ELN systems perform this function. However, very few provide the ability for the approver/auditor to easily see these values at the time the approval is being done.
- verifying any signature on a document or ELN worksheet after it is printed or displayed electronically. A very good way to do this is to provide a water mark to the electronic signature. This watermark proves to the viewer that the signature was electronic and that it was authenticated at the time it was placed on the document.
Paul Denny-Gouldson: When an ELN is deployed in a regulated laboratory, there are a number of options that exist ranging from simple hash algorithm encryption signatures up to digital signatures. Hashing algorithms are used in many industries and have been used for many years to provide tamper evidence. Digital signatures are now also useable to verify identity and provide tamper evidence and are sometimes deemed a higher level of security.
Participants:
François Beillouin
ELN Professional Services Manager
Agilent Technologies
Mats Kihlén
ELN Specialist
Contur Software
Paul Denny-Gouldson, Ph.D.
Product Manager, E-WorkBook Suite
IDBS
Robert Pavlis
President
Labtronics
Steven Neri
Director of Pharmaceutical Business Development
LabWare
Jeff Spitzner
President and Chief Science Officer
Rescentris
Dominic John
Director of Software Marketing
Symyx Technologies
William Buote
Senior Vice President and Chief Technical Officer
VelQuest
Thomas Schmidt, Ph.D.
Informatics Senior Product Manager
Waters
|
|
Jeff Spitzner: Options include commercial third-party services (SAFE, Surety, other hosted signing services), Adobe PDF solutions, and ELNs using either proprietary or open architecture enterprise digital signature systems. Commercial external (SaaS) offerings designed for signing ELN records work for signing simple documents and can benefit labs with limited IT resources. The costs may be high to utilize these strategies and there are risks that these companies may not stay in business. Online and PDF e-signature solutions may not be able to handle complex data sets and other critical lab records that establish the context of the work. Proprietary ELN systems maintain lab records safely behind the firewall, but might not be supported or have accessible data in the future for verification. I recommend open signature systems based on PKI (Public Key Infrastructure) and other public standards that ensure the time/date stamped records, digital signatures, keys and original notebook documents are all accessible in the internal ELN system and backups, such that e-signatures can be verified independent of third-party organizations but cannot be tampered with without detection. These solutions can offer future-proof, secure, and verifiable e-signatures.
Thomas Schmidt: Principally, two kinds of electronic signatures are in use today: the one-factor user/password verification and the true digital signature. With the one-factor user/password verification, you can sign the current status of a document and the ELN application can prevent changes to the signed record. But, when you export the record, e.g., during regulatory submission, you can’t assure the integrity of the signed document without a link between the signature and the record content. In contrast, with the digital signature framework, the record integrity can be guaranteed. This two-factor electronic signature requires an additional hardware token for authentication and links the signature uniquely with the record content. The SAFE BioPharma organization developed a trusted environment for digital signatures that allows exchanging records among different authorities. Because the signature is directly attached to the content, the receiver can unambiguously verify the authenticity of the signer and the integrity of the content.
François Beillouin: Electronic signatures can be split into several categories. Each one of them brings different security elements, but also constraints. The general mechanism consists of signing a document checksum with a trusted certificate. When the certificate is a company one, used server side (when we consider enterprise systems), the maintenance is easy, but the individual authorship proof mechanism relies both on the certificate itself and on the procedure used inside the software to activate and track signatures. When the certificate is an individual one, this is no doubt the easiest way to prove the identity of the signer and, so, the author and witness of an experiment. However, this option requires a lot of efforts regarding certificates management and security. There’s one variation on this mode with SAFE certificates which adds a way to trust electronic records when exchanging them between different companies. The choice between these options has to be debated and accepted with the legal department, and both can be very well adapted depending on the company activity. As these needs can also evolve with time, it’s important to select an ELN that can accommodate all different options.
Steven Neri: In a regulated environment, all records should be audited and should also be preserved in encrypted electronic record form. The implementer should then have the option to selectively determine where and to what extent electronic signatures will be enforced. This approach of combining system-generated electronic records capture with configurable e-sig determination is strongly recommended because it provides a comprehensive audit history, while at the same time enabling the customer to selectively manage the way that electronic signatures effect the user experience.
Q: Time stamping ELN records is critical to any legal challenges, but can be especially tricky when operating across multiple locations and time zones. What steps do you recommend to minimize the risks of alterability of records and to avoid potential legal challenges?
Mats Kihlén: Global systems are, to an increasing extent, operated from a single corporate data center. While the server obviously holds a central time, each ELN client needs to keep track of the local time when an experiment is created or signed. I recommend that the ELN records are stamped for clarity with either UTC or GMT, as well as the local time. In case of ambiguity, e.g. due to erroneous client computer settings, the central time will overrule the local.
Paul Denny-Gouldson: Timestamps are critical, and the problem has been solved by other industries, such as banking. There are standards that are used to provide a unified time format coupled with the time zone information about where the user was when the time stamp was applied. There are also well-documented methods and services (GPS time servers) to provide central timestamps that other systems can reference. The time stamps obtained from “trusted sources” should be used in combination with e-signatures / digital signatures to maximize the security and auditablity of records and audit trails.
Jeff Spitzner: I recommend only using the time stamp of a single server — not local to the client computer or end-user — for ELN records. The server should be synchronized with remote time servers and there should be policies in place for verification of the single official ‘system time.’ The time stamp is added to records from the server as part of the record transaction to avoid any chance that users change their computer time. The location and time zone of the user can be tracked but does not really matter, because the time is absolute not relative. The sequence of events, records and sequential assignment of globally unique identifiers make it nearly impossible to alter a record without detection or without having to change all the data in the system — which should be impossible without a major conspiracy and a system that is not built for compliance. The audit trail will demonstrate that all records are created and managed in proper order and this can be readily verified.
Dominic John: It is critical to use a centralized, common system for all ELN record versioning and time stamps. Time stamps should be generated at the database, reconciled to coordinated universal time (UTC), and recorded with the client’s local time zone offset (from UTC). This ensures consistent time stamps while also preserving the ability to record the local time the action was taken. Signatures should be required when committing an ELN record to the database. The signature should require the user’s credentials, reasons for the change and optional comments. This ensures that the correct person is committing the ELN record to the system.
William Buote: Time stamping all records and changes to records, as well as electronic signatures is required to support the chronology of activities. Time stamps that provide unequivocal reference to UTC time (commonly referred to as GMT) may be implemented by recording three components of the reference clock. These are the day, time and time-zone bias. Using these three components, the actual chronology of events may be determined, even for those events happening in different time zones. In addition to the data recorded in the time stamp, the referenced clock must be controlled and synchronized.
Thomas Schmidt: To obtain comparable time stamps in international ELN deployments, the time stamps should be stored in a standard time format such as UTC, the coordinated universal time. Nevertheless, for the convenience of the user, the ELN user interface should also display the time stamps in the local time. Very often, the application server time, i.e., the time originating from the customers on-site server, is taken as the source for the time stamp. However, the problem with this approach is that the clock may allow for time stamp manipulation or, in some cases, fail altogether. In an optimal solution, the ELN should connect to a trusted time server to achieve the highest reliability while creating time stamps. The trusted timestamp can then be attached to the record along with the digital signature.
François Beillouin: I consider here again enterprise systems which operate from a central location regardless of from where end users connect. The server (or server farms) has to be in charge of records time stamping. Using server time and recording correctly the time zone information associated to each transaction is a minimum. This already provides a good security level, because there are so many interconnected processes and correlated information that hacking such date events is nearly impossible. However, there’s one very nice option which consists of using an external time stamping service like the one provided by Surety which guarantees the time and content of any electronic record independently from the original software. When this mechanism is natively provided as an option and activated, the risk of alterability of records becomes null, and we provide export mechanisms that help anyone prove the authenticity of records.
Q: When working with ELNs, it is essential to maintain the integrity of and track alterations to documents, including associated files created in external applications. What methods do you recommend to create and track these documents while maintaining their version integrity? Are there potential tradeoffs between methods?
Robert Pavlis: The ELN system being used should be able to monitor changes to its documents and track before and after values, as well as the name of the operator making the changes. All of this would be tracked right with the document itself and added to the audit trail. The benefit of doing this in two places is that the data inside the document is more readily available for review purposes. ELN worksheets should go through a completion and approval phase. After approval, no more changes should be allowed unless it goes through a special un-approval process which can require higher authentication levels. Files associated with an ELN worksheet should be stored and managed through a document management system or an SDMS. These systems monitor changes, provide audit trails and are able to lock down a file from being changed.
Mats Kihlén: It is preferable that data is displayed explicitly as images, tables or graphs. Using PDF/A as the primary document format for long-term archiving is clearly recommended. Since hidden versions are hard to manage, we recommend that all changes are shown sequentially. If a correction has been made, it should be appended to the previous erroneous record, rather than replacing it. Binaries should, if possible, be avoided as associated files, not for integrity reasons, but for the general complication of finding applications that can read the files in the future. All associated files, such as raw data from instruments, should obtain a hash-code (“electronic fingerprint”) generated by a published algorithm, e.g. the National Security Agency’s SHA1. In this way, the integrity can always be verified independently of any vendor system. All final records in an ELN should have such codes as part of their electronic signatures. J
Jeff Spitzner: I recommend managing all of the associated files and documents within the ELN system to ensure that they are maintained with the same controls as the ELN records. In this case, these files are also under version and access control, time/date stamped, tracked in the audit trail, and can be digitally signed. Encrypting the digest of these documents and data with the user’s digital signature key prevents non-repudiation and ensures detection of any changes. The registration of the files and assignment of sequential globally unique identifiers, metadata, and computation of the digital digest can be performed even if the storage is not internal within the ELN system, and these can be verified from their source at any time in the future to prove version integrity (or to detect changes). Storage of file and data versions within the ELN system, but using a distributed file system store rather than a relational database ensures that system-wide controls are in place but performance does not degrade due to bloated storage (and disk storage is cheap and readily extended).
Dominic John: ELN records must never be overwritten, and committing a new version of the record cannot obscure prior data. An excellent approach to this problem is to store a new version each time the record is committed. All prior versions are, therefore, still available for review if needed. Storage can be a concern, but can be managed by utilizing data compression routines and archiving. When external files are incorporated into a record, they should be copied into the ELN and associated with the record. This ensures the necessary data used to form the scientist’s conclusions are preserved and not subject to change from outside the system. While it is possible to reference data externally without including it in the ELN, this can result in data integrity problems if the external data is not available at a later date or is updated independent of the ELN entry.
Thomas Schmidt: The scientific documentation process typically consists of information coming from different sources. In the case of free-flow or discovery documentation process, documentation records are subjected to multiple updates until an experiment is finally signed off. For complete traceability, it is important to provide content versioning to keep track of the different versions of an experimental record. Therefore, the ELN must provide a mechanism to freeze a version of a document and to restore or roll-back to this former version if necessary. This can be achieved by embedding documents into the closed ELN environment, where each version is stored independently. You can add an additional level of traceability for Excel spreadsheets by tracking the changes directly in the audit trail of the corresponding ELN experiment. The advantage of this approach is that each change is immediately tracked, and the user doesn’t have to think about versioning the file manually. An alternative approach relies on leveraging a tightly integrated scientific data management system (SDMS). In this approach, documents and files are uploaded and secured within the SDMS and then dynamically linked to the ELN, preventing the user from making changes, regardless of whether unintended or deliberate, adding an additional level of security.
Steven Neri: Any documents that are considered integral to the work processes automated by the ELN should be stored in the database as controlled documents under the control of the ELN application itself. Placing them under secure database control, when done properly, serves to control user access; to enable the tracking of who accessed and viewed documents; and also facilitates version control.