What actually happens with the test files

Cyber Essentials Plus › Malware and browser tests

The part of a Cyber Essentials Plus audit that most people have not seen described is the practical malware testing. It is straightforward, it is not dangerous, and understanding it explains most of the failures.

The two tests

The email test. The assessor sends a set of test files to a mailbox in scope, as attachments and sometimes in archives. The question is whether your email filtering and your endpoint protection between them stop the ones that should be stopped.

The browser test. The assessor attempts to download a similar set of files through a web browser on a sampled device. The question is whether the file can be downloaded, saved and run.

The files are not real malware. They are inert test files and harmless samples that security products are expected to recognise. Nothing is being detonated on your network.

What is being measured

Not whether you have bought a security product. Whether the controls stop the file reaching a position where a user could execute it.

The chain has several links: the email gateway, the mail client, the browser's own protections, the endpoint protection on the device, and any application control. A pass means the chain stops the file. Which link stops it does not matter.

This is why the tests are useful rather than a formality. Plenty of organisations have a well-configured email gateway and a weak endpoint position, or the reverse, and only the practical test surfaces that.

Why passing one and failing the other is common

The two routes are usually protected by different products, configured by different people at different times.

Email filtering is normally a single cloud service, configured once and rarely touched. It tends to be strong, because it is somebody's job.

The browser route depends on the endpoint protection on the individual device and on browser settings, which drift. A device where real-time protection was disabled during troubleshooting, a browser where somebody turned off download protection, a machine that never received the policy. The browser test finds those, which is what it is for.

The failures we see most

Common causes of a failed malware or browser test

Cause	What is actually wrong
Real-time protection off on one device	Disabled during troubleshooting months ago, never re-enabled. The estate policy says it is on.
Exclusions too broad	A folder or file type excluded to stop a line-of-business application being flagged. Everything in that path is now unprotected.
Archive scanning disabled	Files inside a zip pass straight through the email gateway.
Signatures out of date on a device	Usually a machine that has been off, or one not reporting to the console.
Browser download protection disabled	Turned off to stop warnings on a legitimate internal download.
An unmanaged device in the sample	A personal or ad-hoc device with a different, weaker configuration.
Gateway in monitor-only mode	Detects and logs but does not block, often a hangover from a deployment that was never switched to enforce.

How to check before the audit

You do not need the assessor's files. Three checks catch nearly everything.

1. Check real-time protection is on, on every device, from the central console rather than by asking. Look specifically for devices that have not reported recently, because those are the ones sitting outside policy.
2. Review your exclusion list. Every exclusion is a hole somebody deliberately made. Check each is still needed and as narrow as it can be. Broad path exclusions are the ones that cause failures.
3. Confirm the email gateway is in blocking mode, with archive scanning enabled. Monitor-only is a surprisingly common misconfiguration on a gateway deployed in a hurry.

If you want to test it yourself, the EICAR test file is the standard harmless sample for exactly this purpose and is safe to use. Tell your security team first, or you will generate an alert and a phone call.

What a failure costs you

Not the certificate outright. You get a written account of what failed and a period in which to fix it and be retested. The cost is the delay, which matters if you are working to a contract date.

Which is the argument for checking the three things above a fortnight before the audit rather than finding out on the day.

What the day actually looks like

The practical testing is less dramatic than people expect. For a typical small or medium estate it occupies part of a day and involves a handful of devices.

A typical audit sequence

Stage	What happens
Before the day	You supply the device inventory and the cloud service list. The assessor selects the sample from it.
Opening	Confirm scope, confirm the sample, agree how the assessor gets access to each device, whether in person or remotely.
Authenticated scan	Each sampled device is scanned from an account with enough privilege to see installed software. This is where missing patches and unsupported software surface.
Email test	Test files are sent to a mailbox in scope. The assessor checks what arrives.
Browser test	The assessor attempts to download the same sort of files through the browsers in use on sampled devices.
Account checks	Local administrator group membership, account separation, and confirmation that the configuration requirements hold on the device rather than in policy.
Cloud checks	Multi-factor authentication verified across the sampled services.
Close	Anything that failed is explained on the day, so you are not waiting on a report to start fixing.

What to have in the room

Somebody who can log into the management console and answer a question about configuration without going to find someone. Somebody with administrative access to the devices being sampled. And the inventory, in final form, matching what you submitted.

The audit runs long when the assessor asks a question and the answer takes an hour to find. Having the right person available for a few hours is the difference between a half-day and a day and a half.

Remote or on site

Most Plus audits can be done remotely, and for a distributed workforce that is usually the only practical option. Sampled devices are accessed over a remote session with the user present.

The practical requirement is that each sampled user is available at an agreed time and has a working remote access route. Scheduling that across several people is the part that needs organising, and it is worth booking those slots a week ahead rather than on the morning.