Informatiebeveiliging

Informatiebeveiliging

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.

Last updated: 4-2-2021

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.

Technical specification:

Handleiding

Last updated: 13-11-2023

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 clearly communicated to end-users, 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.

Technical specification:
The Security Capability Level is expressed as a Classification for Availability, Integrity and Confidentiality. The score indicates what the maximum level of classification of a processing activity can be that uses this IT service.

The Security Capability Level is determined by following the steps listed at: https://intranet.uu.nl/geschiktheidsclassificatie-voor-it-dienstaanbieder

Handleiding

Last updated: 3-8-2021

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)

Technical specification:
A Configuration Management System is used, where individual Configuration Management Databases (CMDBs) are integrated into a holistic overview of IT assets. The dependencies between assets are registered. It’s easy to see the impact on other assets, when a specific asset goes into maintenance

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
An asset management audit process is in place and executed yearly, the results are administered in a GRC tool.

Handleiding

Last updated: 28-4-2021

Privileged Access involves all user 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.

Technical specification:
Authorisation is based on separation of duties and least privilege. Applications must apply separation of duties. Roles are defined based on tasks, responsibilities and privileges. Extra attention must be paid to accounts with the highest privileges.
The application supports role based access management, which is also configured.

Privileged assets are managed using a PAM tool. Changes are administered using a CMS/ITIL tool.

Logisch toegangsbeveiligingsbeleid https://intranet.uu.nl/system/files/20190829_-_logisch_toegangsbeveiligingsbeleid_versie_2.1_2019.pdf

Handleiding

Last updated: 4-2-2022

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.

Technical specification:
Password domain policies are configured for the various roles of service accounts. Every supported platform has a device management tool to check and enforce the policies automatically.

Where passwords to service accounts do need to be stored, the UU password policy is applicable to service accounts with the following exceptions:
• Minimum of 20 characters
• Password rotation at least every 2 years
Stored in a password vault with encryption and MFA
• When individuals that had access to service accounts change their employment with the organization, service account passwords they had access to need to be rotated

Handleiding

Last updated: 21-04-2023

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.

Technical specification:
Privileged accounts are centrally managed.
MFA is required as defined in IS.2.006.

Personal privileged accounts must make use of the UU password policy for personal privileged accounts as defined in IS.9.002.

If a privileged account has not been logged into for a year, it is disabled. It can be re-enabled by request and only after re-identification of the user.

In the UU there are three types of personal privileged accounts:

• Workstation admin accounts

• Can only login to workstations

• Server admin accounts

• Can only login to servers

• Application admin accounts

• Can only login to applications.

A user might have the need for more than one of these. They are split for risk mitigation. When one type of privileged account is compromised, it limits the effects a malicious party can have on UU services.

It is allowed, for reasons of security like conflict of interest or separation of duties, to split privileged account types into subtypes. For example a domain administrator needing a separate domain administrator account and another account for server admin work.

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
One can request a connection to Splunk to realize central logging and auditing.

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
BtG accounts need to have the following setup:

-MFA should be disabled
-Password length should be at least 16 characters
-The BtG accounts are not federated
-The password shall not expire
-The password is split in two and stored, in sealed bags, in two different physical locations.
-The sealed bags are stored in fire-resistant vaults.
-Access to the vaults is set up that not a single person has access to both vaults.
-At least two people should have access to each vault.
-The rest of the password needs to adhere to the passwords requirements, as described in IS.9.002.

The following activities of all BtG accounts are logged and should be monitored by UU ITS Security Operations:

-Password changes
-Usage of the accounts
-Modifications of the rights of the accounts

BtG account passwords are changed when:

-The account is compromised
-The account is tested or used
-Someone with permission to view a half of the BtG password loses permission to access the password

The BtG accounts are tested every 6 months.

Any usage without approval of the process owner of the BtG accounts is reported to CERT-UU as a security incident. This is usually done by UU ITS Security Operations, the application owner or the process owner.

Handleiding

Last updated: 21-04-2023

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 is centrally managed.

Technical specification:
The standards for MFA for privileged access adhere to the technical specifications from IS.9.005 – Multi-Factor Authentication with the following additions:

Privileged access to ‘sensitive’ systems, applications or networks requires at least level 2 MFA. Privileged access to ‘critical’ systems, applications or networks requires level 4 MFA.

The MFA device must be dedicated to privileged access only. In the case of level 2 this means a separate code for non-privileged and privileged access and no option to accept an incoming MFA request. In the case of level 3 and 4, this means one hardware token/YubiKey for non-privileged access and one for privileged access.

Handleiding

Last updated: 13-11-2023

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

Technical specification:
Technical details of vulnerabilities are considered ‘sensitive’ on the confidentiality scale. The details should thus be stored and processed in systems that apply all the security controls for ‘sensitive confidentiality’ as described in this SCF.

For systems that are internal to the UU network UU ITS – Security Operations can be contacted to help detect vulnerabilities and create a list of vulnerabilities in systems through their vulnerability management services.

For systems that are external to the UU network, agreements need to be made with external suppliers for actively detecting and remediating vulnerabilities. The UU must be informed when systems are exposed to high risk vulnerabilities for more than a week. The UU is informed, in a timely manner, when patches for these vulnerabilities are implemented.

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

Technical specification:
Total number of assets per CVSS level per faculty is reported on a monthly basis also trends of the past 3 months are reported.

Handleiding

Last updated: 30-10-2020

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

Technical specification:
UU responsible disclosure:
https://www.uu.nl/organisatie/it/verantwoorde-openbaarmaking (NL, leidend)
https://www.uu.nl/en/node/1599/responsible-disclosure (EN, translation)

For external suppliers the policy should be in accordance with the guidelines of the Dutch National Cyber Security Centre (NCSC): https://english.ncsc.nl/publications/publications/2019/juni/01/coordinated-vulnerability-disclosure-the-guideline..

Handleiding

Last updated: 4-2-2021

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

Scanning occurs authenticated where possible.

Technical specification:
Security Operations ITS of the UU will specify, maintain and publish requirements and approved tooling for vulnerability scanning.

System owners can ask for access to administer detected vulnerabilities. All production servers in UU network must be connected to this central scanning solution.

Handleiding

Last updated: 4-2-2021

The (web-)application is subjected to automated vulnerability scanning at least once per quarter.

Scanning occurs authenticated where possible.

Technical specification:
Security Operations ITS of the UU will specify, maintain and publish requirements and approved applications for vulnerability scanning.

Handleiding

Last updated: 21-04-2023

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.

Technical specification:
ecurity Operations ITS of the UU will specify, maintain and publish requirements and approved trusted parties for performing penetration tests.

Security Operations ITS of the UU is informed and consulted for all penetration tests on (parts of) the UU network or systems.

For externally performed penetration tests, Security Operations ITS of the UU will require the management summary of the results and follow-up. Security Operations ITS of the UU will determine and advice on remediation actions.

Handleiding

Last updated: 30-7-2020

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

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

Patching takes place in accordance with the change management process.

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

Technical specification:
–

Handleiding

Last updated: 30-7-2020

Software Updates including security patches are tested and installed at first opportunity. Unpatched systems will be treated in accordance with the vulnerability management process.

Technical specification:
Security Operations UU declares when an update is an emergency update.

This includes when no patches are available yet, and mitigating actions can be taken in accordance with UU Security Operations.

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Hardening or security guidelines by the supplier are followed. If guidelines of supplier is absent or insufficient, third party guidelines should be used.

OR:

The most recent version of the CIS Benchmarks are taken into account when configuring devices or operating systems. L1 controls are implemented. If a control cannot be implemented because of business reasons, the exclusion and the reason(s) is/are documented.

Handleiding

Last updated: 28-4-2021

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.

Technical specification:

Handleiding

Last updated: 30-7-2020

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

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

Technical specification:
–

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Switches do not operate in promiscuous mode.

TACACS+ is preferred over RADIUS as a means of authentication.

SNMPv3 Community strings and passwords are managed as part of privileged access management and thus rotated when there have been changes in the roles or employment status of anyone with access to them. The use over SNMPv2 is prohibited.

Anti-spoofing protection is in place, such as IP Source Guard (CISCO), Port Security, DHCP snooping and Dynamic ARP Inspection.

Handleiding

Last updated: 21-04-2023

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.

Technical specification:
Traffic between different segments needs to go via a network firewall with stateful firewalling.

Traffic trying to circumvent these measures must be dropped.

Also see IS.4.011 for systems with critical classification.

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
Use a stateful firewall between the outside world and the DMZ, and between the DMZ and backend services or storage. Configure the DMZ host to only run services it needs for or in support of the public function. Configure the local and network firewalls to minimize exposure of management functions

Management of a DMZ host has to happen via a bastion host, not directly from the outside world.

Connections from DMZ hosts to the inside need appropriate levels of encryption and authentication with a non-personal privileged account.

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
Firewalling is stateful by default: traffic that is in response to or clearly to an already allowed connection is allowed.

IP source routing information is not allowed.

Traffic with the Firewall as destination must be blocked for traffic other than intended administrative tasks.

Traffic with invalid source or destination addresses should must be dropped.

Firewall rules are kept synchronised for IPv4 and IPv6

Broadcast destination addresses aren’t forwarded

Firewall performance should be sized according to SLA goals

Follow best practices in https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf “NIST Guidelines on Firewalls and Firewall Policy”

Handleiding

Last updated: 4-2-2021

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).

Technical specification:
The (D)DoS protection of a preferred supplier is used.

No open DNS resolvers, NTP amplification

Blocking of broadcasting requests to internal IP addresses originating outside of the network

Routers with Access Control Lists

Configure BPDU guard against Spanning Tree Attacks

Rate-limiting is applied either consistently or dynamically to substantial and potentially malicious traffic

Load Balancer

TLS offloader

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Where WiFi is used, it uses at least WPA2 Enterprise or more modern standards.

In lab environments, appropriate configurations of networking protocols such as NFC, Bluetooth, Zigbee & Modbus are used that meet business and security requirements.

Handleiding

Last updated: 13-11-2023

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.

Technical specification:
The identity to use for network access, in order of decreasing trust level:

  • Machine authentication (certificate verification)
  • User authentication (certificate verification, password verification)
  • Physical location on the network (which port on the network)
  • Machine hardware identity (ethernet mac address)

 

Additional conditions for access control decisions:

  • Patch level of operating systems, relevant applications and endpoint protection system

This decision can be made either based on a lookup of the verified machine identity in the configuration management database or by communication with a trusted agent on the system. Machine identities can only be considered verified based on a trusted certificate.

Trusted machine identities are managed by selected identity providers, through a vetted process. Machine identities are only provisioned on validated, managed devices that meet all requirements.

Base protocol for access control is IEEE 802.1x to establish machine or person identity.

IP addresses are not a reliable means of authentication and should only be used in access control as a last resort

The fallback option for unauthenticated users or devices should be to allow minimal network access to means of remediation including updates of operating systems and endpoint protection.

A deep dive is available https://solisservices.sharepoint.com/:w:/s/10824/ERt_S-UFdwZJhRWo4HmYEFkBC0qAgIbu0eawk1cu7HyshQ

Handleiding

Last updated: 13-11-2023

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.

Technical specification:
Network naming uses the DNS protocol. DNS implementations follow the accepted Internet RFCs describing the protocol and implementation.

DNS service is monitored for availability and correctness.

DNS implements need-to-know when answering requests, this means:

DNS servers only allow zone transfers between authorized DNS servers.

Obsolete records are deleted after an appropriate amount of time.

Information in network naming which has no functional need is not published. This means DNS HINFO and DNS LOC records or other types that have limited current use but do give out information are removed.

DNS information which has limited scope is only accessible within that scope. This means DNS views are used to limit access to internal information. Make sure restricted and unrestricted clients get a consistent view of DNS information.

DNSSEC is implemented for DNS zones owned by the UU.

Sensitive or higher services must implement DNSSEC and DNS answers should be validated

Domain registrations are protected against unwanted transfers or expiration.

Records pointing to resources outside organizational control are reviewed periodically (at least yearly).

Handleiding

Last updated: 28-4-2021

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.

Technical specification:
–

Handleiding

Last updated: 21-04-2023

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.

Technical specification:
Traffic between different network segments needs to go via a network firewall with stateful firewalling.

Traffic trying to circumvent these measures must be dropped.

Equipment which is not part of the network infrastructure and has multiple interfaces, must be configured in such manner that routing or forwarding is not possible between interfaces. This is also required for VPN interfaces on a system.

Handleiding

Last updated: 13-11-2023

Public incoming network traffic into the University of Utrecht is restricted and only permitted under specific conditions. To regulate this process effectively, network ports and services are categorized as follows:

Network Ports / Services explicitly permitted:

This category comprises communication channels that are considered to be of low risk and are therefore explicitly permitted. Examples include standard communication ports, commonly used for general online applications. Risks associated with these ports are well-understood and are mitigated through established security protocols.

Network ports / Services that may be opened upon approval:

These are less commonly used ports that faculties and departments may request permission to open. These ports have been pre-evaluated to align with the university’s risk tolerance for low-risk communication.

Prohibited network ports / Services:

All other ports and services fall under this category and are considered to be of higher risk. This includes ports used for remote access functionalities, such as terminal sessions or remote desktops. Due to the elevated risk levels associated with these ports, incoming traffic to these is strictly prohibited unless a specific exception has been granted.

Technical specification:
Technical explanation and the current list of ports in each set are maintained by Security Operations ITS and is documented in the Deep dive – Incoming network ports.

Handleiding

Last updated: 3-8-2021

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

Technical specification:
NTP or NT5DS is used to synchronize computer clocks to a central timeserver slaved to a GPS receiver or other source of time traceable to the international UTC time standard.

Log timestamps are in the local time zone (with correct DST handling), or in ISO 8601 notation to allow correlating log entries with other logs

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
Logs contain at least:
• A timestamp
• User ID
• The originating system of the log
• The activity performed

Logging data retention is 6 months for security incident handling. Logging retention for the purpose of normal operational activities is 2 months maximum.

Handleiding

Last updated: 29-10-2021

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.

Technical specification:
Mutation and data access logs adhere to all logging rules as defined in IS.5.002.

Handleiding

Last updated: 28-4-2021

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

Technical specification:
AD Security audit log central policy enabled.

Handleiding

Last updated: 3-8-2021

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

Technical specification:
Logs are ‘read-only’ by default.

Permissions on log files can only be changed by privileged users.

The privileged users of the log file server(s) cannot be the same users as the system the logs are originally from.

On linux-systems log files have the append-only flag attribute. Conse33quently, to limit removal of the append-only flag, the capability CAP_LINUX_IMMUTABLE must not be set on the log file. A log rotate account is allowed to have the capability. Access to the log rotate account should be limited to privileged users only.
On windows-systems the default protections of the windows event log format should be in place. This means: Have windows event logging turned on and have it log relevant events. The windows event log does not allow for deleting of the logs without an event being written that states it was deleted. Limit access to this ability to administrator level accounts only.

Handleiding

Last updated: 3-8-2021

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

Technical specification:
At a minimum the following information is logged:
• What user accessed a log
• When was the log accessed
• From what device (MAC) was the log accessed
• What IP was the log accessed from

Users with privileged access to logs cannot have privileged access to the logs of log access. Privileged access is editing, creating and deleting of the logs. Reading the logs is not considered privileged access, but should adhere to least privilege principles regardless.

Logging of log access retention is 6 months.

Handleiding

Last updated: 21-04-2023

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.

Technical specification:
The following elements should be logged:

Network authentication (802.1x, wifi or other logging for identification, authentication and authorization used to access the network)

Translation between network identity (IP address) and mac address (ARP for IPv4, NDP for IPv6)

Location on the network (physical ports for wired network, used access points for wireless)

Network access logging has timestamps which can be used in correlating events. This means clocks are synchronized and the timezone of the logging is clear.

The logging is retained for the purpose of network management for 1 month and for the purpose of security monitoring for 6 months.

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Dual power supplies (A+B feed). N+1 redundancy: system will work with 1 power supply missing.

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Separate fiber paths, multiple routers, fas

Handleiding

Last updated: 30-7-2020

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

Technical specification:
Integrate QoS in network design.

Handleiding

Last updated: 30-7-2020

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

Technical specification:
–

Handleiding

Last updated: 30-7-2020

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

Technical specification:
–

Handleiding

Last updated: 29-10-2021

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.

Technical specification:

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
–

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Magma framework

Handleiding

Last updated: 13-11-2023

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.

Technical specification:
Implement logging and monitoring mechanisms to track events, such as failed login attempts and account lockouts. This shows suspicious password-related activities and gives indication of an account or password breach.

Use a Password Protection system that can check accounts or password hashes against breach websites. Examples are haveibeenpowned.com or dehashed.com.

Have procedures in place, or automate, the changing of passwords when a password has been breached.

At the UU IAM, CERT-UU and the ITS Servicedesk fill these tasks. Suppliers will need to implement this, for accounts they manage, themselves.

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Honeypots or Honey-accounts are used: Honeypot systems are systems that outwardly appear as genuine versions of the critical applications, but with vulnerabilities. These systems contain no sensitive data and are monitored closely for attacks, to identify ongoing persistent threats in the network.

Handleiding

Last updated: 21-04-2023

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.

Technical specification:
Red teaming of UU systems is done through UU ITS – Security Operations as part of the vulnerability management service. Systems with the ‘critical’ classification need to be registered at the CISO office to be included in the scope of the red teaming.

Red teaming does not need to be initiated or checked by the system owner. Red team exercises are not communicated past a select group, to keep responses as realistic as possible.

The mandate of the CIO of the UU needs to sign off on all internal red teaming exercises.

If additional red teaming on UU systems is wanted, then UU ITS – Security Operations will help to set this up.

If this security control is applied to a supplier, then the supplier must be able to show a recent red team management summary done in the last 3 years. The red team exercise should have an appropriate scope to the service the supplier delivers. The third party having done the red team exercise should be a company both the UU and the supplier agree is competent and independent.

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
–

Handleiding

Last updated: 28-4-2021

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

Technical specification:
–

Handleiding

Last updated: 30-7-2020

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

Technical specification:
–

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
CERT-UU

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Cooperation with SURFCERT

Handleiding

Last updated: 3-8-2021

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.

Technical specification:

Handleiding

Last updated: 4-2-2021

Endpoints inform users when updates are available and prompt them to install them at a convenient time and they are installed within appropriate times.

Important Security updates can be pushed to managed end-user devices within shorter time frames depending on the risks.

Endpoints that are lagging in security updates do not get access to organizational data.

Technical specification:
After a maximum time period of 7 days after security updates are made available, they are forcibly installed.
Staged rollout of new updates, first test in Acceptance then accept to deploy in Production.

SCCM is used to deploy and manage software updates both inside and outside of the network.

Handleiding

Last updated: 28-4-2021

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.

Technical specification:
–

Handleiding

Last updated: 28-4-2021

Managed Endpoints use Full Disk Encryption (FDE) is on present onfor endpoints where data is stored, for all internal storage (including hard disks and SD’s) containing data.

FDE uses pre-boot authentication to encrypt the disk before start-up.

Data in managed environments on unmanaged devices must be stored encrypted.

Technical specification:
FDE uses Advanced Encryption Standard (AES) with 256 bit key length with simplified key management and escrow. Endpoints should support Intel® AES-NI technology, UEFI and GPT platforms.

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

Last updated: 28-4-2021

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.

Technical specification:
The anti-malware tooling needs to have a minimum set of features:

A high malware detection rate and both signature-based and behaviour-based detection of malware and a sandbox feature in which it will examine files for malware. This feature is usually enterprise specific and not for consumers, but should still be available when working from home and not in the UU network.

Run on-access scans on any files accessed, including directly attached storage and files accessed through the network.

On Windows the tool needs to hook with AMSI to detect in-memory malware.

Anti-malware tooling for Linux and Unix variants is less robust than for Windows and Mac. To limit the damage malware can do anti-malware tooling is still required, but behavioural detection and sandboxing is expected to be less complete. Because of this on ‘basic’ and ‘sensitive’ systems a mandatory access control (MAC) system needs to be implemented that limits permissions of processes, files and users on a kernel level. The MAC needs to be set in a prevention/enforcement mode, not just detection. AppArmor in its default configuration is an example of one such system. For ‘critical’ systems the system needs to be more granular and configured with rules that are specific for the system/application. To ensure this an example would be a specifically configured SELinux or a manually configured and hardened AppArmor installation.

A list of pre-approved anti-malware tooling is kept by UU Security Operations ITS.

Handleiding

Last updated: 30-10-2020

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

Technical specification:
Endpoint OS needs to have Address Space Layout Randomization (ASLR) enabled.

Endpoint OS needs to use executable-space protection, preferably through hardware NX-bits. DEP is enabled for Windows.

Handleiding

Last updated: 30-7-2020

After a maximum of 15 minutes of inactivity on a managed workstation, the session/screen is locked and the user is prompted for their password again

Technical specification:
Centrally managed via AD policy.

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Apply CASB solution to monitor leakage of sensitive data to depreciated services. Inform users about the officially supported services e.g. https://tools.uu.nl/tooladvisor/. Discourage use of shadow IT.

Handleiding

Last updated: 3-8-2021

Organizational data can be deleted from devices remotely.

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

Technical specification:
Deletion of data is on par with NIST Guidelines for Media Sanitization for the level of ‘Clear’ or higher: https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final.

Voorbeeld: https://www.umsystem.edu/ums/is/infosec/data-disposal

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
–

Handleiding

Last updated: 4-2-2021

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

Technical specification:
–

Handleiding

Last updated: 28-4-2021

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

Technical specification:
For managed Windows endpoints the Microsoft Basic Firewall Policy suffices for most purposes: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/basic-firewall-policy-design

Exceptions need to be logged and approved

Handleiding

Last updated: 13-11-2023

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

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.

Technical specification:
The following identity provider is preferred: ITS central Identity Access Management (IAM), The requirements for connecting to this Identity Provider are described here: https://wiki.iam.uu.nl/

SURFconext is also allowed if the service needs to support users from other SURF connected institutions to log on. More information about this identity provider can be found here: www.surf.nl/en/surfconext

ITS Security Operations maintains a list of trusted identity providers.

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:
Only one of the password-policy options below applies to any one account. When in doubt, the stricter policy is chosen. The options are listed from least to most strict.

Chosen passwords must be checked against, a regularly updated, breached passwords list. If the chosen password appears on the list, the password is not allowed to be chosen.

The key space for all passwords is UTF-8. This needs to be supported anywhere a password can be submitted.

A new password cannot be the same as a password that has been used up to 20 times before.

Complexity requirements
Passwords must contain characters from at least three of the following five categories:
• Uppercase characters
• Lowercase characters
• Numerical characters
• Non-alphanumerical characters
• Unicode characters categorized as alphabetic characters but that are not uppercase or lowercase

The length and lifespan of passwords have different requirements based on the type of account:

• Non-privileged personal accounts (End-user accounts)
o Length: Min. 10, max. 127
o Lifespan: Expires every 12 months
• Non-privileged non-personal accounts (Functional accounts)
o Length: Min. 12, max. 127
o Lifespan: Expires every 2 years
 The reason the lifespan is lower than ‘privileged non-personal accounts’ lifespan is that functional account passwords are used by humans regularly and more prone to being re-used and leaked.
• Privileged-user accounts
o Length: Min. 15, max. 127
o Lifespan: Expires every 3 months
o If saved anywhere, then it requires a password vault with MFA
• Privileged non-personal accounts
o Length: Min. 20, max. 127
o Lifespan: Expires every 5 years
Must be saved and managed in a password vault with MFA. Examples: Service accounts or database accounts.
Sources
• https://docs.microsoft.com/en-us/windows/win32/secmgmt/strong-password-enforcement-and-passfilt-dll

Handleiding

Last updated: 29-10-2021

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.

Technical specification:
The UU password policy is applicable to PIN codes with the following exceptions:
• A PIN code must consist of at least 5 characters
• A PIN code is allowed to consist of only numerical characters
• The limitation that passwords cannot appear on leaked-password lists does not apply to PIN codes
• PIN codes do not need to be rotated periodically
• The password history restriction does not apply to PIN codes
• Rate limiting for PIN codes must be set at 20 consecutive attempts before lockout, or incremental lockout of the hardware device where the time between allowed attempts must be at least 1 minute and increase exponentially after every 5 unsuccessful attempts

Handleiding

Last updated: 28-4-2021

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.

Technical specification:
Unknown usernames are not logged, as these may be actually passwords.

Handleiding

Last updated: 29-10-2021

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.

Technical specification:
MFA can be set by users and can only be turned off by using MFA, using a previously generated recovery-token, or by determining the identity of the user by a IdP owner mandated admin.

Rate limiting needs to be enforced for failed authentication attempts.

Within MFA there are a number of levels of assurance when it comes to authentication. The higher the level, the more certain the user’s identity. Depending on the data classification, a specific level of MFA may be required. For any level, implementing a higher level is also acceptable. These levels are defined as follows for the UU:

● MFA level 1: Out-of band-unencrypted

◌ Short Message Service (SMS) and e-mail based technology. Sending a SMS or e-mail with a code to be input to authenticate.

● MFA level 2: Out-of-band encrypted

◌ A software token-based technology. This is software that resides on a device that can generate a code (token) in response to a challenge from the identity provider (IdP). This includes implementations that send a signal from the device to the IdP.

◌ Authenticators must validate to Authenticator Assurance Level 2, according to NIST Special Publication 800-63 section 4.2

● MFA level 3: Out-of-band hardware encrypted

◌ A hardware token-based technology. A hardened, separate, device whose sole purpose is to generate a code in response to a challenge from the IdP. This includes implementations that send a signal from the device to the service provider.

● MFA level 4: U2F

◌ Universal 2nd factor (U2F) based technology. Based on USB and NFC standards. The IdP challenge is not input by a person, but offered directly through a hardware device. The UU requires implementations that meet the U2F standard of the FIDO Alliance.

◌ At level 4, only a physical visit to the IdP administrators is accepted to reset MFA. It is allowed to use U2F technology at lower levels, whereby the weaker identification requirement applies. However, as soon as U2F is used for level 4, this stricter measure applies.

Sources:

● U2F standard: https://fidoalliance.org/specs/fido-u2f-v1.0-rd-20140209/fido-u2f-overview-v1.0-rd-20140209.pdf

● NIST special publication 800-63: https://pages.nist.gov/800-63-3/sp800-63-3.html#sec4 .

Handleiding

Last updated: 28-4-2021

Functions identified as critical and extra sensitive are identified by the IT service owner (both in the application and the underlying software infrastructure) and require re-authentication with Multi-Factor before being accessed.

Technical specification:
Examples of extra sensitive or critical functions include: changing grades, changing bank account numbers for payments in excess of a certain amount, exporting entire datasets with highly sensitive information or deleting entire databases.

Handleiding

Last updated: 28-4-2021

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

Depending on the highest of the CIA-levels of the Security Capability Level of the IT service the maximum duration of the session is as follows:

• Max Basic: 1 day
• Max Sensitive: 2 hours
• Max Critical: 60 minutes

Activity in another application from the same identity provider may be considered continued activity.

Technical specification:
–

Handleiding

Last updated: 29-10-2021

Administrators are able to terminate user sessions on the applications remotely in events of compromised accounts or immediate termination of individuals.

There is a procedure that is communicated to data owners for executing this emergency session termination.

For web applications, closing the browser must invalidate all sessions.

User password changes immediately invalidate active sessions.

Applications respect IdP initiated logouts.

Technical specification:
–

Handleiding

Last updated: 29-10-2021

Once distributed, identities have a unique relation with a natural person. Once issued, (old) accounts and unique account information are never (re)assigned to other natural persons.

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.

Technical specification:
–

Handleiding

Last updated: 30-7-2020

There is 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.

Technical specification:
–

Handleiding

Last updated: 4-2-2022

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

Technical specification:
Apply contextual and behavioural authentication.

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
–

Handleiding

Last updated: 21-04-2023

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

Technical specification:
Where used, Windows Active Directories (AD) need to be implemented and maintained according to the Microsoft security recommendations implementing a 3-tiered model and separate Privileged Access Workstations: https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access

Handleiding

Last updated: 30-7-2020

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

Technical specification:
–

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
–

Handleiding

Last updated: 28-4-2021

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.

Technical specification:
–

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
Normally, this is defined in a DRP

Handleiding

Last updated: 30-7-2020

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

Technical specification:
–

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
Backups of system and application data must be created periodically and backups must be stored encrypted at a different location(s) for Business Continuity purposes. Keys need to be stored securely. The restore procedure must be tested yearly.

Create a backup strategy plan, with at least one offline backup system in place.

It is highly recommended to apply the 3-2-1 backup rule:
-Create 3 copies of your data (1 primary copy and 2 backups)
-Store your copies in at least 2 types of storage media (local drive, network share/NAS, tape drive, etc.)
-Store one of these copies offsite (I.e., in the Cloud)

There are sufficient recent copies (back-ups) of data and configurations for timely recovery of the service within its recovery norms; the recovery time objective (RTO) and the recovery point objective (RPO).

Handleiding

Last updated: 30-7-2020

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

Technical specification:
–

Handleiding

Last updated: 28-4-2021

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.

Technical specification:
–

Handleiding

Last updated: 13-11-2023

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.

Technical specification:
Production, acceptance and testing environments should be seperated from each other on a network level. DTAP environments are not allowed to have direct connections with each other.

Development environments are assumed to be transient and hosted on individual developer workstations. Developer workstations cannot expose development environments to outside of the workstation. If a development environment is not hosted on a workstation then all the restrictions apply as if it is a test environment.

Limit access to the development, testing and acceptance environments by least privilege. If acceptance environments need to face the Internet for any reason, limit the accessibility by IP whitelisting. Access through VPN is preferred.

Development and test environments do not connect to the UU IdP. Acceptance environments connect to the acceptance UU IdP. Production environments connect to the production UU IdP.

Debugging information is turned off in production environments.

A unique naming convention is used for each network (DTAP) environment.

If the application is classified as sensitive on any axis the following applies: Developers should not have write access to the production environment. If this is unavoidable, make sure to use the 4-eyes principle when changing code in the production environment.

Handleiding

Last updated: 29-10-2021

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.

Technical specification:

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

Last updated: 4-2-2021

Developers are demonstrably familiar with secure coding practices.

Technical specification:
Developers maintain “certified secure coder” e.g. CERT Secure coding: https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices?focusedCommentId=88044413

Handleiding

Last updated: 30-10-2020

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

Technical specification:
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Apply appropriate configuration hardening using CIS recommendations where available.
Place files with sensitive information outside public access.
Apply strict permissions on sensitive files.

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

Last updated: 4-2-2021

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.

Technical specification:
Apply RBAC (Role Based Access controls).

Administrators group is removed from personal data storage and replace by a group with break the glass accounts.

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
–

Handleiding

Last updated: 29-10-2021

Automatic forwarding of corporate email to an external address is prohibited. If the individual has a legitimate organisational need to be reached after the end of the formal relationship with the organisation, the individual can request an out-of-office to be set including new contact details.

Technical specification:

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Apply detection for animalities for data in motion; spikes in network usage/bandwidth.

Handleiding

Last updated: 28-4-2021

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

Functionality is designed and configured to prevent enumeration of information.

Technical specification:
Information that should not be enumerable are: usernames, email-addresses, files, versioning information, server configuration and structure, endpoints and so forth.

Error messages should be compact and not contain any technical information about the environment.

Customize default error pages to display only necessary information, no (back-end) software titles version numbers etc.

Handleiding

Last updated: 21-04-2023

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

Technical specification:
Direct access to printers through the network is limited, all printing is done through central print servers which require authentication/authorization by the UU IdP.

Network traffic (print jobs, management) to and from printers is encrypted. Print data at rest is encrypted on both the printer and the central print servers.

Print jobs can only be printed at, and retrieved from, the printers by the submitter of the print job.

Print jobs are safely removed after printing.

Print jobs that haven’t been printed will be safely removed after 24 hours.

All management of printers must be done via the authorized methods with auditing of changes. Access to the printer that is neither authorized printing nor authorized management must be rejected.

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

Last updated: 3-8-2021

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.

Technical specification:
Any input and output will adhere to the concept of ‘do not trust user in/output’.

Any data entered by the user or processed as result of earlier entry should be handled in such a way it can’t cause any side-effects in the application.

In web application programming this means avoiding sql-injection, cross-site scripting and any other influence on the application or on the presentation to the user.

In network traffic handling this means avoiding any side-effects or even crashes such as ping-of-death or other attacks on network stacks.

This also applies to third-party software used in data processing which must be updated when vulnerabilities are found

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Mobile Apps use PIC and ASLR.

See also: NSCS guidelines for mobile apps with regards to data storage.

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
The application has been developed in a secure way.
A CAPTCHA is used to protect authentication methods.

Handleiding

Last updated: 13-11-2023

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.

Technical specification:
All malware scanning should have signature and heuristic behavioural capabilities. The scans should also adhere to all other security controls in this framework related to anti-malware tooling.

All positive malware scans should be checked regularly by IT personnel.

In the case of attachment scanning, the scanning should be done before the email is delivered to the user’s inbox. If malware is found, the e-mail can still be delivered, but without the attachment.

In the case of uploads the scan should be done before an upload becomes available to the application for further use and be done again on access.

In the case of links the scan should be done before the user is able to visit the link.

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
The risk analysis is documented and contains at least the following:
• Are the third-party apps and their codes tested for security (before or in scope of pen tests on the entire application)?
• What are the benefits of the third-party app and what are the potential risks of using it?
• How are the third-party apps and libraries maintained, updated and patched?

Only third-party software that is deemed secure is allowed to be used.

Handleiding

Last updated: 30-7-2020

Authorisations are preferable centrally managed through the Identity Provider and not in the Application.

Technical specification:
Access to an application is authorized by its owner.

Handleiding

Last updated: 29-10-2021

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

Technical specification:
Universal and/or default passwords must not be used.

For existing systems that have built-in default passwords, these can only be used one time, after logging on this password must be changed. The new password meets our password complexity standards as described in IS.9.002 and are handled as confidential information, see DS.2.005.

Handleiding

Last updated: 13-11-2023

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

Technical specification:
Only run and/or install necessary services on a system.

Use the host-based firewall to filter access to the system (ref IS.8.013).

Run services under their own service account with the minimal rights needed to perform its functionality.

If higher privileges are needed at startup, drop those privileges as soon as possible.

Use available solutions to restrict the capabilities of programs such as Application Control for Windows, SELinux or AppArmor.

Configure services according to best practices for security and minimization of information leaks.

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Every newly deployed server has a maximum of one role.

Handleiding

Last updated: 30-7-2020

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

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

Technical specification:
Non-privileged users are prohibited to run unauthorised software on common workspace servers.

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
These validation systems must be kept up-to-date, on a separate network, run a minimum of 2 anti-virus packages from separate vendors with up-to-date signatures and perform detection for malware. These systems have detection and protection against USB-killer functionality and are re-imaged daily.

Handleiding

Last updated: 30-10-2020

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.

Technical specification:
Data sent on physical media such as USB sticks must be encrypted using up-to-date encryption standards.
Use BitLocker To Go or the encryption product of a preferred supplier.

UU internal link on disk encryption

Handleiding

Last updated: 28-4-2021

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.

Technical specification:
–

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

Last updated: 4-2-2021

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.

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

Destruction of storage devices is done by a preferred supplier.

Handleiding

Last updated: 3-8-2021

All data in transit is transferred over encrypted connections, using the encrypted versions of protocols or encapsulation of plaintext protocols over encrypted connections.

Technical specification:
For TLS based protocols including but not limited to https use the latest version of our technical guideline TLS, available at Technische richtlijn (TLS) transportversleuteling which is based on NCSC publication ‘ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS)’
For TLS we use certificates that are managed according to certificate management (IS.20.001)

For other encrypted protocols: the same choices in enabling and disabling key exchange, hashing and bulk encryption algorithms to get the same level of confidentiality, integrity and non-repudiation.

Handleiding

Last updated: 4-2-2022

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.

Technical specification:
Services sending mail, from primary domains uu.nl or students.uu.nl, on behalf of the UU send mail via the UU SMTP relay infrastructure, using SMTP credentials provided by the UU. This communication is done over encrypted connections to the UU infrastructure. SMTP with STARTTLS and SMTPS (secure SMTP) are both allowed. The authentication phase can only start after an encrypted connection has been established.

Services sending mail from non-primary (sub-)domains, like mail.uu.nl, can send that mail from their own SMTP infrastructure. The mail still needs to comply with all other technical requirements. These services can use the RETURN-PATH mail header, which helps to track bounces. Changes to UU subdomain SPF records are not allowed.

Forwarding e-mail on behalf of the UU from a service purely based on the originating IP address is not allowed.

Handleiding

Last updated: 29-10-2021

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.

Technical specification:
All e-mail servers that handle UU e-mail need to implement the following for both incoming and outgoing mail flows (where applicable):

SPF minimized to just allowed senders. In practice this would be Microsoft and ITS. Recursive lookups for SPF records are limited to 10 DNS lookups, including nested records.

DKIM signing of outgoing mail is implemented for all domains and subdomains. The key algorithm should be RSA with a key size of at least 2048 bit and a lifetime of at most 2 years. Hashing needs to be done with SHA-256.

DMARC implemented with ‘quarantaine’ policy.

DNSSEC is implemented on all e-mail related DNS records.

IPv4 and IPv6 are both available.
Security monitoring is setup on e-mail servers. Contact UU ITS Security Operations for details.

All connections to the e-mail servers need to be authenticated. Only servers sending e-mail to non-end-users, like sysadmins, can be done without authentication. In this case the servers should be whitelisted based on IP. Authentication based on machine or application identity is preferred for mail from systems or applications.

All connections to send mail or receive/read mail to/from e-mail servers are encrypted. STARTTLS is allowed to negotiate an encrypted connection.

All e-mail servers have anti-malware and spam filter tooling running on all in- and outgoing e-mail traffic.

E-mail is only sent from/to domains where this is explicitly authorized. All domain and subdomains for which the UU is responsible, that do not send mail need to set the following DNS records by default:
-TXT v=spf1 -all
-TXT “v=DMARC1; p=reject;”
-MX “0 . ”

Handleiding

Last updated: 29-10-2021

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

Technical specification:

Handleiding

Last updated: 28-4-2021

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

Technical specification:
–

Handleiding

Last updated: 29-10-2021

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.

Technical specification:
The warning message in e-mail needs to mention to handle suspicious emails carefully (not click on links without checking) and that suspicious emails and (potential) incidents need to be reported to CERT-UU.

Other communication channels in which identities can be mistaken and impersonated must also be labelled to aid the user in recognizing external sources.

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
IT security incident handling needs mandate to take preventive measures to stop a security incident from causing (more) damage
The security incident process has 6 phases
– Preparation: information needed to handle security incidents is available to security incident handlers and they are trained in handling these incidents
– Identification: incidents that happen are detected, classified, registered and handled
– Containment: the impact of the security incident is minimized
– Eradication: the cause of the incident is stopped
– Recovery: service is returned to normal
– Lessons learned: the incident is evaluated and improvements are recorded
More information on computer security incident handling teams in Guide to setting up a Computer Security Incident Response Team (CSIRT):
https://www.enisa.europa.eu/publications/csirt-setting-up-guide/at_download/fullReport

Handleiding

Last updated: 3-8-2021

The organization has a (contracted) CSIRT.

The CSIRT is fully mandated to respond to active threats to limit the impact of potential security incidents.

Technical specification:
The CSIRT has an average maturity according to the SIM3 maturity model for CSIRTS of 2 or higher on each of the O, H, T and P categories (see: https://www.trusted-introducer.org/SIM3-Reference-Model.pdf).
Contact information of the CSIRT is published in the RFC2350 format.
The CSIRT maturity is reviewed annually.

UU CSIRT implementation: https://www.uu.nl/cert

Handleiding

Last updated: 4-2-2021

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.

Technical specification:
“Naslagwerk m.b.t. vragen van instanties”
Anton van den Hoeven, Juridische Zaken UU.

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Security Operations ITS of the UU will maintain a list of trusted parties to perform digital forensics, available on request.

CERT instructs SecOps to perform research after an incident.

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
Incidents and data breaches should be officially reported to CERT-UU aand the Data Protection Office (Dutch: Functionaris Gegevensbescherming). . These are the only parties that are allowed to share the PII of reporters between them without proving the need to share this information or the explicit consent of the reporter. If incidents get reported to others, they can always forward this information to CERT-UU or the DPO under the same assumptions of privacy and protection.

Handleiding

Last updated: 30-7-2020

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.

Technical specification:
Secure Terms of Use cover at least:
• What’s allowed
• What’s not allowed
• Reporting security issues
• Sanctions
• Network performance
• Solving network problems
• Monitoring security
• Fixing vulnerabilities for which the user is responsible
• Reporting Security Incidents

User terms of use: https://intranet.uu.nl/system/files/documenten/ib_-_gebruiksreglement_ict_versie_1_juni_2010.pdf
Network terms of use: https://intranet.uu.nl/apparatuur-aansluiten-op-het-netwerk-solis-net

Handleiding

Last updated: 28-4-2021

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.

Technical specification:
These manuals explain step-by-step to how the user should operate the system safely. Use screenshots where possible.

If these manuals are meant for public use, they are published at https://manuals.uu.nl/nl/manual_category/solis-id-en-veiligheid/
If these manuals are meant for internal use only, they are published on a SharePoint site so they can be shared accordingly.

Handleiding

Last updated: 21-04-2023

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.

Technical specification:
Certificates that are visible to end-users are signed through a CA Browser forum accepted certificate authority, the certificate chain is passed along, and the certificate is valid: Deep Dive – Transportversleuteling met TLS. Selected approved certificate providers are published as DNS CAA records.

Users can request certificates on behalf of a group where they have the role of certificate requestor. Those certificates are requested with the contact information for a group for renewal notices, to avoid a single point of failure in renewal.

Wildcard certificates: only allowed as an exception under very specific circumstances: Richtlijn ‘Inzet wildcard SSL certificaten’. Certificates are always requested with parameters (hashing algorithms, private key size, validity) set according to the latest CA browser forum baseline SSL/TLS certificates https://cabforum.org/baseline-requirements-documents/

Validity of certificates is checked as part of availability checks of services.

Single domain certificates are preferred over SAN certificates.

Self-signed certificates can be used when:

The trust relation is 1-1 between applications

The certificate generation parameters used still comply to the CA browser forum baseline above

The trust is validated through an authenticated and authorized path. This path does not need to be a technical path and can be a process between people.

# Internal Link explaining digital certificates (requires SolisID);

Informatiebeveiliging – Digitale certificaten | Intranet (uu.nl)

# Public link with request procedure

https://manuals.uu.nl/nl/handleiding/ssl-certificaat-aanvragen/

Also see: IS 17.001

Handleiding

Last updated: 3-8-2021

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.

Technical specification:
Private keys are not to be re-used for more than one service or identity.
Revocation procedures for the Certificate Authority have to be known and available in case of an incident.

Revoked certificates are published via the certificate revocation list (CRL), certificate status can be queried with OCSP and the certificate status is made available via OCSP stapling for public-facing services.

Handleiding

#VALUE!

Handleiding

Last updated: 30-10-2020

All information processing activities have an owner, the process owner.

All processing activities need to be registered and maintained, this is the responsibility of the process owner.

All processing activities need to be classified to determine the potential impact to the organization.

The CISO Office will publish and maintain a classification procedure.

Classifications are updated every 2 years or when major changes to the processing activity warrant re-classification.

Technical specification:
On this page (internal) it is explained how to add processing activities to the processing registry. Classification is a part of that process.

Handleiding

Last updated: 30-10-2020

All processing activities (with and without PII) need to be registered and maintained, this is the responsibility of the process owner.

The registration contains at least the classification of the processing activity, the process owner and a description of the IT services used for the activity.

Technical specification:
On this page (internal) it is explained how to add processing activities to the processing registry. Classification is a part of that process.

Handleiding

Last updated: 30-10-2020

IT services used in the processing activity are considered suitable according to their communicated IT Security Capability level.

Operating procedures for correct and secure usage of the IT services, delivered by the service, are followed.

The IT service offers appropriate functionality for uptime (Recovery Time Objective) and backups (Recovery Point Objective) for the data processing activity.

Technical specification:
When processing information, you normally make use of 1 or more IT services. For example, you could receive information in your email, store it locally on your managed laptop, modify it in an application and upload it to SharePoint. Each of the services you use needs to be appropriate for use.

What is appropriate is determined by the classification of the processing activity and the Security Level of the services you are using. UU services should be offered with a specific Security Level.

Handleiding

Last updated: 30-10-2020

Data processing activities should be processed and stored exclusively on organisationally managed (either contracted or governed by the organisation) hard-and software.

Technical specification:
Use only official UU managed hardware and supplied facilities to process Critical information.

Handleiding

Last updated: 08-09-2022

Users should adhere to internal best practices regarding email to avoid causing data breaches, to limit the impact in case data breaches happen. and to support forensics and impact if a data breach does happen.

Technical specification:

Handleiding

Last updated: 30-10-2020

People must receive instructions and training on how to work securely using most common organisational IT services before processing data.

Technical specification:
As a manager you need to ensure that individuals working under you have received the right instructions and training to perform their work activities in a secure manner. When in doubt, contact informatiebeveiliging@uu.nl about training options.

Handleiding

Last updated: 30-10-2020

Everyone working with UU data consistently demonstrates secure behaviour.

Technical specification:
Secure behaviour includes at least the following:
• Knowledge and awareness of policies
• Follow University Information Security policy
• Knowledge of who in the organisation can be contacted for help
• Alertness and reporting of phishing and suspicious behaviour
• Reporting of data breaches and security incidents (also on personally owned hard- and software if it contains organisational data)
• Approach and inform colleagues when they demonstrate unsafe behaviour

All (suspected) information security incidents are reported to CERT at cert@uu.nl. Follow-up steps suggested by CERT to mitigate the damage will be followed.

Handleiding

Last updated: 30-10-2020

Data can only be moved to hardcopy with express permission of the data owner.

Information Security policy and controls are equally applicable to hardcopy data.

Technical specification:
Do not print critically sensitive information, unless you have explicit permission to do so. You need to treat printed information as secure as digital information.

Handleiding

Last updated: 30-10-2020

In performance reviews, secure behaviour is discussed and part of the evaluation.

Technical specification:
Managers should make sure that working securely and attentively is something that is monitored and part of feedback. Reporting of (potential) risks and incidents should never be punished but rewarded and motivated, and are part of a positive review. Demonstrating the behaviours listed in DS.2.002 should be actively encouraged.

Handleiding

Last updated: 30-10-2020

Information is only distributed to people that have a legitimate need for it. Authentication details and tokens are never shared (not to colleagues or secretarial staff). Only the minimum amount of information that is needed for a purpose is shared, through channels appropriate for the level of data classification.

Technical specification:
Do not share credentials, logins or unnecessary information from your applications with anyone. This includes colleagues that may have to perform certain tasks or favours for you, use appropriate ways to achieve those goals.

Handleiding

Last updated: 30-10-2020

The organization has a social media policy. The CISO Office is consulted for the policy to address security aspects.

The Social Media policy distinguishes between acceptable and representative uses of Social Media for private use, and how Social Media representing the organization must be managed.

Social Media software is subject to the Information Security policies.

All individuals are informed of and adhere to the Social Media Policy.

Technical specification:
Remember when using Social Media that you are considered a representative of the organization. When in doubt whether statements may be considered offensive, local communication experts can always be consulted.

Scraping Social Media is a data processing activity that should not be performed without following the necessary steps listed in DS.1.002 and having performed the necessary Privacy checks.

Handleiding

Last updated: 30-10-2020

Where there are repeated security incidents, lessons will be drawn and the source of (repeated) incidents addressed in a structural manner, changing processes and supporting IT where appropriate.

Technical specification:
It can always happen that something goes wrong by accident, but if a process goes wrong in the same way multiple times, that is a good reason to critically evaluate if there are other ways to perform this process. If assistance is desired in seeing if there are more secure (and often more efficient) ways to perform a process, please consult informatiebeveiliging@uu.nl

Handleiding

Last updated: 5-6-2020

Individuals are responsible for maintaining a clear and secure digital working space. This means no text files with passwords or sensitive information, cleaning up data and archiving historic data appropriately and no installing of excessive programs and tools.

Individuals that work from public locations use privacy screens when accessing information.

Technical specification:
Keep your screen clear and be aware of your surroundings and who may be able to see what you are doing. If you frequently have to work with sensitive information in (semi)-public spaces, consult with your manager if you can obtain a ‘privacy-screen’ for your laptop.

Handleiding

Last updated: 30-10-2020

All systems and devices that are not actively manned and used, need to be locked when leaving the working space unattended.

Technical specification:
Windows key + L, or Ctrl + Cmd + Q on Mac.

Handleiding

Last updated: 5-6-2020

Information is stored appropriately in locked cabinets in working spaces.

Physical working spaces not intended to be open and publicly accessible need to be secured appropriately.

Technical specification:
For non-public workspaces, University buildings need to be protected according to the appropriate operational standards of UU FSC Security, corresponding to “Standard Area” or higher.

Contact FSC security via Topdesk if you wish to check if your working space is appropriately secured.

Handleiding

Last updated: 30-10-2020

Information carriers, the working spaces and personal physical security are all appropriately protected, in accordance with UU FSC Security.

UU areas where processing activities take place are reported to UU FSC Security for appropriate physical protection of assets and people involved in the activity.

Technical specification:
Contact FSC security via Topdesk if you wish to check if your working space is appropriately secured.

Handleiding

Last updated: 30-10-2020

Desks and working spaces should be void of sensitive information, documents and portable data storage devices. This includes post-its with passwords, documents and equipment lying around.

Technical specification:
Clear your desk and working space after you are done. This applies both to the office environment and your home environment. Note that a regular locked door in the office is not sufficient protection for the information in that room. Put sensitive information under lock and key that only authorized people have access to.

Handleiding

Last updated: 30-10-2020

Before commencement of processing activities all individuals working with data and systems have been identified using a nationally issued Identification Document.

Technical specification:
All contracted UU employees and contractors have had their identities validated before accounts have been provisioned. So if you work with UU colleagues, this has already been taken care of. However, if you work with people from outside our organisation, make sure their identities have been sufficiently validated before you exchange information.

Handleiding

Last updated: 5-6-2020

Before commencement of processing activities all individuals working with sensitive data and systems have basic background checks performed to determine integrity, suitability for the tasks and secure behaviour.

Technical specification:
At least 2 references are confirmed and contacted before the start of employment to attest to the integrity and qualities of the candidate.

Personnel is required to deliver a VOG (Dutch for: Verklaring Omtrent Gedrag, Declaration about Behaviour) covering relevant criminal history to this processing activity, or an international equivalent from local law enforcement.

A new VOG is required every 5 years. If a VOG cannot be obtained, the processing activities need to be ceased and the access of the individual revoked at first opportunity.

Handleiding

Last updated: 30-10-2020

Background verification is performed through a trusted third party that involves extensive screening for financial, national, criminal and other relevant factors that could influence the integrity and reliability of personnel before processing activities start. Background screening needs to be repeated every 10 years. If a screening finds issues, processing activities and access need to be revoked immediately and treated as a potential incident.

Technical specification:
We need to ensure that the integrity of people working in Critical roles is appropriate for their critical access. Contact HR and informatiebeveiliging@uu.nl to determine the appropriate level of screening.

Handleiding

Last updated: 5-6-2020

In areas designated only for employees only, employees should be clearly recognisable, carry their corporate identification card visibly and be able to demonstrate said identification upon entry and on request in the working area.

Technical specification:
UU campus cards must be worn visible in locations designated for employees only. Contractors and guest must wear a visible guest card.

Handleiding

Last updated: 30-10-2020

Non-contracted visitors into non-public areas are always accompanied by UU staff.

There must be a procedure for employees from contracted partners to commence activities on site. This procedure includes that contractors must be announced beforehand, identified, be clearly recognisable while performing work.

Technical specification:
If someone visits you, make sure that you are always with them as they navigate non-publicly accessible areas.

When a supplier sends out people to perform activities in non-public spaces, they need to register these activities with us before they start, so that we can validate anyone trying to gain access to non-public locations is authorized for that. Contact FSC Security (Tel: 4444) if you suspect someone may not be authorized to be in this location.

Handleiding

Last updated: 30-10-2020

Organisational processes and research that may attract Nation State actors or Corporate Espionage need to proactively monitor for signs indicative of ongoing intelligence activities, and take additional and tailored actions to protect against potential threats.

Technical specification:
When there is potential threat of espionage, appropriate measure must be taken in consultation with the CISO Office, UU Security Operations and UU FSC Security.

Handleiding

Last updated: 30-10-2020

Threats to the (online) security of affiliates of the University are reported to cert@uu.nl and appropriate custom protective measures are taken to address the risks.

Technical specification:
–

Handleiding

Last updated: 17-8-2020

When travelling to certain countries, appropriate additional information security measures must be followed.

Technical specification:
The CISO Office will monitor a list of countries for which negative travel advice with regards to data security is published. This list will be made known and published to the organisation. There will be tailored and specific advice and facilities to support data security during travel to these locations.

See this page for advice on travelling to high-risk countries: https://intranet.uu.nl/informatiebeveiliging-reizen-naar-het-buitenland

Handleiding

Last updated: 30-10-2020

Only the minimal amount of authorisations are given to individuals for their role and purpose in the processing activities.

Authorisations are only given for the minimum necessary duration the activities will take place.

Preferably these are given based on a role and not attached to individuals.

Technical specification:
This control is for data-owners. Make sure that only people that need access to data to perform their work activities have been granted that access. Do not give people additional access that is not needed. For example: share files with users from your SharePoint with read-only access if these users only need to read and comment.

If you can set roles, make sure that the roles have the minimal amount of privileges necessary for the tasks these people have to perform. A person can be assigned multiple roles, but make sure that there are no conflicting privileges in these roles.

Handleiding

Last updated: 30-10-2020

At least yearly a list of all users in the system is generated along with associated permissions. The data owner should have defined who should be allowed to have access (preferably based on roles) and all access rights should be reviewed by appropriate data owners. Actions taken based on the review are recorded and stored for 2 years.

Technical specification:
At least once every year, check who have permissions to view and modify data for which you are responsible. This includes network storage directories, online cloud storage, permissions in Office365 (Teams and SharePoint), etc… When in doubt if someone still needs access, confirm whether this is the case and remove all authorisations that are no longer needed.

Handleiding

Last updated: 30-10-2020

At least quarterly a list of all users in the system is generated along with associated permissions. The data owner should have defined who should be allowed to have access (preferably based on roles) and all access rights should be reviewed by appropriate data owners. A documented procedure is available for how the review is performed. Actions taken based on the review are recorded and stored for 2 years. If the authorisations are given based on role, the authorisations within the roles are part of the review as well.

Technical specification:
As DS.6.002, but performed at least once every quarter.

Handleiding

Last updated: 30-10-2020

Sensitive tasks and responsibilities are separated and require at least 2 individuals to complete the process.

Technical specification:
As a process-owner, define processes and conditions where a “4-eyes principle” is appropriate before the process can be completed. This can include reviews, approvals, sign-offs or other ways to separate duties. Contact informatiebeveiliging@uu.nl if you need help with this.

When assigning roles, ensure that conflicting duties are not assigned to the same individual.

Handleiding

Last updated: 30-10-2020

Process owners keep an authorization matrix listing who has what access to data, in what capacity.

The authorization matrix includes roles, the authorizations in roles, individuals and which roles the individuals are allowed to have. Optionally, job functions can be used to identify which roles belong to those functions. If there conflicts between certain authorizations that cannot be given simultaneously, the authorization matrix should identify which combinations of authorizations should not be allowed.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Data should have a data owner. Access to data can only be given after approval of the appropriate data owner (which can be mandated or given based on roles, as long as this is documented).

Technical specification:
–

Handleiding

Last updated: 30-10-2020

The requests of individuals that want access to information assets or authorisations to do so are logged and kept for at least 1 year. It includes the requester, and the approval (or rejection) of the appropriate data owner. Revocation requests, end of employment notifications and changes are recorded and kept for at least 1 year.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

After role changes or upon termination of contractual or formal relations between the organisation and the individual, access to data that is no longer part of your role is revoked at first opportunity.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

If revocation of access takes place after the date access was no longer needed according to the data owner (applicable to both role changes and termination of relations), logs must be inspected to determine if inappropriate actions have been performed during this window. If so, this is treated as a security incident. The outcome of the inspection is logged.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

When data carrying devices or sensitive data is given to employees, they must sign for the appropriate handling. This information must be logged in personnel files. Equipment and data must be returned upon termination or role changes. Successful intake of data and equipment shall be registered in personnel files.

Technical specification:
Responsibility of manager or the individual that contracted services. Personnel files are the best location to store agreements and sign-offs that equipment has been returned.

Handleiding

Last updated: 30-10-2020

In exceptional cases, such as the unexpected death of employees or contractors, access to data that has not yet been deleted can be requested by people other than the data owner or individuals who had already been granted access.

The process owner for the data must have a documented procedure available for this which is approved by the CISO Office and the DPO.

Technical specification:
If no other documented and approved procedure is available, the protocol for deceased employee is applicable to all cases of Access to Data in Special Cases. Contact informatiebeveiliging@uu.nl to follow this procedure.

Handleiding

Last updated: 30-10-2020

Documented procedures with regards to how data must be handled when working remotely are available for the processing activity.

Technical specification:
Remote work policy includes whether activities are allowed to take place while working in (semi) public spaces, under what circumstances and using what supporting systems and services.

The usage of privacy screens in public spaces.

Handleiding

Last updated: 30-10-2020

The process owner needs to have a policy on if personally owned devices can be used in the processing activity and under what circumstances.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Upon noting deviations from information security policy and inappropriate handling of data, initially an informal warning will be given by the supervisor. If a second case presents itself within a year, a formal warning will be given and logged in personnel files. If within a year of the last formal warning a new situation presents itself, a final formal warning will be given. If within a year of the final formal warning a new situation presents itself, the case will be presented to a committee consisting of representation of the Organizational Unit, CISO and HR that will determine the disciplinary action.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Police reports will be filed when willfully breaking of the law or actions with criminal intent are ascertained with regards to data handling. A record of this will be placed in the personnel file. The case will immediately be presented to a committee consisting of representation of the Organizational Unit, CISO and HR that will determine the disciplinary action.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Before processing sensitive data, individuals working with the data must agree to non-disclosure agreements that limit the legal room for distributing the data during and for a period after the activities take place. NDA’s also specify consequences of breaches of the agreement and are signed by the individuals.

Technical specification:
UU contracted employees adhere to the Code of Conduct that states they will treat information with the appropriate care and keep it secret. So if you only work with UU colleagues, you do not need NDA’s. If you work with external parties though, make sure they are contractually obligated to keep sensitive information secret.

Contact HRservicedesk@uu.nl for help with NDA’s for contractors.

Handleiding

Last updated: 30-10-2020

Teams plan to have sufficient capacity to execute important tasks, also during holidays. There is monitoring on the capacity of the team and structural understaffing gets flagged and addressed. There are procedures in case of unplanned absence of team-members to continue with important processes.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Individuals in teams that are the only ones capable of performing specific tasks need to be identified as Single Points of Failure. Team leaders are responsible for identifying these individuals and transferring this knowledge to other employees and procedures. If this knowledge is non-transferable, more capable staff or a retainer with a supplier that can provide this expertise needs to be arranged.

Technical specification:
–

Handleiding

Last updated: 17-8-2020

Data stored on portable storage devices is stored encrypted according to modern standards.

Technical specification:
Encryption of portable storage must follow the Dutch NCSC advice for bulk data encryption as described in the guideline on TLS, which can be found here: https://www.ncsc.nl/documenten?trefwoord=TLS%20versleuteling .

UU offers tools that are considered suitable, when used right, for the encryption of data on portable storage devices. See this page for an overview of services (encrypted USB/HDD, winzip with right settings, BoxCryptor, Bitlocker, ….). See this intranet page for more on encrypting your information: https://intranet.uu.nl/informatiebeveiliging-hoe-ga-ik-om-met-externe-harddisks-en-usb-sticks .

Handleiding

Last updated: 30-10-2020

For the processing of data other than the primary process for which this data is collected, Terms of Use and agreements are available that detail how the data can and must be treated, also for internal processes. These Terms of Use have to be agreed to before the processing of data and the data owner remains responsible for the data and monitoring that the Terms of Use are adhered to.

Technical specification:
Data-owners are responsible for the data and remain so, even after granting access to others. This can be the case for developing new software or for research purposes. It is important that there are clear agreements on how data is handled when data classified as Critical on C-I-or -A is shared with others outside the process itself.

These agreements should look a lot like a Data Processing Agreement and contain many of the same clauses, such as how the information is secured and how incidents are treated.

Handleiding

Last updated: 5-6-2020

The identity of receiving and originating party is verified using (digital) signatures.

Technical specification:
Digital signatures must use cryptographic standards and public/private keypairs to sign documents, so they cannot be repudiated or tampered with.
S/MIME may be used for digital signing/verification. Contact secops@uu.nl for help with setting up your data transport in a secure manner.

Handleiding

Last updated: 30-10-2020

Suppliers are contractually obligated to adhere to the information security policies of the UU. All agreements made with the supplier apply to sub-contractors equally and are under the responsibility of the supplier.

Agreements with partners (including external researchers) include appropriate data management and security controls for the classification of the processing activity.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Before new suppliers of Information Technology products or services are contracted or engaged for the purpose of supporting processing activities with this classification or higher, official advice must be requested on the Information Security risks as seen by the CISO Office. The CISO Office can request additional documentation, certifications or conversations with the supplier to formulate a non-open-ended advice whether or not we can continue with this supplier or under what circumstances.

Technical specification:
Before a new service is contracted or used, follow the steps outlined on this page to make sure that information security risks of the supplier and the product are identified.

Handleiding

Last updated: 30-10-2020

Supplier is contractually disallowed from accessing organisational data in any other way than upon specific request of the organisation. This request must be demonstratable and actions taken by supplier logged.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Contractually, suppliers are obligated to inform the UU of any breach to their information security that could potentially affect the UU as soon as possible but at least within 72 hours of establishing the incident.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Contractually, suppliers are obligated to inform the UU if vulnerabilities are found in contracted IT services. This notification does not need to include technical details, but at least contain an indication of the risk to the UU due to the vulnerability, expected timelines for addressing the vulnerability, a comprehensive overview of steps the UU can take to mitigate the risk posed by the vulnerability and if there are indications the vulnerability has been abused.

Contractually, in the event of indications of compromise, supplier is obligated have digital forensics performed by an independent party to determine the extent to which UU data has been exposed or compromised.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Supplier will provide periodic reports to show that agreements and service levels are attained.

Suppliers will allow and facilitate the UU to perform audits to ascertain that the contractual agreements with regards to information security are adhered to and to gain further insight into information security risks related to the continued usage of the IT service or product.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Supplier has existed for at least 3 years.

Supplier must have a proven solution in use at other organizations for comparable use cases. Supplier is able to give references that can be contacted regarding their use of the supplier’s solution.

Supplier can demonstrate measures taken to guarantee continuity of business operation.

Technical specification:
References from successful implementations for comparable use cases are contacted to ask for their experience with the product and supplier.

Measures to account for business continuity may include a large enough workforce with knowledge of the solutions and tools, extensive documentation, separate holdings for intellectual property and financial flows.

Handleiding

Last updated: 30-10-2020

Supplier is appropriately certified for information security by an independent third party auditor. The certification is a maximum of 2 years old.

Technical specification:
For ISO27001 certification the SoA needs to be confirmed by UU information security.

ISAE3402 statements are not sufficient for Information Security.

informatiebeveiliging@uu.nl determines if a certification and its scoping is sufficient for the intended services to be delivered by this supplier.

Handleiding

Last updated: 30-10-2020

Supplier is contractually obligated to deliver the UU data in a convenient and portable format on request.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Data has an identified and recorded period of time for which it is retained and available, which is set to the minimum of legal and business requirements. After this period, data is deleted and unrecoverable. Data deletion for different storage mediums must occur in line with the NIST standard for data deletion level ‘Clear’ or higher: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf.

This includes sensitive data stored hardcopy which needs to be properly shredded and destroyed.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

There is a data archiving procedure detailing how certain documentation that may be needed beyond the data retention period can be archived. Note that archiving is a one-way procedure and meant for long-term storage in read-only repositories.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

When critical data is destroyed (either digitally or the storage medium), a declaration of data destruction has to be signed by the person executing the destruction that includes the identity of the destroyer, the date, the method used to destroy and a signature that destruction took place.

Data destruction declarations are stored and copies available on request.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

At least once every year, a workshop takes place with staff of the services to identify potential risks, attack vectors or improvements. Where possible, suppliers of supporting IT services are included in the workshops. The outcomes of the workshop are documented and identified risks are treated according to existing Risk Management practices. Recommendations to improvements to baselines are shared with the CISO Office.

Technical specification:
–

Handleiding

Last updated: 17-8-2020

After incidents are established, the University communicates as openly and truthfully to affected parties/subjects as is permissible without sharing details of active vulnerabilities.

At least this communication details the extent of the incident, the suspected causes, the steps taken to mitigate risks, what will be done in the future to prevent further incidents and what people can do themselves to further reduce their risks. Furthermore, contact details of the organisation will be given for questions regarding the incident.

Technical specification:
For data breaches involving personal data, see this page on what to do regarding communicating to data subjects: https://intranet.uu.nl/datalek-melden-aan-betrokkenen .

Handleiding

Last updated: 30-10-2020

Critical processes are identified and there are plans for how to proceed under conceivable crisis-situations such as non-availability of supporting IT services. These plans are tested, and revised and updated every 3 years.

Technical specification:
–

Handleiding

Last updated: 30-10-2020

Changes to processes are evaluated for security impact. There will be checked if there are reasons to update the classification of the data processing activity and appropriate measures are taken.

Technical specification:
–

Handleiding

Last updated: 5-6-2020

Projects reserve sufficient time, manpower and budget to assess and adhere to information security policy.

Technical specification:
A rationale for the reservations for security needs to be present. Without a rationale, a 5% of project budget for security and privacy is a recommended minimum.

Handleiding