Why does an internal app that trusts corporate-network reachability still serve an intruder, and what does replacing that check cost?
answer
- a routing fact, not an identity claim
- who else lands in the same place
- the app was never taught to ask
- each flow carries its own credential
- front door or rewrite - nothing is free
basics
~20 sReachability proves only that a packet arrived from an address the network will route; anything that lands inside inherits it. Replacing it means building the login the app never had - a front door on its host, or a rewrite.
solid answer
~50 sBeing on the internal network is a statement about routing, not about who is calling. A plant fabric hands the same position to an employee laptop, a vendor notebook plugged in for a commissioning visit, an unattended shop-floor terminal, and any of those hosts once an intruder owns it - none of which involved anyone proving an identity. That is the single tenet of NIST SP 800-207: network location is not evidence, so each flow must carry its own authenticated identity and be authorised per request. The uncomfortable part with a twenty-year-old ERP or licence server is that it has nowhere to put that credential and no code path that asks for one. So the decision has to be added from outside - an identity-aware front door in the path, or a rewrite - and until someone funds that, `inside` is the whole authentication.
go deeper
Be ready to say plainly what an internal source address proves: a packet was routed, nothing more. Have two concrete examples of something non-employee that holds a position on a corporate network.
Explain the mechanics of the replacement - a credential presented per flow, a decision made per request, and an audit record naming the caller - and why an application with no login cannot do any of that by itself.
Show you have costed it: the enforcement point has to go somewhere, the machine callers need service identities, and the cutover has an outage window. Talk about the inventory before you talk about the design.
Own the framing that this is a portfolio decision across dozens of legacy applications, not one project, and that some of them will be accepted with a signed residual rather than fixed.
### The claim, in one line NIST SP 800-207 rests on a tenet that is easy to nod at and hard to implement: **network location is not evidence**. Where a packet came from is a fact about cabling, address assignment and routing tables. It is not a statement that anybody proved who they were. ### Why a self-hosted plant fabric makes this vivid In a single-tenant data centre serving a manufacturer, the application population is old: an ERP, a shop-floor scheduling app, a licence server, a handful of reporting tools. Their authentication story, stated honestly, is: *the port is only reachable from the corporate fabric, and the corporate fabric only carries our people.* The second half of that sentence has never been true, and it decays every year: - a machine builder's engineering notebook, plugged in for a commissioning visit and never removed from the estate; - a shared terminal on the shop floor that nobody signs out of; - a print server, a building-management controller or a camera recorder that speaks outbound to the internet and accepts commands; - a remote-support path granted to a vendor a decade ago; - an intruder who has taken over any one of the above. Every one of those events grants a **network position**. Not one of them authenticated a person. The ERP's entire access check is therefore satisfied by whoever most recently obtained a route - which is precisely the property an adversary works to acquire first, because acquiring it is the whole login. ### What position actually proves, stated precisely A connection arriving on an internal address proves that *some* host with a routable address opened a socket. It does not prove the caller is an employee, that the device is managed, that the credential behind it is unstolen, or that the human who owns the workstation is the one typing. Direction matters here: reachability is a property of the network; identity is a property of the caller; and the network never observed the second one. ### What has to carry the decision instead Under the model, every flow carries its own authenticated identity, and access is decided per request against that identity plus context - the resource asked for, the state of the device, the time. Position degrades to, at best, one weak signal among several. The practical shape is: something in the path must (a) authenticate the caller, (b) decide, and (c) record what it decided, for **each** request rather than once per network admission. ### The price, which is the half interviews actually probe For an application written in the last fifteen years this is configuration: it already speaks a token or a session, and you point it at an identity provider. For this estate it is not, because the application has no field to carry a credential and no code path that asks for one. That leaves three genuinely different positions, and each costs something: | Option | What you get | What you pay | |---|---|---| | Front it | A real identity on every human session, now | An enforcement point installed on the app host itself, an exception list for every machine caller, connection-level rather than action-level decisions | | Rewrite it | Per-action authorisation and an audit trail with a user on each action | Money and 12-24 months, during which nothing changes | | Accept it | No engineering spend | A shrunken reachability list, recorded sessions, and a named person who signs the residual risk with a review date | There is a fourth cost that all three share and that people forget to fund: **finding out who actually calls the application**. In an estate this age the callers are mostly machines - a nightly batch, a monitoring poller, a reporting server, a script on somebody's desktop from 2013 - and each of them connected straight to the port with no credential because none was ever needed. Until that inventory exists, any change to reachability is an unplanned outage waiting for a cutover window. ### The wrong answer to avoid saying out loud The common senior-level miss is treating this as a labelling exercise - redraw the zones, call the fabric untrusted, declare the programme underway - without noticing that the applications themselves cannot participate. The model does not remove trust from the network by decree; it *moves* the check into something that can make it, and if nothing in the path can make it, someone has to build or buy that thing. That is the whole conversation.
- Someone argues the plant fabric is physically isolated, so position is good enough - what do you say?Physical isolation is a claim about a room, not about a flow. The maintenance laptop, the vendor's remote-support path and any machine that spans both sides all deliver position without identity. Isolation also degrades silently: nothing alerts when somebody adds a route or bridges a network for a project, so the control you are relying on can stop existing without anyone noticing.
- Which internal callers make it hardest to switch this on?The machine ones. A nightly batch, a monitoring poller, a reporting server and a few forgotten scripts connect straight to the port with no human to prompt for a credential. Each needs a service identity issued and a route through the new front door before cutover, and every one you failed to inventory fails during the outage window - which is why the discovery work gets funded regardless of which option wins.
- Does putting the app behind stronger perimeter filtering address the same problem?No. Filtering at the perimeter changes who can reach the fabric from outside; it does nothing about the callers already inside it, which is where the entire population of positions this app trusts lives. It also still decides on addresses and ports rather than on an identity, so a caller who qualifies gets everything the app offers.
A road that reaches your house proves a car can arrive. It says nothing about whether the driver was expected, or who is behind the wheel.
saying these in an interview costs you the question
- Says the firewall already authenticated whoever is inside
- Treats a private internal source address as a trusted identity
- Assumes only employees can obtain a network position
- Thinks zero trust is a product you install rather than a decision you move
- Claims the change is free because the app already works