Security: NIST Considerations
Written by Joe Tietz
The Approach:
NIST 800.82 R2 builds an overly to NIST 800.53 R4 standard. A fundamental approach is to enable communication between an Industrial Control System (ICS), and a corporate network is through intermediate DMZ. The ICS and corporate networks should never communicate directly with each other. A typical architecture for this is the Purdue model using network zones.
General security best practice is that a single product, technology, or solution can not adequately protect ICS. Using a multi-layer strategy utilizing a minimum of two security tools is advised. With tools, we still need to have adequate security policies, incident response, and physical security. The greatest threat is still hacking the human element; security training is critical if not more critical, than any toolset.
As the technology landscape changes, so do prevalent standards to protect ICS. This year, NIST 800-207 was finalized, paving the way for Zero Trust Architecture (ZTA) to protect ICS.
Goal:
To build security architecture with a multi-layer strategy based on NIST 800-82 R2 with an extra overlay of protection based on NIST 800-207 (ZTA)
Toolset:
One of VMware’s key building pillars is Intrestic security and a rich toolset consisting of NSX-T, NSX Advanced Security, AVI, and Carbon Black that are supported by VCF (SDDC Manager) and vRealize Suite (vRA, vLI, vIDM, vROPS). You might be asking your self where is vRealize Network Insight (vRNI). This tool is great but currently does not come with VCF or vRealize Suite; it is considered an add-on.
As complete of a vision VMware has with Intrestic security, it does not cover all use cases. Natural partners are Cisco and Palo Alto. Cisco’s rich toolset includes Cisco ACI, Cisco Stelathwatch, Cisco ISE, and Cisco DNA, with Palo Alto’s Panorama rounding out the typical solution set.
Layered Intrinsic Security:
This toolset has overlapping, and some might say competing technology. I see it more layered defense approach with best breed technology at both the physical and virtual layers.
The diagram below will capture the use case of using the toolset to achieve this blog’s stated goal.
Disclaimer: I did not depict the internet DMZ; this architecture is based on the Purdue model but is not certified by any regularity governance body.
Conclusion:
By preventing direct communication between IT and OT systems and having a broker service in the IDMZ relay the communications, an extra layer of separation and inspection adds to the overall architecture. Systems in the lower layers are not directly exposed to attacks or compromise. If something were to compromise a system at some point in the IDMZ, the IDMZ could be shut down, the compromise could be contained, and production could continue.
This blog focused on the toolset and some of the primary controls to finish the complete design, including operational playbooks I encourage you to read:
NIST 800-53 R4 (Set to be withdrawn 9/23/2021)
vPSO 