An unauthenticated ERP serves any caller inside the fabric and your steering group funds exactly one of front it, rewrite it or accept it - how do you frame the choice?
answer
- three residual positions, not three designs
- a rewrite year is an acceptance decision
- price, owner, expiry, review date on each
- the caller inventory is funded either way
- recommend, then say what changes your mind
basics
~20 sPresent three residual-risk positions, not three designs: what each leaves an intruder able to do, what it costs, who signs it and when it is reviewed. A two-year rewrite accepts today's exposure for two years.
solid answer
~50 sThe failure mode is arriving with three architectures. A funding group can only decide which residual risk the company holds, so frame each option that way. **Front it**: months; an enforcement point on the app host, an exception list for machine callers, connection-shaped decisions - but real identity on every human session this year. **Rewrite it**: the only path to per-action authorisation and an audit with a user on each action, at twelve to twenty-four months and vendor risk, during which the current exposure is unchanged - choosing the rewrite *is* an acceptance decision. **Accept it**: shrink reachability to a named source-host list, record sessions, and have someone sign the residual with an expiry. Attach to each what only they can settle - whose budget, whose outage window, who signs, what evidence a contract or auditor requires - and fund the caller inventory whichever they pick.
go deeper
Understand that the three responses to a legacy app with no login are to front it, rewrite it, or accept the risk deliberately, and that all three cost something.
Be able to describe what each option changes about who can reach the application and what evidence it produces afterwards.
Show you can price each option including the parts people forget - the caller inventory, the exception list, the cutover window and the new operational dependency.
Own the framing: residual risk with an owner, an expiry and a review date, an honest statement that a rewrite period is an acceptance period, and a policy for the whole class of legacy applications rather than one decision at a time.
### What the group is actually being asked They are not choosing a design. They are choosing **which residual risk the company holds, for how long, and who owns it**. An architect who presents three technical options and a favourite has translated the question into a language the room cannot answer in, and the usual result is deferral - which silently selects the third option without anyone signing for it. ### The three positions, priced honestly **Front it.** An identity-aware front door on the application's own host, the application rebound to loopback behind it. Delivery is months. What the company gets: every human session carries an authenticated identity and lands in a record with a name on it, so the population that can reach the ERP shrinks from *anything with a route* to *people who passed a check*. What it pays: an exception list for the machine callers, a cutover with an outage window, a decision granularity of *may connect* rather than *may approve*, and a new operational dependency - if the front door is down the ERP is unreachable, because that is what binding it to loopback means. **Rewrite it.** The only option that ends with per-action authorisation and an audit trail naming a user on each action. Twelve to twenty-four months, a dependency on a vendor who may not commit, and a real chance of arriving late. The sentence that must be said in the room: *for the whole of that period the exposure is exactly what it is today.* A rewrite chosen alone is an acceptance decision wearing a project plan, and if nobody says so, the group believes it has fixed something. **Accept it.** Shrink reachability to a small named set of source hosts, record the sessions on them, review who may use them, and have a named person sign the residual with an expiry and a review date. This is the cheapest and the most honest of the three when the alternative is an unfunded aspiration - and it is only defensible with those four attributes present. Acceptance without an owner and an expiry is not a decision, it is a silence. ### What the architect attaches to each The value you add is the layer above the engineering: | Attach to each option | Why the group and not you decides it | |---|---| | Whose budget and which year | It competes with production capacity, not with other security work | | Who signs the residual | Risk acceptance needs a person with authority to hold it | | Whose outage window | The cutover stops the plant for a period somebody owns | | What evidence is required | A customer contract or an auditor may demand a statement about access control you cannot yet make | | The review date | Otherwise the temporary option is the permanent one | ### The one thing to fund regardless Every option needs to know who calls this application, and nobody does - the callers are mostly machines that never needed a credential. Ask for the discovery work independently of the decision: observe connections for long enough to catch monthly and quarter-end jobs, resolve them to owners, and produce a list. It de-risks the front-door cutover, it scopes the rewrite, and it is what makes the accept option's source-host list small enough to be meaningful. ### Do you give a recommendation? Yes. Refusing to recommend is not neutrality, it is abdication. But separate the recommendation from the decision: state your pick, state the assumption that would change it (a vendor commitment, a customer requirement arriving, a merger that widens the fabric), and state what you need signed if they choose differently. That last part is the mechanism that stops the meeting from producing a comfortable non-answer. ### And the portfolio question behind it This ERP is not alone. The same estate holds a shop-floor scheduler, a licence server and a dozen smaller applications with the same authentication story. Handling them one steering group at a time produces a decade of inconsistent outcomes. The stronger position is to bring a **policy for the class**: fronting is the default, rewrite is reserved for applications where per-action authorisation is genuinely required, acceptance is time-boxed and counted - and report the count of accepted applications every quarter, because a number that does not fall is the argument for the next round of funding.
- The group asks which option you recommend - do you refuse to name one?No. Name it, then separate it from the decision: give the assumption that would change your recommendation, and say what you need signed if they choose otherwise. Declining to recommend reads as neutrality but usually produces deferral, and deferral selects acceptance without anyone owning it.
- How do you stop 'accept it' from quietly becoming permanent?Four attributes: a named owner, an expiry, a compensating measure you can evidence, and a review date on the calendar. Then report the count of accepted applications each quarter. A number that never falls is uncomfortable in a way that a paragraph in a risk register is not, and it is what eventually funds the alternative.
- The rewrite is chosen. What do you insist on for the interim?That the interim is treated as an accepted risk with the same paperwork as the accept option, and that reachability is shrunk now at low cost - a named source-host list and session recording - so the two-year exposure is smaller than today's. Otherwise the project becomes the reason nothing is done meanwhile.
saying these in an interview costs you the question
- Presents a rewrite as the only responsible option
- Hides that a two-year rewrite accepts today's risk meanwhile
- Leaves acceptance with no owner, expiry or evidence
- Prices build cost only, ignoring exceptions and the outage window
- Brings three designs when the group can only decide a risk position