Draft for Tamir's review. Not published.
Know what crosses the boundary first
Segmentation breaks the flows nobody documented. Capture actual traffic across the boundary between the plant and the office for several weeks before anyone draws a target design. Inventory every external account and connection, with the system it reaches and its business owner.
Then decide each flow: a firewall rule, an outward-only feed, or removal, with an owner for each. Plan cutovers around planned maintenance windows, with a rollback for each zone. Keep the design separate from the equipment contract, so one vendor's catalog doesn't shape it.
Controlled access instead of cut or keep
When a vendor demands an always-on connection, offer sessions the plant initiates, through an approved path, with named accounts, recording and time limits. Add an emergency process with a short approval time, so support stays fast. Write it into the contract.
When an analytics project asks you to relax isolation, ask the vendor to show the use case on an approved outward-only feed first. For software you buy, require an inventory of third-party components tied to the delivered build. Then test how the supplier traces a sample advisory to affected versions.
Depending on where you are
If an audit finding started this, write the closure criteria with the auditor before the work starts. If a breach came through a supplier, fix the access model before buying a risk platform or sending questionnaires. Map each failure in the incident to a control the contract should have required.
If you're writing hosting or support terms for renewals, tie them to the data's sensitivity. Define how you'll verify each one, by evidence, test or audit, because a requirement nobody verifies is a wish.
What to check before you decide
- Inventory every external account and connection, with the system it reaches and its business owner.
- Capture actual traffic across the plant and office boundary for several weeks before designing the target.
- Remove or suspend access with no owner or no recent use, and report what was removed.
- Require plant-approved sessions, named accounts, strong authentication, recording and time limits for remaining vendors.
- Define an emergency access process with a short approval time, so support is never stuck.
- Write contract terms for location, encryption, logging, breach notification, audit rights and subcontractors, and how you'll verify each.
- Ask suppliers for a component inventory tied to the delivered build, and how they report affected versions.
Questions people ask
Audit says our OT and IT networks aren't separated, how do I plan segmentation without stopping the plant?
Start with an inventory of what talks to what across the boundary, because segmentation breaks the flows nobody documented. Plan the cutover around planned shutdowns and keep a rollback for each zone. It depends on how many undocumented connections exist and on whether your control vendors will support the change.
A breach came through a supplier's access to our systems, how should we govern vendor access after this?
Start with an inventory of who connects, to what, and why, and remove the access nobody can justify. Then enforce the basics on what remains: named accounts, strong authentication, least access and time limits. Questionnaires come after that. It depends on how many suppliers have access and on which systems they reach.
Automation vendor demands always on remote access to our control network for support, how do we agree to something safe?
Vendors accept controlled access more often than their standard contract suggests: session-based, approved by the plant, recorded, through a jump host, with named accounts. Write those conditions into the contract and offer a fast approval process so support is still quick. It depends on which systems need vendor support and on what your security policy allows.
After a breach at a vendor hosted system, what hosting and security requirements should we put in every contract?
Require controls you can verify, such as data location, encryption, access logging, breach notification within a short defined time and the right to audit, and tie them to the data's sensitivity. Then check them, because a requirement nobody verifies is a wish. It depends on your data classification and on what approved hosting options exist for your sector.
Should we relax refinery network isolation to enable an analytics project?
Require evidence that the business benefit cannot be achieved within the existing isolation boundary. It depends on the information the analytics actually needs and the operational exposure created by any exception.
Should we accept software without visibility into its critical third-party dependencies?
Require an inventory tied to the delivered build and a maintenance process. Completeness matters only if you can identify affected versions and obtain corrective action when needed.
Do we need dedicated industrial cybersecurity software or can existing tools suffice?
Choose against the plant risks and operating constraints that must be covered. It depends on demonstrated visibility, safe use around the installed equipment, response ownership, and the gap remaining after existing controls.
How I can help with this decision
- Ask or talk (Free)
- I give my view on the access model vendors usually accept, and the inventory step that most plans skip.
- Review (Pay if it was worth it)
- I write an independent assessment of the access design, the vendor's terms or the proposed platform against your security policy and operating continuity. I recommend the scope, the sequence and the terms to sign or refuse.
- Retain (When it makes sense)
- I stay available to review cutover plans, access reviews and vendors' evidence against the terms as renewals come up.