Security Operations practice questions

A canary account is a realistic-looking but unused account whose every sign-in attempt is suspicious.

Two requirements decide this. The activity to detect is password guessing against existing usernames, which rules out the honeyfile (a spray never opens a file) and the honeytoken (a spray never uses a planted credential). The team cannot add hosts, which rules out the honeypot server. A canary account lives in the existing directory, so an enumerating spray reaches it, and because nobody legitimately uses it, any sign-in attempt against it is a near-certain sign of hostile activity.

1. Name the attacker behaviour: guessing common passwords against enumerated usernames.
2. Drop decoys the behaviour never touches: a file, or a planted credential the spray does not know about.
3. Drop decoys that need new systems: a honeypot server.
4. Choose the decoy that sits inside the existing directory: a canary account.

Exam tip: To catch credential attacks without new hardware, plant a canary account and alert on any use of it.

Sandboxing executes untrusted code in an isolated, monitored environment so its behaviour can be observed safely.

The analyst needs behaviour (files created, domains contacted), and the sample must not touch production. Only a sandbox both lets the code run and contains it while recording what it does. An antivirus scan gives a verdict, not behaviour; a block list stops the sample from running; a honeypot is a lure for live attackers, not an analysis environment.

1. Note the goal: observe runtime behaviour.
2. Note the constraint: no risk to production.
3. Pick the control that runs code in isolation and records activity: a sandbox.

Exam tip: To learn what unknown code does, detonate it in a sandbox; to stop it, use a block list.

Mobile device management enforces configuration policy on mobile devices and provides remote lock and wipe.

Every requirement is a mobile device configuration or lifecycle action: PIN policy, storage encryption and remote wipe. Those are core MDM functions. Group Policy is the Windows domain equivalent but does not reach phones, EDR focuses on threat detection and response, and NAC only gates network admission.

1. List the requirements: PIN, encryption, remote wipe.
2. Note that all of them are mobile device policy actions.
3. Match them to mobile device management.

Exam tip: Phones need policy and remote wipe: that is MDM.

Application allow lists are default-deny: only approved software runs, so unknown code is blocked without needing to recognise it.

The kiosks have a tiny, fixed set of legitimate software and face malware no one has a signature for. An allow list fits both facts: it is easy to maintain when the approved set is small, and it blocks anything not on the list, including never-seen variants. Block lists and antivirus both need to know the bad file in advance, and HIDS only detects.

1. Note that the approved software set is small and fixed.
2. Note that the threats are unknown variants.
3. Choose the default-deny control that does not depend on recognising malware: an allow list.

Exam tip: Small fixed software set plus unknown threats: use an allow list, not a block list.

A wireless intrusion prevention system (WIPS) detects and contains rogue or unauthorized wireless devices.

The threat lives in the radio space, so only a wireless sensor sees it: that leaves WIPS and WIDS. The requirement to stop laptops associating, not just to report the access point, calls for prevention, which is the difference between WIPS and WIDS. 802.1X controls who joins the company's own network, not which access points laptops connect to, and a NIPS watches wired traffic.

1. Identify the medium: wireless, so a wireless sensor is needed.
2. Identify the need: detect and also stop.
3. Separate the near-twins: WIDS alerts, WIPS also contains.
4. Choose WIPS.

Exam tip: Rogue access points: WIDS reports them, WIPS also contains them.

Host-based sensors see traffic after the host decrypts it; prevention systems block while detection systems only alert.

Two facts must be combined. First, network sensors cannot read TLS payloads unless traffic is decrypted, and the policy forbids that, so both network options are blind to the exploit. Second, the team needs blocking, which an IDS cannot do. The only option that sees decrypted content and can block it is a HIPS on each server. HIDS is the tempting near-twin: right location, but detection only.

1. Note that payloads are encrypted on the wire and cannot be decrypted in transit.
2. Eliminate the network-based sensors, which see only ciphertext.
3. Note that the requirement is to block, not alert.
4. Choose the host-based prevention system.

Exam tip: Encrypted traffic you may not decrypt: inspect it on the host. Need blocking: choose IPS, not IDS.