Information Security Policy 🔗

Our information security policies were created to help us protect:

• Our client’s data and intellectual property
• Innolitics’ data and intellectual property
• Protected health information that we may come into contact with during our work

Failure to follow these policies may result in disciplinary action.

Many of these policies are only required if you work with PHI.

Definitions 🔗

Health information is data in any medium that originates from a provider, insurer, or other healthcare entity, and that relates to any person’s physical or mental health, or to the billing for healthcare services.

Protected health information (PHI) means identifiable health information that can be linked to any specific person(s).

Electronic protected health information (EPHI) means PHI stored or transmitted in electronic form (e.g., on a computer hard disk).

A breach is the actual or potential acquisition, access, use, or disclosure of PHI outside of approved uses.

A workstation is an electronic computing device—for example, a laptop or desktop computer, a smartphone or other devices that perform similar functions, and any storage media that may be connected to any such devices.

A covered system is a workstation or server that may contain or store EPHI.

A covered connection may exist between a covered workstation and a source of EPHI. The following are examples of covered connections:

• Support emails from a client containing EPHI
• Access to a client’s Dropbox accounts containing EPHI
• SSH access to a server within a client’s network, with the server having access to electronic health records containing EPHI

Workforce members are employees, subcontracted staff, or others with roles that may interface with sensitive information.

A covered workforce member is an Innolitics workforce member who is able to make a covered connection.

A covered project lead is the Innolitics employee who is managing a client project that may require covered connections, if not immediately, then at some point in the future.

A security incident is a potential data breach or other possible compromise in the confidentiality, integrity, or availability of protected information.

Password management 🔗

A secure password must be at least eight (8) characters long, is unique, isn’t repetitive, and either includes multiple types of characters or is very long. These are examples of good passwords:

• ilovetowritehighqualitycode (is very long)
• @B1heul!l1 (uses special characters and numbers throughout)

These are bad password examples:

• a!8Ab3 (too short)
• 1111133333 (too repetitive)
• childsname (too guessable)
• hola123! (many people put special characters and numbers at the end)
• @B1heul!l2 (fine normally, unless you also use @B1heul!l1)

Here are our policies for password management using 1Password:

• Your master password must be secure and your account must be protected using multifactor authentication.
• Your company email password must be secure and your email account must be protected using multifactor authentication.
• Store all company passwords in 1Password, except your master and email passwords.
• Generate new passwords using 1Password while meeting the minimum standards outlined above.
• Do not write down your email password or your master password, except possibly for a few days while you’re ingraining them in your memory.
• Never share your master password or company email password with anyone.
• Only share passwords using 1Password.
• Passwords that need to be shared for a particular project should have a shared project-specific folder.
• Software licenses, keys, and other especially sensitive information should be stored and shared using 1Password secure notes.

If you are unfamiliar with 1Password, these video tutorials are helpful.

To the best of our understanding, any passwords contained in your private vault can not be accessed by anyone else at Innolitics. However, 1Password has an activity log that records when you add or edit items in your personal vault. We don’t typically look at this, but if you are concerned about privacy, you may not want to add personal logins to your company 1Password account.

Email and web security 🔗

Before sending a message containing sensitive information, double-check that the recipient’s address is correct. It’s helpful to mention in the message that the contents are sensitive and should not be shared with others.

One trick is create your email first without a recipient address, only adding it as a last step before sending. In this way you don’t inadvertently send an email you haven’t yet fully completed (that is, you avoid the fat finger syndrome). It also lets you be more deliberate as you double-check the recipient’s correct email address.

Spear phishing is an increasingly common tactic that can result in a compromised account, web browser, or workstation. A spear phishing message can be easily disguised to seem legitimate. Often embedded links in the message are designed to exploit a web browser, an attachment exploits the application that interprets it, or the email itself has a call to action that results in divulging information. Once it’s exploited, a workstation might download a malware payload that can execute additional instructions defined by the attacker.

Read this bulletin published by the US Department of Health and Human Services if you’re curious to learn the guidance given to the healthcare industry in general.

A variety of pretext attacks on the web are similar to phishing. Innolitics requires multiple layers of security controls to mitigate the risks of attacks such as these.

Workstation setup 🔗

All covered workstations and systems must implement the following security controls:

1. Require a password, fingerprint, or facial recognition to log in
2. Automatically lock after an hour of inactivity
3. Encrypt internal storage at rest
4. Automaticly check for and install security updates for your operating system (alternatively, you must develop a sytem that will remind you to manually apply security updates and produce a record that you did so once each quarter)

If feasible, non-covered workstations should also be configured in this way. If you opt to use manual updates, we recommend setting a repeating reminder so you don’t forget.

Working with sensitive information 🔗

To limit the proliferation beyond Innolitics’ control and to meet our agreements with the data originators, sensitive information should only be stored and viewed on covered workstations. Before you start working with sensitive information on a new workstation, inform your project lead so they can record details of the host for tracking purposes. We need to keep such a record to be sure it gets deleted when it’s no longer needed.

Innolitics requires the following practices when working with sensitive information:

• Only store EPHI information on covered workstations.
• Store only the minimal amount of sensitive information required to complete the tasks.
• Purge sensitive data from your workstation as soon as reasonably possible using the procedure shown in the next subsection.
• When feasible, store all sensitive information in a single location on your workstation. This makes it is easier to track and delete it when you’ve finished working with it.
• Exclude workspaces containing with sensitive data from any automatic backup utilities that copy data to external devices or to a cloud service.
• Don’t store EPHI on external media such as external hard drives or USB drives.
• Don’t share EPHI in GitHub, Slack, Notion, Google Drive, iCloud, or other cloud services.
• Don’t share sensitive information with people outside of either Innolitics or the client.
• Don’t share sensitive information with individuals within Innolitics unless it’s necessary and is approved to do so by your project lead.
• If you believe that sensitive information may have been breached, immediately notify your project lead.

Purging sensitive data 🔗

It may not be necessary to retain sensitive information when finished with a project, and it’s risky to hold on to it longer than necessary. When you’re sure the data is no longer needed, follow these guidelines to purge the files so they cannot be reconstructed, inadvertently or otherwise.

• On magnetic media, use the GNU coreutils utility shred -u to delete a filesystem handle and overwrite the file data multiple times.
• If storage cannot be purged locally, such as in a bucket on a cloud service, the best practice is to ensure the bucket is statically encrypted by the cloud service before data are written to it, then shred the decryption keys.
• If a covered system or workstation stops working while containing sensitive information, physically destroy the internal storage before disposing of the device.

SSH 🔗

We frequently use SSH to access remote servers. Here are policies regarding its use:

• Use a different key pair on each workstation.
• Use a passphrase (it’s OK if you use the same passphrase for all keys).
• Use an SSH agent when appropriate (e.g., when cloning a GitHub repository from a remote server).

Working in public places 🔗

Avoid working with sensitive information in a public place when feasible. If unavoidable, position your screen so it’s not easily visible by others and be careful to lock your workstation before stepping away from it. Never leave your devices unattended.

When working on a publicly shared internet connection, use a virtual private network (VPN) service to tunnel your traffic through the untrusted connection. Note that tethering to a mobile phone is a more secure option.

Annual training and audits 🔗

If you work with EPHI, you will need to review these documents once each year and configure your devices to meet these security guidelines. Also, your project lead or Innolitics’ security officer will ask you a series of questions regarding how your devices are set up.