Maersk: map the legacy system and its integrations
An inherited application needs its own incident response boundary. The map should connect its origin, business workflows and integrations that remain active.
Читать на португальскомBy Pentesty
The statement describes an ongoing investigation
In a statement dated November 11, 2026, Maersk reported unauthorized access and data extraction involving a local legacy system from an earlier acquisition. Its investigation remains open. The company did not anticipate operational disruption and had found no indication of impact on other systems or customer and partner integrations through APIs and EDI. These are the company’s provisional findings, not independent verification by Pentesty.
For a business depending on that logistics chain, the useful question is which of its processes uses the system concerned. Treating every connection as compromised, or assuming that an available service has already been investigated, can produce decisions disconnected from actual exposure.
Rebuild the inventory the acquisition should have resolved
Propose a record for each acquired application: original entity, current owner, hosting, maintenance provider and business process supported. Include systems awaiting retirement. Remove a migration project from the list only when evidence addresses closed routes, retained data and any remaining responsibilities.
Ask the business owner to connect the application to specific tasks: creating orders, scheduling, dispatch or proof of delivery. Technical teams should identify the corresponding connections. Differences between the inventory and observed workflows become assigned tasks with deadlines, rather than a general legacy category.
Draw the boundary of each workflow
As an authorized exercise, prepare an integration record covering origin, destination, purpose, data types, communication direction and owners on both sides. Record where the connection ends and whether intermediate files, queues or forwarding steps exist. An API identifier alone does not explain which orders depend on it.
Compare that record with execution logs for a defined period. Select sample orders and reconcile sending with receipt, without collecting full documents when identifiers are sufficient. The expected output is a list of confirmed flows and observation gaps, with the origin of each piece of evidence.
Separate continuity, investigation and commercial trust
Use three decision tracks. Operations follows pending transactions and alternatives; security documents the known scope and preserves evidence; relationship owners confirm instructions through a previously established contact. Each track should state what would change its decision. Commercial reassurance does not replace a technical conclusion.
Before blocking an integration, agree a window, an alternative and subsequent order reconciliation. Before restoring it, define the test and its approver. The discussion of dependency recovery applies the same discipline to evaluating whether an alternative supports the task that must continue.
Turn the supplier request into a verifiable package
Someone outside the meeting should be able to understand which operation was assessed, using what evidence and under which conditions. Revise the decision when a new verifiable finding changes that scope.
- Request identification of the service and workflows involved, the period covered by the investigation and the next update. Explicitly record what remains undetermined.
- Bring together the approved diagram, reconciled transaction sample and continuity decision. Protect the records and share only what each team needs.
- If a decision requires removing data or retiring an application, document which copies are included. The Trezor and ShipMonk case provides a complementary discussion of that follow-through.
Frequently asked questions
Does the statement confirm a ransomware attack?
The primary document consulted confirms access and extraction. It does not substantiate attribution to a group, a ransom amount or a data volume; those allegations are excluded from this analysis.
Should every integration be interrupted?
The decision depends on the workflow, investigated scope and interruption impact. Document those conditions and the operational alternative before selecting an action.
What evidence should a customer request?
Clear identification of the service, period assessed, workflows in scope and unresolved questions. Sensitive investigation details should have a defined purpose before anyone requests them.
How should supposedly retired systems be handled?
Keep an owner assigned until connection closure and data disposition are evidenced. A completed task does not establish that the application has stopped serving workflows.
Sources and references
Original Pentesty analysis, published November 11, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.