Maatregelen
IS.01.001. Security Capability Level
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
IS.01.002. Asset Registration
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
IS.01.003. Periodic Check of Asset Registration
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.
IS.02.001. Privileged Access
Last updated: 24-10-2024
Privileged Access involves all access that exposes more functionality than regular users have on any layer of the IT service infrastructure. Authorizations for privileged access are required to follow all principles governing authorisations from the Knowledge and Data Security controls, including Least Privilege (just-enough admin).
Privileged Access is just-in-time, meaning it is only used for when needed and regular user actions are not performed using the privileged account.
Privileged access is demonstrably limited to authorized personnel, an authorization matrix is available for this access.
Technical specification:
Technical Specification
Personal privileged access to systems is done with a personal privileged account. Types of privileged access, that are separate duties, have different personal privileged accounts. Non-personal privileged access is done using non-personal privileged accounts (see IS.2.002).
Authorizations assigned to privileged accounts are based on the principles of segregation of duties, and least privilege.
Role based access management is used. Roles are defined based on tasks, responsibilities and privileges aligned with the procedures in place for the processes handled within the system.
Personal privileged accounts are disabled as soon as the user no longer requires the permissions or account to perform their duties.
Non-personal privileged accounts are set up for a specific task and are disabled/removed when that task is no longer performed. Non-personal privileged accounts are not reused in different applications and services. Example: Do not reuse a database service account for printer management.
Reviews are done to find and disable unused privileged accounts according to classification levels:
Basic: Yearly
Sensitive: Quarterly
Critical: Monthly
Privileged assets are managed using Privilege Access Management (PAM) tooling. Changes are administered using a CMS/ITIL tool with complete audit logging.
IS.02.002. Service Accounts
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
IS.02.003. Separate Accounts for Privileged Access
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.
IS.02.004. Session Management for Privileged Access
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.
IS.02.005. Break Glass Procedure
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.
IS.02.006. MFA for Privileged Access
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.
IS.03.001. Vulnerability Registration
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.
IS.03.002. Vulnerability Risk Estimation & Resolution
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.
IS.03.003. Coordinated Vulnerability Disclosure Policy
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..
IS.03.004. Automated Vulnerability Scanning
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.
IS.03.005. Automated (Web-)Application Vulnerability Scanning
Last updated: 24-10-2024
(Web-)applications are subjected to (web-)vulnerability scanning. Depending on the classification of the application the interval of scanning is:
Basic: At least once every year
Sensitive+: At least once every 6 months
New and updated (web-) applications are scanned for vulnerabilities before going live or with major changes.
Recent scan reports are available.
Technical specification:
Web application scanning is done to find errors in web applications such as those listed in the OWASP top 10.
Dynamic Application Security Testing (DAST) is applied. If a web application is critical in any of the CIA segments, then Static Application Security Testing (SAST) needs to be applied in addition to DAST.
Scanning of applications that have different user privileges is done at multiple authentication levels: public, standard user and privileged user.
Security Operations ITS of the UU has a service for DAST (web) application scanning.
IS.03.006. Penetration Testing
Last updated: 24-10-2024
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:
Security Operations ITS (SecOps) has a penetration testing service and should be consulted for all penetration tests of the UU network and systems.
For penetration tests done by suppliers (including cloud suppliers), performed outside of the UU context, SecOps can advise on the required summary of the results and follow up.
IS.03.007. Update Management
Last updated: 24-10-2024
Only supported software can be used. End-of-Life or End-of-Support software /hardware is not allowed.
For Sensitive and higher classifications: Additionally, any internally developed software must have a designated data management plan and a software management plan in place before it is deployed. These plans must outline the support responsibilities, maintenance activities, and the expected lifecycle of the software. Internally developed software can only be used if it is fully supported and maintained for its entire expected usage duration by the responsible team within the organization.
Software is tested and installed according to a documented and defined patch cycle.
System owners are required to proactively obtain information relevant to their systems to ensure they remain up-to-date with the latest security patches and updates. System owners must ensure that all updates are assessed for their relevance and impact on their systems and must schedule and apply patches and updates according to the change management process. External services must adhere to the same policy regarding update management (or a stricter one).
Unpatched systems will be treated in accordance with the vulnerability management process.
Technical specification:
InsightVM, our Vulnerability scanning service, can also detect outdated software automatically with high accuracy, when an additional agent is deployed on the target systems. Users can create automated reports to receive a list of systems that are using outdated software.
Make sure the updates are from a trusted source, like the official site of the manufacturer, and be sure the file is not altered in transit, e.g. by verifying the hash or CRC code.
A description of the UU change management process can be found on Sharepoint: link. Or contact the change manager ITS for a hardcopy.
IS.3.002 describes the process for unpatched systems and describes maximum tolerable resolution times.
Note that some older protocols are not allowed anymore. More information on these protocols can be found in Deep dive – SMB, NTLM en LDAP.
https://solisservices.sharepoint.com/sites/10046/ChM/Documenten%20van%20Changemanagement/Forms/AllItems.aspx?viewpath=%2Fsites%2F10046%2FChM%2FDocumenten+van+Changemanagement%2FForms%2FAllItems.aspx&id=%2Fsites%2F10046%2FChM%2FDocumenten+van+Changemanagement%2FProces%2C+procedures+en+werkinstructies%2FProces+beschrijving+Change+Management_V3.4.pdf&viewid=5d254635-dc8f-4521-ba51-6c8faf4cbd2b&parent=%2Fsites%2F10046%2FChM%2FDocumenten+van+Changemanagement%2FProces%2C+procedures+en+werkinstructies
https://solisservices.sharepoint.com/:w:/s/10824/EVQoo0wrS-1GqFAqED1DhiQB7xrrmMlzBMUhe8MFvN5o6Q
IS.03.008. Emergency Updates
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.
IS.03.009. Hardening Validation
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.
IS.03.010. Rollback Procedure
Last updated: 30-7-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:
IS.04.001. Network Documentation
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:
–
IS.04.002. Networking Hardware
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.
IS.04.003. Network Segmentation
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.
IS.04.004. DMZ
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.
IS.04.005. Firewall Rule Management
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”
IS.04.006. DDoS Network Protections
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
IS.04.007. Secure ISO Layer 2 & 3 Protocols
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.
IS.04.008. Network Access Control
Last updated: 24-10-2024
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
Is.04.009. Network Naming Security
Last updated: 24-10-2024
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.
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, including DNSSEC validity
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 with limited scope is only accessible within that scope. This means access control lists 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).
DNS service is monitored for availability and correctness, including DNSSEC validity
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 with limited scope is only accessible within that scope. This means access control lists 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).
IS.04.010. Server Internet Access
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:
–
IS.04.011. Critical Systems in Own Segments
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.
IS.05.001. Clock Synchronisation
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
IS.05.002. Remote Logging
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.
IS.05.003. Mutation and Data Access Logs
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.
IS.05.004. Authentication Attempts
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.
IS.05.005. Log Protection
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.
IS.05.006. Logging of Log Access
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.
IS.05.007. Logging of Network Access
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.
IS.06.001. Exit Strategy
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:
–
IS.06.002. Emergency Power
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.
IS.06.003. Internet Connectivity Redundancy
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
IS.06.004. Throttling
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.
IS.06.005. Data Centre Uptime
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:
–
IS.06.006. Data Centre Uptime Guarantees
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:
–
IS.07.001. Risk Monitoring
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:
IS.07.002. Egress & Flow Monitoring
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:
–
IS.07.003. Abuse Case Identification and Monitoring
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
IS.07.004. Password Monitoring
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.
IS.07.005. Intrusion Detection System
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.
IS.07.006. Red Teaming
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.
IS.07.007. Network Intrusion Prevention Systems
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:
–
IS.07.008. Contact With Industry Monitoring
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:
–
IS.07.009. Certificate Monitoring
Last updated: 30-7-2020
There is monitoring for CT-logs for certificates that seem to be issued to the organization.
Technical specification:
–
IS.07.010. Spoofing and Fraud Monitoring
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
IS.07.011. Advanced Persistent Threat Monitoring
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
IS.08.001. Local Privileged Accounts
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:
IS.08.002. Endpoint Updates
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.
IS.08.003. BIOS protection
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:
–
IS.08.004. Data Storage Encryption
Last updated: 24-10-2024
Data at rest must be stored encrypted
Technical specification:
Full disk encryption is preferred, using trusted key management and trusted boot to a managed operating system to allow access.
Encryption of data at rest, including full disk encryption, uses Advanced Encryption Standard (AES) with at least 128 bit key length. Masterkeys should be fully random and unlocked with password-based key derive functions.
Managed devices should have a managed encryption unlock key. On access to these managed encryption keys, a new key should be generated and the unlock key replaced (for example Microsoft Bitlocker Administration and Monitoring).
Endpoints should support Secure Boot and storage of keys in a Trusted Platform Module (TPM).
IS.08.005. Scripts and Executables
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.
IS.08.006. Malware Protection
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.
IS.08.007. Memory Protection
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.
IS.08.008. Screen Lock
Last updated: 24-10-2024
After a period of inactivity, on a managed workstation, the session/screen is locked and the user is prompted for authentication again.
Users must be trained to lock their screen when they step away from the workplace.
Technical specification:
A screen lock policy must be centrally managed. The screen lock policy must be enforced on all managed workstations. The policy should automatically lock the system after 15 minutes.
IS.08.009. Data in Managed Environments
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.
IS.08.010. Remote Wipe of Organizational Data
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
IS.08.011. Public Workspace Security
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:
–
IS.08.012. End-Point Backups
Last updated: 4-2-2021
Data is not primarily stored on endpoints but in environments with appropriate capability levels.
Technical specification:
–
IS.08.013. Host-Based Firewall
Last updated: 24-10-2024
On managed endpoints, the local firewall policies are maintained, reviewed and enforced based on business and security needs.
On unmanaged endpoints the host-based firewall should adhere to least privilege principles.
Technical specification:
ost-based firewalls should be configured to prevent unwanted traffic between endpoints, and to protect the endpoint if exposed to an untrusted network, such as public wifi.
Management traffic and remote login should only be accepted from approved hosts and networks
On systems classified as Sensitive or higher, the risks of administrator lock-out due to (firewall) configuration errors should be assessed and managed.
Both IPv4 and IPv6 and common transport protocols (TCP, UDP) should be supported. If one of these protocols is (partly) unimplemented, the resulting behaviour should be well-known.
Modern implementations, such as application-specific rules and dynamic blocking of risky domains and other known-malicious traffic, are preferred over traditional (static) solutions.
IS.09.001. Authentication Through Trusted Identity Provider
Last updated: 24-10-2024
End-user authentication for applications takes place through a trusted Identity Provider (IdP).
The organisation has a defined relationship with individuals that have been given access, either directly or through contractual agreements with third parties.
Only production environments can be linked to production IdPs.
Technical specification:
Authentication services work on a basis of pre-established trust relations between the service requesting authentication and the identity provider (IdP) handling the request. This process uses a combination of encrypted/signed transfer of authentication material, authorization tokens and user information.
The identity provider maintains centrally managed identities for the organization and shares information about these identities with service providers (SP) when needed for the operation of those services. SPs need to use a IdP that is trusted by the UU to authenticate users.
Authentication services by the IdP are based on the SAML or Oauth 2.0 protocol (direct or through a trusted broker like SURFconext).
System authentication for operating system logins is supported through secure authentication protocols as supported by operating system vendors, using established trust relations between systems and authentication services.
IS.09.002. Password complexity & rotation
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
IS.09.003. PIN and biometrics
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
IS.09.004. Password Visibility
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.
IS.09.005. Multi-Factor Authentication
Last updated: 24-10-2024
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.
Users are allowed to mark devices as trusted, not requiring MFA on that specific device for a maximum period of 30 days.
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
IS.09.006. Re-authentication for Critical Functions
Last updated: 28-4-2021
Users need to use a second factor to authenticate before accessing sensitive data or functionality.
Only ‘what you know’ and ‘what you have’ are considered factors for MFA.
Multi-layer authentication, twice the same authentication factor, is not MFA. Two-factor authentication is only two-factor when both steps are different factors.
Biometrics are not used as factors but can be used as a usability feature in place of a PIN.
MFA-tokens used as factors are user-specific and measures are in place to safeguard that these tokens remain strictly personal.
MFA implementations confirm to at least MFA level 2 as specified.
No distinction is made in location when it comes to MFA. There is therefore no difference between an internal- and an external network for MFA.
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.
IS.09.007. Session Timeout
Last updated: 24-10-2024
After a period of inactivity in an application, a user session should be locked or terminated and require re-authentication.
The duration of inactivity required to force a re-authentication event is determined by the maximum classification of the actions and data to which the user has access. If this is not clear or possible, the classification of the application itself will be used.
In applications with a security capability of critical closing the browser must invalidate the session on the application.
Technical specification:
For non-privileged sessions: The session is locked or terminated after it times out. The user only needs to re-authenticate to regain access to the session or start a new one.
Depending on the highest of the CIA-levels of the Security Capability Level of the IT service the maximum idle time within the session is as follows:
Basic: 1 day
Sensitive: 2 hours
Critical: 60 minutes
Additionally, on sensitive and critical levels sessions should be closed when the browser or application is closed.
For privileged sessions: Sessions need to be tracked on the server side of the application as well. The server must also invalidate the session when it expires.
IS.09.008. Forced Session Termination
Last updated: 24-10-2024
Administrators are able to terminate user sessions on applications in the event of compromised accounts or the immediate termination of individuals. This is preferably done through the application.
A procedure is communicated to the system administrators for executing the emergency session termination. Within 30 minutes of starting the procedure, the user’s session must be terminated. This includes cases where the supplier has to manually terminate a session. This procedure must be supported throughout opening hours (09:00 – 17:00 CEST 5-days a week).
Technical specification:
–
IS.09.009. Unique Identities
Last updated: 24-10-2024
Personal accounts belong to one specific natural person, but a natural person can have more than one account. Personal account ownership is never transferred or re-issued. This includes e-mail addresses.
After individuals have left the organization, their legal & natural identities are kept for a predefined period of time, based on business and legal requirements.
Digital access can always be traced to a unique individual.
Appropriate measures are taken to ascertain the identity of a natural person.
Technical specification:
–
IS.09.010. Review of Account Activity
Last updated: 24-10-2024
Trusted identity providers (IdP) must have a view for users to review their account activity that shows their latest login activity including when, from which location and which device they logged in. Users can report suspicious behaviour from this portal and are prompted to change login credentials when abuse is suspected.
Technical specification:
–
IS.09.011. Session and Identity Correlation
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.
IS.09.012. Secure Authentication Systems
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
IS.09.013. Access Control
Last updated: 24-10-2024
Access Control is used to determine the level of access users and devices are given to UU services and resources. Access to these services requires both validated users and validated devices. Device authentication (preferred) or validation of its attributes (less preferred) ensures that the device is under organizational control and meets required specifications. Validated users with unvalidated devices may get access to a guest network or limited access to specific cloud services.
To enhance security and ensure appropriate access levels, users and devices are categorized as follows, with each category having different levels of access to our services and resources based on the compliance status of the device:
-Employees and students using centrally managed workstations.
-Employees and students using decentrally managed workstations.
-Individuals (employees, students, and guests) using ‘Bring Your Own Device’ (BYOD) devices.
-Individuals (employees, students, and guests) using BYOD devices that have been registered and actively monitored on OS version, patch level, AV status, and other specifications.
Technical specification:
IS.10.001. Physical Access Limitations
Last updated: 30-7-2020
Access to IT systems is limited to authorized personnel according to the NIST Special Publication 800-53: https://nvd.nist.gov/800-53/Rev4/control/PE-3 .
Technical specification:
Locations on UU campus housing IT infrastructure used in supporting the service need to be identified to FSC Security and treated according to Physical Security classification level 5. Restricted Area or higher.
IS.10.002. Advanced Physical Access Protection
Last updated: 30-7-2020
Access to IT systems is limited to authorized personnel according to the NIST Special Publication 800-53: https://nvd.nist.gov/800-53/Rev4/control/PE-3 including the control enhancements.
Technical specification:
Locations on UU campus housing IT infrastructure used in supporting the service need to be identified to FSC Security and treated according to Physical Security classification level 6. Secure Area or higher.
IS.10.003. Procedures Working in Secure Areas
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:
–
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:
–
IS.10.005. Inspection of Physical State of Equipment
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:
–
IS.10.006. Auditing of Access to Areas
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:
–
IS.11.001. Recovery Time Objective and Recovery Point Objective
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
IS.11.002. Testing of Back-Ups
Last updated: 30-7-2020
Restores of backups are tested at least annually and the results of the test are documented.
Technical specification:
–
IS.11.003. Offline Backup
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).
IS.11.004. Communication Backup and Uptime
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:
–
IS.11.005. Disaster Recovery Plan
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:
–
IS.12.001. DTAP
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.
IS.12.002. Data for Testing
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:
IS.12.003. Changes to Production
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:
–
IS.12.004. Secure Coding Training
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
IS.12.005. Static Code Analysis
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
IS.12.006. Configuration Files
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.
IS.12.007. Security Update Packaging
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:
–
IS.13.001. Administrator Data Access
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.
IS.13.002. Email Data Leakage Protection
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:
–
IS.13.003. Email Forwarding
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:
IS.13.004. Data Exfiltration Detection and Prevention
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.
IS.13.005. Unintended Information Disclosure
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.
IS.13.006. Printing Data-Leakage Prevention
Last updated: 28-4-2022
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.
IS.13.007. AI training Data-Leakage Prevention
Last updated: 24-10-2024
AI tools do not use production data, including user prompts, to (further) train the underlying AI models. This also prohibits the entry of data (including questions from which sensitive matters can be derived) with confidentiality ‘1. Basic’ or higher in tools where it is not explicit that this data may not be used.
AI tools are only allowed if they assure the UU that all UU prompts and answers are not used to train the model. Models trained on UU training data may only be used within the context of the UU.
Technical specification:
This applies to all AI tools such as machine learning platforms, natural language processing systems and other AI-driven applications.
AI tools and systems should perform data sanitization to prevent user data entering the training model.
IS.13.008. IdP Restriction of device and application access
Last updated: 24-10-2024
All non-essential (IoT) devices, including, but not limited to smart speakers (e.g., Amazon Alexa, Google Home), smart appliances, and any other device that does not support UU’s essential business functions, are strictly prohibited from connecting to the UU IdP.
Technical specification:
IS.14.001. Application Session Management
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.
IS.14.002. Input and Output Filtering
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
IS.14.003. Web Application Security
Last updated: 30-10-2020
Web applications have taken all appropriate measure to protect against OWASP top 10 Web Application vulnerabilities: https://owasp.org/www-project-top-ten/
.
Technical specification:
Cookies have the following flags by default: Secure, HttpOnly, Domain=[domain], SameSite=Strict
CORS wordt zo ingericht dat alleen de benodigde toegang wordt verleend https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
IS.14.004. Mobile Applications
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.
IS.14.005. Application (D)DoS Protection
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.
IS.14.006. Malware Scanning
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.
IS.14.007. Third Party Apps and Libraries
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.
IS.14.008. Application Authorisations
Last updated: 24-10-2024
Authorisations are preferably centrally managed.
Technical specification:
Access to an application is authorized by its owner.
IS.15.001. Default Passwords changed
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.
IS.15.002. Service Hardening
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.
IS.15.003. Server and Application Infrastructure Not Shared
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.
IS.15.004. White-Listed Applications
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.
IS.15.005. Portable Media Hardware Protection
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.
IS.15.006. Disk Encryption or Removal Protection
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.
IS.15.007. Legacy Systems
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:
–
IS.16.001. Organizational Data Deletion
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
IS.16.002. Purging of Data Media
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.
IS.17.001. Encrypted Connections
Last updated: 24-10-2024
All data in transit is encrypted.
Technical specification:
For TLS based protocols including but not limited to https use the latest version of our deep dive on TLS, available at https://solisservices.sharepoint.com/:w:/s/10824/EWufJC7WWJVIr3eKqOBVc88BimyCynLCKAhmGa7mn5B7Mg
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.
IS.17.002. Official Mails Sent From Organisational Address
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.
IS.17.003. Mailserver Security
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 . ”
IS.17.004. Mailsender Non-Repudiation
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:
IS.17.005. Domain reservations
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:
–
IS.17.006. Labelled External Communication
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.
IS.18.001. Incident Response Process
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
IS.18.002. CSIRT
Last updated: 24-10-2024
The UU has a Computer Security Incident Response Team (CSIRT) handling IT security related incidents
The CSIRT is mandated to respond to active threats and to take all necessary measures to limit the impact of ongoing or potential security incidents.
Technical specification:
The CSIRT mandate includes the authority to order corrective measures as part of triage.
The CSIRT has the necessary insight/experience/knowledge to handle security incidents, assess information security risks and select appropriate triage methods.
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 and kept up-to-date with the upstream CSIRT and in the trusted introducer listings at https://www.trusted-introducer.org/.
Organisation users are made aware of the CSIRT. People responsible for IT services are aware of the CSIRT and its mandate.
The CSIRT maturity is reviewed annually.
The UU CSIRT is CERT-UU, information at: https://www.uu.nl/cert
IS.18.003. Law Enforcement
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.
IS.18.004. Forensics
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.
IS.18.005. Safeguards for Incident Reporting
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.
IS.20.001. Certificate Management Registration
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
IS.20.002. Certificate Revocation
Last updated: 14-10-2024
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.
See also Deep dive Transportversleuteling met TLS
https://solisservices.sharepoint.com/:w:/s/10824/EWufJC7WWJVIr3eKqOBVc88BimyCynLCKAhmGa7mn5B7Mg
IS.20.003. Certificate Crisis Plan
Last updated: 4-2-2022
There is a documented procedure for dealing with situations in which mass replacement of TLS certificates is needed. The target is to return to a normal situation with valid certificates as soon as possible.
Technical specification:
This procedure describes:
• Governance
• A list of pre-approved backup certificate suppliers
• A link to the list of current certificates
• Instructions for setting priority in replacing certificates, based on impact
• Steps to replace the certficates
• Steps to ensure the certificates used in the crisis situation are managed properly