Destiny Security Practices

Following is information and best practice advice for Destiny Cloud and self-hosted customers. Destiny Cloud districts are always on the latest version of Destiny, including any patches or auto-updates.

Self-hosted best practices

Self-hosted districts always need to do the following for security as soon as possible:

  • Update to the latest version of Destiny. You are responsible for monitoring and applying the latest patches, auto-updates, and releases in a timely manner.

  • Install the latest security patches to your Operating System (OS). You are responsible for monitoring and applying the latest OS security patches.

  • Install the latest security patches to SQL Server. You are responsible for monitoring and applying the latest SQL Server security patches.

Inbound and outbound ports

As an internet based software, Destiny requires external access. As such, certain ports must be opened.

Note: In addition to the PUT method for AASP, GET and POST are also required, as some firewalls and security apps/appliances filter the PUT method.

Connectivity options

Static Nat configuration is the one used most often. It requires a dedicated public IP address to be mapped to the internal address of the Destiny server. Only 443, and, optionally, 210 (for z39.50 protocol) should be “open” for the outside address. Additionally, it is required to have a CA signed SSL certificate to use for securing login information that is passed from the patron’s web browser to the Destiny server. An "A" DNS record needs to be created and point to the external address mapped to the Destiny server. Destiny requires the certificate pass the requirements for Mozilla, Apple, Android, Java, and Microsoft and is signed by the vendor you use as a Certificate Authority (CA). You should install the root, intermediate, and signed certificates into the destiny.keystore.

Single sign-on (SSO) (Destiny Cloud and self-hosted districts)

It is highly recommended to integrate with an SSO system and NOT maintain student and faculty passwords in Destiny. This ensures district password policies and protections are integrated with Destiny authorization and helps protect student data. It is permissible (and sometimes necessary) to pull usernames into the Destiny system for matching purposes, but the user password is left blank when using SSO.

District-level users

Create district-level user accounts as named users. Give each district user their own names tied to them, with their own unique, strong password.

Example: If there are three district catalogers, give each their own account, using their name, with the permission to Manage Library Materials for the District.

Review district users regularly, as there is no automated removal process (not in SIF or rostering) for them.

Password policies:

  • Define a strict password policy.

    In cases where passwords are stored in Destiny (destinyadmin and districtusers – all other users should be authenticating via SSO), security vulnerability can occur if users select common terms as their password.

    Use the Password Policies option to configure Destiny to enforce a strict password policy. To require users to create passwords that are 8 characters or greater in length and include a mixture of digits and letters, select the Strong password required checkbox.

    note: Setting up strong passwords does not invalidate any existing weak passwords.

    Use the Login expires field to enforce the change to your district's password policy.

  • Define a password expiration date.

    Always have an expiration date on passwords in Destiny. If you are using SSO, this won’t apply to many users, so always leave it on.

  • Define a password lockout policy.

    An effective defense against automated password discovery tools is to temporarily disable a user account after a specific number of invalid login attempts. By selecting a numerical option from the Login attempts allowed drop-down, and then entering the number of minutes to disable the account in the Login lockout delay field, you can configure the login security to match your district's security needs.

    Example: If you select 2 from the Login attempts allowed list and enter a 5 in the Login lockout delay field, then, after two failed login attempts, Destiny will lock the user's account for 5 minutes.

Security of your system is central to protecting your district’s data. By using Destiny Cloud hosting, Follett manages most of this for you. This is especially critical as the pace of technology changes and installations become more complex. To ensure your system remains reliable and to protect data integrity, Follett will continue to implement safeguards within our solutions that enhance the security of your Destiny system.

Encrypting Destiny data files

Protect data on the Destiny application server

Follow your IT security best practices for protecting end-user data and the cyber-resiliency of the server that houses the Destiny application, application files, and SQL Server database.

The indexes folder (keyword search indexes) should have virus scanning off – this is a highly read/written file that many virus checkers quarantine and affects Destiny.

The SQL database files should also be excluded from virus scanning.

Important backup information:

The backup process only encrypts the contents of the folder where Destiny is installed. If you copy the contents of the Destiny directory to another location, the files may not be encrypted in the new location.

You may want to encrypt your backup location as well, using the same steps as above. In case of server malfunction, you may also want to export the certificate you used to encrypt the folder. For more information on this process, contact Microsoft technical support.

Recommended best practices

  • Follett recommends you configure Destiny to notify you when auto-updates are received and to automatically apply auto-updates.
  • Routinely update/change all passwords on the server, including any database account passwords or domain credentials.
  • Investigate the possibility of conducting regular vulnerability scans of the server and its hosted content to help identify and mitigate potential vulnerabilities.
  • Ensure systems are patched in a timely fashion and verified routinely.
  • MS-ISAC recommends implementing logging and monitoring logs to ensure only authorized users are accessing resources, and identify any unauthorized modifications or unusual traffic. Store logs for a minimum of 90 days.
  • Ensure antivirus and antimalware solutions are properly maintained. Signatures and detection engines must be updated to ensure optimal protection from threats.
  • Perform regular backups of all systems to limit the impact if/when a compromise occurs.
  • Apply the principle of Least Privilege to all systems and services.
  • Enable encryption of your data “at rest” in MS SQL Server.
  • Have knowledgeable IT staff follow the current security best practices for your network, servers, and identity provider/SSO.

 

Click here to download the pdf.