Skip to content
PRO-04 Secure configuration management
ASD EssentialsIT.PRO-04.1

ASD Essentials IT.PRO-04.1 Define Approved Hardening Baselines Disabling Unneeded Services, Insecure Settings and Weak Protocols

What it says

Define approved configuration baselines, informed by vendor and industry hardening guidance, that disable or remove unnecessary services, insecure settings, and unsupported or weak communication protocols.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Defines approved settings per system type that switch off unneeded services, risky options and weak protocols, based on vendor and industry advice.

Many products arrive with settings chosen for ease of use, not security. To meet this, approve a standard set of settings (a baseline) for every system type, based on vendor, ASD and industry advice. It removes or switches off unneeded services, risky options, and unsupported or weak network protocols, such as Telnet. Record why each setting was chosen, so later changes can be judged against it, and review the baseline on a set cycle.

Where this action applies

What's in each domain?

ASD orders the work by domain: apply this action to each ticked domain, phase by phase.

Phase 1
Phase 2
Phase 3

Why it matters

Systems left on factory settings give attackers extra ways in. Unneeded services can be attacked, unused features can hide harmful code, and open remote management lets them run commands. Risky settings make sign-in details easy to steal, and weak protocols expose data as it travels.

How to implement

  1. The head of IT infrastructure should use the asset list to name every type of system needing a baseline, such as firewalls, servers and laptops.

    Give each an owner, and cover device, operating system and app settings.

  2. Each baseline owner should build from the vendor's guidance for the exact version in use, ASD's security guides and recognised industry benchmarks.

    List the sources used, and pick the stricter setting where they disagree.

  3. System engineers should list the services, features, network ports and interfaces each system type needs.

    The baseline removes everything else, such as unused server roles, or switches it off where removal is not possible.

  4. Security architects should list risky settings to switch off, such as guest access and options that expose sign-in details.

    List unsupported or weak protocols to disable, such as Telnet and old file-sharing (SMB version 1), with secure replacements.

  5. The baseline owner should record why each setting was chosen, including departures from guidance, to help judge later changes.

    The head of security or a delegate approves each version, and the owner reviews it on the set cycle.

Keep it running

Manage baselines as formal documents, each with a named owner and an approved, numbered version. Owners review them on the set cycle. They review sooner when vendor or ASD advice changes, a new product version arrives or a setting proves weak. Each new version needs approval before it replaces the old one. Write baselines in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the baseline register alongside the asset list, grouped by system type.

    Look at

    Whether some system types, such as firewalls or management consoles, have no baseline or run factory settings.

    Good evidence

    Every system type on the asset list has a named owner and an approved, numbered baseline.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Request sample baselines with their approval records and the guidance each one cites.

    Look at

    Whether baselines are approved and current, or unapproved drafts or copied factory settings with no source.

    Good evidence

    Each baseline is formally approved and traces to current vendor and industry guidance.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask each baseline owner to walk through the service, setting and protocol sections.

    Look at

    Whether unneeded services, risky settings or weak protocols are still allowed with no recorded reason.

    Good evidence

    Each baseline says what it removes or switches off, and names secure replacements for disabled protocols.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the recorded reasons behind a sample of settings, especially departures from guidance.

    Look at

    Whether reasons are missing, or too vague to tell an intended setting from an unapproved change.

    Good evidence

    Each sampled setting and departure has a specific reason that later checks can use.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the set review cycle and each sampled baseline's review and change history.

    Look at

    Whether reviews are overdue, missed new guidance or product versions, or revisions went unapproved.

    Good evidence

    Reviews are on time, and new guidance or product versions show up in approved revisions.

ASD indicators of good practice (9)

The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".

Not effective(2)

  • NE-1No documented configuration baseline exists for assets.
  • NE-2Systems are deployed with vendor defaults and no documented hardening has been applied.

Partially effective(3)

  • PE-1A baseline exists but does not address all applicable asset types.
  • PE-2The baseline is documented but has not been reviewed or updated within the cycle defined by the organisation.
  • PE-3The baseline exists but rationale for configuration decisions is not documented.

Fully effective(4)

  • FE-1A documented and approved baseline exists for all applicable asset types.
  • FE-2The baseline disables or removes unnecessary services, insecure settings, and unsupported or weak communication protocols.
  • FE-3Configuration decisions are documented with rationale to support drift assessment.
  • FE-4The baseline is reviewed and updated on a cycle defined by the organisation.

Mappings

Closest match in ISO/IEC 27001: A.8.9, Configuration Management for Secure IT Systems, which this control partially meets.

ISO 27001

ISO/IEC 27001: 1 mapping

  • A.8.9Configuration Management for Secure IT SystemsPartially meets
Essential Eight

ASD Essential Eight: 27 mappings

  • E8-AH-ML1.1Disable or remove Internet Explorer 11Partially overlaps
  • E8-AH-ML1.2Web browsers must not execute Java content from the internetPartially overlaps
  • E8-AH-ML1.3Web browsers block web ads from the internetPartially overlaps
  • E8-AH-ML1.4Web browser security settings locked down to usersPartially overlaps
  • E8-AH-ML2.1Web browsers are hardened with the most restrictive guidancePartially overlaps
  • E8-AH-ML2.2Block Microsoft Office from creating child processesPartially overlaps
  • E8-AH-ML2.3Block Microsoft Office from creating executable contentPartially overlaps
  • E8-AH-ML2.4Block Microsoft Office from injecting code into other processesPartially overlaps
ASD ISM

ASD Information Security Manual: 5 mappings

  • ISM-0380Disable Unneeded OS Accounts and ServicesPartially overlaps
  • ISM-1409Implement Restrictive OS Hardening GuidelinesPartially overlaps
  • ISM-1603Disabling Vulnerable Authentication MethodsPartially overlaps
  • ISM-1914Ensure Operating Systems Have Approved ConfigurationsPartially overlaps
  • ISM-1916Ensure Server Application Configurations Are ApprovedPartially overlaps

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.