Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
API Standard for Third Party Network Connectivity 2007: Securing the Operational Technology Boundary in Pipeline Systems
Technical deep dive into the scope, segmentation requirements, and compliance framework for third party access to critical SCADA and control networks.
The API Standard for Third Party Network Connectivity 2007 establishes the baseline architecture and technical controls for allowing external entities—such as pipeline SCADA vendors, remote engineering firms, and regulatory bodies—to safely access an operator’s Operational Technology (OT) network. Published by the American Petroleum Institute, this standard was an early driver for the Electronic Security Perimeter (ESP) concepts that were later formalized in the broader API 1164 cybersecurity lifecycle and aligns conceptually with the zones and conduits model of IEC 62443. This article reviews the core technical requirements, implementation strategies, and key compliance notes.
Scope and Applicability
The standard applies to any electronic communication link established between a pipeline control system (including control centers, RTUs, and pipeline SCADA historians) and an external third party. The scope explicitly covers:
- Persistent site-to-site VPN connections to third-party remote operations centers.
- On-demand remote access by field service technicians and OEM support personnel.
- Automated data feeds for regulatory compliance and flow accounting.
- Interconnections with engineering analysis platforms.
The standard specifically excludes internal corporate enterprise networks (merely passing through the corporate AS is covered) and pre-existing hard-wired connections which are decommissioned.
Critical Scope Note: The standard does not cover the physical security of the third party’s own facilities or network equipment. It assumes the operator has no visibility or control over the third party’s internal security posture. All trust is relegated to the designed boundary controls at the operator’s Electronic Security Perimeter.
Core Technical Requirements
Architecture: The Dual-DMZ Model
The 2007 standard mandates a dual-firewall architecture to create an Operational Demilitarized Zone (ODMZ). Traffic must traverse at least two discrete firewalls:
- External Firewall: Terminates the third party’s VPN tunnel and performs access control list (ACL) enforcement.
- Internal Firewall: Allows only application-layer traffic (e.g., port 44818 for EtherNet/IP, port 20000 for DNP3, port 443 for secure Historian queries) from the DMZ to the process control network.
Direct traffic flows from the third party to the control network are strictly prohibited.
Jump Host and Bastion Host Configurations
All interactive access by third parties must be mediated through a Jump Host (Bastion Host) located within the DMZ. The Jump Host serves as the single point of entry and audit. Requirements include:
- Dual-factor authentication (SMART card, TOTP, or certificate-based).
- Session logging (all keystrokes and screen output must be recorded to a Syslog server).
- Role-Based Access Control (RBAC) restricting commands and destinations.
Best Practice: Implement a “just-in-time” access model for Jump Hosts. Tickets are auto-approved only for the duration of the maintenance window. This limits the time window for credential compromise.
| Connectivity Layer | Required Authentication | Minimum Encryption | Protocol Filtering |
|---|---|---|---|
| VPN Tunnel (External to DMZ) | Certificate + PSK or MFA | AES-256 (IKEv2/IPSec) | ESP / IKE/ NAT-T only |
| Jump Host Access (DMZ to DMZ) | MFA + AD/LDAP | TLS 1.2 | SSH (22), RDP (3389) |
| Control System Data (DMZ to Control Net) | Application Layer + IP Allowlist | Native or TLS tunnel | DNP3, Modbus TCP, OPC UA |
| Historian Replication | Certificate + Service Accounts | TLS 1.2 | HTTPS (443), MS SQL |
Table 1: Minimum Security Control Matrix for Third Party Connections
Implementation Highlights
Successful implementation requires close collaboration between the pipeline operator’s OT engineering team and the security office. Key implementation steps include:
- Network Segmentation: Mapping all third party connections to a dedicated VLAN within the DMZ, separate from vendor specific VLANs or corporate traffic.
- Intrusion Detection: Placing network taps in the DMZ to feed an IDS (e.g., Zeek/Bro) tuned specifically for SCADA protocol anomalies.
- Log Aggregation: Forwarding logs from VPN gateways, Jump Hosts, and DMZ firewalls to a centralized Security Information and Event Management (SIEM) system with a minimum retention of 365 days.
- Vendor Hardening: Requiring third parties to submit pre-hardened laptops or dedicated remote access gateways (RAGs) that meet the operator’s build standard.
Operational Success: Operators who adhere strictly to the DMZ and Jump Host requirements of the 2007 standard typically reduce the attack surface by 80-90% compared to flat network architectures. It creates an unambiguous choke point for monitoring and control.
Compliance Notes and Auditing
Compliance with the API Standard for Third Party Network Connectivity 2007 is often audited as a pre-requisite for connecting to major pipelines. Auditors look for:
- Policy Documentation: A formal Third Party Connectivity Policy signed by the OT Security Manager.
- Configuration Reviews: Annual review of firewall rules to remove unused or permissive ANY/ANY rules.
- Penetration Testing: Annual external penetration tests against the DMZ from the internet and quarterly internal tests from the vendor network segment.
- DIAP Compliance: The standard aligns with the Department of Transportation’s Pipeline and Hazardous Materials Safety Administration (PHMSA) requirements for Data Integration and Access Protocols.
Non-Compliance Risk: Failure to adhere to the Jump Host authentication and logging requirements is a common finding in PHMSA audits. A failure to show evidence of session recording for a third party incident can result in operational shut-downs and the initiation of a Corrective Action Plan (CAP).
The 2007 standard remains an essential reference document for any pipeline operator establishing or auditing third party electronic connections. While newer standards like API 1164 offer a broader system lifecycle view, the specific architectural mandates of this connectivity standard—particularly its stringent DMZ and dual-firewall principles—provide a mature, high-assurance foundation for defending the process control network against external threats.
Q: Does the API Standard for Third Party Network Connectivity 2007 conflict with modern cloud-based SCADA architectures?
A: Not inherently. The architectural principles of the DMZ and Jump Host apply equally to cloud deployments. The third party connection to the cloud gateway is outside the operator’s scope, but the cloud environment itself must replicate the DMZ/ODMZ structure defined in the standard. API 1164 provides additional guidance for cloud deployments.
A: Not inherently. The architectural principles of the DMZ and Jump Host apply equally to cloud deployments. The third party connection to the cloud gateway is outside the operator’s scope, but the cloud environment itself must replicate the DMZ/ODMZ structure defined in the standard. API 1164 provides additional guidance for cloud deployments.
Q: What is the recommended frequency for updating Jump Host credentials used by third parties?
A: The standard recommends a maximum credential lifespan of 90 days for automated service accounts and daily or per-session credentials for interactive human access. MFA tokens should be synchronized with the contract lifecycle.
A: The standard recommends a maximum credential lifespan of 90 days for automated service accounts and daily or per-session credentials for interactive human access. MFA tokens should be synchronized with the contract lifecycle.
Q: How does this standard interact with NIST SP 800-82 (Guide to Industrial Control Systems Security)?
A: NIST 800-82 provides general guidelines, while the API Connectivity Standard provides the specific implementation for Oil & Gas OT networks. The DMZ architecture in the API standard directly addresses the “Network Architecture” and “Boundary Protection” controls (SC-7) in NIST 800-82.
A: NIST 800-82 provides general guidelines, while the API Connectivity Standard provides the specific implementation for Oil & Gas OT networks. The DMZ architecture in the API standard directly addresses the “Network Architecture” and “Boundary Protection” controls (SC-7) in NIST 800-82.