Basic cyber defences every organisation needs beyond the Essential Eight

I’ve been talking about AI and cyber security for a while, often making the point that we need to get the basics right before worrying about more sophisticated AI-enabled attacks. Then I realised I had never actually explained what I mean by “the basics”.

I do not mean just the Essential Eight.

The work also includes knowing what you operate, governing your data, controlling access, detecting suspicious activity and being able to respond and recover. Someone needs to own that work, fund it and have the authority to act.

Buying another security product is not the same as doing it.

Australia’s Essential Eight is a sensible starting point. But asset visibility, data governance, detection, incident response, supplier controls and tested recovery also belong in the basics. Broader guidance such as CISA’s Cybersecurity Performance Goals helps put that work in context.

1) Know what you are protecting

You cannot make sensible decisions about security if nobody can tell you which systems you operate, who owns them, or what happens when they stop working.

Maintain an inventory of devices, applications, cloud services and critical dependencies. Identify the services that matter most to the business, not just the equipment that happens to be on the IT asset register. CISA explicitly includes asset inventory and configuration documentation in its baseline security goals.

For each critical service, ask:

• Who owns it?
• What data does it hold or process?
• Who can access it?
• Is it exposed to the internet?
• Which suppliers does it depend on?
• How would we operate without it?

This is also data governance. What data do we hold? Where does it live? Who is accountable for it? Who can use it? Why are we still keeping it?

These are not questions for a separate policy exercise later. They are part of knowing what we need to protect.

An inventory is not a spreadsheet someone completed three years ago. It needs to reflect the organisation as it operates now.

2) Make identity and access a priority

Multi-factor authentication, or MFA, and restricted administrative privileges are core elements of the Essential Eight maturity model.

Start with these:

• Require MFA for email, remote access, cloud services and privileged access, using phishing-resistant methods wherever supported.
• Give people only the access they need.
• Separate administrative accounts from everyday accounts.
• Remove access promptly when people leave or change roles.
• Review supplier access and privileged permissions regularly.
• Assign owners to service accounts, API credentials and other non-human identities.

The test is not whether you have an access policy. It is whether you can explain who has access to your critical systems, why they have it, and how quickly you can revoke it.

3) Patch systems and deal with unsupported technology

Patching applications and operating systems belongs in the baseline. So do application control, restrictions on Microsoft Office macros and application hardening. These are established components of ASD’s Essential Eight approach.

Patching also needs priorities. CISA’s guidance calls for known exploited vulnerabilities in internet-facing systems to be patched or otherwise mitigated within a risk-informed timeframe, prioritising critical assets.

In practice, that means:

• Know which systems are exposed.
• Set patching deadlines according to risk.
• Check that patches actually deployed.
• Remove unnecessary services and insecure configurations.
• Replace unsupported systems, or isolate them while a funded replacement plan proceeds.

“We cannot patch it because the business needs it” is not a resolution. It is a decision to retain risk. A business I deal with got hacked due to a new unpatched vulnerability recently, and every single customer of theirs was breached.

That decision needs an accountable owner, compensating controls and a deadline. Otherwise the exception becomes permanent.

4) Protect endpoints, email and cloud services

The organisation’s defences need to cover the places where people work and data moves: laptops, servers, email, identity systems and cloud services.

Question that should be asked:

• Which devices and services are actually protected?
• Which are missing?
• Can users disable the protection?
• Who notices if protection stops working?
• Are cloud and email controls configured, or merely licensed?

Do not accept “we have the product” as evidence that the control works.

5) Collect logs and make them useful

Detection depends on evidence. CISA’s baseline guidance calls for security-relevant logs to be collected and stored for detection and incident response. It also recommends notifying security teams when a critical log source is disabled.

Start with identity, email, endpoint, cloud administration, remote access and critical business systems. Then work out which events need investigation and who will investigate them.

Can you identify an unexpected administrator account? Who investigates suspicious remote access? Who notices when a critical system stops sending logs?

Logs nobody reviews may help with a later investigation. They are not, by themselves, an active defence.

Collecting the evidence is one job. Having people who can investigate it and act is another.

6) Detection needs people, not just products

XDR stands for extended detection and response. It brings together security signals from endpoints, identity systems, email, cloud services and other connected sources to help detect, investigate and respond to threats. Actual coverage depends on the product and its integrations.

But someone still has to do the work.

That is the job of a security operations centre, or SOC: people monitoring activity, investigating alerts and responding to incidents.

You do not necessarily need to build your own. You do need to know who is doing that work, when they are available and what they are authorised to do.

Before buying XDR, establish:

• What systems and services it covers.
• Who monitors and investigates alerts, including outside business hours.
• Who can isolate a device, disable an account or revoke access.
• Which actions can happen automatically and which require approval.
• How you test that detection and containment work.

If you do not have the people to run this capability, consider an outsourced or shared service. Managed detection and response, or MDR, combines technology and human expertise for monitoring, investigation and response.

Buying XDR does not give you a SOC. Outsourcing monitoring does not automatically give your provider permission to contain an attack.

Sending an alert is not the same as containing an attack. Who can act at 2 am, what can they do, and when do they need your approval?

Read the service agreement and settle those decisions before the incident.

7) Limit how far an attacker can move

Access controls and network separation should make it harder for a compromise in one area to reach everything else. The ability to move laterally across your networks makes an attackers job easier.

CISA’s guidance on network segmentation includes restricting access to operational technology networks and denying connections unless they are explicitly permitted for specific functionality. That is particularly important where digital systems interact with physical operations.

For other environments, apply the same practical question: what can this account, device or connection reach?

Separate ordinary user access from administration. Restrict access to critical systems and backups. Limit supplier connections to what is genuinely required.

In operational technology, changes and automated containment also need to respect safety and service requirements.

8) Back up what matters and prove you can restore it

Having a backup is not the same as being able to recover.

ASD’s Essential Eight maturity model calls for resilient backups of data, applications and settings, protection against unauthorised modification or deletion, and restoration testing as part of disaster recovery exercises.

The questions that should be answered include:

• Can someone who compromises production systems also delete the backups?
• Are configuration settings and recovery dependencies included?
• Can we recover if our normal identity systems are unavailable?
• How long does restoration actually take?
• How much data would we lose?
• Has anyone restored the complete service, rather than a few sample files?

Set recovery priorities around business services. Restoring a database is useful. Restoring the service that depends on it is actually the outcome that matters.

9) Rehearse an incident before you have one

Every organisation needs a workable incident response plan. CISA’s guidance explicitly calls for organisations to maintain, practise and update plans for relevant threat scenarios.

Keep it usable. Identify:

• Who leads the response.
• Who can authorise containment or a shutdown.
• Who contacts suppliers, insurers and external specialists.
• Who handles legal advice and assesses reporting obligations.
• Who communicates with staff, customers and other affected parties.
• How the team communicates if normal systems are unavailable.

If you use a SOC or managed provider, include them in the exercise. Test the handover between their detection and your decisions.

A tabletop exercise can expose missing authority, outdated contacts and assumptions about what a supplier will do. Better to discover those gaps in a meeting than during an incident.

10) Make suppliers and staff part of the defence

Supplier security belongs in the operating model. CISA’s cybersecurity goals include mechanisms for organisations to learn about and respond to incidents affecting vendors and service providers.

I recommend named owners for important suppliers, controlled access, clear incident notification arrangements and an understanding of who is responsible for recovery.

Staff also need practical processes, not just annual awareness training. Make suspicious activity easy to report. Establish a separate verification process for consequential requests, such as changes to payment details. Give people a way to pause and check without being punished for slowing things down.

Security processes that depend on everyone being perfectly alert, all day, are not a sensible design.

The leadership test

All of this needs ownership, funding and regular testing. Leadership needs evidence that the controls work, not merely reassurance that the products have been purchased.

Here are the essential questions for leadership:

• Which critical assets remain unmanaged?
• Where are MFA and privileged access controls missing?
• Which high-risk vulnerabilities are overdue?
• What proportion of the environment is monitored?
• How quickly can we investigate and contain an incident?
• When did we last restore a critical service successfully?
• Which exceptions remain open, and who has accepted them?

None of this requires pretending that every organisation needs the same security architecture. A small business, a university and a water utility have different environments and consequences.

But all of them need to know what they operate, control access, maintain their systems, detect suspicious activity and recover essential services.

XDR can help. So can a SOC or a managed security service. None removes the need for someone inside the organisation to own the decisions.

If nobody can authorise containment, the alert waits. If nobody funds the replacement, the unsupported system stays. If nobody tests recovery, the backup remains an assumption.

This is what I mean by the basics: controls that work, clear ownership and people with the authority to act.