Integrating VMware Avi into Purdue and NIST Frameworks for the Marine Industry

A practical architecture guide for protecting vessel IT, OT, and maritime services with application delivery, segmentation, and cybersecurity governance

Modern vessels increasingly depend on interconnected systems: navigation, automation, propulsion monitoring, cargo operations, crew services, and shore-based management. This connectivity improves efficiency, but it also creates a larger attack surface and makes the separation between IT, OT, and safety-critical systems essential.

VMware Avi, now part of VMware Avi Load Balancer, can contribute to this environment by providing application delivery, load balancing, health monitoring, and application-layer traffic controls. However, it is important to position Avi correctly: it is an application delivery and security component—not a replacement for OT firewalls, industrial segmentation, or vessel safety controls.

This article explains how to integrate Avi into a Purdue Model architecture, map its capabilities to the NIST Cybersecurity Framework, and apply the design to a marine environment without introducing unnecessary risk to operational technology.

Why This Matters in Maritime Cybersecurity

A vessel is not simply a floating data center. It is a cyber-physical environment where a disruption to an application can affect cargo operations, maintenance, communications, or—if poorly designed—operational safety.

A useful architecture must therefore answer three questions:

Where does the application belong in the Purdue Model?
Which NIST cybersecurity outcome does each control support?
How can security be improved without creating a new dependency or attack path into critical OT systems?

The Purdue Model provides a way to organize industrial systems by operational function and trust boundary. NIST CSF 2.0 provides a risk-management structure built around six functions: Govern, Identify, Protect, Detect, Respond, and Recover. NIST describes CSF 2.0 as a taxonomy of cybersecurity outcomes rather than a prescriptive list of technologies.

1. Understanding VMware Avi in a Marine Environment

VMware Avi Load Balancer is a software-defined application delivery platform. Its capabilities include load balancing, application health monitoring, TLS termination, application analytics, and—depending on the deployed edition and configuration—security capabilities such as WAF, rate limiting, and DDoS protection.

In a vessel or maritime data-center environment, Avi can be used to protect and distribute traffic for applications such as:

Crew welfare and intranet portals
Maintenance and condition-monitoring dashboards
Cargo and logistics applications
Fleet management portals
Ship-to-shore reporting services
Vendor access portals
Maritime analytics and API services
Replicated applications hosted across vessel and shore infrastructure

What Avi should not do

Avi should not become a direct control path to:

Main engine PLCs
Propulsion control systems
Navigation control systems
Safety instrumented systems
Cargo-control PLCs
Critical field devices

These systems require their own approved industrial security architecture, access controls, and operational procedures. Avi can protect applications that consume OT data, but it should not be used as a substitute for an OT firewall, safety boundary, or industrial protocol security gateway.

2. Purdue Model Mapping for Marine Operations

The following mapping adapts the Purdue Model to a vessel and its shore-connected environment. Exact layer assignments may vary by vessel design and vendor architecture.

Layer-by-layer integration

Purdue layer	Marine examples	Avi integration
Level 5	Fleet management, shore cloud, ERP, corporate identity	Load balance shore applications, protect external portals, provide TLS and application analytics
Level 4	Vessel IT, crew services, maintenance applications	Primary placement for internal application delivery and secure application access
Level 3.5	Industrial DMZ, jump servers, file transfer, historian replication	Optional placement for approved DMZ applications; enforce application boundaries
Level 3	HMI, SCADA, historian, engineering workstations	Usually consume protected services through approved interfaces; avoid direct Avi dependency for control functions
Levels 0–2	Sensors, actuators, PLCs, propulsion, navigation, safety	No direct Avi insertion into control loops; preserve deterministic operation and approved OT controls

Design principle: Avi should sit beside the Purdue security architecture, not replace it.

3. Reference Architecture: Vessel-to-Shore

The following reference design separates application delivery from control-system traffic.

Recommended traffic flows

Example 1: Fleet maintenance dashboard

The application can present maintenance information without exposing the engineer directly to the PLC network.

Example 2: Vendor remote support

Avi may protect the vendor-facing application, but remote access authorization, session control, and OT access policy remain separate responsibilities.

4. Avi Components and Their Roles

Avi commonly uses a Controller for centralized management and Service Engines to process application traffic. The platform supports centralized policy management, analytics, and application delivery across supported environments.

Component responsibilities

Component	Purpose	Marine design consideration
Avi Controller	Central configuration, policy, analytics	Place in a secured management zone; restrict administrative access
Avi Service Engines	Application traffic processing	Deploy only in approved IT/DMZ segments; avoid direct control-network placement
Virtual Services	Front-end application endpoints	Use dedicated IPs, DNS names, certificates, and access policies
WAF / application security	Inspect and control supported web/API traffic	Apply to web applications, not raw PLC protocols
Health monitors	Check application availability	Use non-invasive application checks; avoid polling that can affect OT systems
Analytics / logs	Visibility into application traffic and performance	Forward relevant events to centralized monitoring or SIEM

5. Mapping Avi to NIST CSF 2.0

NIST CSF 2.0 contains six core functions. The mapping below describes how Avi can contribute to those outcomes; it does not imply that Avi alone satisfies a function or control requirement.

NIST function	Objective in a marine environment	How Avi contributes	Additional controls required
Govern	Establish cybersecurity ownership, risk tolerance, and maritime security policies	Provides policy and administrative controls for application delivery	Governance, asset ownership, risk assessment, supplier management, safety management
Identify	Discover vessel applications, dependencies, and data flows	Application inventory, service visibility, traffic analytics	OT asset inventory, network diagrams, data classification, dependency mapping
Protect	Prevent unauthorized access and reduce application attack surface	TLS termination, WAF, access policies, rate limiting, application segmentation	Firewalls, MFA, PAM, network segmentation, secure configuration, patching
Detect	Identify suspicious traffic and service anomalies	Application analytics, security events, health monitoring	IDS/IPS, SIEM, endpoint monitoring, OT anomaly detection
Respond	Contain incidents while maintaining safe operations	Policy changes, service isolation, traffic blocking, operational visibility	Incident response plans, bridge procedures, OT incident playbooks, communications
Recover	Restore services and improve resilience	Application health checks, failover, service recovery support	Backups, disaster recovery, alternate communications, tested restoration procedures

Important distinction

Avi protects the application delivery layer. NIST CSF applies to the entire organization and its technology, people, processes, and supply chain. NIST explicitly states that the CSF does not prescribe a specific technology or implementation method.

6. Detailed NIST Integration Architecture

Example: NIST Protect outcome

Scenario: A vessel maintenance portal is exposed to approved shore users.

Avi controls:

TLS termination and certificate management
WAF policy for web requests
Rate limiting for abusive traffic
Application access restrictions
Health monitoring
Centralized application policy

Other required controls:

Identity provider and MFA
Firewall rules
Secure remote-access gateway
Role-based authorization
Vulnerability management
Logging and incident response

The resulting protection is layered rather than dependent on a single product.

7. Marine Industry Use Cases

Use Case A: Vessel Maintenance and Condition Monitoring

Problem: Maintenance teams need access to application dashboards, but the underlying OT systems should remain isolated.

Architecture:

Security benefit: The engineer interacts with a controlled application rather than directly accessing the control network.

Operational benefit: Multiple users can access a highly available application without placing additional traffic directly on the OT network.

Use Case B: Crew Portal and Vessel IT Services

Avi can distribute traffic for:

Crew welfare portals
Internal announcements
Training applications
Document management
Maintenance requests

HR and payroll interfaces

Design note: Crew and guest networks should remain separated from operational systems. Avi does not replace that segmentation.

Use Case C: Fleet Management and Shore Analytics

For shipping companies operating multiple vessels, Avi can provide consistent application delivery for fleet services hosted on shore or in a private cloud.

Security benefit: Centralized application policies and visibility can be applied to shore-hosted services.

Availability benefit: Load balancing and health monitoring can help maintain access when application instances fail.

Caution: Vessel-to-shore connectivity may be intermittent or bandwidth-constrained. The application architecture must support offline operation, local caching, and controlled synchronization where required.

8. Recommended Security Zones

A practical deployment should separate the management plane, data plane, and application backends.

Key design rules

Separate Avi management from application traffic.
Use dedicated administrative identities and least privilege.
Restrict Controller access to authorized management networks.
Place Service Engines only where application traffic is expected.
Use firewalls between IT, DMZ, and OT zones.
Do not route arbitrary IT traffic through OT networks.
Keep safety-critical control systems independent of Avi availability.
Forward security-relevant logs to centralized monitoring.

VMware’s Avi design guidance recommends dedicated accounts, role-based access, and least privilege for Controller administration and integrations.

9. Implementation Roadmap

Phase 1 — Govern and Identify

Define the vessel and shore cybersecurity scope.
Identify business-critical and safety-critical applications.
Document Purdue layers and trust boundaries.
Record application dependencies and data flows.
Identify owners for Avi, network security, OT, and vessel operations.
Define acceptable downtime and recovery objectives.

Deliverable: Approved application and network architecture.

Phase 2 — Protect

Deploy Avi in a dedicated management and application zone.
Configure secure administration and role-based access.
Create virtual services for selected applications.
Configure TLS certificates and approved access policies.
Apply WAF policies to supported web applications.
Integrate Avi with firewalls and identity services.
Validate that no new route to critical OT systems is introduced.

Deliverable: Controlled application delivery with documented security policies.

Phase 3 — Detect

Enable application analytics and health monitoring.
Forward relevant logs to the SIEM.
Establish alerts for abnormal application behavior.
Monitor failed authentication, policy violations, and service degradation.
Correlate application events with firewall and OT monitoring data.

Deliverable: A baseline of normal application behavior and an alerting process.

Phase 4 — Respond

Define procedures for blocking malicious application traffic.
Create a process for isolating compromised application instances.
Coordinate Avi changes with vessel operations and shore security teams.
Ensure emergency procedures do not depend on the availability of the application layer.
Test incident escalation and communications.

Deliverable: An incident response playbook covering Avi and adjacent systems.

Phase 5 — Recover

Test application failover and service restoration.
Maintain configuration backups.
Document recovery dependencies.
Validate that OT operations remain safe if Avi or the application is unavailable.
Review lessons learned and update the architecture.

Deliverable: Tested recovery procedures and an updated risk register.

10. Example Security Policy Matrix

Traffic flow	Allowed?	Recommended control
Shore user → Fleet application	Yes	HTTPS, Avi virtual service, WAF, identity, rate limiting
Crew device → Crew portal	Yes	IT firewall, network segmentation, Avi application policy
Vendor → Industrial DMZ jump server	Controlled	MFA, approved remote access, firewall rules, session logging
Maintenance application → Historian replica	Controlled	Allowlisted API or approved data protocol
Historian replica → PLC network	Highly restricted	OT firewall, approved one-way or tightly controlled flow
Avi Service Engine → Main engine PLC	No direct dependency	Preserve independent OT control architecture
Guest Wi-Fi → OT network	No	Network isolation and firewall enforcement
Avi Controller → OT control network	No direct management path	Dedicated management network and approved integration boundaries

11. Operational and Safety Considerations

Avoid creating a single point of failure

Avi can improve application availability, but the vessel must remain operational if Avi fails. Critical control and safety functions should not require:

An Avi Controller
An Avi Service Engine
A shore application
A cloud identity service
A ship-to-shore link

Use passive or low-impact validation for OT

When integrating or testing the architecture:

Prefer configuration review and traffic observation.
Use approved maintenance windows.
Validate application health checks against test or replicated services.
Avoid aggressive scans or malformed traffic against PLCs.
Do not introduce WAF or load-balancing policies into deterministic control paths.
Test failover without interrupting propulsion, navigation, or safety systems.

Consider maritime connectivity constraints

Satellite links and vessel-to-shore networks may have:

High latency
Limited bandwidth
Intermittent connectivity
Expensive data transfer
Strict operational availability requirements

Application design should account for these conditions through local services, caching, asynchronous synchronization, and graceful degradation.

12. Measuring Success

Avi integration should be evaluated using both cybersecurity and operational measures.

Area	Example metrics
Govern	% of applications with assigned owners and approved risk assessments
Identify	% of application dependencies documented; unknown services discovered
Protect	TLS coverage, WAF policy coverage, unauthorized access attempts blocked
Detect	Mean time to detect application anomalies; log coverage
Respond	Time to isolate a compromised application; incident playbook completion
Recover	Application recovery time; successful failover tests
Marine operations	No unplanned impact to OT systems; vessel application availability; shore-link resilience

These metrics should be interpreted in the context of vessel operations and safety requirements—not only IT performance.

13. Common Mistakes to Avoid

Conclusion

Integrating VMware Avi into a marine cybersecurity architecture is most effective when it is treated as an application delivery and security layer within a larger defense-in-depth design.

The Purdue Model helps define where systems belong and how they should be separated. NIST CSF 2.0 helps define what cybersecurity outcomes the organization needs to achieve. Avi contributes to those outcomes through application visibility, secure traffic handling, availability, and application-layer protection.

The resulting architecture should follow this principle:

Protect maritime applications aggressively, but protect operational control systems conservatively.

A well-designed deployment improves application resilience and visibility while preserving the independence, segmentation, and safety requirements of vessel OT.

Reference Architecture Summary

Author’s note: This is a reference architecture for design and planning. Actual vessel deployments should be validated against the vessel’s approved network diagrams, equipment vendor requirements, flag-state obligations, company security policies, and operational safety procedures.

Integrating VMware Avi into Purdue and NIST Frameworks for the Marine Industry

Why This Matters in Maritime Cybersecurity