In part two of our look at the Cyber security standards we will focus on the standards that relate to user accounts and their security, namely:
- Accounts should only have the access they require to perform their role and should be authenticated to access data and services
- You should protect accounts with access to personal or sensitive operational data and functions by multi-factor authentication
Restricting the ability of potential attackers using the rights of standard user accounts to deploy and execute malware is a powerful way to limit the threats and so a principal known as least privilege has long been part of the best practice approach to delivering IT.
There is a trade-off though between locking down accounts while still allowing users to do the things they need to do and make best advantage of the technology available. There are also some users who will need elevated privileges, system administrators for example, and these accounts require additional attention to ensure they are secure.
As discussed in Part One of this series, passwords are not a great way to secure systems and as a result additional layers of security should now be considered to further protect the user accounts.
User Accounts
As with most things relating to security there is a mix of technical measures and policy/process interventions to drive behaviour. This is certainly true with this particular standard.
Unlike the earlier standards there isn’t a simple list of things to tick off – partly because for this to be effective it is as much the policy and process side that needs to be in place.
The first important thing to ensure is that users can only access devices and the network with a user account that is unique to them. To do this it is important that there is a policy on user access to be clear who gets access to what systems and with what level of privileges. This should include not just staff and students but also consider how others gain access, for example 3rd-party contractors or visitors.
To ensure this there should be a clear process for the creation of user accounts. For students this may be automated as part of their enrolment into the student records system and this would be best practice as it removes the chances of errors that can arise from re-entering data manually.
For staff and other accounts the process should have a clear authorisation mechanism and ideally would be part of the wider HR processes so that IT only get asked to generate accounts when HR are satisfied that the request is for a genuine and approved member of staff.
Similarly, there must be a mechanism for removing user accounts when someone leaves and again for students this may be automated when they are marked in the student records system and for staff this should be part of the HR process with HR giving IT a list of accounts on an agreed timely basis.
One thing to note on this is that the process may need more nuance when using cloud services as the primary store of user data, as removing the account may well trigger the removal of the data associated with that account so an intermediate step to lock the account for an agreed duration to preserve the data may be advisable.
The user lifecycle process for staff should also include an element to deal with situations when staff move between departments to ensure that they only retain access to the data that their new role requires and removes access to data relating to their old role. This would cover both file data and access to business systems.
This raises another point not directly referenced in the standard. When looking at user accounts it is too easy to consider only the main logon account that grants access to the system overall, however the exact same principles should apply to any other system that requires a username and password. Individual system owners where they exist should have a process for authorising the issuing of account credentials that as a minimum matches the main user account process.
By default user accounts should be created on the basis of least privileges. That is to say, the access rights assigned to an account should be the minimum to allow the user to operate effectively. This can sometimes lead to conflict as users feel constrained when they need to seek intervention from IT to, for example install software, however this isn’t only a question of enhancing security, it also allows the organisation to ensure only licensed software is used.
Clearly there are those within an organisation who need increased rights for them to be effective in their role. Even here though the principle of least privilege should apply. Namely, the default for those who need enhanced rights should not be the global administrator role if there are other roles that would fulfil the requirement without giving unfettered access.
Whatever role and permissions applied, the account should only be used for the tasks requiring the enhanced rights and should not be used for general, routine business. This means that administrative users should have at least two accounts, one with enhanced right used to undertake tasks requiring those privileges and another for general use such as internet browsing or email.
This should be enshrined in policy and where possible there should be an audit to ensure that people are using the right account. Clearly, human nature would be to use the account with the highest privileges all the time but this creates a potential security issue were the account to be compromised.
Further to the standard policy there should also be a consideration as to whether those with elevated access rights should be bound by a specific code of conduct of which using the correct account would be a section. The code of conduct also gives the systems admins added legal cover in the event that they have to access data that they would not normally have access to without specific consent from the data owner.
The next section looks in more depth as additional measures that can be implemented to further protect user accounts.
Accounts should all be subject to a password policy that has some basic considerations namely:
- A minimum password length must be set at a system level
- If using a deny list the minimum should be 8 characters, if not the minimum should be 12 characters
- The NCSC recommends using 3 random words rather than a standard password
- Accounts should become locked after a number of failed attempts
Passwords must be reset if a password has been compromised or suspected of compromise. This needs end-user training to be aware of the signs that their account may have been compromised. The training should also include training on how to select a strong password or passphrase.
There is another important form of account that needs special attention. Usually only used for software running at the server level, a form of account called a service account often has access rights at the highest level to allow it to function. These are clearly very attractive accounts for would-be attackers as they in some cases will grant full access to the server and the wider network. Therefore protection of these accounts is critical.
Firstly, software and services that require a service account should not be configured with a user’s account. They should have a unique account for each service and these should be documented. Service accounts should, where possible, be set to not allow interactive logon – that is not able to be used as a standard user to logon to Windows for example. Finally, these accounts should have a unique and highly complex password assigned and documented.
In Part One we looked at the subject of password manager software and service account passwords are an excellent reason why such software can be extremely valuable. The software can both generate and store the passwords so that only authorised personnel can view them.
With all of the above said, the standard then goes on to look at use cases where the advice may not apply. Specifically it looks that how to manage cases where we are dealing with younger children or users with special educational needs.
In some cases, the very devices used may not support individual user accounts, for example, iPads.
The first thing to consider would be; what data will the user have access to? If it is a younger user they may only be accessing an app on an iPad that doesn’t use the network other than to access the internet. If the user doesn’t have access to sensitive data or the wider network it may be that a user account adds little to the security landscape.
The standard makes a number of suggestions:
- consider using authentication methods other than passwords – this would allow you to have separate user accounts but make it easier for say, someone with special educational needs, to log on and could be biometric or ID card related. In many cases, users with SEN will have specialised, dedicated equipment and so implementing special authentication methods should be considered as part of their initial assessment
- consider using a separate account accessed by the teacher rather than the student – again, this retains the benefits without the user having to deal with the authentication element although it would require the teacher or teaching assistant to remember the account details
- segment the network so such accounts cannot reach sensitive data – as with the iPad example above if a device is simply used to access apps and internet-based services then having them access wi-fi using a separate internet only mechanism would work. As an aside, the user of iPads by users accessing wider college systems and files does need further risk assessment as they are, unless part of a system to override their default operation, single-user devices not designed to work with authenticated user accounts
- consider if the data or service being accessed requires authentication – as above; if they are just using a device for internet access there may be no benefit to having user account authentication
The standard says that these measures should be implemented as soon as possible, however mostly this is long established best practice and should already be in place. In reality, there may be a mixture of implemented and not-implemented with the technical measures being broadly present but some of the process and policy elements not.
In particular not using administrator accounts to conduct general activities is an area often overlooked and is one for review.
Multi-factor authentication
Multi-factor authentication (MFA) describes a technology solution that requires more than one form of authentication to be used in order to access a system. The most common forms will require two different verification steps. Often this is described as something you know and something you have, typically a password and then either a code generated on a device such as a mobile phone or a hardware token.
Specifically the standard requires that any MFA implementation should require at least 2 of:
- password constructed in the formats described previously
- a managed device that may belong to the organisation
- an application on a trusted device (for example an authenticator app on a mobile phone)
- a device with a trusted IP address (although it specifically states not to use this in administrator account scenarios)
- a physical token
- a known/trusted account where a second party authenticates another credentials
- a biometric test
Although the title of the standard references sensitive operational data, the technical requirements recommend that all staff be encouraged to use MFA and that is a recommendation I would firmly endorse.
However, the main challenge in successfully implementing MFA is to do it in a manner that users find as unobtrusive as possible and that is why the list above contains a number of different options. While it adds to the technical complexity at the IT delivery end, implementing different MFA mechanism for different use cases will make user acceptance much more likely.
To see how this might work in practice, imagine a teacher who wants to check their email before heading to work and to do this is using an app on a smartphone. It may be that the email contains sensitive data and so to access would need to be authenticated. The first time the app is used it may ask for the password and require confirmation on an authenticator app on the phone that has been configured to provide the 2nd factor authentication.
Once in school, the teacher logs onto a laptop that is assigned solely to them. If at this point they have to use a password and a code it will be seen as cumbersome, however, from the list above we know that a combination of a known device and a known network can be used as additional factors so these will suffice alongside a standard logon.
Later, the teacher stops off on the way home to grab a coffee and fires up the laptop to do some work. This time the device may be known but the network isn’t so we may decide to require a further check is necessary.
When designing an MFA scheme it is vital therefore to understand users, devices and possible use cases before getting into the technology and should be based on a risk-based approach.
That’s it for part two. In the next part, we will move onto anti-malware, software licensing and ensuring that applications are safe.
