After a new MFA policy rollout, the SIEM generates an alert for five failed logins to a SaaS admin portal from one IP, followed by a successful login to the same account from an IP in another country. The account owner says they were in meetings all day. What should the analyst do first?
This is the best first step because triage should validate the alert and establish context before disruptive containment. Correlating identity provider, VPN, and endpoint telemetry can show whether the login came from an expected corporate path, a known remote-access method, or a likely compromise. The analyst can then decide whether account disablement, password resets, or escalation is warranted based on evidence rather than a single suspicious event.
Why this answer
The alert shows a successful login after five failures from a different country, which is a classic indicator of a potential account takeover. The analyst must correlate identity provider logs (e.g., Okta, Azure AD) for authentication details, VPN logs for network origination, and endpoint logs for device posture to determine if the successful login matches the user's normal behavior. This step validates whether the activity is legitimate or malicious before taking any irreversible action.
Exam trap
The trap here is that candidates assume MFA is infallible and ignore the geographic anomaly, leading them to delete the alert (Option C) or take premature action (Option A or D) without performing proper log correlation.
How to eliminate wrong answers
Option A is wrong because disabling the account immediately without checking other logs could disrupt legitimate access and ignores the possibility of a false positive or a misconfigured MFA policy. Option C is wrong because deleting the alert simply because MFA was enabled and the login succeeded overlooks the fact that MFA can be bypassed (e.g., via session hijacking, token replay, or social engineering), and the geographic anomaly warrants investigation. Option D is wrong because reimaging the laptop is a drastic, premature step that assumes compromise without evidence; the analyst must first confirm whether the successful login originated from the user's device or an attacker's system.