Library kiosks, an AUP nobody can audit, and ransomware that beaconed for eleven days
City of Lakes has 3,000 staff, 1,200 shared library kiosks that all log in with one shared "kiosk" AD account, and public Wi-Fi used by about 5,000 patrons a day. Staff use an explicit proxy; kiosks and patrons are redirected transparently. Council policy requires an AUP to be displayed and accepted before internet access, and blocks Proxy Avoidance, Hacking, Extreme, and a custom Illegal Activities list. Reporting shows 45 percent of sessions as user "Unknown." The AUP page reappears roughly every 30 minutes on kiosks, and there is no record of which patron accepted it. Separately, a staff laptop ran a ransomware binary that beaconed to a rare domain over HTTPS for 11 days; Web Reputation is set to Monitor globally, the Uncategorized category is set to Allow, and HTTPS is not decrypted.
1. Why is 45 percent of traffic reported as "Unknown," and what would you change to make AUP acceptance auditable per patron?
Read the worked answer
"Unknown" is what the WSA reports when it has no authenticated identity and falls back to an IP-based identification profile. Transparent redirection alone provides no identity, and a single shared kiosk AD account would collapse 1,200 devices and every patron into one name even if it authenticated, which is useless for both reporting and AUP accountability.
Changes:
- Separate the populations with identification profiles: staff subnet (explicit, authenticated), kiosk subnet (transparent), patron Wi-Fi subnet (transparent). Each profile should have a distinct name so reports show the identity confidence, not just "Unknown."
- For patrons, deploy a guest portal on the WSA that captures a self-registered identity or a sponsor-issued code and presents the AUP. Acceptance is then attached to that portal session, giving an auditable record per patron rather than per IP.
- For kiosks, stop using one shared AD account as the identity anchor. Either use a per-device identity issued by the portal or MDM, or explicitly document that kiosk traffic is device-identified and cannot be attributed to a person; the second option is a policy decision the council must accept in writing.
Check the result by running a report grouped by identification profile rather than by user name; the unknown bucket should drop sharply and the remainder should be explainable.
2. The AUP page keeps returning and is not reliably shown. What causes each behaviour and how do you fix it?
Read the worked answer
Two separate mechanisms are at work.
Reappearing acceptance: AUP acceptance is cached for a configured duration and tied to the identity and session. If the session timeout or re-authentication interval is shorter than the intended consent period, or the kiosk clears cookies between users, the WSA correctly re-presents the page. Align the AUP acceptance duration, the authentication session timeout, and the kiosk browser profile so that consent survives normal use, and decide deliberately whether a new patron on the same kiosk must re-consent. For a public kiosk, per-patron consent is usually the right answer, which argues for a portal session that ends when the patron's session ends rather than a long cached acceptance.
AUP not shown at all: in transparent mode the AUP is delivered as an HTTP redirect. If the client's first request is HTTPS, the WSA cannot inject that page without decrypting the connection. Staff who open a browser straight to an HTTPS start page may never see the AUP, and the same applies to applications that never issue an HTTP request.
Fix: enable decryption for the kiosk and patron identities so the AUP can be delivered over HTTPS, and install the WSA's signing certificate on the kiosk image and on patron devices via the onboarding portal. Validate by opening an HTTPS-only start page on a clean profile and confirming the AUP appears before content loads.
3. How would you close the ransomware detection gap, and what are the limits of each control you would enable?
Read the worked answer
The eleven-day dwell time is consistent with a design that sees only cleartext and only reacts to known-bad URLs.
Controls and their limits:
- Web Reputation: move from Monitor to Block, with a considered threshold. Reputation is evaluated on the HTTPS CONNECT hostname even without decryption, so it can catch a known-bad destination; it cannot catch a new domain with no reputation history.
- Uncategorized handling: changing Uncategorized from Allow to Block is the highest-impact single change here, because newly registered C2 domains are frequently uncategorized at first contact. It will also break legitimate new sites, so pair it with a monitored exception process and a user-facing block page rather than a silent failure.
- SSL decryption for staff: without it, file payloads and full URLs inside HTTPS are invisible. Decrypt staff traffic with a documented privacy policy and a narrow do-not-decrypt list for regulated categories, and push the signing certificate by GPO.
- Anti-malware and AMP file reputation/analysis: these inspect files that the WSA can see. They do nothing for a connection that is never decrypted, and they do not stop a payload that arrives encrypted or is executed from a USB device.
- L4 Traffic Monitor: useful as a backstop for known botnet/C2 IPs, but it is IP-based and blind to domain-only or fast-flux infrastructure.
State the residual risk explicitly: a novel domain contacted over an undecrypted TLS session is the gap that remains after all of the above.