NetApp HCI FISMA Reference Architecture · NetApp HCI Reference Architecture for FISMA v1.1| White Paper 6 NSX is a recommended element of the reference architecture with capacity

W H I T E P A P E R – J A N U A R Y 2 0 2 0

NETAPP HCI REFERENCE ARCHITECTURE FOR FISMA SUITABILITY TO ASSIST AGENCIES AND CLOUD SERVICE PROVIDERS IN F ISMA DEPLOYMENTS

C O A L F I R E O P I N I O N S E R I E S

NetApp HCI Reference Architecture for FISMA v1.1| White Paper 2

TABLE OF CONTENTS EXECUTIVE SUMMARY .............................................................................................................. 3

DESCRIPTION OF FISMA USE CASE AND ASSUMPTIONS .................................................... 3

OVERVIEW ............................................................................................................................... 3

Reference Architecture Assumptions ........................................................................................ 3

MULTITENANT MODEL with MANAGEMENT CLUSTER ......................................................... 4

NETWORK AND BOUNDARY DESIGN ...................................................................................... 5

COMPUTE NODE CLUSTERING ................................................................................................ 7

STORAGE .................................................................................................................................... 9

EXTERNAL TECHNOLOGY REQUIREMENTS .......................................................................... 9

Coalfire Opinion ........................................................................................................................ 10

A Comment Regarding Regulatory Compliance ..................................................................... 10


EXECUTIVE SUMMARY Based on a product knowledge of NetApp HCI, which is a combined technology stack containing compute,

network, and storage elements, the Federal markets are targeted for small to medium scale deployment of

dedicated cloud environments. It is the purpose of this solution brief to present a representative use-case-

driven Reference Architecture (RA) of HCI for this marketplace.

DESCRIPTION OF FISMA USE CASE AND ASSUMPTIONS

OVERVIEW FISMA is a law enacted in 2002 that mandates a process to strengthen the security posture of government’s

information systems. When most agencies (and their vendors) discuss being “FISMA compliant,” they are

usually referring to meeting the controls identified in National Institute of Standards and Technology (NIST)

Special Publication (SP) 800-53, “Recommended Security Controls for Federal Information Systems.” This

is because the law is enforced through various processes (as described by the Office of Management and

Budget Circular [OMB] A-130), which establish definitions, processes, and requirements for federal

agencies to follow.

FISMA (through A-130) recommends guidance issued by NIST, such as FIPS 199, FIPS 200 for impact-

level categorization (Low, Moderate, or High-impact systems), and NIST SP 800-53A Revision 4

Recommended Security Controls for Federal Information Systems and Organizations (NIST SP 800-53 Rev

4) for the selection and implementation of security controls based on the system impact level. The control

selection, implementation, and testing are where IT professionals responsible for “FISMA compliance”

perform the majority of work especially when meeting compliance is essential to receiving an authority to

operate (ATO) by government agencies.

For our HCI Reference Architecture example, Coalfire is making a number of assumptions about the nature

of workloads, agency requirements, and risk posture to assist in reducing the vast potential number of

possible modes of HCI deployment.

REFERENCE ARCHITECTURE ASSUMPTIONS Our assumption for the RA model and key use case are as follows:

• Workloads are moderate or simple in their complexity, being composed of a single line of business

applications.

• Agency data is considered critical, private (PII), and at risk for undesirable disclosure and must be

contained and protected.

• Multiple workload consumers access the application via a variety of connection models, including

classic client-server, web access, and application front-end processed. These modes are typically

delivered via three-tier, classic applications, yet may be deployed using cloud-native and

containerized processing elements.

• As is required by HCI, external network services supply VLAN, routing and firewall services which

surround and sustain the HCI.

• Following the recommended design patterns of VVD, which are depicted in this VMware reference

diagram:


VMware ESXi clustering is used to create a Management cluster on two ESXi hosts, to operate the

core vCloud components (VMware vCenter, vRealize Operations, ESXi management, Update

Manager, vRealize Log Insight, and so on), an edge cluster (perimeter firewall, DLR, and NSX

controller VMs) on two hosts, and a minimum of two hosts for the tenant/workload (called the

compute cluster in the original VMware design guides).

• HyTrust DataControl resides in the tenant/workload cluster to provide complete ownership of the

VM and Key Management by the tenant admin.

• VLAN and datastore provisioning is reserved for management administration, and workload

functions will add, move, or delete resources running on the VLANs and datastores created by the

management admin.

• Use of predefined VLANs and datastores by the workload virtual machines include the creation of

new VMs, subscription to datastores, and VLANs permitting workload administration to self-serve.

• HyTrust Cloud and Data Control "lock down" all workloads, provide for RBAC granularity, asset

segmentation and separation, encryption (with per-VM encryption granularity), and key

management to be used as an integral part of the HCI deployment

MULTITENANT MODEL WITH MANAGEMENT CLUSTER One or more workloads will be deployed (see above) on dedicated clusters to create tenant abstraction and separation. Following the precepts of VVD, a series of external network switches (typically VLAN integrated, and operating with a Cisco Nexus or Nexus-like feature sets) and boundary firewalls are traditionally used to isolate the HCI workload and management plane from other systems, with a design similar to what is depicted in the following section. When more than one tenant is deployed on HCI, it is recommended that either unique ESXi hypervisors are used (per tenant) or VMware NSX-V is employed to position dedicated logical routers per cluster with per-VM and/or boundary firewall protections to separate the workloads. This approach can be used to create edge-cluster and workload-cluster separation, when the design calls for rich and diverse edge services (suggested when using mobile device managers, virtual desktop instances, exotic web-delivery farms, and so on).


Tenant administration may be apportioned using HyTrust CloudControl functions, and unique RBAC roles and participants per workload. HCI Infrastructure managers might be assigned roles for the management plane, and then allocated rights to the workload, or unique rights might be reserved for the workload cluster operations team, following the design patterns desired by the agency.

NETWORK AND BOUNDARY DESIGN An example VVD-inspired network topology is seen here:

Figure 1 - HCI architecture

External switches (see above) and security devices serve HCI systems by extending the intrinsic 10/40Gb network switching outside of the HCI and into the corporate switching fabric. Dedicated VLANS, purpose-built for management, storage, and workload(s) serve to extend network connectivity to the agency LANs as desired. Firewall devices positioned outside of HCI might be used to create an outer perimeter for a completely contained HCI infrastructure and might also be brought into the internal NSX/virtual switch on ESXi via common VLAN integration or by NSX service insertion. This approach affords virtually any workload-protecting network design with perimeter, bastion, or micro-segmentation network vigilance and enforcement.


NSX is a recommended element of the reference architecture with capacity to support L2 and L3 network functionality (see above) running on top of the external network switches and powerful n-tuple stateful firewall network protections on a per VM basis. Using NSX also brings additional software defined networking (SDN) functionality with intrinsic layer-3 router, VPN termination, port-based IP abstraction and load-balancer objects. NSX satisfies all five requirements of NIST 800-125 properties for complete micro-segmentation operating within the ESXi hypervisors. Should it be desired or required, VPN tunnel transit might be constructed to supply FIPS 140 level data in-motion encryption.

Figure 3 – L3 Routing within NSX

Figure 2 - Layer 3 transport sample


In this reference architecture, NSX provides the routing functionality to the virtual workloads hosted in

vSphere. The east-west traffic is handled by the distributed logical router (DLR) and the north-south traffic

is handled by the NSX Edge. The NSX Edge acts as a gateway to the external world and also as a transit

point for the virtual network to the physical network and vice-versa. DLR and NSX Edge also provide the

necessary firewall capabilities to isolate the workloads and help establish secure tenancy.

COMPUTE NODE CLUSTERING Using NetApp Deployment Engine (NDE) automation creates a basic network design similar to this set of build worksheets:

Figure 4 - HCI Network Layout

In the reference architecture, six ESXi 6.7 hypervisors are deployed using "extreme" best practices for proper allocation of VLANs and networks for all VMware key roles including vMotion, logging, kernel management, and iSCSI storage networking. NDE deploys an "idealized extreme" version ready for manual VMware hardening following the 6.7 VMware Hardening Best Practices .XLSX guidance spreadsheet. NDE builds an ESXi cluster with complete deployment of VMware vCenter and the SolidFire management node (mNode). Additional integration of NSX-V Version 6.4 is added to the design to leverage desired SDN functions (see above). Manual deployment of HyTrust CloudControl and DataControl follows basic deployment guidelines and resides entirely on four (4) VMs exclusively in the management cluster. HyTrust is deployed in such a fashion to create security, policy control, and vigilance for the vSphere infrastructure elements, delivering a comprehensive HCI package, ready for Agency workload deployment and FISMA security control customization. Multiple risk acceptance models may be enabled by HyTrust with capacity to satisfy FISMA low, moderate and high control objectives including single tenant, with and without edge clusters. Geolocated VMs might be tied to specific hypervisor CPU serialization, with data at rest encryption and policy support for "zero exit boundary" of cryptography keys and the images they control. With this method, policy-based location enforcement might easily benefit the Federal agency. HyTrust provides an intuitive user interface as shown below:


Figure 5 - HyTrust User Interface

HyTrust hosts at deployment are shown below:

Figure 6 - HyTrust Hosts


HyTrust roles are shown below:

Figure 3 - HyTrust Roles

STORAGE A key feature of HCI is the intrinsic HCI storage layer with support for scale-out and scale-up flash SSD. Storage on multiples of 6 and 12 drives, with a future upgrade path (in the H610S-2F model) to FIPS-140 Level 2 encryption on-drive. As reviewed in the H410S model used for this evaluation, storage is delivered via iSCSI using an internal 25G (maximum) backplane, unique architecture (based on NetApp SolidFire), and dedicated iSCSI network fabric enables SLA-style contracts for IOPS guarantees for the workloads. The FISMA recommended provisioning model restricts block volume creation to management cluster administrators, by convention. Although workload administrators are not allowed to self-provision the block storage, they are able to allocate VHDFS for VMs, once a VMware datastore is created for that purpose. HyTrust DataControl services can also provide key-managed PKI support for per-VM encryption of data at rest. The HCI storage backed by NetApp SolidFire can encrypt all the data stored on the cluster using AES-256 bit encryption at the drive level. It also supports full-featured, zero-footprint volume snapshots and clones plus the full suite of VMware Site Recovery Manager (SRM) replication and data management. In addition to the VMware Storage vMotion, VM clones and template operations are natively supported by vCenter and ESXi.

EXTERNAL TECHNOLOGY REQUIREMENTS HCI with HyTrust has high functionality, but the requirements for an Agency trying to adhere to FISMA security controls require the following outside (from corporate LAN) or HCI-hosted (typically in the management workload) toolsets for the following defense-in-depth (DiD) management elements: • Centralized Logging via Security Incident and Event Management (SIEM), integrated to HCI with

the syslog provisioning of all elements • Anti-malware packages to detect, manage, and control image pollution by viruses and spyware • File integrity management • Additional key management system should a pre-existing KMS system be required by the Agency • Automated software testing suites to locate and patch vulnerabilities


• Systems patch management systems • Multi-factor authentication (MFA) systems with the HyTrust implementation of MFA features • Additional DevSecOps technologies • Backup and disaster recovery systems

COALFIRE OPINION The NetApp reference architecture for FISMA is a specific use case recommended as a starting point for

securing federal agency workloads that are being specifically constructed for FISMA NIST SP800-53r4

compliance. All these workloads require keen attention to the customer responsibilities for both technical

and organization controls under FISMA, and the use of NetApp HCI reference architectures only serve as

a starting point for the completed system.

It is Coalfire’s opinion that the use of the NetApp HCI might be successfully used in a program of compliance

for FISMA when the essential design patterns of this reference architecture are followed.

A COMMENT REGARDING REGULATORY COMPLIANCE

Coalfire disclaims generic suitability of any product to cause a customer using that product to achieve

regulatory compliance. Customers attain compliance through a Governance, Risk Management, and

Compliance (GRC) program, not via the use of a specific product. This is true for FISMA compliance

in federal agencies, as well as for customers targeting compliance with other regulations.


ABOUT THE AUTHORS AND CONTRIBUTORS

Chris Krueger | Author | Principal II, Solutions Engineering, Coalfire Systems

As Principal, Mr. Krueger contributes as an author and thought leader on information security and

regulatory compliance topics for Coalfire’s clientele in the “new and emerging” technical areas.

Mitch Ross | Contributor | Senior Consultant, Solutions Engineering, Coalfire Systems

Mr. Ross consults on information security and regulatory compliance topics as they relate to

advanced infrastructure, emerging technology, and cloud architectures.

James DeCaires | NetApp Project Sponsor | Sr. Product Manager, NetApp

Mr. DeCaires is an HCI Product Manager with responsibility for the HCI product suite.

Arvind Ramakrishnan | Technical Lead | Solutions Architect, NetApp

Mr. Ramakrishnan is an Architect focused on developing and validating converged and

hyperconverged infrastructure solutions.

Published January 2020.

ABOUT COALFIRE As a trusted advisor and leader in cybersecurity, Coalfire has more than 15 years in IT security services. We empower organizations to reduce risk and simplify compliance, while minimizing business disruptions. Our professionals are renowned for their technical expertise and unbiased assessments and advice. We recommend solutions to meet each client’s specific challenges and build long-term strategies that can help them identify, prevent, respond, and recover from security breaches and data theft. Coalfire has offices throughout the United States and Europe. www.coalfire.com

Copyright © 2014-2020 Coalfire Systems, Inc. All Rights Reserved. Coalfire is solely responsible for the contents of this document

as of the date of publication. The contents of this document are subject to change at any time based on revisions to the applicable

regulations and standards (HIPAA, PCI-DSS et.al). Consequently, any forward-looking statements are not predictions and are

subject to change without notice. While Coalfire has endeavored to ensure that the information contained in this document has

been obtained from reliable sources, there may be regulatory, compliance, or other reasons that prevent us from doing so.

Consequently, Coalfire is not responsible for any errors or omissions, or for the results obtained from the use of this information.

Coalfire reserves the right to revise any or all of this document to reflect an accurate representation of the content relative to the

current technology landscape. In order to maintain contextual accuracy of this document, all references to this document must

explicitly reference the entirety of the document inclusive of the title and publication date; neither party will publish a press release

referring to the other party or excerpting highlights from the document without prior written approval of the other party. If you have

questions with regard to any legal or compliance matters referenced herein you should consult legal counsel, your security advisor

and/or your relevant standard authority.

http://www.coalfire.com/

Documents

NetApp HCI FISMA Reference Architecture · NetApp HCI Reference Architecture for FISMA v1.1| White Paper 6 NSX is a recommended element of the reference architecture with capacity