FITS OM: Authorisation
Once users have been authorised to access the school network, they can access the services they require. Most student users, however, have only limited access to the network.
Authorisation is the mechanism by which user access is determined. User access must always follow the 'least privilege' principle, which states that users may have the access required to perform their required functions and no more. Technical support staff, on the other hand, should have full access to the network.
The most common way of implementing authorisation is with role-based access control (RBAC). RBAC means that users with the same need should have the same access to the system. This is important for auditing purposes because if a relatively large number of people are grouped into a relatively small set of access roles (for example, students), it becomes easier for an auditor to see if someone has access that he or she should not have. In setting up access roles, there is a very fine line between maintaining least privilege and maintaining RBAC: it is true that least privilege requires many roles with fine distinctions between them, whereas true RBAC requires a minimum number of roles for a maximum number of users. The balance is somewhere in the middle and varies from school to school.
A school could adopt the following RBACs as standard:
- Student
- Teacher
- School administrator
- School manager
- ICT staff.
Best practice for schools is to implement all user accounts to the lowest common denominator (such as a student profile) and only provide additional privileges based on further defined roles. The granting of additional privileges on the school network should only be allowed through the access control forms.
When setting up authorisation in your school you should consider the following:
- Accountability and shared user IDs
Whenever a user creates a security-relevant event on the system, whether it is authorised or not, that event is recorded in the audit log, along with the user ID that caused the event to occur. Therefore, for accountability, it is important for each user to have an individual user account and for no one to share user accounts.
In a primary school where a child may not be able to remember a user name and password, it is sometimes necessary to have a single logon and no password. If this is the case, set the RBAC at the lowest possible level providing no access other than to materials that support the curriculum and their classroom work.
- Account lockout
Another way in which hackers try to gain access to a system is by what is called a brute-force attack. This is when they keep trying guessed passwords until they guess correctly. A good way to reduce this risk is by configuring the system to lock out a user's account after a specified number of failed logon attempts due to incorrect password entry. It is possible to configure systems so that a locked-out account can only be unlocked by technical support staff. Thus users who get locked out have to identify themselves to the service desk and confirm that they made a mistake or forgot their password. If users find their accounts locked out and they were not at fault, this may be an indication that someone is trying to break into the system.
The account lockout policy controls what happens when someone enters an incorrect password. The policy should be established to allow users who mistype passwords to give it another try or two. However, you should establish a limit that discourages intruders from continually trying until they guess a user's password.
Account lockout can create a lot of extra work to implement as technical support staff not only have to change passwords but also have to unlock accounts. RBAC could impose account lockout for 'sophisticated' users, but not for the 'student' profile with limited privileges.
- Settings to limit unauthorised systems access
One common way for malicious users to access the system is to wait for someone to leave a workstation unattended and gain access through that individual's account. There are several ways to minimise the possibility of this happening. The first is procedural: the school should provide regular security-awareness training to all users and educate them regarding the following:
- The importance of locking their screens or logging out of their sessions before leaving their desks, even if they think they will only be gone for a few minutes
- How to lock their screens or log out of their sessions.
Proper training is the key to any effective security policy.
The other mechanism is a simple technical implementation. Configure systems to lock out a user's session automatically after no more than 15 minutes of inactivity. When the system (or the user) locks out the session, the screen appears covered by a solid colour or a screen saver so that an observer cannot see what the user was working on, and the user must re-authenticate before returning to the session.
- Setting permission on network resources
Privileges and permissions can be set to control access to specific objects (files, folders, colour printers and so on). The level of detail to which this can be accomplished depends on the structure of the operating system and the nature of the file system. You should set this up appropriately beforehand using the advice in Directory Services Administration.
Most computer operating systems allow you to tie accounts to specific computers. So, for example, the office manager account may only be able to be used on computers office01 and office02. This makes sure that this account can only be used in a secure area.