OpenAthens security guide 2.3
Contents:
Introduction
OpenAthens is a cloud-hosted Identity and Access Management solution that supports the SAML 2.0 protocol to provide a single sign-on user experience for library patrons. OpenAthens can be configured to connect to an organization’s own LDAP directory or other identity provider (eg. Azure, Okta). Or OpenAthens can act as your identity provider.
Additionally, OpenAthens offers a service provider product, which enables integration with single sign-on via an Open ID Connect (OIDC) layer to verify the identity of users on their platform. OpenAthens maps the OIDC claims into our SAML 2.0 access management tool.
OpenAthens takes security seriously. We use a range of measures to secure our applications and data, ensuring good security practices are embedded across our organization. OpenAthens is part of Jisc, the UK not-for-profit organization that provides digital, data and technology services to tertiary education, research and innovation communities. Jisc has a strong security culture and cyber security is one of the services it provides to its customers.
This document provides an overview of OpenAthens’ approach to security. It contains information useful to customers and prospective customers carrying out due diligence on OpenAthens as a supplier.
Jisc
Security management
Jisc’s information security team maintain our organizations information security management system (ISMS). The ISMS is continuously monitored and improved to conform with or exceed the standards required by ISO 27001. Annual, mandatory security training is delivered through an online learning platform to ensure all staff are familiar with their responsibilities and up to date with policies and procedures. Clear processes are in place to manage security related incidents and to liaise with law enforcement if required.
Business continuity
Jisc follows robust business continuity plans, reviewed and approved by Jisc’s senior management. These plans protect the health and safety of our staff, and the delivery of our products and services to members and customers. We design and manage our services so that colleagues working remotely can securely and easily operate and support them. Jisc’s flexible working strategy allows us to react to business continuity events and manage our operations as required. Our cloud-based infrastructure provides excellent resilience against physical threats, such as bad weather and power interruption.
Recruitment
Jisc’s HR team ensure that all new employees are background checked through references and confirm their qualifications. Contracts for new staff and the induction process emphasize individual responsibilities for information security and the potential penalties for misuse. Staff resignations trigger a leaver process to ensure access rights to Jisc systems are revoked in a timely fashion.
Acceptable use
Jisc’s acceptable use of assets policy provides guidance and policies covering the acceptable use of Jisc’s information assets. It is issued to both permanent and contract staff and forms part of the induction for new starters.
Security awareness
Security awareness training is delivered through Jisc’s online training platform. It is delivered at least annually and is mandatory for all employees.
Risk management
An organization-wide risk management system is in place to identify, track, and manage risks that threaten Jisc’s ability to achieve its objectives. Risk is owned at board level and managed by the Risk Management team, with information security risks being specifically managed by the information security team. Their responsibility is to identify and manage relevant risks.
Google Cloud Platform (GCP)
Almost all of the OpenAthens applications and data are hosted on Google Cloud Platform (GCP). Google’s approach to security was a major factor in the selection of GCP as the hosting platform for OpenAthens. Google provides a secure infrastructure and continues to improve and develop their security tools.
GCP security overview
Google’s security approach for GCP is outlined in its security white paper which is available to you along with this document and it is also available from the GCP website. We recommend that customers read the document, as GCP is a key part of the overall security stance for OpenAthens.
GCP physical data center security
Google’s data centers include a range of measures to ensure only authorized users can access the sites. These include custom-designed electronic access cards, alarms, vehicle access barriers, perimeter fencing, metal detectors, and biometrics. The data center floor features laser beam intrusion detection and access is gained via a security corridor that uses multi-factor access control. All sites are monitored 24/7 and are patrolled by security guards. Less than 1% of Google’s staff has access to the data center floor.
GCP network and infrastructure
Google’s IP data network uses its own fibre, public fibre, and undersea cables. Transfer of data across the public internet is limited to reduce opportunities for data to be intercepted. Only approved protocols and services are allowed to traverse the Google network with non-approved traffic automatically dropped. All incoming traffic is routed through front end servers that detect and drop malicious requests and DDoS attacks.
GCP hardware
Google uses its own custom-built processors, servers, and network components that do not include unnecessary components that could be a source of vulnerabilities. Servers run a Google maintained, security hardened, Container-Optimised OS (COS). The location and status of all hardware components are tracked using barcodes and asset tags with metal detectors and surveillance cameras used to prevent unauthorised removal. A robust disposal process ensures all data is wiped at the end of a component’s life.
GCP operational security
Google uses a wide range of measures to scan and identify vulnerabilities and has a dedicated vulnerability management team responsible for tracking and resolving issues. It continuously monitors traffic to identify security issues and suspicious behaviour using both automated and manual inspections. Incident management procedures cover courses of action, notification processes, escalation, mitigation and are structured around the NIST guidance for incident handling.
OpenAthens
Infrastructure
With the exception of the EU portion of the OpenAthens managed proxy service, all OpenAthens applications run on Google Cloud Platform (GCP).
Our production, test, and development environments are run in separate projects within GCP, each with their own dedicated network and firewall. This ensures separation of traffic and data between projects and from other GCP customers.
Applications run in Kubernetes and Compute Engine virtual machines, both using COS instances, or GCP’s serverless technologies; AppEngine and Cloud Run. This approach minimizes the amount of server administration required by the OpenAthens team and therefore helps to reduce security risks. Google provides robust management of the underlying hardware infrastructure, and the latest, most secure updates are readily available and deployed. OpenAthens follows GCP recommendations for configuring and hardening its applications.
The data storage tier is a combination of GCPs managed SQL instances and Apache Cassandra. Both these platforms offer high availability.
Our managed proxy service provides access to resources that are not available in a SAML access management federation. This service is cloud hosted and geographically dispersed to provide improved response times to customers outside of the EU. For legacy reasons, EU customers of this service currently run on physical hardware in a UK data center. Our managed proxy service does not contain or transfer any personally identifiable data.
Networking
Data in transit
We encrypt all data in transit using a minimum of TLS 1.2, both from the users’ browser to the applications in Google Cloud and data moving between front end applications and databases over Google’s network.
Data at rest
All data stored in Google Cloud is encrypted at the storage level using AES256.
Web Application Firewalls (WAF)
We use a GCP network security tool called Cloud Armor, which monitors any activity, analyses any suspicious behavior and identifies how to respond.
Data
What data is stored and why?
OpenAthens stores personal data, but by default, it does not contain information that would be considered sensitive. A key GDPR principle is to minimize the data attributes required to only those that need to perform its basic function as a single sign-on service.
OpenAthens can be run by identity providers in either of two ways: Firstly, it can act as an organization’s account directory, ie. its store of user account data. In this instance, a username, email address, first name, and last name are required to create a user account.
Secondly, it can be used when a customer has an existing directory or authentication system. In this instance, OpenAthens can connect to that directory or authentication system and customers can map data attributes they want to transfer into OpenAthens. By default, only a unique identifier needs to be mapped in this second method.
In both instances, customers can configure OpenAthens to add additional data attributes. For example, to provide richer reporting capabilities or to enhance personalization features on some publisher websites.
Data exchange with Service Providers
OpenAthens shares a limited set of data attributes with its service providers as part of the authentication process. These data attributes are sent to service providers to authorize access to the relevant content. The required data attributes sent to service providers are both anonymous and unique to each service provider. Customers can configure OpenAthens to send additional information to service providers if required.
Data is exchanged using the SAML 2.0 standard and messages passed to service providers are encrypted and signed using XML cryptography and TLS.
Where data is stored
All live OpenAthens data is stored on GCP, and all personal data is stored within the Europe West region which is in London, UK. The data storage is a combination of Google’s fully managed relational database (Cloud SQL), and Apache Cassandra.
Backups and recovery
To ensure data can be recovered in the event of a failure we take daily backups and store a full relational backup in GCP. Data is additionally backed up offsite within a third-party cloud provider for further redundancy. Backups are AES-256 encrypted and are retained for a maximum of 30 days
Who can access data?
OpenAthens uses the principle of least privilege, therefore a small number of the OpenAthens team, with responsibilities for administering and supporting the system, have access to the production environment, databases, and user logging. This is strictly controlled by role and requires two-factor authentication to gain access.
Customer access to user data is only possible through OpenAthens applications using an administrator account. The data model defines a hierarchy of organizations which is the basis for our security model. At the highest level of each customer’s hierarchy, there is a unique domain administrator account that provides a logical separation between OpenAthens customers.
Where a customer has multiple organizations, each organization has a separate administrator account below the domain level account which provides logical separation of organizations within a customer domain. This model enforces the security boundaries by ensuring any domain or organization administrator is only able to access data for their own organization and those below them in the hierarchy.
There is no access permitted to higher levels of the hierarchy or between domains.
OpenAthens maintains a separate development and test environment. These environments make use of dummy data, so customer data does not interact with our non-production environments.
Applications
OpenAthens is made up of a series of applications that provide a range of supporting functions required to run the service. The core of OpenAthens is the authentication service that creates an OpenAthens session for end-users and administrators. The session allows access to online resources for end users and access to management tools for administrators.
User account security
Misuse
OpenAthens monitors user activity to detect potential misuse of accounts. There are several scenarios that constitute misuse, for example signing in to OpenAthens from different countries within a set time. If suspected misuse is detected the user account moves to a blocked status which prevents further use. The administrator for the account receives an alert to investigate, and they may remove the block if required.
Auditing
OpenAthens offers account auditing through the administration area user interface (UI). This allows administrators to see what events have occurred with an end user account and who actioned the event. They can also view the administrator events such as login and failed login events.
Reporting
An administrator can configure the reporting UI to show individual user logins. Customers using their own account directory can report on any attribute released to OpenAthens. The onus is on the administrator to ensure that any released attribute is appropriate to local data protection guidelines.
Account lifecycle
It is vital that personal data stored within OpenAthens meets the requirements for data privacy and protection. Part of that is ensuring personal data is not retained beyond what is necessary as defined in OpenAthens terms and conditions.
As outlined below there are two ways to provide users access to online content.
Lifecycle when using OpenAthens as a directory
When a customer uses OpenAthens as their directory, an administrator is responsible for the creation of accounts. Alternatively, where a self-registration scheme is used, accounts can be created by the user themselves via an online web form. When creating new accounts an activation process can be used to ensure the user’s e-mail address is confirmed as valid. All accounts are created with an expiry date which determines the point at which an account can no longer be used unless renewed. Accounts in an expired state are deleted from OpenAthens a set period after the expiry date, which can be configured by organization administrators.
Lifecycle for customer directories
When a customer is using their own account directory or authentication service, an OpenAthens account is created when the users first sign in. When the account expires in the source directory or authentication system, the user can no longer use their OpenAthens account. The account is deleted a set period after their last login date. This process ensures that OpenAthens remains in sync with the customer’s account directory.
Acceptable use
Customers must use the OpenAthens product in line with our terms and conditions and in any documentation referenced in our terms and conditions.
Contract termination
On termination of an OpenAthens subscription, the customer’s access is revoked via a status change in our account system. All customer administrators and user accounts within the domain are suspended and a 6-month cooling off period is put in place. At the end of this period, all data is deleted from the OpenAthens database. Within one month of deletion, all data is also removed from back-ups and logs.
Customers using OpenAthens as their account directory need to assign a username and password to each individual account. Length and complexity restrictions are enforced, and passwords are checked against a banned list to prevent use of common words or phrases. The nature of the service means that passwords do not expire. Requests to reset forgotten passwords result in a new activation link being sent to the account’s registered email address.
Product development and releases
OpenAthens aims to minimize the security risks associated with development of its products and services. As part of this, product development is the responsibility of a dedicated, in-house development team. Where contract staff are used, they work within the OpenAthens team and follow its internal standards and processes.
Our teams work to Agile principles and processes to achieve regular releases of new features and resolution of issues. Development sprints are currently every two weeks.
Security is a major consideration when developing new features. The impact on security and privacy is assessed as part of the planning process for each individual piece of development work. Team members develop in line with a defined architectural pattern, and all code is subjected to peer review assisted with static code analysis tools to highlight security issues as well as code quality.
Testers are integrated into the team ensuring all individual features and bug fixes are tested as soon as development is complete. When features and bug fixes are combined into a release, the release is tested in a dedicated environment using a mix of automated and manual methods. Security tools are used as part of this testing phase to identify issues against common CVEs and vulnerabilities, such as the OWASP Top 10 Risks.
When a release is ready it is passed through a formal change control process to provide appropriate levels of authorization. Post-release, applications are carefully monitored for any unexpected changes in behavior. Release notes are published in the OpenAthens documentation site to detail new features and issue resolutions.
Operational security
The day-to-day operation of OpenAthens is the responsibility of a dedicated in-house team supported by Jisc’s extensive operational policies and procedures. Using GCP, Google focusses considerable resource and expertise in maintaining and securing the underlying infrastructure. This enables the OpenAthens operations team to focus its efforts on managing the service itself.
OpenAthens is continuously monitored for service availability using both uptime and transaction-based checking. In addition to the protection provided by GCP and Google’s security command center, our team monitors for suspicious activity or unexpected patterns of traffic using manual and automated methods.
Patching
To ensure the infrastructure is up to date with the most secure versions available, all core applications are patched on a monthly cycle. The exception to this rule is if a security vulnerability is discovered that dictates an immediate response. In this scenario, emergency patching is carried out as soon as is practical. Much of OpenAthens runs in a container-based architecture where a restart automatically triggers an update to the latest available image. This enables rapid response to situations requiring immediate patching.
High availability
All applications and data are distributed across multiple nodes and the nodes are distributed across multiple availability zones within GCP, this ensures high availability of the service. The use of a container-based architecture further helps to ensure high availability. For example, applications automatically restart if they encounter issues and if a node fails it is removed from service and traffic is directed to the remaining ‘healthy’ nodes. Where appropriate, nodes are set to automatically scale to handle unexpected increases in traffic.
Regular service management meetings review the performance and future capacity needs of the service. The infrastructure enables implementation of horizontal and vertical scaling with significantly reduced lead times compared to a physical infrastructure.
OpenAthens continuously monitors its service availability against a service level agreement (SLA) of 99.95% for core services. For more details see the OpenAthens SLA document.
Penetration testing
OpenAthens undergoes penetration testing at least annually. Testing is carried out by an independent third party and any vulnerabilities found are added to the development backlog and addressed according to their severity classification. The service then undergoes a retest to check vulnerabilities have been cleared. Major product releases or releases introducing significant new functionality may be additionally penetration tested prior to release.
Incident management
OpenAthens has a dedicated service desk that handles all incoming incidents. Out of hours, a dedicated on-call team is on hand to cover service incidents, so there is uninterrupted cover. All incoming incidents are classified and assessed for impact and escalated accordingly. When a major incident occurs, an incident manager is assigned and takes responsibility for managing the incident through to resolution. All major incidents are followed up with a full report that details the incident, follow up actions, and an action plan. Service impacting incidents are communicated to customers via the OpenAthens status page.
Any incident related to information security or data privacy is additionally reported to the Jisc information security team and Jisc data protection team. The information security team provides support and operates additional specific processes required for managing security incidents, including communications with external agencies where required.