ILAB OPERATIONS SOFTWARE TECHNICAL SECURITY MEASURES

Effective as of October 19, 2018

Scope

The purpose of this document is to outline the strategies and control mechanisms that form the Security Management practices of the iLab Operations Software (“iLab”) service (the “Service”). Additionally, it provides a description of the information security safeguards provided by third-party tools and vendors used by iLab.

Purpose

The purpose of the Security Management practices is to ensure that information stored and accessed through the iLab Service is managed such that:

• All information is available and usable when required.
• All information is observed by/disclosed to only those individuals who have a right to know it.
• All information is complete, accurate and protected against unauthorized modification.
• All information exchanges can be trusted.
• Where appropriate, information access and modifications are tracked for audit purposes.

Approach

Agilent works continuously with researchers, lab-managers and administrators to identify information-security needs, and with experts in the hardware security, application security and network security to update the Service to meet those needs.

Overview

Technical security measures are in place to guard against security threats including:

• Damage or unauthorized access to hardware
• Low level vulnerabilities such as Buffer overflow attacks
• Application or OS vulnerability and misconfiguration
• Data malformation attacks, including SQL injection, and XSS
• Session fixation attacks
• Sniffing/eavesdropping
• Network attacks

Agilent takes measures across the three layers of the application framework in order to maximize security precautions:

• Hardware protection
• Application protection
• Network protection and monitoring

Hardware Protection

Agilent locates all hardware in SAS 70, Type II certified facilities, which meet the most stringent civilian hardware uptime and security standards. Facilities ensure 24/7 information availability, prevent against unauthorized access to hardware, and provide protection against hardware damage from accidents and natural disasters.

Hosting provider security

Hosting providers maintain SOC Type II certifications. In addition, the implementation of the iLab service on the cloud service provider is reviewed by the Agilent’s ISRM group (Information Security Risk Management) and must meet Agilent’s Cloud Security Standards. These standards define guidelines around firewall implementations, server patching, etc.

Application Protection

The iLab Service is built on an application stack which integrates best-in-class operating systems, database-servers and application-servers. Agilent continuously updates all components of the stack with the latest security patches and releases to prevent unauthorized attempts to gain access or control of the Service.

Authentication

Measures aimed at ensuring that only authorized individuals can access the iLab Service.

Authenticated system access

Accessing the iLab Service requires authentication with a login identifier and password. All login identifiers are unique and all passwords are always encrypted. Agilent logs all successful and failed system login attempts to identify suspicious activity trends.

Strong passwords

The iLab Service requires that all passwords be between 8 and 40 characters long and contain:

• At least one lower case letter
• At least one upper case letter
• At least one number
• At least one non-alphanumeric symbol (e.g. [! ,%, @, #, $, ^, *, ?, _, ~, &])

Agilent salts and encrypts all stored passwords.

Inactive session termination

In order to mitigate the risk of unauthorized access from a user forgetting to log out of the iLab Service, iLab automatically terminates all sessions after 120 minutes of “inactivity”.

Password expiry

Agilent offers customers the option to define the frequency with which users must change their passwords in order to protect against password guessing, cracking or threat.

Server access

Only registered iLab administrators have access to the iLab database servers, application servers and operating systems with a secure password. In addition, Agilent audits all server access attempts.

Authorization

Measures aimed at ensuring that only authorized users can access specific pieces of information in the iLab Service.

Data partitioning

Users can control access to data at a granular level, including providing access to individual “information assets” such as files, with the ability to specify which other users are allowed to read, modify, and share each information asset. In addition, administrators can control which users have access to project, lab, or department information.

Data validation checks

Agilent tests all user-generated input for malformed input, which prevents unintended code execution and inappropriate access to information in files or databases. We prevent SQL injection and Cross-Site Scripting (XSS) attacks by using parameterized queries, applying stringent data validations and sanitizing all user input before use.

Agilent access to information

All Agilent access to user-generated content is controlled by the following policies and conditions:

• Access user-generated content for the purpose of user support.
• The Agilent Cloud Site Reliability Engineering team and senior members of the Agilent CrossLab R&D Software Engineering group have default access to the information in the Service; all other Agilent staff must work through these groups in order to gain access.

Auditing

Auditing User Activity

Agilent maintains detailed logs of access to and modification of all information in the Service. Audit entries capture:

• Username
• Date and time of modification
• A description of the action taken
• Identity or name of affected data, system or resource
• Old value/new value information for changed data, where appropriate
• Audit trails are protected from unauthorized modifications

Product development process

• All software applications are developed based on industry best practices and incorporate information security throughout the development lifecycle.
• All system and software changes are tested before deployment.
• Separate development, staging, and production environments are maintained.
• Production data is never used for testing or development.
• All test data and accounts arc removed before production systems become active.
• All temporary accounts, usernames, and passwords are removed before an application is released to customers.
• Source code is reviewed, and applications are tested periodically for security vulnerabilities, especially those related to:
  • Invalid login and authentication
  • Cross-site scripting (XSS) attacks
  • Injection vulnerabilities (for example, SQL injection)
  • Cross-site request forgeries (CSRF)
  • Improper error handling
  • Logical data separation to ensure that one customer’s data is not visible to others even in the case of programmer error
  • Customer data is protected from corruption even in case of programmer error

Enterprise grade data protection and encryption

• Data backups are bulk encrypted using the AFS algorithm immediately upon creation.
• Fully documented key management processes and procedures are used for encryption keys.
• Keys are generated using a cryptographically strong pseudorandom number generator.
• Encryption keys are never transmitted via unsecure protocols.
• Encryption keys are changed periodically, at least annually.

Network and Monitoring

Network protection

Multilevel security products from leading security vendors and proven security practices ensure network security.

• To prevent malicious attacks through unmonitored ports, external firewalls allow only ssh, http, and https traffic on specific ports.
• All data is encrypted in transfer to prevent sniffing/eavesdropping attacks.
• Web based applications that collect or display customers data do not allow access via un-secured HTTP and redirect all HTTP connections to HTTPS (SSL/TLS).
• Remote administration protocols other than SSH and SSI./TIS are tunneled through a Virtual Private Network (VPN). Telnet. FTP. VNC, or SNMPv1 are never used for remote administration.
• Router Access Control Lists (ACLs) are configured to refuse any type of network connection that is not explicitly allowed by the ACL rules.
• The ability to make changes to the router ACLs is limited to one single user account.
• High availability routers are in place and configured to provide failover services in the event of primary router failure.

Monitoring

Agilent has implemented systems to monitor security and immediately alert the iLab team of suspicious activity to allow a response before the first level of defense is breached.

Additionally, the enterprise monitoring application on host machines is configured to alert support staff personnel when pre-defined system thresholds are exceeded that include, but are not limited to, the following:

• Disk space
• CPU load
• Memory utilization
• Backup success and failure
• Connectivity and availability
• Hardware issues