Nonessential Functionality

Fifteen objectives collapse into three lists.

Programs are [a] through [c], functions are [d] through [f], and ports, protocols, and services are [g] through [o]. Treat ports, protocols, and services as one combined list, because a firewall rule that blocks a port blocks the protocol and the service behind it.

Classify in three tiers and the definitions write themselves.

Essential is what your requirements and business functions need. Restricted is allowed only through an approved, documented rule where everything else is blocked by default. Prohibited is the known-insecure set blocked outright, such as FTP, Telnet, and SMBv1, so that no future rule allows them by accident.

Defining nonessential as everything outside the essential list is a legitimate definition.

Objectives [b], [e], [h], [k], and [n] ask that nonessential use is defined. State in the procedure that anything outside the essential definitions is nonessential and is blocked, disabled, or removed on discovery. That sentence satisfies the definition objectives without an impossible enumeration.

Do not classify a hundred Windows services one by one.

Define essential at the level you control: the roles a machine serves, the applications on the approved list, the ports the firewall permits. Operating system services that support those roles are covered by the baseline, and the ones your CM.L2-3.4.2 benchmark says to disable get disabled there.

Functions are capabilities you can switch off, and naming a few is enough.

Reading, editing, and saving project documents is essential. Bluetooth file transfer, games, and music streaming are nonessential functions you restrict. The objectives ask for definitions and enforcement, not an exhaustive taxonomy.

One rules list serves this requirement and CM.L2-3.4.2.

The firewall export with a business justification per rule evidences established configuration settings there and essential port definitions here. Build it once and reference it from both.