Attack surfaces: systems, credentials, devices, identity providers and exposed data

Objective 2.4 continues. The previous lesson took weaknesses inside software. This one takes the attack surface — the conditions in an estate that give an attacker somewhere to start: systems nobody maintains, services nobody needs, accounts nobody closed, devices nobody approved, and the new surfaces SY0-801 adds: identity providers, language models, public repositories and open cloud storage.

Why this matters

Attack surface is the sum of the points where an untrusted party could try to interact with your systems. Most real compromises do not need a clever exploit; they need one of the conditions in this lesson. An exposed service, a leaver's account that still works, a storage bucket readable by anyone — each is an open door that required no skill to find.

The habit that scores marks, and that works in practice: for each thing an attacker could touch, either it is needed and defended, or it is not needed and should be gone. Most findings are the second kind.

The lesson

Unsupported, unpatched, obsolete and unmanaged systems as four different problems

The exam separates four conditions that people blur together. Each has a different cause and a different fix.

• Unsupported — the vendor no longer issues fixes. Every flaw discovered from now on is permanent, so the risk grows over time. This applies to hardware and firmware too: an end-of-life appliance gets no more updates of any kind. The answer is replacement; until then, isolate it, restrict who can reach it, monitor it, and record the accepted risk with a review date.
• Unpatched — a fix exists and has not been applied. This is a process failure, not a product one, and the fix is the vulnerability management programme: know what is missing, prioritise it, apply it, verify it.
• Obsolete — technology that has been superseded, whether or not it is still technically supported. Its hidden cost is that modern controls often cannot be applied at all: a switch that cannot do port authentication, a server with no hardware security chip, an appliance whose newest TLS version is one you should have disabled. The blocked control is the real expense.
• Unmanaged — a system outside IT's management: not in the inventory, no agent, no patching, no monitoring. It may be perfectly current today and nobody will know when it stops being so.

A quick way to tell them apart in a question: no fix exists is unsupported; a fix exists is unpatched; too old for today's controls is obsolete; nobody is looking after it is unmanaged.

Open ports and services, misconfiguration, rogue devices and shadow IT

Ports and services. Every listening service is an entry point. The question is not whether it is vulnerable today but whether it needs to be reachable at all. Management interfaces — remote shells, remote desktop, database ports, hypervisor and appliance consoles — reachable from the internet are the classic finding. Close, filter, or restrict by source, and know what is listening in the first place.

Misconfiguration is the largest single category of real findings: unnecessary services enabled, default settings never changed, permissions wider than needed, logging never turned on. In cloud it dominates. The shared responsibility model says the provider secures the platform and you secure what you build on it — your configuration, identities and data — and nearly every cloud incident falls on the customer's side of that line. Configuration baselines and automated posture checks are the controls.

Rogue devices are hardware connected without approval: a wireless access point an employee plugged in for better coverage, a personal laptop on a wired port, a small computer hidden behind a printer. Each bypasses the controls applied to managed devices. Network access control, port authentication, wireless scanning and an inventory to compare against are how they are found.

Shadow IT is technology used for work without IT or security approval — a team's own SaaS tool, a personal cloud drive holding work files, a departmental database on a desktop. There is usually no malicious intent: people reach for it because the sanctioned option is slow, missing or hard to use. The risk is concrete all the same: data with no backup or retention, systems invisible to scanning and monitoring, accounts that survive offboarding, and vendors nobody assessed. The controls are discovery first — cloud access security brokers, DNS and egress logs, expense records — and then a sanctioned alternative good enough that people use it. Prohibition alone reliably fails.

Stale credentials, and the identity provider as one concentrated target

Unmanaged or stale credentials are valid access that nobody is watching: accounts belonging to people who have left, contractor and test accounts that were never removed, service accounts whose passwords have not changed in years, API keys issued for a project that ended. They are attractive precisely because nobody will notice them being used. Controls: tie account removal to HR events, give temporary accounts end dates, run regular access reviews, rotate service credentials or replace them with managed identities, and alert on dormant accounts that suddenly sign in.

An identity provider (IdP) is the system that authenticates users for many other applications through single sign-on. That concentration is its value and its risk. One strong, well-monitored sign-in protects everything behind it — and one compromise of the IdP, its administrators, or the keys it uses to sign sign-in tokens, exposes everything at once. A stolen token-signing key lets an attacker issue valid sign-ins for any user without knowing any password.

Treat the IdP as the most sensitive system you have: phishing-resistant MFA for its administrators, a small number of dedicated admin accounts, signing keys protected in hardware, alerts on configuration changes such as a new trusted federation partner, and logs kept and watched.

Virtualisation, mobile devices, and wireless and low-power links

Virtualisation. The hypervisor is the security boundary between guests. VM escape — code in one guest reaching the host or another guest — is rare and severe, because it breaks the assumption underneath the whole design. Resource reuse, where memory or storage is handed to a new guest without being cleared, is the quieter version. And VM sprawl, machines multiplying faster than anyone tracks them, creates unmanaged systems. Patch hypervisors as a priority, keep management interfaces off general networks, and keep an accurate inventory.

Mobile devices leave the building, join untrusted networks, and are lost. Their security depends on the store, the sandbox and the vendor's updates, so sideloading apps from outside the official store, and jailbreaking or rooting to remove the manufacturer's restrictions, strip away the protections everything else relies on. Devices whose manufacturer has stopped shipping updates are unsupported systems on a short cycle. Mobile device management that checks device state and refuses compromised devices is the control.

Wireless and low-power communications. Wi-Fi with weak or shared keys, and access points an attacker can imitate, expose traffic to anyone in range. Low-power links used by IoT and building devices — Bluetooth Low Energy, Zigbee and similar — often have limited processing power, so they use weaker or no encryption, pair with minimal confirmation, and are hard to update. Use current wireless security, keep low-power devices on their own segment, and choose products with a credible update path.

Large language models, public code repositories and open object storage as new surfaces

Large language models. An application that uses an LLM inherits a new kind of input. A model cannot reliably tell instructions from data, so anything it reads — a web page, an email, a document — may steer it; anything in its prompt may be repeated; and any tool it is allowed to call becomes reachable through it. The surface is the model plus everything it can read and do. The AI threats lesson covers the attacks and controls in full; for 2.4, recognise the LLM as a surface to inventory and restrict like any other.

Public code repositories. Code meant to be private is published by mistake, and code meant to be public carries things it should not: hard-coded secrets, internal hostnames, configuration that maps the network. Public package registries are the other direction — malicious packages published under names that imitate popular ones, waiting for a developer to install the wrong one. Controls: repository visibility rules, secrets scanning, approved package sources, and dependency checking in the build.

Public object storage. Cloud storage buckets set to allow anonymous read — or worse, anonymous write — are among the most common causes of large data exposures. Nobody attacked anything; the data was simply available. Controls: block public access at the account level by default, so making anything public requires a deliberate exception; scan continuously with cloud posture management; and classify data so the sensitive buckets are known.

What to take into the exam

• Unsupported: no fix exists. Unpatched: a fix exists. Obsolete: too old for modern controls. Unmanaged: nobody is looking after it.
• Every open port needs a reason; misconfiguration is the commonest real finding, and in cloud it is usually on the customer's side.
• Shadow IT is answered by discovery plus a sanctioned alternative, not prohibition alone.
• Stale credentials are valid access nobody watches; access reviews and HR-linked deprovisioning close them.
• An identity provider concentrates risk: protect its admins, its signing keys and its configuration above everything else.
• Public repositories leak secrets; public buckets leak data. Default to private and scan.