Expected documents

• Information Security Policy
• Privacy Policy, Data Protection / Data Access and Handling Policy
• Data Recovery / Business Continuity Plan

Questions and points to discuss and clarify

Here is a number of questions regarding security, data protection and privacy. The answers will allow us to better understand the maturity level of the proposed solution; how security risks are addressed in its development and operations; what intrusion protection, detection and response mechanisms are in place etc.

Please don’t strive for verbose, detailed responses. Short but factual answers are fine. Where applicable, answers pointing to existing and provided Information Security documents are strongly preferred. If we have any further questions after analysing the received documents and answers, we will just ask.

Documents - can you please share any such or similar documents that you already have established:

• Information Security Policy
• Privacy Policy, Data Protection / Data Access and Handling Policy
• Data Recovery / Business Continuity Plan

Authentication and access control:

• Can CERN SSO be enabled for CERN users (using SAML 2.0 or OAuth2 or OIDC (OpenID Connect))?
  • Which SSO authentication protocols are supported?
• Can non-CERN users authenticate with OpenID, or their Google, Facebook, LinkedIn etc. accounts?
  • Which 3rd party authentication providers are supported?
• Can 2FA be enabled for CERN users?
• Can 2FA be forced for different categories of CERN users (e.g. admins, users with a given role, etc.)?
• Can access for CERN admins be restricted to a whitelist of client IP addresses or IP subnets?
• Do CERN admins have access to user connection logs (time, source IP, username, etc.)? User activity logs?
  • What categories of logs are available to CERN admins?
• Can CERN admin block specific users?

Hosting:

• Where are data and services physically hosted? 
  • Under which jurisdiction?
• What about backups and disaster recovery?
  • Under which  jurisdiction?
• Who is the owner of the data?
  • Is it CERN?
• How are CERN’s privileges and immunities preserved?
  • Please find the protocol defining the CERN’s privileges and immunities here.

Development and operations:

• How are devops trained for security?
  • Is the training mandatory? Periodical or one-off?
• What technologies (OS; web, DB and application server; programming platform etc.) are used?
• Do developers have access to production instances or production data?
• How is the CERN instance isolated from other instances? (database, VMs, hypervisors etc.)
• Is there any WAF (Web application firewall) solution used? Which one?
• What DDoS protection measures are in place?

Security management:

• How is vulnerability management organised?
• Is there an established threat management process in place?
• Who performs penetration testing? Can reports (summaries) be made available?
• Is the CERN Computer Security Team allowed to perform pentesting (no DoS) on a test instance?

Intrusion detection and response:

• What IDS measures (host-, network-, and application-level) are in place?
• Will the Provider be contractually obliged to report to CERN any relevant security incidents?
• What categories of logs are collected?
  • How detailed are the logs?
  • Will CERN be able to request access to them if needed?

Points for the eventual contract

General points - to be decided by the legal service drafting/reviewing the eventual contract:

• ownership of data
• means in place to recover data at contract end
• geographical location and jurisdiction of data and hosting of services
• if and how security best practices should be required
• what penalties the provider faces in case of data leaks of customer data
• will the provider be contractually obliged to report to CERN any relevant incidents

Technical requirements:

• Integration with CERN Single Sign-On, using SAML2 or OAuth2 or OIDC (OpenID Connect).
• Automatic antivirus scan, with a good antivirus software using up-to-date signatures, of all documents uploaded by users. Quarantine or rejection of infected documents.
• Access (direct or upon request) for CERN admins to user activity, application-level logs for the CERN instance(s).
  • These logs should contain at least the following information for each action/access: timestamp; client IP address; name/id of the authenticated user; authentication method; action type (read/write/create/delete); type and id of the accessed document or object; and other relevant details.
• Easy direct access for CERN admins to the list of recent logins and password changes (both successful and unsuccessful) of a given user, including client IP addresses and authentication methods.