-
Stacks production instances are run on a 99.9% uptime-guaranteed managed host. Stacks monitors hardware and network connections for reliability purposes. Stacks utilizes a cloud environment to maintain a high degree of security while integrating all recommended information security standards as defined by ISO 27001. This includes the following: Enforces the use of highly secure RSA keys for server access and encryption; Maintains logging of all servers; Regularly patches servers and applications; Enforces the use of firewalls and server monitoring; and Follows the openSCAP security guidelines for all servers not on our managed host.
-
Stacks protects against brute-force password attacks by limiting the number of login attempts from a single IP address over a predefined period of time. Failed login attempts are logged and visible to administrators. Stacks can also be configured to allow administrators to ban individual IP addresses and address ranges.
-
Stacks supports salted hash passwords with stretching applied (multiple hashes) for native Stacks users such as Staff users stored in the database. Third-party authenticated users such as ILS authenticated patrons are supported by a salted hash encryption method. Stacks also supports a variety of password policies such as minimum length, complexity, or expiration. Industry standard authentication practices are also supported including SSL and 2-factor authentication for Stacks Staff.
-
Stacks performs exhaustive internal testing to ensure the security of our system and information. Testing is conducted prior to releasing software, as well as periodic penetration testing independent of software releases, not only on the layers of protection put in place, but across the data lifecycle. Stacks does not share test dates or results.
- Stacks ensures that data is validated and scrubbed before entry in the database. The system tests that user-entered data--and even the form fields themselves--match prescribed, expected formats and values. Tokens are injected into each form as it is generated, to protect against potential CSRF attacks. Database abstraction layer performs additional security checks on data as it is written to and retrieved from the database.
-
Stacks provides a hierarchical role structure which is designed to support all levels of staff. Intricate moderation rules such as requiring proofing and approval before publishing with email notifications, ensures safe and responsible workflows within your organization. Administrators can control who can see and who can modify every part of the site including menu links and features that can be automatically hidden from users who do not have appropriate access. For example, a user role could be created that allows a user to create and update content, but not publish or delete it--permissions reserved for the editor role--while administrative settings are reserved for a separate role entirely. These roles can be further refined by individual organizations post implementation as necessary. Default roles include: Administrator, Moderator, Editor, Contributor and User.
-
The data centers employed by Stacks are state of the art, utilize innovative architectural and engineering practices, and are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
-
Access and information is only granted to data centre employees and contractors who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked. All physical access to data centers by data center employees is logged and audited routinely.
Why is SSH Port 22 open and what compensating controls are in place?
All dedicated clusters are single-tenant and exist as read only meaning the tenant can only be written to via our deployment pipelines or through the application tools themselves. The network is behind a firewall for incoming connections. While port 22 is open to incoming traffic, it is protected by SSH access only and risk is neutralized by using the most stringent SSH access controls including restricted access to highest levels of security personnel, MFA with real time issuance of private keys (preventing key leaks) and certificate generation with certificates stored in local SSH configurations and automatically cycled every hour for a new certificate as long as that session is active. If an administrator is inactive for an extended period, the certificate expires, and is required to login again the next time a command requires authentication. Additional measures that mitigate access attempts include:
Additionally, please note as a library services platform, there is very little if any sensitive data contained within any given Stacks implementation, thus reducing the risk of bad actors. Should we identify attempts to exploit Port 22, this activity would trigger an incident response that may include closing or restricting the port and/or blocking bad actors.