Bulletins
March 2017
BD is committed to providing safe and secure products to our customers given the important benefits they provide to patient health. We value the confidentiality, integrity and availability of all protected health and personally identifiable information (e.g., PHI, PII) in accordance with all applicable federal and state privacy and security laws, including the Health Insurance Portability and Accountability Act.
This notification provides product security information and recommendations related to a security vulnerability found within specified versions of BD Kiestra™ Total Lab Automation (TLA), BD Kiestra™ Work Cell Lab Automation (WCA) and BD Kiestra™ InoqulA™ +.
- BD Kiestra database. 3.0.61 and previous
- PerformA. 2.0.14.0 and previous
- KLA Journal Service. 1.0.51 and previous
In February 2017, BD was made aware of two security concerns from a customer and through internal risk assessment identified an additional security concern with the BD Kiestra platform that could result in an attacker gaining access to the BD Kiestra database and limited PHI/PII information.
- A legacy networking protocol (SMB1), which may still be active on customer servers. This protocol is not needed for use with the BD Kiestra platform.
- The use of default third-party credentials on the BD Kiestra database.
The BD Kiestra database uses default third-party account credentials from Embarcadero Interbase. These credentials are widely known and can be found online.
If an attacker has access to the internal hospital network or if the hospital allows incoming traffic from the internet into their internal network on TCP/IP port 3050 (database communication port), an attacker may have direct access into the BD Kiestra database and can use the default third-party credentials to log in. This could result in an attacker gaining access to the BD Kiestra database and limited PHI/PII information. - BD Kiestra applications use hardcoded passwords to connect to the BD Kiestra database.
All applications use changed credentials, with the exception of PerformA and KLA Journal Service, which still use the default credentials. The credentials for those two applications need to be updated in order to keep the applications functioning after the credentials on the database have been changed.
Vulnerable data includes:
- The BD Kiestra database contains all sample data being processed through the TLA/WCA/InoqulA+ system.
- Additionally, PHI and PII are impacted, but limited to the Sample ID, as it is transmitted when communicating with the laboratory.
- Other sensitive data may be included in two optional and customer customizable fields in the laboratory information system (LIS). This only applies if the fields are customer enabled and sensitive data is entered into the fields by the customer.
- Patient names and social security numbers are NOT accessible through this vulnerability.
This vulnerability has been assessed for clinical impact by BD and represents a negligible probability of harm to the patient.
BD has identified a resolution that includes customer action for immediate mitigation:
- Disable SMB1 protocol on the database server; file/program server; backup server if this is active.
- Ensure TCP/IP port 3050 is closed to incoming and outgoing connections (e.g., from internet to internal hospital network).
- Close port TCP/IP 3050 on the internal network for traffic other than BD Kiestra applications with the BD Kiestra database.
Starting April 2017, BD will begin taking the following actions, including:
- Updating the default Interbase credentials on the BD Kiestra database itself with secure ones by changing the customer password on the database. This will be done remotely and ensure a unique password for each customer.
- Updating the credentials for two applications, PerformA and KLA Journal Service, which still use the default Interbase credentials to connect to the database.
Note: All other applications have already implemented password changes previously as part of the continuous software improvement program.
Note: These changes will be implemented through our biannual release, starting April 2017 and may continue through the next biannual rollout in October 2017.
For more information on our proactive approach to product security and vulnerability management, contact our Product Security Office.