Defining the scope of your Cyber Essentials assessment will be difficult. Ideally it should to be done right at the beginning of the process and should apply to the whole organisation. Most likely though, it will develop as the answers to the section questions are collected and developed, and determining if mitigation is required or possible. Changing the scope is one method of refining the submission. This will particularly apply if time/people/skills/financial resources are not going to be available to provide the required mitigation or remove the risk element identified.
***Covid-19 consideration***
The Covid-19 changes to service delivery and user work patterns has moved most users and often a reasonable amount of previously on-site equipment to home/remote locations with reduced management. This is being considered a temporary arrangement by the Information Assurance for Small to Medium Enterprises consortium IASME including the expectation that a transition back to normal will be slow and certainly different. With respect to question A1.7 home workers, your home worker count is those that have home working as part of their employment contract, not all that are currently home working.
Putting things out of scope is not a mechanism to ignore them. Out of scope means that the services they use or provide are isolated completely from any other service delivered to users that are within scope and that those users cannot access them without going through an established control set that includes authentication, logging and will not introduce or expose the risk to the wider service delivery infrastructure.
For those organisations that can apply the certification to the entire business operation, the preferred option, then the IASME certification comes with some limited cyber insurance as part of the achievement. However it is likely that some elements of your infrastructure are likely to currently result in some action being required. Some examples of queries that Jisc have dealt with are:
- The business has lodger organisations onsite who are not part of the organisation, but use some of the services the IT team manage.
- The business runs income generation activities onsite (conferences, weddings etc.) that IT services are expected to provide services for.
- The business has to provide residences for students onsite with internet access for devices that may not support usual authentication methods.
- Some schools/faculties still use proprietary software that is out of vendor support and there is no acceptable alternative or resource to move to a supported version.
In all the cases above, the simplest resolution is to ensure that these elements of service usage are written out of scope at the start of the document. If they are part of the core business and removing them from scope reduces the “whole organisation” description, then you will not be able to apply for the included insurance offer, not being able to gain the insurance does not affect the amount you will pay to IASME, base level Cyber Essentials is still £300+VAT.
The associated risks of the above scenarios continuing to operate within your service delivery model without any additional layers of security being put in place should be obvious. Determining the layers of security that need to be applied should be generated by asking yourself a set of questions, i.e:
- Do they use authentication to access their devices and wider services?
- Can authentication at the connected device by bypassed by re-patching at the network socket?
- Does this authentication extend to both wired and wireless connections?
- Can our users see their connection method and connect?
- If yes, do they then bypass our filtering and firewalls?
- Does their traffic flow amongst our traffic and use the same egress/ingress paths for internet traffic?
- In the case of ‘guest’ access, can I identify the users?
- Do I have generic accounts in use?
- Et al…
Failure to identify how they are to be put out of scope, will result in the Cyber Essentials assessor developing queries and will result in your submission being returned with either requests for greater clarity or a fail and requirement to resubmit. Much of the mitigating solutions required will already be in place and will probably simply require extending:
- If the users do authenticate against your or their own directory services then authentication can be seen to be compliant.
- If they don’t authenticate, then are their devices in a controlled access environment? This would be compliant, but the addition of authentication to record and provide an audit record of ad-hoc/hot desk machine access by persons authorised to be in that area would be a better solution.
- Multiple solutions exist to prevent services being delivered to unknown devices simply by being re-patched to the network socket. Port security is often used on switches, granting limited services on connection and redirection to an authentication point (commonly the firewall) or other enterprise level security products providing intruder protection and/or access control are acceptable.
- Specify which you have, if none, which can be enabled and which is going to generate the minimum number of support tickets.
- Most Jisc members have markedly improved their use of ‘guest’ access to their networks, however procedures in place vary considerably as we often see when we visit sites. Being given a laminated card with the guest network SSID and WPA key printed on arrival, suggests that it probably doesn’t get managed very well!
- Can/do your lodger organisation(s) deliver their own WLAN service? Probably yes. Do they use reasonable authentication? Possibly not. If WPA is in use onsite then the key should be considered compromised as soon as it has been given out. This guest access effectively becomes an anonymous user as the onward dissemination of the key cannot be controlled unless WPA3 is available. The guest provision should be actively managed as a one-time-use.
- Generic accounts should not be used, however, often sets will be issued to a teaching area for local management. Many members do limit services to these accounts, i.e. no email, no NFS, limited desktop which do all help in risk management. If they have to be used then logging out, should prompt an account reset including password, and those managing the issue and use of the account should retain identity information of the person that used the account. Generic accounts for online exams should have all the restrictions listed above in place and they are usually only accessible under supervision and against an identified user, this process documented is acceptable.
One of the harder requirements to achieve is that of the applying all vendor released security and critical software patches within 14 days of release. For many the usual method of sitting on the patch for a week or so until somebody else has discovered the grief it can cause is no longer viable. The patching routine in place will need improving by:
- Obtaining more competent tools that can deploy, roll back and/or rebuild quickly.
- Establish a ‘sandbox’ of machines that represent the service models deployed, so problems can be fed back quickly by these ‘tame’ users.
- Know what happens to machines that are not active on the domain, desktops powered off or laptops powered off in trolleys, or laptops that are taken home by users, particularly staff laptops that may go off site for months at a time. Reconciliation of successful patching can only be done if you have an accurate asset tracking method in place or embedded in the patching tool as a standard patching solution is likely to only record connected devices success or failure.
- It is likely that some departments/schools/faculties are going to have legacy applications that they simply cannot live without, this may include systems that have to be kept for legitimate fixed time archiving purposes. If they are in place and use, then without vendor support they must be either be put out of scope or have physical and/or logical separation from the in-scope services. In some Jisc member sites, this has been determined to be the entire student fleet. This can’t be fully endorsed as an option, particularly if in-scope users have to use out-of-scope equipment such as front of classroom machines for presentation etc.
Defining the scope will have many influencing variables and the application to IASME has to be supported and signed by a member of the senior leadership team. They will need to be sure of the buy-in from the other stakeholders in the business. This is easier to understand if changes are all supported with published policy documentation.
Developing a few scope scenarios would be recommended. The out-of-scope elements of concern can then be recorded in the IT risk register and the risk treatment plan can be developed. They can then be made compliant in a managed manner and then perhaps added to the scope at the next annual accreditation.
Remember, Cyber Essentials is not externally validated, your declared statement of truth is trusted. For those that need to move on to the Cyber Essentials Plus certificate (currently all those receiving ESFA funding by September 2021), external validation of your statement is part of that assessment.
As mentioned in an earlier blog, the relaxation of requirement to attain CE by September 2020 does require a evidence base of continued work towards attainment to be kept. ESFA retain the right to ask for this evidence for inspection. IASME have stated that for educational organisations a logical separation between student and administrative/corporate networks, whereby controls only applying to the staff network can count as the whole organisation (essentially treating ‘users’ as being staff and the students as client systems). Whilst this is helpful, when developing your controls limiting their application to this scope would not be endorsed as it will require a revisit and rework in the future.