On and Off-boarding users

The on and off boarding process for users is an important consideration for any IT system. A sound on and off boarding process ensures that users can only access what they need to access, the user is authenticated and access can be revoked as required. The on boarding process ensures that users are authenticated and 'Principle Of Least access Privilege' (POLP) is applied (POLP works by allowing only enough access to perform the role / required task).

The registration / approval process can be segregated by permissions and roles to maintain system (and data) access integrity. System permissions ensure duties are segregated throughout the system and data access. Additionally, when a user has been added, a 2nd step of authentication can be included as required. The off boarding process ensures that data privacy and integrity is maintained - Users should be denied access to the system as soon as their access is no longer relevant.

The prime on and off boarding process and features align with the ISO 27002 Code of Practice (clause 9 'Access Control'), providing effective security practices;

Code of Practice ‍

A.9.1 Business requirements of access controlA.9.1.1 Access control policy

• Documented in the finao confluence space
• System Admin vs Admin vs Module Admin
• POLP
• Off-boarding process

A.9.1.2 Access to networks and network servicesN/AA.9.2 User access managementA.9.2.1 User registration and de-registration

• User registration workflow (on-boarding)
• Admin assigns role (according to POLP)
• Form history and system logs
• Off-boarding process (including inactive and deactivated user management)

A.9.2.2 User access provisioning

• Access rights per role is periodically reviewed
• Role and associated access is documented
• Only System Admin can assign 'high risk' roles (privileged accounts)

A.9.2.3 Management of privileged access rights

• Only System Admin can assign privileged accounts
• System Admin vs Admin vs Module Admin
• Role access is periodically reviewed

A.9.2.4 Management of secret authentication information of users

• Password policy (10 characters using alpha numerics and special characters)
• Code sent by text for authentication / authorisation

A.9.2.5 Review of user access rights

• Roles and access rights per role is periodically reviewed

A.9.2.6 Removal or adjustment of access rights

• Off-boarding process (including inactive and deactivated user management)

A.9.3 User responsibilitiesA.9.3.1 Use of secret authentication information

• On-boarding process can include acknowledgement of ISP / terms of use etc

A.9.4 System and application access controlA.9.4.1 Information access restriction

• Documented in the finao confluence space
• System Admin vs Admin vs Module Admin
• POLP

A.9.4.2 Secure log on procedures

• Username and password (10 characters using alpha numerics and special characters)
• 2-factor authentication enabled

A.9.4.3 Password management system

• Password policy (10 characters using alpha numerics and special characters)
• No passwords sent to users
• Password storage is separated from other data / application

A.9.4.4 Use of privileges utility programs

• Controlled internally in finao using POLP
• 2-factor authentication enabled
• All access is logged

A.9.4.5 Access control to program source code

On-boarding process

• Register user
• Approve user
• User receives email to set password
• User receives text for authentication

Off-boarding process

• If an email has been bounced to a user then Admin is notified - This may indicate that their work email has been terminated
• Inactive users are moved to the Inactive tab (after 30 days of inactivity)
• After a further period of being in the Inactive tab, the user is deactivated
• The period of inactivity / deactivation can be set in the Admin console to suit an organisation's specific needs