Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026
Guest connectivity becomes an internal-network route
SC06 · Retail · hotels · offices · shared premises
What really happened
In its 2008 TJX action, the FTC alleged inadequate wireless-access controls and insufficient limits between systems, alongside other security failures. The intrusion exposed payment-card data and other consumer information.
FTC · TJX settlement announcement
Evidence limit: This is an older, well-documented boundary-failure example. Modern radio and authentication controls differ; it is not evidence that TJX used an evil portal or the tools in our proposed test.
The question for the client
Can a guest, nearby device or misleading WiFi login cross into business access or capture sensitive interaction?
Business impact: Credential exposure, internal access, disrupted transactions and customer trust damage.
- Systems involved
- Guest/staff access points, SSIDs, network isolation, onboarding portals, endpoint certificate handling and internal services.
- Where people fit
- Visitors and staff choose networks; administrators define separation and onboarding. The test should evaluate protective controls, not merely whether a person recognises a network name.
How a similar risk could develop here
Proposed client threat model, not a reconstruction of undocumented incident details.
Obtain nearby/guest connectivity or present a misleading network → exploit weak onboarding or trust → observe allowed traffic or reach internal services → pursue sensitive access where boundaries fail.
Each route depends on several controls. If one stage is blocked, later checks can only continue as a separately authorised, clearly labelled assumed-compromise test. Do not claim an end-to-end attack succeeded merely because a downstream test identity was supplied.
Referenced attack-vector guides
Approval is specific, never inherited from the guide. Check the client, campaign, individual person/asset, method, channel, time window and risk ceiling. Deny overrides allow; absent, expired or withdrawn permission blocks the action. LOW/MED/HIGH describe proposed test impact, not permission or finding severity.
Read the approval rules.
Assessment playbook · Part 1
Start with G01 scope and Target Management, G02 intelligence gathering where needed, and G03 tool/resource preflight. Each selected vector receives its own scoped invocation record.
SC06-S01LOW · proposed test impact1. Confirm real wireless scope
Inventory test devices, bands, locations, SSIDs and expected guest/business separation.
- Why this is needed
- It tests a barrier in the route above and helps answer: Can a guest, nearby device or misleading WiFi login cross into business access or capture sensitive interaction?
- Vector / method
- Tools and guides
- Repository input
- wireless-matrix.csv · RES-020 · published assessment resource; pin its version/hash in the case record.
- Output
- Radio and network scope; attach evidence, target ID, vector version and approval revision.
- Measure
- Required coverage verified / approved required coverage. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Resolve missing bands/locations and define the actual guest/business boundary. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC06-S02HIGH · proposed test impact2. Isolated portal/trust simulation
Use an owned lab SSID and test users only, if specifically authorised; use inert pages without password capture. No nearby guests or production access points are involved.
- Why this is needed
- It tests a barrier in the route above and helps answer: Can a guest, nearby device or misleading WiFi login cross into business access or capture sensitive interaction?
- Vector / method
- Tools and guides
- Repository input
- canary.txt · RES-022 · published assessment resource; pin its version/hash in the case record.
- Output
- Portal and endpoint observations; attach evidence, target ID, vector version and approval revision.
- Measure
- Correct trust/onboarding decisions / approved executed cases. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Improve onboarding trust and certificate handling; do not collect real passwords or test unrelated nearby users. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC06-S03MED · proposed test impact3. Boundary and alarm checks
Compare allowed and denied flows from the approved test device and verify a benign alert reaches a reviewer.
- Why this is needed
- It tests a barrier in the route above and helps answer: Can a guest, nearby device or misleading WiFi login cross into business access or capture sensitive interaction?
- Vector / method
- Tools and guides
- Repository input
- network-flows.csv · RES-019 · published assessment resource; pin its version/hash in the case record.
- Output
- Flow evidence and response measures; attach evidence, target ID, vector version and approval revision.
- Measure
- Prohibited flows blocked; generated alerts received; acknowledgement time. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Restrict the failed guest/internal flow and repair the missing alarm or reviewer route. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
Use one step-result record per case and G06 reporting for the client deliverable. The report must explain successes, failures, uncertainty, prohibitions and coverage limits.
Recommendations to reduce the risk
Reduce the likelihood: Strengthen wireless authentication, onboarding and certificate handling; keep guest and business access separate.
Reduce the impact if it happens: Limit what any guest or low-trust device can reach, and monitor meaningful boundary violations.
How to verify improvement later: repeat the failed control case and a permitted/clean comparison using the same agreed measure; compare conditions and evidence. A better test pass rate alone is not a quantified reduction in business risk.
End of Part 1: evidence-backed findings and mitigation recommendations. The implementation action plan, allocated work, commercial service packaging and costs are deliberately deferred.
Supporting TenguProtect capabilities
Baseline from the 13 October operational audit. This does not claim the complete service is ready or that permissions are already enforced across every agent.
| Capability | Observed readiness | Remaining gap |
|---|
| Wireless and guest-network separation | Partial; sensor and hardware coverage unresolved | Reconcile the stale sensor and actual bands; inventory the field kit and prove capture/alert receipt on an owned lab network. Shannon is not a wireless executor. |
| Network exposure, segmentation and ransomware containment | Partial; selected network fixture required | Verify tools under the real worker account and demonstrate findings, exceptions and retest on a small owned network. |
| Monitoring, alert delivery and incident triage | Some telemetry live; managed SOC/MDR not established | Define customer telemetry, coverage, service hours, triage and escalation. Verify event freshness and alert receipt; do not sell 24/7 response without staffed coverage. |