IT Controls
IS.1.001. Security Capability Level
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
IS.1.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.1.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.1.004. 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.2.001. Privileged Access
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
IS.2.002. Service Accounts
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
IS.2.003. Separate Accounts for Privileged Access
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.
IS.2.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.2.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 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.
IS.2.006. MFA for Privileged Access
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 .
IS.3.001. Vulnerability Registration
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.
IS.3.002. Vulnerability Risk Estimation & Resolution
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.
IS.3.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.3.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.3.005. Automated (Web-)Application Vulnerability Scanning
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.
IS.3.006. Penetration Testing
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.
IS.3.007. Update Management
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:
–
IS.3.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.3.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.3.010. Rollback Procedure
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: