Systems holding personal confidential information - part 2 (4.3.1 - 4.5.5)

Systems administrators by nature of their role have elevated rights compared to a normal user. Normal users’ access can be restricted to role and limited to what they need to do to perform, therefore protecting the organisation and themselves.

Conversely, administrators do not have the same level of role limiting protection, so it falls to the individual. Systems administrators therefore have a great deal of system power and with great power comes great responsibility. The system administrator needs the highest level of integrity in terms of respect of the confidentiality, integrity or availability of the systems they support.

The CIA triad

Confidentiality - ensuring you only view what you need to administer the system and not disclose sensitive information.

Integrity - ensuring you do not alter records inappropriately.

Availability - ensuring that systems up time is kept as high as possible and all maintenance is agreed to local standards.

Administrators should be accountable for that responsibility.

Use

Using an elevated account for high-risk activities such as reading email and browsing the web is a high-risk activity. This is because malware that can reside on emails or web pages can run with elevated access on that device.

For example, a single windows account used by an IT administrator for general Outlook and Chrome web browsing use that is also a member of the Domain Admins group in Windows Active Directory. This account is also used to manage servers with Active Directory Users and Computers as well as other Active Directory applications.

Your organisation should only grant privileged access on devices owned and managed by your organisation. The devices in scope are end user endpoints (PCs and mobile devices) not servers.

If there are circumstances where this is not possible this should be explained or managed as part of your risk management process. Such as the systems’ backend infrastructure being cloud based or managed as a service by 3rd parties on your behalf, however you may still have privileged access (at some level) to those devices/systems.

Logging

Privileged access users who have the highest level of access to systems can have a tremendous impact in resolving incidents when they occur, such as by reviewing changes made by a malicious attacker and reverting back to the original data. However, they can also unfortunately cause serious incidents due to their high level of access and increased responsibility.

In line with, and contained within, your logging policy, you should have the facility to store and retain all privileged user sessions for offline analysis and investigation. This will allow you as an organisation to examine the root cause analysis and identify areas for improvement.

Revocation

Due to the nature of these accounts having an elevated level of privileged access it is even more important that this level of access is revoked when no longer required.

This can be where the individual leaves the organisation or through role change (generally through disabling or deleting the administrative account). This is relatively simple to manage in line with any user (albeit it is more important it's done in a very timely fashion).

However, it is more difficult to monitor where an individual has not left or changed role but they no longer require escalated rights for that system. In such instances, users may accumulate rights resulting in administrator privilege creep.

It's important that your organisation is clear about who (or what in the case of automated functions) has authorisation to interact with the network and information system.

For people this journey starts with employment checks prior to employment. However, digitally, our primary concern is identification and authentication prior to access.

Identification being a digital identifier that signifies who you are and authentication a method of proving so. The most common combination being a username and password.

For those critical systems under the Network and Information Systems (NIS) directive you should ensure multifactor or hardware authentication is enabled unless there is an exceptional (and documented) reason for it not to be. 

It's important when identifying and authenticating 'things' (systems and devices), that things can have a higher threshold of identification and authentication than people.

For example, a device can have a longer identifier which is non guessable. It can also have a digital certificate. A system, such as a Windows account used in an automated script, can also have a longer identifier and an associated very high strength password.

The more factors the stronger the authentication.

Read the NCSC guidance on identity and access management.

Staff should understand that there is capability and capacity for their actions within systems to be monitored and recorded.

The more sensitive the system, the more granular and extensive the monitoring should be.

The type of activities that can be monitored include:

• creation of new items
• reading of items including navigating between items
• updating and modification of items
• deletion or disabling of items
• printing of items (what’s printed and to where)
• exporting or saving items outside the system

Typical recording events would also include the date and time, the user account used, and the ID of the device used.

Examples of monitoring recording events include:

• recording when a new user is added to a theatre’s system
• what patient records are viewed within a patient administration system
• a user account is disabled on a cardiology system
• a service users drug dosage is modified in a mental health administration system
• a clinical discharge letter is printed from a correspondence document management system

For each system, there should be an understanding of what events are monitored and how.

For example:

1. A theatre system monitors the creation, viewing modification, deletion of theatre slots, allocated patients and their demographics, movement of patients between slots and any administrative function, such as changing time units and turnaround between slots. This is through the proprietary system within the application developed by the supplier.
2. For Windows Active Directory, as well as the inbuilt Microsoft functionality, we employ a third-party tool XYZ that provides functionality logging against each administrator for their activity against all objects (CRUD), the schema and the ability to record and recover tomb stoned objects
3. We have many clinical systems by the same supplier (PAS, RIS, theatres, pathology and cardiology). They all have the same central Microsoft SQL monitoring system that can record all the common events (create, delete, update, view) for each record within the system. It can also look across systems to see who has interacted with a patient’s records through any interaction with any of the systems. We produce and act upon management intelligence, such as most viewed patient across system (such as during a recent high-profile patient case), the most modified patient record, the most active users.

This information monitoring logging should be recorded against each system holding personal data. If you have an established and well-regarded information asset register, this information can be appended to that asset record.

The organisation ensures that logs, including privileged account use, are kept securely and only accessible to appropriate personnel.

Staff awareness that their actions are monitored within systems can have a positive effect on reducing the more dubious action some staff can take within systems.

It's important that staff are reminded of monitoring. Delivery can take many forms – it can be a discrete event or part of a wider employee induction. It can be delivered face to face or digitally. It can form part of an annual email reminder, a Windows login banner, a Windows background or screensaver or more traditionally with posters.

However you choose to make your staff aware of monitoring, it’s important that it is effective and that you can measure that effectiveness.

Notification of staff can form part of your wider programme of staff guidance on confidentiality and data protection issues as covered in guide 1.

You should have a password policy (either individual or part of a wider policy) that covers giving staff advice on managing their passwords.

As a minimum this should cover:

• how to avoid choosing obvious passwords (such as those based on easily-discoverable information)
• not to choose common passwords (use of technical means, using a password block is recommended
• no password reuse
• where and how they may record passwords to store and retrieve them securely (such as through using a passwords manager)
• if password management software is allowed, if so, which

NCSC guidance - Password administration for system owners

NCSC - enhancing usability case study

You should have technical controls in place that support and enforce your password policy and help prevent password guessing attacks.

The types of technical controls can be group policy in Windows Active Directory with a group policy on password length, password age and history.

You should also look at account lockout. For example, in Windows AD you can set the number of failed attempts (threshold) and length of time for the lockout duration. NCSC recommends between 5 and 10 login attempts before the account is frozen, to avoid accidental lockout.

Technical controls enforce password policy and mitigate against password-guessing attacks.

Recently there has been a change in advice on not using complexity and not enforcing password expiry requirements on user passwords. This is to reduce burden on users, instead use a longer passphrase or avoid user generated password where possible (NCSC).

NCSC guidance - Password administration for system owners

Multi-factor authentication is enforced on all remote access and privileged user accounts on all systems, with exceptions only as permitted by the national MFA policy.

The national MFA policy requires that organisations must enforce MFA on all remote access, and on all privileged accounts on external systems, and should enforce MFA on privileged accounts on internal systems. If you rely on any of the specific exceptions allowed by the policy, you must provide (within your response to this assertion) a summary of your internal approvals and your plans to minimise or eliminate those exceptions. Full detail is given in the policy and explanatory guidance.

System accounts are those accounts not used by people but by systems. These can be standards in built-in system accounts, such as a Simple Network Management Protocol (SNMP) Community String or ones you create yourself such as an account in Windows AD, which requires domain admins rights to run several automated scripts.

These accounts should not use the default password such as public in the SNMP example.

You should remember that system accounts are not used by people so should not be bound by password attributes associated with people (they don’t have to be memorable). If the systems support it, they can be very long, very random and highly complex.

Systems or infrastructure with no concept of identity/accounts

There are devices (especially legacy ones) where there is no username and access is controlled through one password for that device. Generally, this password only login would give you extensive set rights as the device/system has no granularity of access, so it’s all or nothing and it tends to be all.

For systems and devices falling into this category the password should be high strength.

Social media accounts

Given the accounts by their nature are very public, social media accounts can represent an easy way to hijack an organisation’s public persona if weak or guessable passwords are used.

Social media should use passwords that are not easy to guess and are high strength.

You should avoid the top most leaked passwords.

You should have the ability to grant limited privileged access both in terms of scope and longevity.

This would be applicable to contractors and third parties undertaking specific or time limited tasks.

This can take the form of an account with a shortened expiry date, an account which is used for the task then disabled (such as one during a remote support session) or using an account that uses a one-time password where you control the password generator.

So those internet facing services including authentication services you use should utilise high strength passwords.

A high strength password, not guessable, not top most leaked backed up with technical enforcement (such as using password blocklists). This should be in line with current NCSC password guides.

NCSC - article about password deny lists

NCSC guidance - Password administration for system owners