Informatiebeveiliging – acc

Informatiebeveiliging – acc

Maatregelen

Dit is het Security Control Framework (SCF) van de Universiteit Utrecht. Voor een uitleg voor medewerkers hoe dit raamwerk toegepast kan worden verwijzen we graag naar deze pagina op intranet. 1 keer per kwartaal kijken we naar de maatregelen in ons SCF om ze waar nodig te actualiseren, een overzicht van alle wijzigingen wordt voor UU medewerkers hier bijgehouden. UU medewerkers kunnen zich aanmelden voor deze updates via deze link. Heb je vragen, terugkoppeling of ben je van buiten de UU en zou je ook de updates willen ontvangen? Neem dan alsjeblieft contact op met informatiebeveiliging@uu.nl. De maatregelen zijn voor UU medewerkers ook als Excel-bestand beschikbaar, klik hier om die te downloaden. Selecteer aan de linkerkant de BIV van de proces of systeem om te zien welke maatregelen worden voorgeschreven voor een gepaste beveiliging.

IT services are offered with a specific security-capability level (Dutch: geschiktheidsniveau). The IT Security controls for that level are applicable to the IT service.
The security capability level of the IT service is documented in the IT service description and communicated to end users through the IT service catalog, so they can use appropriate services for their data processing activities based on classification.
Information Security Advisory ITS initiates verifications to see if IT services have correctly implemented the appropriate controls.

Handleiding

Organizationally owned assets are registered with their relevant lifecycle status, an asset owner (by role) and a classification of the information asset. At a minimum the following hardware and software assets used in the processing of information are registered:
• (portable) data storage
• media (including hardcopy)
• portable and fixed processing units
• connected peripherals
• network equipment
• user accounts
• operating systems
• packaging and administration software
• business applications
• scripts and automations
• certificates and keys
• suppliers
• physical locations relevant to the IT services (including datacentres

Handleiding

The topicality of registered information assets is checked yearly. Results of the checks are documented and stored.

At least once every 2 years potentially missing assets are located and updated.

Handleiding

Privileged Access involves all access that exposes more functionality than regular users have on any layer of the IT service infrastructure. Authorizations for privileged access are required to follow all principles governing authorisations from the Knowledge and Data Security controls, including Least Privilege (just-enough admin).

Privileged Access is just-in-time, meaning it is only used for when needed and regular user actions are not performed using the privileged account.

Privileged access is demonstrably limited to authorized personnel, an authorization matrix is available for this access.

Handleiding

Service account are only used when necessary for system authentication (no association with natural persons) or system-to-system authentication. The purpose of a service account always needs to be documented. Each unique application to service link should have a unique service account.

Service Accounts are never used to perform actions as natural persons.

Service Accounts are configured according to Least Privilege and, where used, have stronger password complexity requirements than regular accounts. Where possible passwordless authentication is used for service accounts.

Regular user account can only be used to automate tasks for the individual user and not for generic processes.

Changes to service accounts are performed according to 4-eyes principle. Service accounts are registered in the CMDB and have an owner.

Abuse cases of service accounts are identified. There is active security monitoring of service accounts with more privileges.

Handleiding

Accounts for privileged-personal use are separate from personal-non-privileged accounts. If a user needs privileged functionality, a second privileged account will be issued to keep the privileged and non-privileged activities separated.

Personal-use privileged privileges are Just-in-Time, meaning they are only provided when needed and the privileges are revoked after they are no longer required.

Handleiding

Privileged Access to IT services is orchestrated through a session management system.

Actions taken using privileged accounts are logged or recorded. These actions are reviewed (either sample-based or systematically).

Credentials to privileged accounts are not exposed to end users.

When passwords are used instead of cryptographic keys or passwordless authentication, passwords are rotated automatically (one-time-use passwords) at the end of the session.

Handleiding

There is a procedure to use Privileged Access Management in unpredicted and/or emergency situations when access to privileged accounts is required in unanticipated events (privileged or nonprivileged). Passwords are rotated every time when the break the glass procedure is carried out.

A Break the Glass (BtG) account is an account that is never used, unless normal way of access to the system is unavailable.

The CISO and Process Owners are informed of any usage of the break the glass procedure. The process owner approves use of BtG accounts.

Handleiding

Authentication for access using privileged accounts has multi-factor Authentication. This includes applications, systems, and networks.

Devices cannot be marked as ‘trusted’ for multi-factor authentication for privileged access.

MFA for privileged access with SolisID-based accounts is centrally managed, either through the use of a trusted IdP, or a stepping stone.

 

Handleiding

System owners are responsible for documenting all identified vulnerabilities in a dedicated register. The following information must be minimally captured:

  • Risk assessment of the identified vulnerability (Low, Medium, High, Critical);
  • Date of vulnerability discovery;
  • Current status of the risk (New, Resolved, Mitigated, Accepted);
  • Individual or entity that has accepted the residual risk;
  • Date by which the risk must be re-evaluated.

Vulnerabilities that are not expected to be remediated within 30 days should be recorded as exceptions in the vulnerability register. Should 30 days elapse without the exception being documented, it must be recorded as soon as reasonably possible thereafter.

Resolved vulnerabilities must be retained in the register for a minimum duration of one year.

Handleiding

 

Last updated: 13-11-2023

Vulnerabilities are treated based on the risk-estimate of found vulnerabilities according to the CVSS score of the vulnerability and their the estimate of the risk-context:

Risk-context UU Critical Medium High Critical Critical
High Low Medium High Critical
Medium Low Medium Medium High
Low Low Low Medium Medium
Low
[0-3.9]		 Medium
[4-6.9]		 High
[7-8.9]		 Critical
[9-10]
CVSS-Score of the vulnerability

For external suppliers, the risk-context is the highest of the AIC-ratings of the Security Capability Level (where Low = Low, Basic = Medium, Sensitive = High and Critical = Critical).

If CVSS-score is not yet available, a professional estimation is made based on the ease of exploitation, exposure of the vulnerability, observed exploitation internally and externally and the potential impact of the vulnerability.

Vulnerabilities need to be resolved depending on their risk-estimate and the following resolution times:

 

Risk-estimate Maximum resolution time
Critical 5 working days
High 1 month
Medium 3 months
Low Best effort

 

Handleiding

The organization has a published Coordinated Vulnerability Disclosure Policy to encourage security researchers and individuals to ethically find and report vulnerabilities.

Handleiding

Network connected IT systems are subjected to automatic vulnerability scanning based at least once per month.

Scanning occurs authenticated where possible.

 

Handleiding

(Web-)applications are subjected to (web-)vulnerability scanning. Depending on the classification of the application the interval of scanning is:

Basic: At least once every year

Sensitive+: At least once every 6 months

New and updated (web-) applications are scanned for vulnerabilities before going live or with major changes.

Recent scan reports are available.

Handleiding

Before go-live of new IT services, and after major updates and changes, a penetration test of the information security needs to be performed by a trusted party. A penetration test takes place at least once every 2 years.

The management summary should contain at least which party performed the test, when the test was performed, what the scope of the test was, the number of vulnerabilities that was found and their associated risks.

Found vulnerabilities must be handled according to IS.3.002.

 

Handleiding

Only supported software can be used. End-of-Life or End-of-Support software /hardware is not allowed.

For Sensitive and higher classifications: Additionally, any internally developed software must have a designated data management plan and a software management plan in place before it is deployed. These plans must outline the support responsibilities, maintenance activities, and the expected lifecycle of the software. Internally developed software can only be used if it is fully supported and maintained for its entire expected usage duration by the responsible team within the organization.

Software is tested and installed according to a documented and defined patch cycle.

System owners are required to proactively obtain information relevant to their systems to ensure they remain up-to-date with the latest security patches and updates. System owners must ensure that all updates are assessed for their relevance and impact on their systems and must schedule and apply patches and updates according to the change management process. External services must adhere to the same policy regarding update management (or a stricter one).

Unpatched systems will be treated in accordance with the vulnerability management process.

Handleiding

An emergency update is an unscheduled software update released to address critical vulnerabilities, significant bugs or major performance issues that cannot wait for the regular update cycle. A patch that is released on schedule but has a high risk if it is not deployed faster than the regular update cycle is also considered an emergency update. 

 After the deployment of the emergency update the normal update process is followed post-deployment. Stakeholders are informed, audit trails are created and change management process is followed retroactively. 

 A procedure for applying emergency updates should be in place. 

Handleiding

IT systems have standard configurations that follow recommended hardening guidelines.

Before new systems are taken into production, the systems are tested for adhering to the hardening guidelines.

The standard images are tested for security vulnerabilities during regular vulnerability management process and are updated accordingly.

Handleiding

Major changes and/or migrations that could have potential impact to the availability of the IT service need to have a rollback procedure and a step-by-step plan for the change documented on forehand and approved by the relevant change boards.

This rollback procedure can be requested.

Handleiding

All network equipment is documented and kept up-to-date with security updates.

Zoning information and access methods for the different zones are documented.

Handleiding

Networking maintains a list of approved hardware components and their required configurations. This equipment and configuration is approved by Security Operations ITS of the UU for use in production.

Networking hardware components are not accessible to unauthorized individuals.

Handleiding

Networks need to be segmented if they have different risk levels. This mitigates the risk of one intrusion spreading to other parts of the network.

Each network segment is separated by a (virtual) firewall.

Handleiding

The DMZ (demilitarized zone) is the network location for public-facing services.

Only systems in the DMZ can accept communications initiated from outside the network.

The DMZ is separated from the outside world and the internal network with Firewalls.

Only the public facing component of a service can be in the DMZ, data processing and storage must be in separate parts of the network according to the data classification.

Systems within the DMZ treat other DMZ systems as non-trusted.

Inside services verify requests from DMZ hosts to have the right source and authorization.

Handleiding

The network firewall is set up to protect hosts on the network against networkflows that are potentially insecure. The firewall is one part of a layered defense.

The firewall rules are set to default deny traffic and only rules are implemented that allow what is necessary for functionality as described in the architectural design.

All firewall rules are documented with a textual explanation of their purpose and a revision date. Firewall rules are revised on or before their revision dates.

Access to the firewall itself should be appropriately protected, has a safe configuration by default: filtering all traffic and not exposing administrative interfaces.

Firewalls log denied and allowed traffic for the purpose of investigating network problems or security incidents.

Handleiding

Network of IT services must be hardened against Distributed Denial of Service (DDoS) attacks.

Services are configured to avoid participating in DDoS attacks.

There is a documented procedure in the event of high network load (in the case of for example DDoS attacks).

Handleiding

Secure and up-to-date standards are used for networking protocols.

IPv6 is supported. Firewall rules applicable to IPv4 need to be replicated for IPv6.

Handleiding

Network Access Control is used to determine the level of access users and devices are given to the network. Unidentified users may get access to a guest network.

Access to certain networks requires at least both validated users and validated devices. Device authentication (preferred) or validation of its attributes (less preferred) proves the device is under organisational control and meets required specifications.

Authenticated users with managed devices can be allowed in the internal network after verification of the correct level of operating system, applications and endpoint protection.

Handleiding

Best practices for Network Naming Security are followed.

UU managed systems belong to one, UU managed, security domain.

DNS records only point to UU managed systems or partners through which we, by means of contractual agreements, have validated the information security and suitability.

Handleiding

Servers do not have direct access to the public internet.

Updates and licensing for production servers go through dedicated and product specific proxy servers for these purposes. Users can access internet, if needed through proxy services such as Citrix.

Handleiding

Critical systems reside in their own segment based on business function. Critical systems that form part of different IT services are (logically) separated into their own network segment.

Each network segment is separated by a (virtual) Firewall.

 

Handleiding

Logs contain standardized timestamps that are synchronized to a reference time source and contain an established time zone or the time zone is documented.

Handleiding

 

Logs for the audit trail need to be stored on a logging server that is not the source that generated the logs and is a dedicated server for managing logs. The IT service ideally supports logging to an UU managed central logging server.

The UU can ask for relevant audit logs for incident resolution. This can also take the form of a permanent, near-live, datastream to the centralized security monitoring solution managed by the UU. This is only required when the UU requests it, but can be requested as a feature at any time.

A retention period for logs is defined based on abuse cases and relevant business and legal requirements. It is recommended to work with rotating logs.

 

Handleiding

Applications log access (attempts) to data.

Applications log mutations of system configurations and sensitive data. Original values are recommended but not necessitated to be stored.

 

Handleiding

Authentication attempts are logged including originating IP and attempted user. Passwords are not logged.

Handleiding

Stored logs are appropriately protected from deletion, editing and unauthorized reading and writing.

 

Handleiding

Access to logs is in itself logged. These logs are stored separately and permissions to these logs are least privilege and separated.

 

Handleiding

Access to the UU network is logged and every action can be resolved to a user.

A purpose of logging network access is to assist in finding a machine/person identity when resolving an incident where a network identity (IP address) and a timestamp is available.

Handleiding

A documented plan exists for how to transition away from the suppliers needed for the IT service both at short notice and more gradual, to avoid vendor lock-in, when contracted services or products change to no longer suit needs or when in emergency situations the service does not offer sufficient capabilities

The exit strategy is revised every 3 years.

Handleiding

Emergency power to IT equipment is available or a hot-site connected to a separate power source is available.

Emergency power or the hot-site connection is tested once per 6 months.

 

Handleiding

The connection to the internet is redundant for all necessary connected equipment part of the service. There are no Single-Point of Failures (SPOFs) on any layer.

Providers can demonstrate this redundancy, and show that it is tested at least once a year.

 

Handleiding

A procedure is in place to throttle traffic from non-critical sources, to ensure continued minimal essential functioning of the service.

Handleiding

Datacentres used in IT service providing have measures in place according to Uptime Institute Tier II (or equivalent) or higher.

Handleiding

Datacentres used in IT service providing have measures in place according to Uptime Institute Tier III (or equivalent) or higher.

Handleiding

Event data is aggregated from multiple sources.

Accepted organizational risks are monitored through defined abuse cases.

Personnel security and awareness is monitored and periodically tested. This information can only be used for improving security and is never reported on a per-user identifiable level. Relevant privacy and security measures are taken to handle this information.

Handleiding

A list of relevant known IOCs is maintained and shared among industry peers.

A list of known malicious networking addresses is maintained for egress filtering.

Network flow monitoring is applied for detecting intrusions, denial of service, unauthorized actions and other relevant security purposes.

Handleiding

At least once every 2 years, potential abuse cases for the IT service are identified and revised.

Relevant monitoring for abuse cases will be implemented and the service owner sets the thresholds for possible alerts and organizes the follow-up.

Event data form multiple sources needs to be considered and correlated for the abuse cases.

Handleiding

There is security monitoring on organizational credentials appearing in (publicized) data-breaches.

If there are indications of compromise of passwords or risks the credentials of individuals are compromised, passwords will be forcibly changed and the users informed.

Handleiding

Intrusion Detection Systems are in place to proactively detect active attacks and attempts against critical IT services.

Attacks against the IDS are used to define new and improve existing abuse-cases and monitoring.

Handleiding

Red teaming is used to identify weaknesses in the security posture of the organization at least every 3 years.

Attack vectors and lessons learned are acted upon to improve the security posture of the UU (or supplier).

The CISO office and the DPO will be consulted prior to all red teaming activities.

Handleiding

A baseline for normal network and application packet traffic is established around critical IT services.

Network Intrusion Prevention Systems are used to dynamically detect deviations from the baseline.

Handleiding

Industry contacts with other Security Operations ITS and CSIRTs need to be maintained and relevant information regarding threat actors and vectors shared.

Handleiding

There is monitoring for CT-logs for certificates that seem to be issued to the organization.

Handleiding

There is monitoring for online presences that claim to be organizational but are in no way affiliated, including domains and email addresses.

Malicious actors will be blocked.

Hosting parties are asked to cease supporting the malicious activities.

Relevant authorities are engaged where appropriate and legal steps taken.

Handleiding

Attack vectors known to be used by Advanced Persistent Threats (APTs) are actively monitored. When the threat of APTs is active, appropriate personnel will get informed of the threat and what they can do to reduce the risks.

Handleiding

Regular end-users do not have the ability to modify systems privileged access to endpoints, including the ability to modify organisationally managed system settings, including making changes to environment variables, directly read or modify the registry, modify files in system directories or install programs.

Approved business applications are deployed through a centrally managed solution.

User workstations have protections to prevent them from leaving the organizational domain.

Privileged setting and features cannot be controlled using a non-privileged account.

Only users that have a demonstrable need for a local privileged account to perform their work activities can have access to a local privileged account. This access adheres to the privileged access controls, including just-in-time and is just-enough admin.

Handleiding

All endpoints (including desktops, laptops, mobile devices, and servers) must be kept up to date with the latest software, firmware, and operating system updates. This includes security patches, bug fixes, and relevant feature enhancements. 

A system is considered out of date if it has not applied the most recent security updates within 30 days of the release of the patches. 

Administrators need to stay aware of patches for their relevant software, firmware and operating systems. 

All software, firmware and operating systems in use must be supported by the vendors. If software is end of life it needs to be it needs to be dealt with according to IS.15.007. 

Important security updates must be able to be deployed to endpoint devices within shorter time frames depending on the risks. 

Endpoints that are lagging in security updates should not get access to sensitive or critical organizational data. 

Handleiding

BIOS access on organizationally managed hardware is password protected.

BIOS passwords are considered and treated as privileged access.

BIOS passwords need to be managed.

Boot from external sources disabled.

Handleiding

Data at rest must be stored encrypted

Handleiding

Last updated: 30-7-2020

Unless necessary for executing job responsibilities, user endpoints will by default not allow the execution of scripts and executables.

If the function necessitates this access, it will be documented and requested by the supervisor.

Technical specification:
Office Macro’s and Powershell are disabled by default.
It’s optionally granted when a valid motivation is provided.

Handleiding

Anti-malware tooling is present on endpoints.

Anti-malware software needs to be mature and effective. Tooling and malware definitions are kept up-to-date.

Peripheral devices are not allowed to auto-run content.

Handleiding

Endpoints need to have appropriate protections to prevent attacks on memory.

Handleiding

After a period of inactivity, on a managed workstation, the session/screen is locked and the user is prompted for authentication again.

Users must be trained to lock their screen when they step away from the workplace.

Handleiding

Sensitive data only resides in organizationally managed environments. This can include managed devices or managed containers on unmanaged devices.

Before sensitive data leaves the organization, official relations including agreements with the receiving party about data storage and handling exist.

Handleiding

Organizational data can be deleted from devices remotely.

Encrypted data to which the key is unavailable complies to this standard.

Handleiding

Shared workspace endpoints are physically protected from tampering with or removing the hardware.

Public workspace are reimaged daily and do not have autologon.

Browsers on public workspaces delete all cookies and session information when the browser is closed.

Handleiding

Data is not primarily stored on endpoints but in environments with appropriate capability levels.

Handleiding

 

On managed endpoints, the local firewall policies are maintained, reviewed and enforced based on business and security needs.

On unmanaged endpoints the host-based firewall should adhere to least privilege principles.

Handleiding

End-user authentication for applications takes place through a trusted Identity Provider (IdP).

The organisation has a defined relationship with individuals that have been given access, either directly or through contractual agreements with third parties.

Only production environments can be linked to production IdPs.

Handleiding

 

Last updated: 29-10-2021

Systems that allow setting passwords enforce that passwords satisfy minimum complexity requirements.

Rate-limiting is enforced for failed password entries.

From the data classification policy an account name has a classification of ‘basic’ while a password has a classification of ‘critical’. A hashed password has a classification of ‘sensitive’. These classifications are on the confidentiality axis.

During password creation, an indicator of password complexity is reported to the user. Easy passwords are prohibited. If initial passwords or reset passwords are assigned by the system or by operators, they need to be changed by the user upon first login.

Passwords to personal accounts are only chosen by the account owner. One-time passwords are exempt.

Every account has a traceable owner that is responsible for password maintenance on the account.

Technical specification:

Handleiding

PIN codes are a subset of passwords that usually have limitations to the complexity. Usage of PIN codes in place of passwords is only permitted in a one-to-one relation to physical access (to either hardware or locations). A PIN code is hardware specific, and where possible also user specific.

Biometrics can be used in place of a PIN code if processed on-device and can only be offered as an optional usability feature, meaning a PIN code must be set. Biometric authentication is also subject to rate limiting, and needs to adhere to the guidelines set in according to NIST Special Publication 800-63 section 5.2.3: https://pages.nist.gov/800-63-3/sp800-63-3.html#sec5. There is no central processing of biometric information and the use is always optional.

Handleiding

Passwords must not be visible during entry (other than at creation, when prompted by the user).

Passwords are not visible to anyone (including administrators), meaning they need to be hashed (using a unique salt per user) according to https://www.nist.gov/publications/secure-hash-standard or a superseding standard.

If passwords/secrets are stored, they must be stored in an appropriate password vault service.

Handleiding

Users need to use a second factor to authenticate before accessing sensitive data or functionality.

Users are allowed to mark devices as trusted, not requiring MFA on that specific device for a period of a maximum of 30 days for access, if the device meets all requirements for a second factor (such as being personal and meeting all hardware requirements).

Users can mark a maximum of 5 devices as trusted. Authenticated users can access an overview of devices they have marked as trusted and be able to remove the trusted status of a device.

Only ‘what you know’ and ‘what you have’ are considered factors for MFA.

Multi-layer authentication, twice the same authentication factor, is not MFA. Two-factor authentication is only two-factor when both steps are different factors.

Biometrics are not used as factors, but can be used as a usability feature in place of a PIN.
MFA-tokens used as factors are user-specific and measures are in place to safeguard that these tokens remain strictly personal.

MFA implementations confirm to at least MFA level 2 as specified.
● No distinction is made in location when it comes to MFA. There is therefore no difference between an internal- and an external network for MFA.

Handleiding

Users need to use a second factor to authenticate before accessing sensitive data or functionality.

Only ‘what you know’ and ‘what you have’ are considered factors for MFA.

Multi-layer authentication, twice the same authentication factor, is not MFA. Two-factor authentication is only two-factor when both steps are different factors.

Biometrics are not used as factors but can be used as a usability feature in place of a PIN.
MFA-tokens used as factors are user-specific and measures are in place to safeguard that these tokens remain strictly personal.

MFA implementations confirm to at least MFA level 2 as specified.

No distinction is made in location when it comes to MFA. There is therefore no difference between an internal- and an external network for MFA.

Handleiding

After a period of inactivity in an application, a user session should be locked or terminated and require re-authentication.

The duration of inactivity required to force a re-authentication event is determined by the maximum classification of the actions and data to which the user has access. If this is not clear or possible, the classification of the application itself will be used.

In applications with a security capability of critical closing the browser must invalidate the session on the application.

Handleiding

Administrators are able to terminate user sessions on applications in the event of compromised accounts or the immediate termination of individuals. This is preferably done through the application.

A procedure is communicated to the system administrators for executing the emergency session termination. Within 30 minutes of starting the procedure, the user’s session must be terminated. This includes cases where the supplier has to manually terminate a session. This procedure must be supported throughout opening hours (09:00 – 17:00 CEST 5-days a week).

Handleiding

 

Personal accounts belong to one specific natural person, but a natural person can have more than one account. Personal account ownership is never transferred or re-issued. This includes e-mail addresses.

After individuals have left the organization, their legal & natural identities are kept for a predefined period of time, based on business and legal requirements.

Digital access can always be traced to a unique individual.

Appropriate measures are taken to ascertain the identity of a natural person.

Handleiding

Trusted identity providers (IdP) must have a view for users to review their account activity that shows their latest login activity including when, from which location and which device they logged in. Users can report suspicious behaviour from this portal and are prompted to change login credentials when abuse is suspected.

Handleiding

Protections are in place to detect and prevent unauthorized user activity based on context and behaviour.

Handleiding

Security best practices from suppliers of authentication systems are followed and implemented.

Handleiding

Access Control is used to determine the level of access users and devices are given to UU services and resources. Access to these services requires both validated users and validated devices. Device authentication (preferred) or validation of its attributes (less preferred) ensures that the device is under organizational control and meets required specifications. Validated users with unvalidated devices may get access to a guest network or limited access to specific cloud services.

To enhance security and ensure appropriate access levels, users and devices are categorized as follows, with each category having different levels of access to our services and resources based on the compliance status of the device:

-Employees and students using centrally managed workstations.
-Employees and students using decentrally managed workstations.
-Individuals (employees, students, and guests) using ‘Bring Your Own Device’ (BYOD) devices.
-Individuals (employees, students, and guests) using BYOD devices that have been registered and actively monitored on OS version, patch level, AV status, and other specifications.

Handleiding

Access to IT systems is limited to authorized personnel according to the NIST Special Publication 800-53: https://nvd.nist.gov/800-53/Rev4/control/PE-3 .

Handleiding

Access to IT systems is limited to authorized personnel according to the NIST Special Publication 800-53: https://nvd.nist.gov/800-53/Rev4/control/PE-3 including the control enhancements.

Handleiding

Procedures for working in secure areas are in place and adherence monitored. The procedures include at a minimum rules regarding
• how and when access can be obtained by whom
• work should be supervised or checked
• no recordings can be made in secure areas
• how guests and contractors can perform their work activities
• rules regarding consumption of food
• emergency protocols and how any out-of-ordinary situations can be reported

Handleiding

Cables of supporting IT services run out of reach and sight. Inside buildings or outside underground.

Power cables and data cables run separately to avoid interference.

A mechanism for detection of tampering with cabling should be in place. Any tampering with cabling is treated as a security incident.

Handleiding

Equipment needs to be maintained according to the supplier suggested maintenance guidelines and schedules.

There is a maintenance schedule for each piece of equipment.

There is a registration of known physical deficiencies and performed maintenance work on hardware.

Repaired and/or serviced equipment is inspected before being put into production again.

Handleiding

Access to Secure areas is monitored and audited. This includes at least (sample-based) checks on audit logs of card readers and reviewing camera footage.

Handleiding

For the IT service the Recovery Time Objective (RTO) is defined and communicated. The RTO is the maximum amount of time the service can be unavailable before significant impact is incurred.

The Recovery Point Objective (RPO) is defined and communicated. The RPO is the maximum amount of historical data that can be lost before significant impact is incurred.

For the IT service, the availability and backup measures safeguard that the RTO and RPO are protected by default.

The RTO and RPO for the service are actualized annually.

Handleiding

Restores of backups are tested at least annually and the results of the test are documented.

Handleiding

Data critical to the operation of the IT service is periodically stored on offline backups.

Offline backups are kept in secure locations and there are procedures in place for restoring and (re-)moving them.

Offline backups are kept geographically separated from the IT source of the backup.

All data necessary to continue operation of a service in case of an incident, are in accordance with the agreed recovery time objective (RTO) and the recovery point objective (RPO). This also includes a test, that successful restoration is possible.

Handleiding

The uptime percentage, the backup interval and backup retention periods are clearly communicated to users of the service.

Handleiding

A disaster recovery plan needs to be present for potential disaster scenario’s that could affect the availability of the IT Service.

The disaster recovery plan is reviewed at least annually.

The disaster recovery plan needs to be periodically tested. This can be (through tabletop readings or simulations , simulations, parallel test or full interruption), at least once every 2 years. , and a full parallel test or full interruption test at least once per 5 years.

Handleiding

All environments (Development, Test, Acceptance, and Production) must be clearly distinguishable, for example through different color schemes.

Limit access to development, testing, and acceptance environments based on the principle of least privilege.

On-premise and IaaS/PaaS environments
At least distinct environments for acceptance and production must exist. Where development activities occur, at least one distinct environment for development must be in place.

Each environment should be utilized strictly for its intended purpose. For example, the development environment should only be used for development activities, the acceptance environment for acceptance testing, and the production environment should only be used for deploying finalized, accepted changes.

Privileged access to the production environment must be strictly separated from privileged access to other environments.

Authentication to non-production environments should not occur through the production Identity Provider (IdP).

The acceptance environment must mirror the production environment as closely as possible, with the exception of not being publicly available.

Changes to the production environment must first be tested in the acceptance environment.

SaaS environments
Ensure that Service Level Agreements (SLAs) or equivalent contracts with the SaaS provider specify requirements for uptime, data integrity, and security measures.

From an information security perspective, having an acceptance environment is not mandatory for SaaS solutions. However, if an acceptance environment is procured for functional reasons, all stipulations concerning On-premise/IaaS/PaaS environments, as outlined above, must apply.

Handleiding

No production information (o.a. sensitive production data, API keys, credentials, production server hostnames, …) is exposed or reused in environments other than for acceptance testing.

Handleiding

Last updated: 4-2-2021

Test results in acceptance are logged and kept for at least 1 year.

Sign-off on a change is documented before go-live.

4-eyes principle is applied to changes.

For major changes, rollback procedures are in place before the change is applied.

Technical specification:
–

Handleiding

Developers are demonstrably familiar with secure coding practices.

Handleiding

During development, static code analysis software is used to detect potential security design flaws.

Handleiding

Appropriate secrets management is applied to confidential information needed to develop and deliver the service.

No hardcoded credentials and configurations are present in source code but only in separate configuration files with appropriate security protections.

No sensitive information can be found in versioning information and older releases in version management systems. Configuration should be stored in environment variables or in versioned scripts that generate the configuration based on user input.

Handleiding

Last updated: 28-4-2021

Security updates to software are not part of the normal release cycle for features but instead are released for currently supported versions of the software so they can be installed without functional testing.

Appropriate security is part of the core premise of any service and fixing security issues shall not only be done on the request of clients.

Technical specification:
–

Handleiding

Only data owners have access to their data. Administrators and suppliers can only technically access the data through a break-glass procedure that involves business sign-off and consultation with the UU.

Handleiding

The most common sources of dataleaks using corporate email are identified, and protective measures are in place to detect and prevent them, requiring extra prompts and automatic detection of potential leaks.

Handleiding

Automatic forwarding of corporate email to an external address is prohibited.

Handleiding

There are measures to prevent users from downloading entire datasets. Additionally, or if these measures cannot be implemented, alerting and monitoring for users downloading large amounts of information from the service is in place.

Handleiding

Applications and services are configured to not display information that is unnecessary.

Functionality is designed and configured to prevent enumeration of information.

Handleiding

Printing services are appropriately protected to make sure information sent to printers is protected against unauthorized access.

Handleiding

AI tools do not use production data, including user prompts, to (further) train the underlying AI models. This also prohibits the entry of data (including questions from which sensitive matters can be derived) with confidentiality ‘1. Basic’ or higher in tools where it is not explicit that this data may not be used.

AI tools are only allowed if they assure the UU that all UU prompts and answers are not used to train the model. Models trained on UU training data may only be used within the context of the UU.

Handleiding

To ensure the confidentiality and integrity of UU data, only devices and services that have been explicitly approved within UU and comply with the relevant provisions in the Security Control Framework (SCF) are permitted to access data and systems authenticated via the UU Identity Provider (IdP).

This policy applies to both physical devices and external (cloud) services that authenticate via the IdP and subsequently gain access to applications, communication platforms, or other institutional resources. Access is limited to approved services and to devices that meet the required security posture for the requested data and functionality.

Non-managed devices and services that do not meet these requirements are not permitted to establish access through the IdP, preventing unauthorized or uncontrolled data exposure.

Handleiding

Last updated: 28-4-2021

Applications need to implement session timeouts and verify against the Identity Provider if the User still has a valid session.

Technical specification:
Sessions are managed according to NIST Special publication 800-63 Section 7.1 https://pages.nist.gov/800-63-3/sp800-63b.html.

Handleiding

All variable information that gets sent by a client is filtered and sanitized before processed in the application. The same applies to user-chosen output that is presented back to users. This avoids any unintentional side-effect of processed data.

Handleiding

Web applications have taken all appropriate measure to protect against OWASP top 10 Web Application vulnerabilities: https://owasp.org/www-project-top-ten/

Handleiding

Mobile Applications use certificate pinning to prevent MitM attacks on apps and Open WiFi.

Mobile applications have protections for the binaries that users can download.

Mobile apps preferably store information encrypted and containerized.

Sensitive information must be stored server-side unless specifically needed for functioning of the application.

Handleiding

The application has taken application level steps to prevent Denial of Service attacks such as caching where possible, CAPTCHA, rate limiting and designing functionality to be non-blocking..

This includes protecting API endpoints against executing requests that could lead to DoS, limiting upload field data size and locking out users through reset functionality.

Handleiding

Any central system, application or server, that stores and serves files or links to users shall scan attachments, uploads and links for malware and block access to content identified as harmful by these scans.

Workstations that process these sorts of content also scan for malicious content, controls are based on IS.8.006.

Handleiding

A documented risk analysis is available for each third-party app used by the application.

Third party apps and libraries are tracked for vulnerabilities and security updates as part of the main app.

Handleiding

Authorisations are preferably centrally managed.

Handleiding

Default Passwords on any piece of hardware or software are changed before it is deployed.

Handleiding

Assets should be hardened. The attack surface should be reduced where possible, through minimalization, least privilege and effective use of available controls.

Handleiding

IT services run in their own virtual environments, vulnerabilities in one service cannot give access to other services. This includes no multiple websites on the same webserver unless they share the same Security Capability Level and purpose, the same applies to databases between different services.

Handleiding

Servers used in delivering the IT service only allow whitelisted executables.

Where possible, the integrity of executables is confirmed using integrity hashes .

Handleiding

Peripheral devices, such as USBs, are validated by separate systems designed specifically to validate the security of the devices. Only after this validation can these devices be inserted into hardware used to deliver the IT service.

Handleiding

Storage disks have appropriate FDE enabled equivalent to endpoint protection, or appropriately secure datacentre security controls are in place to prevent removal of storage devices.

Handleiding

Legacy Systems are systems that are End-of-Support (including no longer supported through ‘extended support’).

Legacy Systems that need to be maintained are kept as isolated as possible and are segmented only with other legacy systems they need to interface with. Access to non-legacy services occurs through secure Bastions. Security of production services is not downgraded for compatibility with legacy systems. Legacy systems have no access to the internet.

Where possible Legacy Systems are virtualized.

Where possible complete system images and backups are available for legacy systems.

There is additional security monitoring for Legacy systems.

Handleiding

Last updated: 30-7-2020

After the retention period or when the data medium is decommissioned, lost or repurposed, organization data is deleted.

End users receive sufficient warning before data is deleted.

Technical specification:
Deleting takes place according to NIST Guidelines for Media Sanitization for the level of ‘Clear’ or higher: https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final

Handleiding

When the data medium containing data that might be classified with confidentiality of Critical is decommissioned, lost or repurposed, that data needs to be purged.
Destruction of encryption keys is considered equivalent to data purging.
A declaration of data purging must be demonstrable on request.

Handleiding

All data in transit is encrypted.

Handleiding

The IT services send emails to end-users using an email address ending in a top-level domain for which the organisation is legally responsible.

Handleiding

Mailservers take measures to prevent the reception and transmission of spam and malicious mails.
Mails should be revocable on managed servers and supported endpoints.

Links in emails should be validated to not be malicious.
Mailserver reputation is monitored. Thresholds are determined and actions are taken to improve the reputation if it falls below thresholds.

Handleiding

Mail can only be sent by the owner of the mailbox or explicitly authorized individuals. All mails and actions are traceable to the individual.

Handleiding

Domain names reserved for organisational purposes cannot be released shortly after the domain name is no longer needed.

A list of domain names that can never be released needs to be kept.

Domain names not on this list need to remain reserved with a placeholder message that the domain is no longer in use by the organisation for 3 years before they can be released and used by other partie

Handleiding

Communication coming from outside the organisation needs to be clearly marked with warnings that the originating party is from outside the organisation. This includes electronic messages received in email programs.

Handleiding

An incident response process for dealing with incidents in IT services is in place
The incident response process has processes for dealing with security incidents
Security incidents are escalated appropriately.
Security incidents are evaluated.
Information on security incidents is handled on a need-to-know basis.
Security incidents involving personal data are also seen as possible data breach and handled accordingly.

Handleiding

The UU has a Computer Security Incident Response Team (CSIRT) handling IT security related incidents

The CSIRT is mandated to respond to active threats and to take all necessary measures to limit the impact of ongoing or potential security incidents.

Handleiding

There is a protocol in the event of (suspected) data-breaches when it is appropriate to involve law enforcement and through which channels. This protocol is approved by the CISO and Legal Affairs.

There is a protocol for dealing with questions from law enforcement.

Handleiding

After suspected data-breaches, digital forensics are applied to targeted systems to determine the extent of the potential breach, actors, to recover data and logs and determine attack vectors.

Handleiding

The organization should have policies in place that allow for anonymous reporting of incidents and guarantees that reporting incidents never negatively reflects on individuals.
The official receiving party of incidents do not divulge personal identifiable information of the reporter or their named sources to parties that are not explicitly authorized to have this information.
Only if demonstrably necessary for the resolution of incidents the identity of the reporter may be shared following least privilege principle.
The identity of the reporter can be shared with specific individuals if the reporter freely consents to this information being shared to these people.

Handleiding

Terms of Use for Information Technology Assets and Services are agreed to by employees, that include secure and safe usage of organisational equipment and data. There is monitoring on adherence to the Terms of Use.

If Terms of Use are not followed, the usage of the IT assets and services can and should be suspended until the associated risks are addressed.

Handleiding

Manuals and Operating Procedures that detail how to work with Information Systems and Services in a secure manner are available, communicated to end-users and there is monitoring on whether these instructions are followed and understood. Appropriate measures are taken when operating procedures are not followed.

Handleiding

Certificates for Transport Level Security (TLS) are registered with at least: for what service it was issued, what the owning group is including contact information, expiration date and technical details of certificate.
There is a process for requesting and revoking official certificates. Requesting and approving certificate requests are separate roles. The organization selects approved certificate providers..
Users receive warnings when their certificates are about to expire.
The private keys for certificates must be stored in a password vault with encryption and MFA, other than on systems where the certificates are actively used.

Handleiding

If there is any indication that a system is potentially compromised, current certificates have to be revoked, new private keys generated and replacement certificates requested based on the new private keys. Clients check whether certificates have been revoked as part of the certificate verification.

Handleiding

There is a documented procedure for dealing with situations in which mass replacement of TLS certificates is needed. The target is to return to a normal situation with valid certificates as soon as possible.

Handleiding