Contractor Access Without Endpoint Trust
An engineering firm gives 1,200 contractors access to 15 internal web applications and 30 sanctioned SaaS apps from personally owned laptops in 14 countries. MDM is not an option - the contractors refuse it and legal has conceded the point. Last month a contractor pasted roughly 40 lines of a pricing engine from Salesforce into a personal Gmail account; it was caught only because a colleague reported it. The data the contractors touch is subject to GDPR and customer NDAs. The current remote access stack is GlobalProtect with a posture check that no personally owned device can satisfy, so support has issued 300 temporary bypasses in the last quarter. A pilot of network-level isolation worked for Salesforce but broke a supplier-portal upload workflow - uploads above 5 MB failed silently - and the helpdesk cost was judged unacceptable. Leadership wants contractor access that does not depend on the endpoint being trustworthy.
1. Choose the access architecture for the contractor population and defend it against the alternatives.
Read the worked answer
Choose a managed enterprise browser with agentless ZTNA - Prisma Access Browser for the session, with browser-based application access to the internal apps rather than GlobalProtect.
Why it fits the constraints: the enforcement point moves from the device to the browser session, which is the only thing you can actually control on a personal laptop. No agent, no posture check to fail, and therefore no bypass backlog - the 300 bypasses are the strongest evidence that the current control is theatre.
Against VDI: VDI would work technically and is the classic answer, but it was frozen on cost, and it puts every contractor's latency behind a data-centre round trip from 14 countries. It also does not solve data movement - contractors can still photograph a screen.
Against network-level isolation alone: the pilot already showed it breaks real workflows at scale. Isolation that people route around has negative security value because it generates exceptions.
What the browser buys you that the others do not: per-application policy on clipboard, upload, download, print and screenshot, evaluated inside the session. That directly addresses the Salesforce-to-Gmail paste, which no network control would have seen because it never left the endpoint.
State the residual risk: a determined user can photograph a screen or retype data. The browser raises cost and captures signals; it does not eliminate exfiltration, and leadership should not be told otherwise.
2. Define the data-flow controls you would apply, and explain why a blanket block is the wrong starting point.
Read the worked answer
Baseline for all contractors (default-deny on the risky verbs):
- Clipboard: block paste from managed apps into non-managed destinations; allow copy within the session where the workflow requires it.
- Upload: allow to sanctioned destinations only, with a size ceiling and file-type restriction.
- Download: allowed for documents under a threshold, logged above it; block for datasets and code repositories.
- Print and screenshot: block by default on the apps handling customer data; log-only elsewhere.
- Session: force IdP authentication with MFA, bind the session to the identity rather than the device, and set short idle timeouts.
Why not blanket block: a blanket block on clipboard and upload will break the supplier portal, the code review workflow and probably two things nobody has documented, and the result will be a queue of exception requests approved by whoever is most tired. That is how the 300 GlobalProtect bypasses happened. Blanket blocks also destroy your telemetry - you learn nothing about normal data movement.
Instead: start in monitor for every app except the one that just leaked, where you block paste-out immediately. Use 30 days of session data to see which flows are genuinely routine, then convert the top three risky flows to block with a named business owner for each. Policy per application, not per population, is what keeps the exception count near zero.
3. The supplier-portal upload fails silently above 5 MB. How do you resolve this without abandoning inspection?
Read the worked answer
Treat it as a workflow defect first, a policy question second.
Diagnose: silent failure at a specific size strongly suggests a buffering or content-inspection step timing out, a proxy body-size limit, or the portal's own chunked-upload logic not tolerating an intermediary. Reproduce with a 4 MB and a 6 MB file and capture where the request dies. Silent failure - as opposed to a clear error - is itself a bug worth raising, because users who cannot tell why an upload failed will find another route.
Remediate, in order:
- If inspection is the cause, raise the size limit for that one application rather than disabling inspection globally, and stream rather than buffer where supported.
- If the portal's chunking is incompatible, exclude the specific endpoint path from content inspection while keeping authentication, clipboard and download policy intact for the session.
- Only if neither works, allow the upload uninspected for that destination and compensate with download restrictions and alerting on volume anomalies.
Guardrails on the exception: scope it to the supplier portal hostname, not to all uploads; give it an owner and an expiry date; log every exempted upload; and report the count monthly. An exception with a review date is engineering. An exception without one is the beginning of the next 300 bypasses.