Authentication Failures, a Stale Feed, and a Full Database
On Monday morning four problems land at once. Credentialed scans now fail authentication on roughly 3,100 of 9,000 hosts, though network checks still return results. The plugin feed has not updated in nine days. The platform database volume is at 92% capacity. Nightly scans are running past 06:00 into business hours, which the service desk has escalated. Internal audit also reports that 40% of in-scope assets return no results for a specific compliance benchmark file. A change window on Friday rotated service account passwords and applied a new endpoint protection policy. The team has one engineer available this week and no maintenance window until the following month.
1. Order the four problems for this week and justify the sequence, including which you deliberately leave alone.
Read the worked answer
Sequence by outage risk to the platform itself, then by data validity, then by comfort.
- Disk at 92%. This is the only item that can take the whole platform down and destroy the evidence needed to fix everything else. Purge scan results beyond retention, relocate or truncate logs per vendor guidance, and free headroom immediately. Do it first even though it fixes no findings.
- Authentication failures. Credentialed failure is a silent false-negative generator: scans still return results, so dashboards look healthy while patch-level and configuration checks vanish. That directly invalidates the audit evidence in item 4. Correlate against Friday's password rotation and endpoint protection policy first - the timing makes those the leading suspects.
- Stale plugin feed. Nine days means new vulnerabilities are invisible. Note the possible shared cause with item 1: a full disk will also break content updates. Check whether the feed stopped on the same date the volume crossed a threshold before assuming a proxy or licence problem.
- Scan window overrun. Real, but it is a scheduling and throttling issue, not a correctness issue. Address next week unless it is causing endpoint impact during trading hours.
Deliberately deprioritised: the compliance benchmark gap as a separate item - at 40% with credentialed scans failing on a third of hosts, it is almost certainly a symptom of item 2, not an independent fault.
2. Describe the diagnostic you would run on the authentication failures before making any change, and list what would falsify your leading hypothesis.
Read the worked answer
Run one experiment that distinguishes credential from policy.
Diagnostic:
- Pick five failing hosts and two working hosts on the same subnet and OS build.
- Attempt an authenticated connection manually using the same service account and the same protocol the scanner uses.
- On a failing host, check the local security log for failed logon events - the failure code tells you whether the credential was rejected (bad password, expired, locked) or never presented (blocked by policy, port closed, protocol disabled).
- Check account lockout state and lockout threshold at the domain level - a password rotation that races against a high-concurrency scan will lock accounts repeatedly and look like a broken credential.
- Check the endpoint protection policy for anything that blocks remote service creation, remote registry access, or SMB signing mismatch.
Falsifiers for 'the rotation broke it':
- Working hosts authenticate with the new password - then the credential is fine and the variable is host-side policy.
- Failures cluster by subnet or OS build rather than by time since rotation.
- Local logs show the account is locked out rather than rejected, pointing at concurrency and lockout threshold.
- Failures began before Friday.
If any falsifier lands, change the hypothesis rather than adjusting the credential again - a second blind reset during a scan window will deepen the lockout spiral.
3. What maintenance routine would have prevented this week, and what do you put in place given there is no maintenance window until next month?
Read the worked answer
What was missing: the platform had no capacity trend, no content-freshness alert, and no credential-health metric. All three failures were visible in the data for days before anyone looked.
Routine to adopt:
- Capacity: weekly trend on database and log volumes with a threshold alert well below the danger line, plus a purge job tied to the documented retention period.
- Content freshness: alert if the plugin feed is older than 48 hours, with a named owner.
- Credential health: report authentication success rate per region and per OS family every scan cycle; alert on any drop greater than a few points.
- Scan duration: track window overrun per zone as a first-class metric.
- Change correlation: a standing rule that credential rotations and endpoint policy changes are listed on the vulnerability team's calendar, not just the identity team's.
Given no maintenance window for a month:
- Do the disk remediation and feed diagnosis under the existing operational change process as corrective actions - they are stability fixes, not feature changes, and should not wait four weeks.
- Defer anything requiring a reboot, agent upgrade, or firewall change to the next window and log it as accepted technical debt with a date.
- Freeze further policy changes until the authentication question is answered, so you are not debugging two variables at once.