AWS for Industries
How Woodside built a Level 3.5 OT DMZ on AWS
Woodside Energy is a global energy company, founded in Australia, providing reliable and affordable energy to help people lead better lives. From the first Liquefied Natural Gas (LNG) plant in the southern hemisphere, to the world’s largest not-normally-crewed offshore platform, to one of the first fully remotely operated LNG plants, Woodside has been at the forefront of digital technology adoption in the energy industry. To drive this level of technology adoption, Woodside has collaborated with companies like Amazon Web Services (AWS). With AWS, Woodside has pioneered an immersive 3D digital twin, called Fuse, introduced an Internet of Things (IoT) sensing system, and developed advanced supply chain optimization tools.
Woodside’s digital innovation extends to Operational Technology (OT). Industrial Control System (ICS) technology has evolved slowly and cybersecurity engineers responsible for OT security are challenged by a growing number of threat vectors. Engineers are exploring how cloud technology can help improve ICS security, while delivering the cost optimization, operational efficiency, and innovation opportunities that have been enjoyed by Information Technology (IT) teams for many years. In this post, we learn how Woodside addressed its OT cybersecurity challenges by migrating its ICS Demilitarized Zone (DMZ) networks to AWS, and we discuss some of the additional resulting benefits.
Migrating the DMZ to AWS
The Purdue Model (Figure 1) has been used since the 1990s and provides an architectural framework for segmenting ICS networks from corporate enterprise networks and the internet. Although the Purdue Model wasn’t originally intended as a cybersecurity tool, many energy asset operators find this hierarchy to be useful for delineating between IT and OT networks.
A Level 3.5 DMZ is often included as a security barrier, or buffer, to separate less secure corporate and internet environments in Level 4 from the Process Control Network (PCN), defined here as Level 3 and below. Level 3.5 DMZs are a logical or physical network zone, and the asset owner can require that all network traffic between the corporate environment and the PCN should pass through it. In an in-line implementation, the Level 3.5 DMZ includes a ‘northbound’ firewall into the corporate environment and a ‘southbound’ firewall into Level 3.
Figure 1 Purdue model with in-line Level 3.5 DMZ
A secure and flexible alternative to hosting the DMZ on-premises is now emerging: the migration, or extension, of the DMZ network to the cloud. This can be done completely privately, without exposing the PCN or Level 3.5 network directly to the internet. This allows OT services in the cloud to connect to the site across one consistent, secure, and private hybrid network. It also enables the asset owner to prescribe a consistent and highly secure PCN remote access method to its contractors.
Woodside has traditionally maintained a central Level 3.5 DMZ hosted on hardware independent from the corporate environment and behind its own firewalls. Plants and offshore facilities are connected securely to the central DMZ. Woodside decided to move its on-premises Level 3.5 DMZ to AWS with the advent of cloud technology, and its desire to increase connectivity, use modern security and artificial intelligence/machine learning (AI/ML) tools, and reduce IT capital costs. Woodside determined that this would enable it to use centralized, modern security artifacts that would improve its cybersecurity posture, allowing for stronger detective controls and better access to modern software as a service (SaaS) security solutions.
Additional benefits of migrating the DMZ to AWS include:
- Tighter alignment with corporate IT security policies and practices.
- Direct integration of SaaS remote access tools to bring international engineering support closer to the operations, while maintaining identity and network control within the corporate environment.
- Reduction in on-premises computing and networking hardware.
- Improvement in change management tracking and operational efficiency.
- Inter-regional scalability and reduced human errors enabled through the adoption of infrastructure as code (IaC) DevOps.
- Improved system reliability, availability, and resilience.
- Web OT portals accessible through ephemeral hosts.
- Direct access to cloud-native AI/ML services and applications from AWS and AWS partners.
DMZ design
A high-level architecture for the central DMZ is presented in Figure 2. The architecture is highly available and resilient, and it relies on the elasticity and flexibility of AWS Transit Gateway. This fully managed networking service allows companies to build hub-and-spoke networks, connecting up to thousands of Amazon Virtual Private Clouds (Amazon VPCs) and AWS Site-to-Site Virtual Private Networks (VPNs) running over all-private, dedicated connections. VPCs are logically isolated virtual networks and Transit Gateway routing can be defined to allow, or block, communication between any combination of VPC and VPN ‘attachments’. Traffic between these attachments can be optionally routed through a security Inspection VPC, in which AWS Network Firewall or the company’s preferred third-party security appliance, or Next Generation Firewall, can inspect and intercept traffic. AWS also supports Traffic Mirroring for out-of-line deep packet inspection. The Transit Gateway-based approach allows companies to quickly build isolated and protected networks with segmented levels and zones that suit their requirements.
Figure 2 Centralized OT DMZ on AWS
Remote access for Woodside OT staff
Australia’s Security of Critical Infrastructure (SOCI) guidance emphasises the importance of implementing hardened remote access patterns for operators of critical energy assets. Comparable governmental cybersecurity guidance exists in many countries. Remote access to OT systems is required by OT engineers to commission and patch control systems, deploy code updates, and monitor and manage operations from remote locations. Remote access hosts typically reside in the DMZ and must be protected by security controls. These controls must be defined in an operator’s risk management plan, and AWS provides the digital tools and compliance certifications that help asset operators to meet these obligations.
Woodside built a custom web “OT Portal” for remote access from the DMZ (Figure 3). This allows OT staff to access OT workloads from the trusted IT corporate networks using an OT-specific identity. The OT remote access user identities are federated against a dedicated OT Azure AD, which has a B2B trust relationship with the Corporate AD. OT-issued Multi-Factor Authentication (MFA) is required.
The OT Portal is accessed with AWS AppStream 2.0, and traffic is secured using AWS WAF and Amazon CloudFront. AppStream 2.0 provides secure and scalable access to non-persistent desktops and applications from any location. This approach offers advantages as compared with conventional on-premises remote hosts. The ephemeral nature of the instances reduces the bastion host attack surface. No customer data leaves AWS and only encrypted pixels are transmitted to the user’s device. In the rare event that host operating systems are affected by an issue like the 2024 CrowdStrike outage, applying a fix to a single AppStream 2.0 image enables an entire fleet of hosts to instantly become functional again.
Connectivity
Communications between the DMZ and Woodside assets run over a dedicated OT AWS Direct Connect. This service links corporate or site networks directly to AWS with dedicated, low-latency physical infrastructure. Direct Connect ensures fast, private communications between the DMZ and Woodside’s operating facilities, with IPSec encryption applied in a VPN overlay.
For smaller, remote, or less critical sites, Woodside can connect their cloud DMZ via their third-party Secure Access Service Edge (SASE) solution and Software Defined Wide Area Networks (SD-WAN). SD-WAN overlay tunnels can operate over a range of communication technologies, including LTE and Wi-Fi mesh networks. Amazon’s Project Kuiper satellite communications network will soon offer another option for building and connecting remote OT networks, as it allows for fully private connectivity from almost anywhere on the planet, directly to the AWS backbone.
Woodside maintains a manual site firewall disconnect procedure to isolate the control systems during an emergency “lock-in” scenario. This can also be achieved in software with, for example, a manually executable AWS Lambda function that creates a blackhole route in a Transit Gateway.
Remote access by third-parties
Woodside’s SASE solution allows industrial automation vendors and system integrators to connect securely to the SASE VPC in the DMZ from a pre-configured hardware device sent to them by Woodside. Woodside can now dictate a security baseline profile through which its vendors and integrators access the PCN to commission, program, or patch Programmable Logic Controllers (PLCs) and other ICS assets. This is operationally more efficient than setting up a unique, temporary VPN architecture for each vendor access event.
AWS account management and security
Woodside uses multiple OT-specific AWS Organizations to provide strong isolation between groupings of AWS accounts in the DMZ architecture. Organizations is a service that allows customers to centrally manage and govern multiple AWS accounts. One of its key features is Service Control Policies (SCPs), which are used to set guardrails for users with the fine-grained controls available in AWS Identity and Access Management (IAM). By using multiple Organizations, Woodside can completely isolate the landing zones, governance, and security controls between root accounts responsible for the pre-existing IT networks, the OT Level 4 networks, the ‘Tier 0’ Level 3.5 Domain Controller VPC, and ‘Tier 1’ workload VPCs. A root AWS account may only create a single Organization, which mitigates the risk that a compromised Tier 1 account could, for example, compromise the Domain Controllers. Woodside’s root accounts are configured with MFA and physical Fast IDentity Online (FIDO) keys, which are stored in a vault. The root accounts are not used for day-to-day tasks and they are monitored. A zero trust model is applicable to all users accessing the DMZ.
Amazon GuardDuty is used as an additional security layer to protect all accounts, workloads, and data with intelligent threat detection. All data at rest, in all workloads, is encrypted using AWS Key Management Service (AWS KMS). Passwords are protected using AWS Secrets Manager.
Logging and system maintenance
Woodside’s Computer Security Incident Response Team (CSIRT) receives domain and traffic logs for analysis. Logs generated from VPC Flow Logs and AWS CloudTrail are sent to CloudWatch Logs. AWS Config is used to assess, audit, and evaluate any changes to the architecture in accordance with recognized industry cybersecurity frameworks, and AWS Backup is used to persist images of the architecture for disaster recovery (DR) purposes.
Woodside commits DMZ IaC into continuous integration and continuous delivery (CI/CD) pipelines, backed by secured code repositories. This allows it to automate the delivery of Staging and Production code for the DMZ, and to rapidly stand up new central DMZs in overseas AWS Regions, which connect to the Woodside sites in those locations.
Woodside uses AWS Systems Manager to automate common, repetitive operations and management tasks across its AWS accounts. Systems Manager works across hybrid networks and can be used to manage hosts in the cloud, or on-premises, with customized runbooks. Common use cases include patching the host OS, creating backups, and restarting servers during Maintenance Windows.
File transfer
The ability to securely transfer files between the DMZ and the control environment is an important requirement for an industrial control system. Files pulled into the PCN can include software updates, patches, configuration changes, scripts, and more. Data extracts, system logs, reports, and backups are examples of files that may need to be exported out of Level 3.
Woodside developed a file transfer solution that mitigates the risk of malware infiltration into the control environment and prevents confidential information leakage. Files bound for the OT environment are uploaded into the OT Portal and deposited into an Amazon S3 ‘dirty’ bucket. This triggers a custom AWS Step Functions workflow, involving multiple Lambda functions. Files are indexed and the metadata is stored in Amazon DynamoDB. The files are checked by GuardDuty Malware Protection for Amazon S3. These checks include anti-virus, zip bomb, and file type inspections. Files that pass are moved into a ‘clean’ bucket before transfer to a site file server. Files on the site servers can be browsed from the DMZ. When files are pushed out of the OT environment, a similar, automated workflow is triggered.
North-South traffic
An OT internet egress capability in this architecture allows Woodside to download data files, OT operating system patches, anti-virus updates, and firewall patches. This is achieved with a dedicated OT Level 4 Organization or “OT Egress Org”. Traffic passes through Network Firewall, a NAT gateway, and an internet gateway to reach the internet.
East-West traffic
Data may be shared from the OT Egress Org to another Organization, or account, over a peered network connection (VPC or Transit Gateway peering) that operates at Open Systems Interconnection (OSI) Layer 3. This is equivalent to joining two Purdue Level 4 networks. If East-West firewalls are required between sites, then another Inspection VPC can be introduced as a Transit Gateway attachment.
AWS PrivateLink can also be used to connect VPCs and AWS services over the private AWS backbone between accounts and Organizations in different AWS Regions. In this architecture, private endpoint services can be configured in the OT Egress Org, to which an endpoint client in the “IT Org” requests a connection. This gives OT staff complete control over the connection, and there are multiple options for sharing data. For example, an MQTT broker in the OT Egress Org could connect to a data source (such as an historian) located in the DMZ, and publish messages to a consumer in the IT Org. An endpoint service can also be set up in the reverse direction. PrivateLink is an OSI Layer 4 connection, so it can’t be used to transfer Modbus TCP or OPC-UA data.
ISA/IEC 62443
ISA/IEC 62443 is a set of standards that focuses on cybersecurity for operational technology in automation and control systems. ISA/IEC 62443 emphasises the need for risk assessment, defence-in-depth strategies, and the establishment of risk ranked ‘zones’, based on the potential impact to the business if the zonal systems are compromised. The zones are interconnected by ‘conduits’. The layered structure of the Purdue Model supports the ISA/IEC 62443 concept of defence-in-depth, but it does not obviate the ongoing importance of defining secure zones and conduits within the levels.
Woodside found that a cloud-native approach to re-imagining the Purdue Model can be achieved while embedding ISA/IEC 62443 security measures that harden the zones within these levels. AWS tools and services are well-suited to achieving these measures. For more information, readers are directed to Guidance on using ISA/IEC 62443 for IIoT projects. NIST 800-82 is another commonly used guide that can be used to characterize, segment, and isolate devices and workloads in OT systems built on AWS.
The project
Woodside led the build with a team of contracted and internal technical staff. The design phase began with the specification of functional requirements. The architecture was designed in accordance with AWS Well-Architected and was aligned with Woodside’s cloud governance tools and standards for consistency with its existing in-house practices and skills.
A Staging environment was built first to handle the traditional Woodside OT ‘Develop’ and ‘Test’ processes applied to new OT systems. The team built the entire platform in parallel to the existing, operational DMZ. The OT Team began testing the new DMZ features and functionality against the requirements and some early use cases. The Staging environment was connected to a Staging PCN for performance testing, user testing of remote access, file transfer testing, and debugging.
During the testing phase, the design was completed and preparations were made to add new tunnels to remote sites to allow connection of the Production environment. A small user group was engaged to test within Staging, and then within one Production demonstration site. Once stable, users were set up in the system and asked to commence authentication. When most users had completed initial connections, the old DMZ network was shutdown. There was no downtime or loss of capability during the migration.
Conclusion
The new DMZ has improved Woodside’s OT cybersecurity, while providing a range of additional benefits. It has streamlined the OT team’s operations by standardizing remote access patterns and reducing on-premises hardware. The project has fostered closer collaboration between OT and IT staff, creating synergies for designing and maintaining future cloud-connected sites. New OT resources are now only a few clicks away and engineers can quickly test new ideas or trial a wide range of SaaS solutions from the AWS Marketplace. Woodside is now exploring and developing concepts for a Level 3 PCN on AWS. This will connect across sites and open up a range of opportunities to migrate new OT workloads to the cloud.
A DMZ on AWS is an excellent foundation for companies to enhance their OT systems with advanced cloud technologies, and it provides a place for OT engineers to securely host and manage industrial applications of the future. These will include components of AI production optimization systems, cloud-native historians, OT data modelling tools, computer vision systems, and predictive maintenance solutions, to name a few. For more information, contact your AWS account representative or the AWS author below.