Informatiebeveiliging test

IT Controls

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

Last updated: 28-4-2021

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

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

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.

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:

Last updated: 28-4-2021

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

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

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


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

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

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

Last updated: 44596

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

Last updated: 3-8-2021

Accounts for privileged are separate from regular user accounts. If a user needs privileged functionality, a second (privileged) account will be created to keep the privileged and non-privileged activities separated.

Privileged Accounts usage is Just-in-Time, meaning they are only provided when needed and the access revoked after the tasks are completed

It’s prohibited to log in with privileged accounts on public facing services, only local services (with non-internet routable IP’s) may be configured to accept direct logins with privileged accounts.

There are additional protections to change or reset MFA access methods for Privileged Access, that involve validating the identity of the administrator before MFA tokens can be reset.


Technical specification:
For privileged accounts, the second factor must exist of a physical token that is handed out in person.

The UU password policy is applicable to Personal Privileged Accounts with the following exceptions:
• At least 15 characters
• Password rotation every 3 months

Tooling is used to dynamically perform automated searches of the enterprise for evidence and identification of privileged accounts, such as domain administrators or accounts that directly or indirectly (through inheritance of privileges) have privileged-account-level authority.

The PAM solution has built-in password management functionality and compliance can be enforced automatically. Out-of-compliance accounts are disabled and reported.

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.

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 after use of Break Glass Procedure

The CISO and Process Owners are informed of any usage of the break-glass procedure.


Technical specification:
Make use of a four-eyes procedure and sealed bags.

Last updated: 28-4-2021

Authentication for access using privileged accounts has Multi-Factor Authentication. This can include Multi-Factor Authentication to get access to a network and subsequent strong cryptographic asymmetric keys for authentication.

Devices cannot be marked as ‘trusted’ for Multi-Factor for privileged access.

Biometrics are not used as factors.

MFA-tokens used as factors are user-specific and measures are in place to safeguard that these tokens remain strictly personal.


Technical specification:
Authenticators must validate to Authenticator Assurance Level 3, according to NIST Special Publication 800-63 section 4.2: https://pages.nist.gov/800-63-3/sp800-63-3.html#sec4 .

Last updated: 30-10-2020

A system owner is responsible for maintaining a list of known vulnerabilities, including the associated risk of the vulnerability, when the vulnerability was reported, what action resolution was taken and the current status of the vulnerability. Vulnerabilities can be ‘resolved’, ’mitigated’ or ‘accepted’. If the vulnerability is ‘mitigated’, a new risk estimation needs to be done for the mitigating measures in place.

After resolution, resolved vulnerabilities need to remain registered for 1 year.


Technical specification:
Vulnerabilities are scanned and reported with a vulnerability scanner from a preferred supplier. System owners can ask for access to administer detected vulnerabilities. Alle production servers must be connected to this central scanning solution.

Last updated: 28-4-2021

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.

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

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.

Last updated: 4-2-2021

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

Scanning occurs authenticated where possible.


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

Last updated: 44596

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.


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

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

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

Last updated: 30-7-2020

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

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

Patching takes place in accordance with the change management process.

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


Technical specification:

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.

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.

Last updated: 28-4-2021

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

This rollback procedure can be requested.


Technical specification: