It's important that once in a while you review your security posture, from the perspective of access management on your MaaS360 system. The access by both users comment but more importantly administrators, is something which needs to be reviewed by our customers, in order to ensure that their security posture is as tight and careful as it can be.
There are a number of places in the MaaS360 console where you can review access and make sure that it as careful and curated as you would want it to be. Please note where you see linked text, you can click through for further information in our Knowledge Centre. For the 10 points below, we suggest you use them as a checklist for review and regularly revisit the checklist to see if changes are needed.
1. Users (Users / Directory)
User accounts need to be up-to-date: you need to set the tasks in place to ensure this occurs regularly. People who have left the organisation should not be able to access their data. You can choose the type of authentication or login for users, under Setup / Settings / User Settings. Where you use directory users, you should make sure that your directory synch is working correctly, whether On Premise directories through cloud extender, or cloud directory sync using IBM Verify and Microsoft Azure AD (or as it’s now known, Entra ID). When your users join their accounts are created and given access, but when they leave their accounts should be disabled, and if not you need to pay attention to how devices get deactivated (you can choose this on the Settings page, under User Deactivation Settings). Where your users are created locally, you need to take more care: regularly update user records to disable those who have left. You can do this individually or in bulk using a CSV file.
2. Administrator users (Setup / Administrators)
Administrators who access the MaaS360 administrator console must be only those who need access today. If your admin changes team – some leave or some new ones come – you need to review admin accounts: add new administrators, or remove old ones. You can also set the authentication (login) type at Setup / Settings / Administrator Settings / Advanced. You can either use local MaaS360 accounts to log in as an administrator, or you can use directory users which are managed in the directory. Where admin account logins are local to the MaaS360 portal (where you set the password directly on MaaS360), if someone leaves the team and you don’t disable the account or reset the password, they can continue to log in even from their home. So, local accounts should be disabled when admins leave. Any records such as compliance rules or policies should be transferred to a new owner. Admin users which use directory authentication will be able to log in while their account is active, and the password is valid. If you disable the account on the directory, there’s still the chance that the change doesn’t synch, with a potential for continued access to systems. While we’re at it, let’s mention administrator roles. These are permission sets (there are 5 by default) and you can create custom roles which allow you to be as liberal or as restrictive as you need to set the correct level of access for each administrator user or group. Team managers should review the roles and permissions applied as well as the set of active admin accounts.
3. Web Services admin accounts (Setup / Administrators)
An aspect of admin accounts is that of the Web Services user, which allows other platforms to make calls to your MaaS360 platform, and synchronize data whether in read or write mode. It's important to ensure that these accounts are restricted and that the credentials are only given to those people who need to have them. We recommend you set the flag ‘script-only user’ which ensures that the same account is not used to log into the admin console, which can end up cause credential ‘lockout’ and prevent the Web Services calls from working correctly.
4. Credential security (outside of MaaS360)
People use different ways are used to store passwords – clear text files (not encrypted), encrypted files, password manager utilities, and browser-console saved passwords. Using a password manager utility, which is corporate approved, should help: but if not, and passwords are being stored into browser accounts, do you have control over these accounts and particularly where people leave the organisation? The passwords should be stored or not in the browser according to your security principles, and implemented through training and awareness not just in IT teams but for all users.
5. Privacy (Security / Privacy)
The Security / Privacy menu ensures that you can meet data privacy requirements, whether required as a legal or compliance obligation or not. This option, allows you to disable the tracking of both apps installed and device location, categorised if you need by who owns the device. So, if a user is using their personal device to access corporate data, you don't want to have a list of the personal apps they have installed. This would qualify as Personally Identifiable Information (PII) which is subject to laws like GDPR. Under such regulations, user location and personally installed apps should not be tracked out of hours, and not on a device not owned by the organization. In this case location permissions should be restricted to only the professional applications and only as required.
6. Common agreed standards for security (Setup / Settings / User settings)
Let's consider now what we call the Acceptable Use Policy. Other organisations call this the User Charter, Professional Usage document, and so on. It is a document which is usually co-created between Finance, HR and IT teams, sometimes with Legal input. The purpose of this document is to get buy-in or acceptance from users so that their usage of corporate data and devices is restricted to what is acceptable. Common sense applies here: for example, no adult websites or apps on corporate devices, and no misuse of mobile data our financial systems for personal use which go beyond what's been agreed. Your policy document can have anything you need. You can upload the document to MaaS360 and require users to accept it during enrollment. For users already enrolled, you could send out a communication saying that continued use of technology implies acceptance of the document from this point forward.
7. Devices (Devices/Inventory)
The directory and enrollment settings are found under Setup / Settings. Mainly you can choose between self-enrollment (where users can choose when to enroll), or sending out enrollment invitations (where the admin chooses when this should happen). Self-enrollment gives more flexibility and autonomy to users which can be appropriate for large or geographically wide-spread organisations. Enrollment invitations may be more appropriate for smaller organisations or for those with tighter controls.
8. Authentication: passwords and more (Setup / Settings / Enrollment settings)
We recommend the use of strong authentication so that passwords “just aren’t enough”. Through MaaS360 you can use two-factor authentication, so the user is required to retrieve and enter a one-time passcode before accessing their system, enrolling and so on. We also support authenticator apps and you can set these up using an integration with IBM Verify, including if you are using Microsoft Azure / Entra ID multi-factor authentication.
9. Authentication: passcodes (Security / Policies / Device policies, or Workplace persona policies)
MaaS360 supports a lock-screen passcode, which a user must type in to unlock the data. Both for iOS and Android devices, you can use this both to force device encryption, and protect user data on the screen. This can be configured on the device policy, and you can do things like preventing excessively simple passcodes or ones which can easily be guessed. In addition, the MaaS360 Workplace policy provides for a separate container passcode, so that you can use a second level of protection on a device. We also support biometrics, so you can use the fingerprint on a mobile device to unlock it or unlock the MaaS360 apps.
10. Use compliance rules to automate corrective action (Security / Compliance rules)
There are times when you won’t be available. Users may not have access to use your expertise. So it’s good to put in some measures that will happen automatically, without your input being needed at that moment. Compliance rules help you to do this. They help you do things like prevent enrollment for lower or higher OS versions than you want, for jailbroken or rooted devices, for those with identified malware and so on. You can also use a clever approach by creating a custom device group (based on search criteria), and using a group-based rule you can run automatic actions on devices detected in that group. A simple example is asking a user to plug in a device that has low battery status. So, you search for devices with low battery charge percentage, and set the rule to run on devices in the group. You can for example trigger a message, or buzz the device, to warn the user to plug the device in before the battery dies.
Finally, plan regular reviews
A lot of the settings and approaches described here above are things that you can – and potentially should – revisit with some regularity. Can you set your calendar to look at these things maybe once every 3 or 6 months? The goal here is to ensure that users and admin accounts are up-to-date, correspond to only current people in the organisation, who currently have a need to access devices and data; that security and authentication settings are accurate and strong, and that privacy is respected.