Webb Technologies · brief for IT, security and controls
How a plant-floor software project works with your IT, security and controls teams
A summary of how we work on plant-floor projects, for the people who review them. The specifics for your site, such as the systems, accounts and firewall rules, are written into the scope for your project and agreed before work starts.
1.Data flow: read-only by default
- By default we read plant data read-only from your historian or an OPC UA server, through your industrial DMZ where you have one, so nothing in the cloud or on the business network opens a connection into the control network.
- We read from the highest layer that has the data, the historian or an OPC UA server such as Kepware, not the controllers. PLC logic and panel HMIs stay with your controls team and integrator.
- Anything that writes back to the plant, such as setpoints, recipes or commands, is scoped separately with your controls engineers, never added to an existing read-only path.
Three zones. OT network: PLCs and HMIs, unchanged, with no connection to the project; and the historian or OPC UA server, read through a read-only account. A solid line marks the OT boundary. Industrial DMZ, where present: a collector built in the project reads the historian or OPC UA server, read-only, and pushes outbound over HTTPS. Your cloud account or network: the API and database, and the dashboards and screens people use, with sign-in through your identity provider. Every arrow points away from the plant. Nothing in the cloud or on the business network opens a connection into the OT network.
2.Access we need, and who grants it
We work through the access your team grants. For reading plant and business systems we ask for read-only service accounts, one per system, named and documented, rather than shared or personal logins. The exact accounts are listed in the scope for your project.
Access a plant-floor project typically needs and who grants it
- System
- Historian (or its DMZ replica)
- Access:
- Read-only account limited to the named points
- Granted by:
- Controls team
- System
- OPC UA server
- Access:
- Read-only user scoped to the named tags
- Granted by:
- Controls team
- System
- Business databases, if used
- Access:
- Read-only login to named views
- Granted by:
- IT
- System
- Firewall rules
- Access:
- Opened by your network team; we don't change network equipment
- Granted by:
- Network team
- System
- Repositories and cloud accounts
- Access:
- Member access for us during the project
- Granted by:
- IT
- System
- Sign-in for users
- Access:
- Through your identity provider
- Granted by:
- IT
| System | Access | Granted by |
|---|---|---|
| Historian (or its DMZ replica) | Read-only account limited to the named points | Controls team |
| OPC UA server | Read-only user scoped to the named tags | Controls team |
| Business databases, if used | Read-only login to named views | IT |
| Firewall rules | Opened by your network team; we don't change network equipment | Network team |
| Repositories and cloud accounts | Member access for us during the project | IT |
| Sign-in for users | Through your identity provider | IT |
3.Where code, data and infrastructure live
- In your repositories and cloud accounts, from the start. All code, infrastructure and documentation are yours. No lock-in.
- Infrastructure is defined as code, so every environment matches and every release can be repeated.
- We work to your requirements for access, hosting and data, and flag anything we can't meet during scoping.
4.NDA, security questionnaire and walkthrough
- NDA before any engagement. We sign it before any other work starts.
- We answer your security questionnaire and walk your IT, controls and security teams through the architecture.
- Before any connection to plant systems, your teams get a data-flow diagram showing every connection and its direction, and a firewall rule list with the source, destination, port, protocol and purpose of each rule.
5.What your controls team reviews and signs off
- The data-flow design, before we build and before any software connects to the historian or OPC UA server.
- The tag list, and the permissions of the read-only accounts: they can read, and a write is refused.
- Any proposal to write to the plant, as its own separately scoped piece of work.
6.What's handed over at the end
- The code, infrastructure, documentation and access, all under your control.
- Architecture and setup notes, deployment and operations guides, and knowledge transfer with the people who will own it.
- Every account confirmed as yours, secrets rotated, and our access removed or reduced to whatever support is agreed.
7.How changes are agreed: in writing
If the scope needs to change, we price the change and agree it with you in writing before doing the work. Nothing is added to your bill without your say-so.