This is the third in the Road to CE series, we’ll be talking about the written policies need to support Cyber Essentials, most of these will just be updates to existing policies.
TLDR: Review and update your policies to enshrine the technical controls and accommodate for technical control feature lackings.
If you don’t have an Acceptable Use/Bring your own device (BYOD)/Secure Working/Software Asset Management Policy you may wish to implement one, written policy is what you and your organisation use to enforce the technical controls/limitations you will need for CE compliance.
Students are currently OUT OF SCOPE for CE and for they can be ignored unless the device is owned by our organisation
Owned by your organisation Owned by a third party BYOD Employer ✓ N/A ✓ Volunteer ✓ N/A ✓ Trustee ✓ N/A ✓ University research assistant ✓ N/A ✓ Student ✓ N/A ✕ MSP administrator ✓ ✕ ✕ Third party contractor ✓ ✕ ✕ Customer ✓ ✕ ✕
Under CE you need to have a log of any device used by staff to connect to/manipulate corporate data (e.g. email/files/instant messaging/reporting/phone calls), this can be a purely written exercise but for better results in CE show you have technical controls to back it up. This should be written into your policy document(s) requiring users to register devices. The devices should also be kept up to date by the end user, ideally through technical control, and if a device is out of support it should no longer have access to corporate data/services.
What about using a VDI (virtual desktop infrastructure)? Under CE you have to ensure both the VDI and the connecting device are compliant for CE. If you have been using VDI to avoid upgrading certain devices, under CE this is no longer an option.
You can use an out of date device, but it needs to be isolated. Under CE my reading of this is for older devices such as control machines where they can be air-gapped. You have to put this down as exceptions in the CE application.
Deciding which operating systems to support also needs to be detailed in policy. Linux desktop should be avoided unless required, only ubuntu is currently supported in Intune, and even then it’s limited. For Apple devices ensure you have DEP (Device Enrolment Program) configured and linked to your MDM system. For Windows Autopilot should be used, this ensures devices auto enrolled in MDM at the point of procurement.
Speaking of procurement, you should ideally try to procure devices from a CE certified supplier, with the abilities to register your procured devices directly in your MDM via DEP/AP.
For application installation on devices, CE requires that where possible all applications should be kept up to date, or where that isn’t possible policies in place to review these applications and enforce additional restrictions if needed. Winget is your friend for Windows, this new tool in Windows 10+ works in the same way as yum/apt in Linux. You should have a written policy stating that applications should be centrally controlled, ideally through your MDM. Under CE you need to keep a log of those, and if asked provide a report of applications installed on those devices. For Mac’s try to just use applications from the store.
For non store/winget/apt/yum installations you will need a policy in place to monitor the application, any updates that come out will need to be deployed in a timely manner and reviewed periodically.
Users should also not have admin rights on their device on the account they do day-to-day work on. This is includes PIM admin roles. You need to have written in policy that if admin abilities are required a separate ‘admin’ account is needed, this account should be centrally managed and controlled. Policies should have clauses written in to make use of the ‘admin’ account for the specific purposes, installing software, performing admin related tasks, and should explicitly state not for general purpose use. Ideally it shouldn’t even have internet access.
Services (Microsoft 365/G Suite/Salesforce/etc) also need to be audited, logged and monitored. MFA is a must on any cloud service that is in use, ideally through an IdP (AAD) to further protect that service and wider services. The more platforms you can have using a single IdP (SSO) the better for monitoring/investigating issues.
If the service is going to be offered to customers that services should comply with the Zero Trust models available in the market, ideally supporting SSO technologies rather than relying on unique/separate credential systems. By using SSO you can centralise the monitoring and auditing of access to these services, for customers that goes for their auditing abilities and their own CE certification.
In the pilot group we tested these updated policies with the users, seeking feedback on them before finalizing the policy for the wider Jisc.
In the next post in this Road to CE series we will start exploring the technical controls, we will mainly looking at Intune, but these controls should cross over into other MDM solutions.
