Data SecurityData Security

Data stored during the implementation phase 

The data we store is relative to the specific implementation proposal for a given customer, but common examples are:

• Legacy data, e.g. a data dump from whatever system a given customer currently haves
• Data from a HR system - i.e. data relevant for the implementation project as delivered by the customer
• Data from a Finance system - i.e. data relevant for the implementation project as delivered by the customer

Any data stored as part of a Pure implementation project is deleted when the implementation project is completed (i.e. when the customer goes into production).

Data stored during the test phase 

In advance of a major Pure release, we may ask customers for a copy of certain data for test purposes. The usage of the data is agreed between Elsevier and the customer, and all data is deleted when the test phase is completed. The exact date is communicated as part of each agreement with the customer.

Data transmission between Elsevier and customer

All data is transmitted via secure network channels (e.g. VPN, SSH, SFTP, secure web-dav) depending on the capabilities of the customer. We do not use physical media (e.g. USB stick) for this purpose.

Access control at our office (Aalborg office)

Access to our Aalborg Office is regulated with access control (access cards). Hence, only Elsevier employees at the Aalborg office can enter the office. Our offices are issues with alarms (motion detectors) and a Security company is alerted in case of alarms (say, after office hours).

Access to our network from laptops, small devices and desktops at our office is controlled and monitored via appropriate means (passwords, limitation to specific MAC addresses, packet inspection, encryption, firewalls, etc).

Access control to our servers

Our physical servers are placed in Aalborg and virtual servers are placed in the Amazon cloud. Our physical servers are placed in a secured room, and appropriate backup procedures are in place (i.e. data is backed-up to an off site location).

Our system administrators have root access to all our servers. Depending on the situation (e.g. support) and phase in the implementation project, then specific developers may have access to the servers as well (not root access). Both our developers and system administrators are trusted employees.

Hosted Pure

If a customers Pure is hosted by Elsevier, then it is exclusively in the Amazon cloud.

Access to a hosted Pure is handled by Apache HTTPD - configured to use the newest version of SSL / TLS that the web-client supports (i.e. the web-browser the user is using). We also enable forward secrecy for clients supporting it.

Pure data will be backed up every night (to Amazon S3), and then moved to Glacier after some time.

If a hosted Pure needs to access systems at the customer site (e.g. HR, Finance, etc) then the customer must supply a secure channel to that system (usually the interface is a database-view).

Any data stored as part of a hosted Pure is deleted (including backups) upon request from the customer, or when a given customer cancels their engagements with Elsevier.

Data storage

Pure stores logs and audit trail in "Pure's file system" - "Pure's file system" is stored on disk. The audit trail reflects all changes done to content in Pure (and by which user) and additional information such as log-ins, assignment of rights to users, etc. The audit trail reflects the difference between information before and after it was changed - hence, even information that is deleted can be found in the audit trail.

User accounts in Pure can be configured to authenticate against external systems / SSO solutions, or for local authentication.

Passwords of locally authenticated users stored in the Pure database are hashed using 1000 iterations of salted hashing in addition to an initial round of hashing. From release 5.10, you can further secure local accounts by setting defining a global password policy, that sets requirements for password length and complexity.

If a centralised security solution is required, we recommend using a external system / SSO solution instead. Pure integrates well with most major SSO systems and mechanisms.

Pure ships with a very elaborate roles and rights system, that combined with the workflow engine in Pure, allows users to control access to information stored in Pure in a very fine-grained manner. Please refer to Pure White Paper for more information.

Elsevier Security Statement

Download PDF version of Elsevier Security Statement