VMWARE VALIDATED DESIGN FOR SDDC & … · Implementing CJIS: Use Case Examples ... Per the Criminal Justice Information Services (CJIS) ... “the essential premise of

VMWARE VALIDATED DESIGN FOR SDDC & WORKSPACE ONE COMPLIANCE CAPABLE SOLUTION FOR CRIMINAL JUSTICE INFORMATION SERVICES (CJIS) VERSION 5.5 Technical White Paper

MARCH 2017

This is the final document in the compliance reference

architecture for CJIS. You can find more information on

the framework and download the additional documents

from the CJIS compliance resources tab on VMware

Solutions Exchange here.

https://solutionexchange.vmware.com/store/products/vmware-cjis-compliance-and-cyber-risk-solutions#.VRLHNJPF9Fg

VMWARE VVD FOR SDDC &AND EUCWORKSPACE ONE COMPLIANCE CAPABLE SOLUTION FOR CJIS 5.5

VMWARE VVD FOR SDDC & WORKSPACE ONE COMPLIANCE CAPABLE SOLUTION FOR CJIS 5.5

Technical White Paper | 2 Technical White Paper | 2

Table of Contents

Executive Summary ................................................................................................................... 5

For Additional Consideration .............................................................................................. 5

Implementing CJIS: Use Case Examples .................................................................................. 6

VMware Compliance Capable Solution for CJIS 5.5 ................................................................. 6

VMware Validated Design for Software-Defined Data Center ........................................... 7

Physical Infrastructure Design .......................................................................................................... 8

Virtual Infrastructure Design .......................................................................................................... 13

Organization Workload Architecture ................................................................................ 27

VMware Workspace One ................................................................................................. 30

VVD VMware Software Components in the Validated Design for SDDC 3.0 .................. 35

Validation Scope and Approach ............................................................................................... 36

Findings and Observations ...................................................................................................... 37

Policy Area 10: System and Communications Protection and Information Integrity ........ 37

Information Flow Enforcement ...................................................................................................... 37

Boundary Protection........................................................................................................................... 40

Partitioning ............................................................................................................................................. 48

Virtualization ......................................................................................................................................... 49

Policy Area 13: Mobile Devices ........................................................................................ 51

Bluetooth ................................................................................................................................................. 52

Mobile Hot Spot .................................................................................................................................... 53

Mobile Device Management (MDM) ............................................................................................. 53

Wireless Device Risk Mitigation .................................................................................................... 63

Patching/Updates ................................................................................................................................ 69

Malicious Code Protection ................................................................................................................ 69

Personal Firewall ................................................................................................................................. 69

Local Device Authentication ............................................................................................................ 69

Summary .................................................................................................................................. 69

Resources ................................................................................................................................ 70

Acknowledgements .................................................................................................................. 71

About Coalfire .......................................................................................................................... 71




Revision History

Date Rev Author Comments Reviewers

March 2017 1.0 Jason Macallister Final Release Coalfire and VMware SME

and legal teams

Design Subject Matter Experts

The following people provided key input into this whitepaper.

Name Email Address Role/Comments

Jason Macallister [email protected] Senior Consultant/Principle Author

Chris Krueger [email protected] Principle/QA to Customer Draft Release

Anthony Dukes [email protected] Technology SME, VMware

Joshua Lory [email protected] Director of SDDC Architecture, VMware

Carlos Pelaez [email protected] Compliance and Cybersecurity SME, VMware

mailto:[email protected]








Trademarks and Other Intellectual Property Notices

The VMware products and solutions discussed in this document are protected by U.S. and international

copyright and intellectual property laws. VMware products are covered by one or more patents listed at

http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the

United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks

of their companies.

Solution Area Key Products

Software-Defined Compute

VMware ESXi™, VMware vCenter™, VMware vCenter Server®, VMware vCenter Server®

Standard™, VMware vCenter™ Single Sign-On, VMware vCenter Server® Appliance™,

VMware vCloud Suite®, VMware vSphere® Data Protection™, VMware Tools™, VMware

vSphere® Distributed Resource Scheduler™, VMware vSphere® Distributed Power

Management™, VMware vSphere® Enterprise Plus Edition™, VMware vSphere® Fault

Tolerance, VMware vSphere® Flash Read Cache™, VMware vSphere® High Availability,

VMware vSphere® Storage DRS™, VMware vSphere® Storage vMotion®, VMware vSphere®

vMotion®, VMware vSphere® Web Client, Platform Services Controller™

Software-Defined Networking

VMware NSX®, VMware NSX® Manager™, VMware NSX® Edge™, VMware NSX® Controller™,

VMware NSX® Services™, VMware NSX® Virtual Switch™, VMware NSX® API™, VMware

NSX® for vSphere®

Management and Automation

VMware vRealize® Suite Enterprise, VMware vRealize® Operations™, VMware vRealize®

Operations Manager™, VMware vRealize® Hyperic®, VMware vRealize® Configuration

Manager™, VMware vRealize® Infrastructure Navigator™, VMware vRealize® Log Insight™,

VMware vRealize® Log Insight™ Content Pack for xxx, VMware vRealize® Operations Insight™,

VMware vRealize® Orchestrator™, VMware vRealize® Orchestrator Appliance™, VMware

vRealize® Operations for Horizon®, VMware vRealize® Operations for Published Applications™,

VMware vRealize® Operations Manager™ for Horizon®, VMware vRealize® Automation™,

VMware vRealize® Business™ Enterprise, VMware vRealize® Operations Management Pack™

for xxx, VMware vSphere® Service Manager™, VMware vSphere® Syslog Collector, VMware

vSphere® Update Manager™, VMware vSphere® Update Manager Client™, VMware vSphere®

with Operations Management™, VMware Power CLI

Disaster Recovery

Automation VMware vCenter™ Site Recovery Manager™, VMware vSphere® Replication™

End User Computing

VMware Workspace™ ONE™, VMware Horizon® Enterprise Edition, VMware Horizon® FLEX™,

VMware Horizon®, VMware View®, VMware View® Composer™, VMware View® Manager™,

VMware Horizon® Client, VMware Horizon Agent™, VMware Identity Manager™, VMware User

Environment Manager™, VMware Workspace Environment Manager™, VMware App

Volumes™, VMware App Volumes™ for Endpoints™, One Cloud, Any App, Any Device™, One

Cloud, Any Application, Any Device™

Enterprise Mobility

Management

VMware AirWatch®, VMware AirWatch® Yellow Management Suite™, VMware AirWatch®

Agent™, VMware AirWatch® Appliance™, VMware AirWatch® App Catalog™, VMware

AirWatch® App Wrapping™, VMware AirWatch® Cloud Connector™, VMware AirWatch®

Connect™, VMware AirWatch® Enterprise Mobility Management™, VMware AirWatch®

Container™, VMware AirWatch® Mobile Device Management™, VMware AirWatch® Mobile

Application Management™, VMware AirWatch® Inbox, VMware AirWatch® Kiosk Mode™,

VMware AirWatch® Laptop Management™, VMware AirWatch® Launcher™, VMware AirWatch®

Mobile Access Gateway™, VMware AirWatch® Content Locker™, VMware AirWatch® Content

Manager™, VMware AirWatch® Mobile Browsing Management™, VMware AirWatch® Mobile

Email Management™ VMware AirWatch® Browser™, VMware AirWatch® Secure Email

Gateway™

http://www.vmware.com/go/patents




Executive Summary Per the Criminal Justice Information Services (CJIS) Security Policy version 5.5, “the essential premise of

the CJIS Security Policy is to provide appropriate controls to protect the full lifecycle of [Criminal Justice

Information (CJI)], whether at rest or in transit. The CJIS Security Policy provides guidance for the creation,

viewing, modification, transmission, dissemination, storage, and destruction of CJI. This policy applies to

every individual – contractor, private entity, noncriminal justice agency representative, or member of the

criminal justice entity – with access to, or who operate in support of, criminal justice services and

information.” (CJIS Information Security Officer, 2016) The common framework for security of CJI as

shared by participants with criminal justice services and information is useful for supporting the

confidentiality, integrity, and availability of the information it serves. It provides a foundation of trust for

access to CJI among various federal, state, and local agencies as well as outside supporting organizations.

The readiness of this information is useful for the efficient enforcement of the law.

VMware recognizes the importance of the CJIS Security Policy and the role it plays for the protection of

CJI. VMware also understands the relevance that information technology infrastructure, management, and

end-user compute solutions play regarding the security of critical digital assets. By standardizing an

approach to compliance and expanding that approach to include technology partners, VMware provides its

customers with a solution that may more fully address their compliance needs. This standardized approach

provides management, IT architects, administrators, and security and compliance auditors more

transparency into risks, solutions, and mitigation strategies for moving critical assets and data to the cloud

in a secure and compliant manner in alignment with the recommendations and requirements of the CJIS

Security Policy for the protection of CJI.

VMware enlisted its audit partner, Coalfire Systems, Inc. (Coalfire), to engage in a programmatic approach

to assess VMware products and solutions for their capabilities to address CJIS Security Policy

requirements and recommendations and to report these capabilities into a set of reference architecture

documents. This is the second in a series of two documents representing Coalfire’s assessment of VMware

technologies that are available to organizations that use (or are considering using) VMware Software-

Defined Data Center (SDDC), Software-Defined Networking (SDN), and End-User Computing (EUC)

platforms to host CJIS regulated applications and services. For this assessment, the SDDC, SDN, and

EUC platforms have been designed and implemented in one of the Centers of Excellence to support testing

of capabilities to address CJIS Security Policy requirements.

Coalfire has found that the assessed VMware Compliance Capable Solution, as described in this paper,

provided sufficient control capabilities in support of the selected CJIS Security Policy requirements.

For Additional Consideration

Both VMware and Coalfire understand that no one technical solution or product can fully enable security

and compliance. A strong security posture is best instituted through application of sound security design

principles. Organizations are best able to attain compliance through comprehensive governance, risk

management, and compliance (GRC) programs and not by a specific product or solution.

For more information on the VMware Reference Architecture Framework documents and VMware’s

general approach to compliance issues, please review VMware Compliance Cyber Risk Solutions.

The recommendations and requirements selected for this paper are from the CJIS Security Policy

document version 5.5, dated June 1st, 2016. This paper has been authored and reviewed by Coalfire and

VMware’s combined staff of virtualization and cloud experts and CJIS Security Policy auditors.

If you have any comments regarding this white paper, we welcome any feedback at [email protected].

https://solutionexchange.vmware.com/store/products/vmware-compliance-cyber-risk-solutions#.VXXPhXlFCHs




Implementing CJIS: Use Case Examples For organizations engaged with CJI and requiring compliance with the CJIS Security Policy, VMware chose

to demonstrate the capability of VMware solutions to facilitate control capabilities specific to use cases

related to CJIS Security Policy compliance. The coverage of VMware solutions to address CJIS Security

Policy compliance capability was more broadly discussed in the VMware Validated Design for SDDC and

Workspace One CJIS 5.5 Product Applicability Guide. From the broader discussion of solution to

compliance framework alignment found in the Product Applicability Guide, VMware selected a couple of

use cases to showcase for validation of compliance capability.

The two use cases selected by VMware include data center network protection of CJI and mobility of

the criminal justice workforce. These use cases are supported by the frequency with which inquiries are

made to VMware with respect to these topics relative to VMware capabilities. Additionally, these use cases

align with technology capabilities that VMware has chosen to highlight for this validation exercise.

Coalfire selected the CJIS Security Policy requirements aligned to these use cases. This alignment

included a selection of requirements from CJIS Security Policy Area 10, System and Communications

Protection and Information Integrity, and Policy Area 13, Mobile Devices. While VMware capabilities likely

exist to address additional technical requirements and recommendations in other policy areas, they are not

addressed specifically in this document and validation exercise. Later amendments to this document may

include additional use cases as well as policy requirements and best practice recommendations.

This document conveys VMware’s commitment to their client’s compliance and security requirements as

well as their understanding of applicability of security and compliance to the technology solutions they

provide. Because every organization is different regarding their approach to compliance, this document is

intended to be an example for organizations wanting to achieve compliance.

VMware Compliance Capable Solution for CJIS 5.5 The Center of Excellence used for this compliance capable validation exercise was a joint initiative by

VMware and Intel. The hardware platform for the test lab was inclusive of Intel equipped SSDs, Network

Controllers, and Intel Xeon based CPUs. The Center of Excellence follows the VMware Validated Design

for Software Defined Data Center. Figure 1 graphically illustrates, at a high level, the conceptual design of

the VMware Validated Design for SDDC.

Figure 1: Conceptual Rendering of the VMware Validated Design for SDDC




Layered on top of the VMware Validated Design for SDDC is VMware’s End-User Compute and Mobility

Solutions, which form a comprehensive platform for end-user access to systems and data called VMware

Workspace ONE. Workspace ONE includes virtual desktop infrastructure, secure data access options,

identity management, and mobility management. VMware Workspace ONE provides several options for

secure control enablement supporting end-user access and interaction with CJI. The Workspace ONE

implementation follows VMware’s validated architecture and design criteria and best practices for practical,

efficient deployment and delivery of end-user solutions.

To demonstrate functional control capability for operational workloads, VMware layered on workloads

representative of multiple distinct security domains as may exist in a typical organization. In alignment with

the topic of CJIS, the security domains were labeled as CJI and non-CJI. Each server workload further

represented a multi-tier server architecture representing web, application, and database. Additional user

access functionality was granted and made available through VMware Workspace ONE.

This section will provide a high-level summary of the architecture and design elements for the test lab made

up of the VMware Validated Design for SDDC and VMware Workspace ONE. The focus in this section will

be on the components that specifically relate to the aforementioned use cases. For more complete and

detailed information about the VMware Validated Design for SDDC, please refer to the VMware Validated

Design for SDDC documentation. For more complete and detailed information about a validated integration

design for VMware Workspace ONE, please refer to the VMware Workspace ONE Reference Architecture:

Validated Integration Design document.

VMware Validated Design for Software-Defined Data Center

The VMware Validated Design (VVD) provides a comprehensive and extensively-tested design to build and

operate the SDDC stack. VMware Validated Designs are based on VMware’s expertise in data center

design and further de-risk deployments through extensive product testing to ensure interoperability,

availability, scalability, and security. The designs are holistic and span across compute, storage,

networking, and management, defining a gold standard for how to deploy and configure the complete

VMware SDDC stack with support for a broad set of use cases. Additionally, these designs include detailed

guidance that synthesizes best practices for optimally operating the deployed SDDC.

Documents included in each design:

Validated SW Software Bill of Materials (BOM) – Inter-operable versions of software that work together for a given VVD version

Release Notes - Any known issues with the design

Design Details – Design objectives, Design decisions, and the deep technical aspects of the designs

Architecture Diagrams – Visualization of the architecture and the design

Pre-Deployment Checklists – List of needed items for deployment

Deployment Guides – Detailed instruction on how to deploy the data center

Configuration Workbooks – How to configure the system and components

Validation Workbooks – How to test and validate prior to go-live

Operational Guides – Detailed guidance on Monitoring and Alerting, Backup and Restore, Upgrade, Security and Compliance, Startup and Shutdown, and more operation modules

Use Case Guides – Modular guides that cover use cases like Micro Segmentation, IT Automating IT and more

http://www.vmware.com/solutions/software-defined-datacenter/validated-designs.html

http://www.vmware.com/solutions/software-defined-datacenter/validated-designs.html




Physical Infrastructure Design

As with any technical solution, whether on premise or in the cloud, the solution starts with physical compute,

storage, and network hardware. The physical layer is a foundation for any data center deployment whether

on premise, public cloud or hybrid cloud. This lab environment made use of the software-defined

infrastructure deployed on Dell PowerEdge R630 servers. This hardware was chosen for its modular

design, which simplifies deployment and reduces time to operation.

Figure 2: SDDC Architecture Physical Layer

The VMware Validated Design for SDDC uses common building blocks called pods. Pods represent the

physical grouping of hardware (network, storage, and compute) that support a certain function. The

functions represented by the pods in the test lab for this validation exercise included compute,

management, and edge pods. Figure 3 conceptually illustrates the pod architecture for the CJIS lab

environment.

Physical Design Fundamentals

Figure 3: Pods in the SDDC

The compute pod hosts the tenant or organization workload virtual machines (VMs). In a single subscriber

model or private cloud, tenants may represent different departments of the organization. Also included on

the workload cluster are Guest Introspection ESX Agents to support antivirus/anti-malware for the virtual

machines on the cluster. In the case of the CJIS validation assessment, the compute pod hosted both the

CJI and non-CJI workloads. For this lab environment, desktop and application pools were hosted on the

workload cluster as well.




Table 1 is a listing of physical ESXi hosts that make up the compute pod in the CJIS test lab.

Host Name VMkernel Management IP Address VLAN ID Cluster

comp01esx01.ccrscoe01.local 172.19.8.21 2008 Compute01






Table 1: Compute Cluster Physical Compute

The management pod runs the virtual machines that manage the SDDC. In the case of the CJIS validation

assessment, the management pod contained virtual management layer components, cloud management

layer components, and service management layer components. These components included vCenter

Server and the Platform Services Controller, NSX Manager, NSX Controller, vRealize Operations

Management, vRealize Log Insight, vRealize Automation, vRealize Orchestrator, and other shared

management components as may be needed for the operation. Other shared management components

may include Microsoft Active Directory Domain Controllers. Table 2 is a listing of physical ESXi hosts that

make up the management pod in the CJIS test lab.


mgmt01esx01.ccrscoe01.local 172.19.1.21 2001 Mgmt01





Table 2: Management Cluster Physical Compute

The edge pod supports on-ramp and off-ramp connectivity to physical networks, connects VLANs in the

physical world, and optionally hosts centralized physical services. Edge pods also connect virtual networks

(overlay networks) provided by NSX for vSphere and the external networks. The edge pod for the CJIS lab

hosts Edge Services Gateway appliances, distributed logical routers, and universal distributed logical

routers in support of overlay networks. NSX controller appliances are also hosted on the edge pod. Table

3 lists the physical ESXi hosts that make up the edge cluster in the CJIS lab.


edge01esx01.ccrscoe01.local 172.19.13.21 2013 Edge01




Table 3: Edge Cluster Physical Compute

Physical Network Design

The physical network is designed using a leaf and spine design for simplicity and scalability to best support

the network virtualization architecture. Leaf switches represent top of rack switches and provide network

connection points for servers and uplink to spine switches. Leaf switches primarily handle east-west traffic

within the environment and are made up of Cisco Nexus 5612P switches. These are wire-rate Layer 2 and

Layer 3 10 GBE switches. Spine switches primarily support north-south and cross physical VLAN traffic.

Spine switches in this lab environment are provided by Cisco Nexus 9000 series switches. In this design,

the spine represents multiple high-throughput Layer 3 switches with high port density. Figure 4 illustrates

the physical network architecture to support the network virtualization architecture.




Figure 4: Leaf and Spine Physical Networking

The architecture supports expansion through the inclusion of additional racks, each with a top of rack pair

of Nexus 5612P switches and additional data center core spine switches as needed to support performance

requirements. These physical switches provide physical transport support for the organization’s data

center. Not included in the evaluation for this validation exercise are physical firewall appliances that may

sit at the physical boundary of the organization’s network and connecting to the organization’s Internet

service provider(s) (ISP).

Top of rack physical switches are configured with trunk ports that connect with the ESXi hosts. Top of rack

switches are configured to provide all the necessary physical VLANs via an 802.1Q trunk. These connect

to virtual distributed switches (vDS) and form the basis for port groups on the vDS. Each ESXi host in the

compute rack is connected redundantly to physical switches to support the SDDC fabric.

Each ESXi host in the compute rack and the management/edge rack uses VLANs and corresponding

subnets for internal-only traffic. Leaf switches in each rack act as Layer 3 interface for the corresponding

subnet. The following figures and corresponding tables represent the connectivity of ESXi hosts to physical

switch infrastructure in each of the pods respectively for compute, management, and edge.

Figure 5: VLANs and Subnets within the Compute Pod




VLAN ID Subnet Purpose

2008 172.19.8.0/24 VMkernel ESXi Host Management

2009 172.19.9.0/24 VMkernel vMotion Network – Layer 2, non-routable network supports migration of

virtual machines including distributed resource scheduling (DRS)

2010 172.19.10.0/24 VMkernel Storage Network – VSAN storage network

2016 172.19.16.0/24 VTEP (VXLAN) supports VXLAN overlay networks

2012 172.19.12.0/24 VMkernel NFS Storage Network – NFS storage

Table 4: Physical to Virtual Networking – Compute Pod

Figure 6: VLANs and Subnets within the Management Pod



2002 172.19.2.0/24 VMkernel vMotion Network – Layer 2, non-routable network supports migration of virtual

machines for HA and DRS

2003 172.19.3.0/24 VMkernel Storage Network – vSAN Network


2012 172.19.12.0/24 VMkernel NFS Network – Supports NFS Storage

Table 5: Physical to Virtual Networking – Management Pod




Figure 7: VLANs and Subnets within the Management Pod



2014 172.19.14.0/24 VMkernel vMotion Network – Layer 2, non-routable network supports migration of virtual

machines for HA and DRS

2015 172.19.15.0/24 VMkernel Storage Network – VSAN Network


2012 172.19.12.0/24 VMkernel NFS Network – Supports NFS Storage

Table 6: Physical to Virtual Networking – Edge Pod

Please note that the Network File System (NFS) network VLAN is common for each cluster and host. For

this CJIS test lab, the NFS storage supported management with ISOs, virtual machine images, and so

forth. It was also purposed as a vSphere Data Protection (VDP) backup target and as a target for vRealize

Log Insight logs.

In addition to these VLANs represented in the diagrams above, two additional VLANs existed on the Edge

vDS and on the Management vDS. These VLANs supported uplink connectivity to the organizations

outbound network for the Edge Services Gateways. Table 7 lists these uplink VLANs for the Edge Services

Gateway appliances.

VLAN ID Subnet Purpose ESG Support

2005 172.19.5.0/24 vDS-Mgmt01-Uplink01 ccrscoe01-MGMT-ESG01-0

ccrscoe01-MGMT-ESG02-0 2006 172.19.6.0/24 vDS-Mgmt01-Uplink02

2017 172.19.17.0/24 vDS-Edge01-Uplink01 ccrscoe01-EDGE-ESG01-0

ccrscoe01-EDGE-ESG02-0 2018 172.19.18.0/24 vDS-Edge01-Uplink02

Table 7: Edge Services Gateway Uplink Connections

Communication between VLANs is controlled by Layer-3 physical switching infrastructure and primarily

handled by access control lists on the physical switch.




Physical Storage Design

Physical storage for this lab environment was primarily served by Virtual SAN (VSAN). Each cluster in the

environment contained its own VSAN. The VSAN was made up of a mix of high performance Intel SSD

drives and high capacity Seagate SAS drives, with local disk groups being served from each host in the

cluster.

Additional physical storage was made available to prevent NFS volumes as a target for virtual machine

templates and ISOs for the setup of the virtual infrastructure. Additional NFS volumes served to provide a

storage target for vSphere Data Protection as well as aggregated log storage for vRealize Log Insight.

Virtual Infrastructure Design

The SDDC components are conceptually made up of a virtual infrastructure layer, cloud management layer,

service management layer, business continuity layer, and security layer. Each layer works together to

provide resources, management, provisioning, availability, security, and compliance for both the virtual

infrastructure and the contained workloads that service the greater organization purpose. These

components are networked together and secured with software-defined networking provided by VMware

NSX for vSphere. The following is an overview of the infrastructure management, service management,

and cloud management components with software-defined networking that make up the CJIS SDDC. The

narrative and illustrations to describe the CJIS test lab infrastructure are purposely focused on the benefits

that these components bring to the use cases described in a previous section, primarily that of network

security. The architecture, design, and logical network elements show the intentional boundaries of

functional components to support separation of purpose and the implementation of least privilege or least

function.




Figure 8: SDDC Management and Operations Networked Together

The design of the virtual infrastructure includes the software components that make up the virtual

infrastructure layer of the SDDC. The components include the hypervisors, virtualization management or

control, and pools of resources to be provided to workloads in the environment. As previously discussed,

the hypervisors are made of ESXi hosts that are separated into three distinct pods to service management,

edge services, and compute. Where the compute cluster hosts the organization’s workloads. The

virtualization management is anchored by vCenter. To support improved separation between management

and organization workloads, two separate vCenter clusters were used to each service the management

cluster and the organization’s compute and edge cluster. Storage resource pools are delivered for use by




virtual machine with the VSAN and NFS. Network resources are provided to the virtual machine’s virtual

distributed switches. vDS ports and virtual machine vNICs are managed by vCenter, while virtual wires are

managed by VMware NSX for vSphere. Finally, pools of compute resources are provided by ESXi.

vCenter Server Design

Two vCenter Servers provide infrastructure support for the CJIS test lab. As part of the VVD design, one

vCenter Server has primary responsibility for the management cluster. The other vCenter Server services

the edge and compute or organization workload cluster. The separation of compute and management and

edge clusters onto their own vCenter helps to provide better functional separation for these distinct

purposes. Both vCenter Servers are also served by a pair of Platform Services Controller. A single vCenter

Single Sign-On Domain provides single sign-on services for authentication to vCenter. The vCenter Single

Sign-On Domain is connected to a single Microsoft Active Directory Domain to provide user and

administrator accounts for access to vCenter. The following diagrams and corresponding table depict the

relationship of the components that make up vCenter.

Figure 9: vCenter for the CJIS Lab




Figure 10 illustrates the relationship of vCenter with the ESXi hosts and the clusters they manage.

Figure 10: vCenter with Respect to ESXi and Clusters

Table 8 shows the virtual machines that make up the core management components of the software-

defined data center including vCenter servers, platform services controllers, and NSX managers.

VM Name Application Cluster IP Address vDS Port Group

mgmt01vc01 vCenter Server

(Management)

Mgmt01 172.19.1.101 vDS-Mgmt01 vDS-Mgmt01-Management

mgmt01psc01 Platform Services

Controller

(Management)


mgmt01nsx01 NSX Manager

(Management)


comp01vc01 vCenter Server

(Compute)


comp01psc01 Platform Services

Controller

(Compute)


comp01nsx01 NSX Manager

(Compute)

Mgmt01 172.19.1.106 vDS-Mgmt01 vDS-Mgm01-Management

Table 8: Virtualization Infrastructure Management




Virtualized Network Design

Figure 11 conceptually represents the architecture of VMware NSX for vSphere. This figure shows the

functional separation of components representing the three clusters of management, edge, and compute.

Moreover, it illustrates the placement of NSX components regarding their integration with the separate

vCenter instances. While this illustration shows the architecture of a multi-region deployment, the CJIS lab

infrastructure was inclusive of a single region.

Figure 11: Network Virtualization Conceptual Design

NSX for vSphere created a network virtualization layer. The virtual networks that are created on top of this

layer are an abstraction between the physical and virtual networks. The network virtualization layer was

made up of components of vSphere and NSX including vCenter Server, NSX Manager, NSX Controller,

NSX Virtual Switch, and NSX for vSphere API. These components were separated into different planes to

create communications boundaries and provide isolation of workload data from system control messages.




The applicable design goals for virtual networking in the VMware Validated Design for SDDC included

meeting diverse needs, reducing costs, boosting performance, improving availability, supporting security,

and enhancing infrastructure functionality. Some of the networking best practices applied to the design

included the separation of networking services from one another, the use of network I/O control and traffic

shaping, separating network services on a single vDS, separating vMotion traffic to a separate network,

and separating storage traffic to a separate network.

Separation of different types of traffic onto different VLANs was required to reduce contention and latency

and for access security. This helped achieve the functional goal of meeting security and compliance

requirements for CJIS 5.5 Security Policy. Virtual networks supported multiple functions in the SDDC and

the separation of traffic types should be considered respectful of organizational policies, procedures, and

standards. vSphere operational traffic was segmented and defined by management, vMotion, VSAN, NFS

Storage, vSphere Replication, and VXLAN. The following diagrams illustrate the placement of port groups

on vDS’s. These port groups are an extension of the physical connections illustrated in Figure 5 through

Figure 7 above. The port groups represent the vDS interfaces for VMkernel connections, virtual machine

vNIC, and virtual appliance vNIC connections.

Figure 12: Compute vDS VLAN extension




Figure 13: Management vDS VLAN Extension

Figure 14: Edge vDS VLAN Extension




nic0 – nic3 in Figure 12 through Figure 14 represent the physical network interface cards for the ESXi

hosts. These NICs are connected to the physical switch ports that are configured as trunk ports. The NICs

are aggregated together to support throughput and availability. Each VLAN is tagged from the physical

switch and identified by the tag on the virtual distributed switch. The virtual distributed switch is distributed

through each of the hosts in the cluster. Beyond the vDS sit the logical components of VMware NSX for

vSphere to support logical routing, load balancing, logical firewall, distributed routing, distributed firewall,

and logical switches.

Figure 15 illustrates the relationship between logical components of VMware NSX for vSphere. Logical

switches create logically abstract segments to which virtual machines can connect. A single logical switch

is mapped to a unique VXLAN segment ID and is distributed across the ESXi hypervisors within a transport

zone.

The universal distributed logical router provided virtual machine to virtual machine, or east-west routing.

The NSX Edge Service Gateway provided north-south connectivity by peering with upstream top of rack

or leaf switches, which allowed virtual machines or tenants to access public networks. The logical firewall

provided dynamic security capability for the virtual data center. The Edge Firewall components helped to

meet perimeter security requirements for the CJIS lab instance, which allowed for the creation of DMZs

based on IP/VLAN constructs and workload to workload isolation such as between CJI and non-CJI zones

or in a multi-tenant environment between tenants. The tenant Edge Firewall also provided NAT, partner

(extranet) VPNs, and user-based SSL VPNs. The virtual Distributed Firewall allows for micro-segmentation

of virtual data center entities like virtual machines. Segmentation with the virtual Distributed Firewall allows

for segmentation based on virtual machine names and attributes, user identity, vCenter objects like data

centers, clusters, resource pools and hosts, and traditional 5-tuple networking attributes like source and

destination IP address, port, and protocol.

Figure 15: VMware NSX for vSphere Logical Networking

While these virtual network constructs have primary support capability for isolation and segmentation of

organization workloads, they were also useful for this test lab environment for providing segmentation and

security for some of the operational and cloud management components of the environment in support of




vSphere Operations Management, vSphere Log Insight, and cloud management and consumption

components of vRealize Automation. The following sections and corresponding diagrams represent the

architectural, logical, and network design for these important infrastructure solutions.

Operations Infrastructure Design

Operations Management is a required element of a SDDC. Monitoring Operations Support in vRealize

Operations Manager and vRealize Log Insight provides capabilities for performance and capacity

management of related infrastructure and cloud management components. The VMware Validated Design

for SDDC also includes vSphere Data Protection for the management components in the environment to

ensure continuous operation of the SDDC. To support disaster recovery (DR) in the SDDC, the VMware

Validated Design provides protection of vRealize Operations Manager and vRealize Automation by using

VMware Site Recovery Manager and VMware vSphere Replication. When failing over to a recovery region,

these management applications continue the delivery of operations management and cloud platform

management functionality.

vRealize Log Insight

vRealize Log Insight provides a log management solution for the infrastructure to allow for the ingestion

and analysis of logs from various infrastructure components. vRealize Log Insight also includes capability

to ingest and digest logs from other sources in the environment, including workloads, to provide a

comprehensive analysis capability to identify threats and issues present in the environment.

Figure 16: vRealize Log Insight Architecture




Figure 17: vRealize Log Insight Network Design

Figure 17 details the vRealize Log Insight network connectivity, which is an abstraction from Figure 8:

SDDC Management and Operations Networked Together. Logically, how vRealize Log Insight connects

to the components of the infrastructure it serves as well as the storage that supports it is represented in

Figure 18.

Figure 18: Logical Connectivity for vRealize Log Insight




vRealize Operations

vRealize Log Insight and vRealize Operations work together to provide visibility into both performance and

event-driven analytics for greater understanding of the function and security of the infrastructure. The

following diagram illustrates the logical connectivity of vRealize Operations in the environment in support

of local and remote locations that may serve the organization.

Figure 19: vRealize Operations Logical Design

Figure 20 illustrates an abstract from Figure 8: SDDC Management and Operations Networked Together

and shows the connection of these components into the Universal Distributed Logical Router, UDLR01,

and served by an Edge Service Gateway instance providing load balancing services for components of

vRealize Operations.

Figure 20: vRealize Operations Network Design




Table 9 is a listing of virtual machines that represent the operations management components of the

infrastructure.


vrops-mstrn-01 vRealize

Operations

Manager - Master

Node

Management

192.168.11.71 vDS-Mgmt01 vxw-dvs-50-universalwire-2-

sid-30001-Mgmt-xRegion01-

VXLAN

vrops-repln-02 vRealize

Operations

Manager - Replica

Node

Management



VXLAN

vrops-datan-03 vRealize

Operations

Manager - Data

Node

Management



VXLAN

vrops-datan-04 vRealize

Operations

Manager - Data

Node

Management



VXLAN

vrops-rmtcol-01 vRealize

Operations

Manager -

Remote Collector

Management


sid-30003-Mgmt-RegionA01-

VXLAN

vrops-rmtcol-02 vRealize

Operations

Manager -

Remote Collector

Management



VXLAN

vli-mstr-01 vRealize Log

Insight - Master

Node

Management



VXLAN

vli-wrkr-01 vRealize Log

Insight - Worker

Node

Management



VXLAN

vli-wrkr-02 vRealize Log

Insight - Worker

Node

Management



VXLAN

vdp-mgmt-01 vSphere Data

Protection

Management

172.19.1.107 vDS-Mgmt01 vDS-Mgmt01-Management

vcm-collector vSphere

Configuration

Manager -

Collector

Management


vcm-db vSphere

Configuration

Manager -

Database

Management


vcm-web vSphere

Configuration

Manager - Web

Interface

Management


vrni-platform vRealize Network

Insight- Platform

Management


vrni-proxy vRealize Network

Insight- Proxy

Management


Table 9: Operations Management Virtual Machines




Cloud Management Platform Design

The Cloud Management Platform (CMP) layer is the management component of the SDDC. This layer

includes the Service Catalog, which houses the facilities to be deployed; Orchestration, which provides the

workflows to get the catalog items deployed; and the Self-Service Portal, which empowers the end users

to take full advantage of the SDDC. vRealize Automation provides the Portal and the Catalog, and vRealize

Orchestrator takes care of the Orchestration.

These components establish subscriber self-service and further simplifies deployment of workloads to the

requestor, thus increasing service delivery capability for the organization. Like the other elements, the

design of these components regarding their integration with the infrastructure, segmentation and isolation,

and delivery of least functionality is consistent with that supporting security and compliancy requirements;

because, these elements are designed and orchestrated into the service catalog. Table 10 provides a

listing of virtual machines that make up the cloud management platform that support organizational tenant

self-service for the deployment and management of workloads.


vra01svr01a vRealize

Automation

Appliance #1

Management 192.168.11.12 vDS-Mgmt01 vxw-dvs-50-universalwire-2-


VXLAN

vra01svr01b vRealize

Automation

Appliance #2



VXLAN

vra01iws01a vRealize

Automation Web

Server #1



VXLAN

vra01iws01b vRealize

Automation Web

Server #2



VXLAN

vra01ims01a vRealize

Automation

Manager Server

#1



VXLAN

vra01ims01b vRealize

Automation

Manager Server

#2



VXLAN

vra01dem01 vRealize

Automation DEM

Worker / Agent

#1



VXLAN

vra01dem02 vRealize

Automation DEM

Worker / Agent

#2



VXLAN

vra01ias01 vRealize

Automation

Proxy Agent #1


sid-30003-Mgmt-

RegionA01-VXLAN

vra01ias02 vRealize

Automation

Proxy Agent #2


sid-30003-Mgmt-

RegionA01-VXLAN

vra01sql01 Microsoft SQL

Server 2012

(vRA & vRO DB)

Management 172.19.11.13 vDS-Mgmt01 - vxw-dvs-50-universalwire-

4-sid-30003-Mgmt-

RegionA01-VXLAN





vra01vro01a vRealize

Orchestrator

(Execution)



VXLAN

vra01vro01b vRealize

Orchestrator

(Execution)



VXLAN

Table 10: Cloud Management Virtual Machines

The VVD for SDDC includes implementation automation for quick deployment including built-in application

of hardening best practices to limit surface area for attack. Network ACLs, segmentation, and routing

provided by the infrastructure takes into consideration rules to limit component communication to that which

is necessary to support the specific function.

All of this is designed to support the organization or tenant workload, where a tenant is a consumer of the

cloud pool of resources presented by the previously described infrastructure. VMware NSX for vSphere

goes beyond providing networking resources regarding virtual network ports and bandwidth to the

workloads, but also includes the capability to meet security and compliance requirements for the

organization workloads it serves. A control may include the use of isolation and segmentation mechanisms

as called for to separate multi-tier application architecture elements as well as for isolating organization

defined and disparate zones of trust. These components not only enable this security and compliance

capability, but allow services to be delivered securely without sacrificing the benefits of cloud services

including operational efficiency, performance, extensibility, and agility.




Organization Workload Architecture

The organizational workload was layered onto the aforementioned infrastructure and made use of VMware

NSX for vSphere networking. This section discusses these workloads and how the security capabilities of

NSX were applied to meet security and compliance requirements of CJIS Security Policy 5.5. The workload

virtual machines were represented by three-tier system composed of web, application, and database. The

workloads were setup on the compute cluster of the SDDC. There were two workloads used for lab testing

and evaluation purposes representing both CJI and non-CJI zones.

Figure 21 shows an overview of the logical network that supports the workloads. Each trusted security

zone is segmented from the other using NSX Edge Services Gateways CCRS-Public01 and CCRS-CJIS01

to represent non-CJI and CJI zones respectively. These segments were further segmented using an NSX

distributed logical router to provide segmentation for each tier of the application. Finally, the distributed

firewall was applied through NSX Service Composer to provide micro-segmentation between VMs in each

segment (web, application, and database) with rules to prevent communication between the VMs east and

west on that segment. Load balancing for the web and application tiers were provided by the Edge Services

Gateway Load Balancing service.

Figure 21: Workload Logical Network Overview




Figure 22 details one of the security zones (CJI) with more specificity on how the segmentation was

provided and on the connectivity for outside services such Active Directory, NTP, DHCP, DNS and

certificate services. This diagram shows the relationship between the distributed logical router, the NSX

Edge Services Gateway to provide services for the CJI zone, and the connectivity from the CJI zone north

bound to the corporate network and external networks through the Edge01 and Edge02 Edge Services

Gateways.

Firewall rules from the edge firewall at Edge01 and Edge02 as well as the CJIS01-EDGE01 and EDGE02

provide security services to dictate the flow of information from outside the security zone and within the

security zone, respectively.

Figure 22: CJIS Logical Network Detail




Figure 23 illustrates the flow of a user connectivity to an application within the secure CJIS zone, where

UserA is accessing from outside of the CJIS01-3Tier-Apps-Transit. UserA connects to the web client

hosted in the web tier. Load balancing to the web client is provided by the Edge Services Gateway. UserA

never has direct access to the application or database tier. Web services on the web server are allowed to

communicate to the application tier and database tier as necessary. Communication between each tier in

the application is provided by the distributed logical router CCRS-CJIS01-DLR01, which is distributed by

CCRS-CJIS01-EDGE01. The Edge Firewall at CCRS-CJIS-EDGE01 contains the rules dictating

communication between tiers in the application.

Figure 23: Flow of User Access to CJIS Zone Assets




Figure 24 illustrates the firewall policy from NSX providing the connections between segments of the three-

tier application.

Figure 24: Firewall Policy for CJIS 3-Tier Application

Security groups for the firewall policy are defined in NSX Service Composer using variables to define

members of the security group. There are many options for defining security groups.

VMware Workspace One

VMware NSX for vSphere can provide mechanisms to control the access to apps hosted on servers in the

organization’s data center. VMware also provides solutions for end-user computing to allow end users the

freedom to securely access applications and data from any device from any location. The combined

solution of VMware Horizon, VMware AirWatch, and VMware Identity Manager into a package called

VMware Workspace ONE gives organizations greater control over the end-user experience without

sacrificing the flexibility and agility that end users come to expect in the execution of their jobs.

Workspace ONE was used in this lab environment to demonstrate secure end-user access capabilities

with respect to providing end-users, both remote and local, on end-user devices, PC, Mac and mobile

devices and tablets, access to CJI. The following is a list of servers that were included in the infrastructure

to support Workspace ONE. Table 11 lists the virtual machines that make up the management of

Workspace ONE in the infrastructure.

Server Application Cluster IP Address vDS vDS Port Group

AP-HV01 EUC - Access Point Management 172.19.7.50 vDS-Mgmt01 vDS-Mgmt01-Ext-Management

AP-VIDM01 Horizon Server -

Access Point Identity

Manager

Management 172.19.7.51 vDS-Mgmt01 vDS-Mgmt01-Ext-Management




AVMGR01 Horizon Server - AV

MGR

Management 172.19.1.56 vDS-Mgmt01 vDS-Mgmt01-Management

COMP01 Horizon Server -

Composer


CS01 Horizon Server -

Connection Server#1


CS02 Horizon Server -

Connection Server#2


FILESRV01 Horizon Server - File

Server


Horizon-DB Horizon Server -

Database Server


RDSH01 Horizon Server -

RDSH


VIDM01 Horizon Server -

Identity Manager


AW01 AirWatch Management 172.19.7.52 vDS-Mgmt01 vDS-Mgmt01-Ext-Management

AWC01 AirWatch Management 172.19.1.58 vDS-Mgmt01 vDS-Mgmt01-Management

Table 11: Workspace ONE Infrastructure Components

Figure 25 shows the core infrastructure components that make up VMware Workspace ONE. Above these

components is a listing of features available through Workspace ONE to provide secure delivery of access

to information and applications that may be provided by the agency as a privately hosted SaaS application,

cloud hosted application, or native mobile application. Delivery of applications includes client server

applications that can be delivered for the use of end users using Horizon Apps or made available on

Horizon Desktops.

Figure 25: VMware Workspace ONE Components




Figure 26 illustrates the flow of access from managed end user devices for access to Workspace ONE

delivered applications, data repositories and virtual desktops. There are many options to deliver

applications and data to end users. These options can vary by business use case or security requirement

and can be adjustable based on specific scenarios or criteria applied to managed devices and end users.

Relevant criteria can include geographic location of the accessing device, source IP address, logical

location, security of the internet connection utilized by the accessing device and so forth.

Figure 26: AirWatch Access Provisions




Figure 27 illustrates the Workspace ONE interface for the on-demand catalog. Organizations can establish

an approved catalog of applications and data repositories that can be presented to the user. These

catalogs can be tailored to users or user groups to provide only those services, applications and data

repositories that are relevant to the role of the user accessing the Workspace ONE portal. The catalog

allows users to self-subscribe to applications as needed. In addition to self-service, organizations can

automatically entitle users for applications which would be available for access from the launcher.

Figure 27: On Demand Access for Any Type of Application

Figure 28 illustrates the launcher for the Workspace ONE portal where users can launch applications. The

ability to launch applications, remote desktops and data repositories can be policy driven based on criteria

discovered about the device being used to access the portal. Policies for access can be driven through

AirWatch MDM as well as Horizon Policy Orchestrator.

Figure 28: Workspace ONE Portal Launcher




Figure 29 illustrates Workspace ONE Client access to applications and desktops that are serviced by

Horizon Desktops and RDS Hosts hosted in the organizations data center. A combined process for

authentication and authorization includes the use of VMware Identity Manager Service with Horizon

Resource Access. Access through the organizations DMZ to the remote hosted applications is made

through an access gateway as represented by the Access Point in the DMZ.

Figure 29: Remote Workspace ONE Client Access

Figure 30 illustrates local client access to Horizon delivered resources whereby the local client is able to

directly communicate with the Horizon Connection Servers for access to the Horizon Desktops, RDS Hosts

and applications.

Figure 30: Horizon Client Access




VVD VMware Software Components in the Validated Design for

SDDC 3.0

The following is a list of products and their respective versions that were used to build the CJIS Center of

Excellence.

SDDC Layer Product Group and Edition Product Name Product

Version

Virtual

Infrastructure

VMware vSphere Enterprise Plus ESXi 6.0 Update 2

VMware vCenter Server Standard vCenter Server Appliance (ISO) 6.0 Update 2

VMware Virtual SAN Standard or higher Virtual SAN 6.2

VMware vSphere Replication vSphere Replication 6.1.1

VMware Site Recovery Manager Enterprise VMware Site Recovery Manager 6.1.1

VMware NSX for vSphere Enterprise NSX for vSphere 6.2.4

Cloud

Management

VMware vRealize Automation Advanced or

higher

vRealize Automation 7.0.1

vRealize Orchestrator 7.0.1

vRealize Orchestrator Plug-in for NSX 1.0.3

vRealize Orchestrator Plug-in for vRealize

Automation 7.0.1

7.0.1

VMware vRealize Business for Cloud

Advanced

vRealize Business for Cloud 7.0.1 and

7.0.1

Express

Patch

Service

Management

VMware vRealize Operations Manager

Advanced or higher

vRealize Operations Manager 6.2.1

vRealize Operations Management Pack for

NSX for vSphere

3.0.2


vRealize Log Insight

1.0.1


vRealize Automation

2.0


Storage Devices

6.0.4

VMware vRealize Log Insight vRealize Log Insight 3.3.2

vRealize Log Insight Content Pack for NSX

for vSphere

3.3

vRealize Log Insight Content Pack for

Virtual SAN

2.0


vRealize Automation 7.0

1.0




SDDC Layer Product Group and Edition Product Name Product

Version


vRealize Orchestrator 7.0

1.1


vRealize Operations Manager 6.x

1.6

Business

Continuity

VMware vSphere Data Protection vSphere Data Protection 6.1.2

Validation Scope and Approach This validation effort built upon the concepts of compliance capability discussed in the VMware Validated

Design for SDDC and Workspace One Product Applicability Guide for CJIS version 5.5. Specific use cases

were selected to narrow down the scope for this validation engagement. It was VMware’s intention to

showcase capabilities that may be meaningful to the criminal justice and non-criminal justice agencies and

entities engaged with criminal justice services and information. This validation engagement was limited to

two defined use cases.

It is essential to enable controls to provide secure enclaves for systems and data to reside whereby the

transmission of data can be routed appropriately and protected from unauthorized access. VMware chose

to demonstrate the capability of VMware solutions to enable system and communication protection and

information integrity. This aligns with CJIS Security Policy Area 10. Testing and assessment included the

policy topics of information flow enforcement, boundary protection, partitioning, and virtualization.

The inspection of boundary protection mechanisms was limited to capabilities supported by VMware

technologies. It did not include evaluation of traditional boundary protection measures provided by physical

firewall appliances placed at the physical boundary of the organization’s network. Rather, what was

demonstrated was the effectiveness of VMware Edge Services Gateway to provide edge protection for the

virtualized infrastructure and workloads.

Mobility and remote access for agents in the field is also important for the efficient and effective

enforcement of the law. Secure access to criminal justice systems and information may be required for

many of these agents as it can help to collect and submit evidence, identify parties in an engagement, and

facilitate decision making. The security of remote and mobile access is important to allow for maintenance

of confidentiality, integrity, and availability of CJI. This aligns with CJIS Security Policy Area 13. Policy

topics covered and relevant to VMware technologies include mobile hotspots, mobile device management,

wireless device risk management, patching/updates, personal firewall, access control, identification and

authentication, advanced authentication, and device certificates.

It should be noted that VMware and partner solutions are not limited to these use cases. There are certainly

many more use cases available to demonstrate the capability of VMware to enable technical controls for

the security of CJI in compliance with CJIS Security Policy version 5.5.

Coalfire considered the policy citation for each policy topic included in scope for assessment. To expand

on the basic consideration of the policy topic and provide a broader understanding of capability to achieve

compliance, VMware, with the help of Coalfire, aligned NIST 800-53 rev 4 controls with CJIS Security Policy

version 5.5. This effort also supported VMware’s interest for using a common framework of alignment to

illustrate capabilities across a wider selection of compliance frameworks. The broader definition of control

relative to the CJIS Security Policy statement included NIST 800-53 rev 4 control statements and

supplemental guidance. Control determination, examination, tests, and interviews were tailored for this




type of vendor solution assessment. For control statements that require organization-defined variables,

Coalfire identified the breadth of options available from the technology solution to provide support. In many

cases, more than one possible option was available to satisfy the control objective.

The testing was performed against a lab environment that followed VMware best practices. Additional

configuration was made purposefully to demonstrate the usefulness of the solutions for supporting

compliance objectives. It is understood that each agency must consider, for alignment with its own GRC

program, its own organizational policies, procedures, organizational controls, management structure, risk

assessment, and technical controls that are pertinent to their particular mission and environment.

In general, and for each selected test, Coalfire performed the following activities:

1. Interview

a. Subject matter experts on demonstrated technology capabilities specific to control

objectives

b. Subject matter experts, architects, and designers of the test lab

2. Examine

a. Overall information system design documentation

i. Understanding of baseline configuration as part of best practices implementation

for foundational components of the test lab: the VVD and VMware Workspace

ONE

b. Information system configuration settings specific to each control decision and associated

component configuration documentation

i. Understanding of specific configuration settings designed to meet control

objectives relative to the CJIS Security Policy

c. Event and audit logs as a demonstration of activity results supporting control objectives

3. Selective Tests1

a. Demonstrate effectiveness of control in place

Finally, the overall architecture and design of the solution was evaluated for effectiveness in supporting

organizational operations in a secure manner.

Findings and Observations

Policy Area 10: System and Communications Protection and

Information Integrity

The policy topics were chosen based on the alignment with the specified use cases. As a result, not all

Policy Area 10 requirements were included for validation.

Information Flow Enforcement

1 Not all controls were tested; tests that were performed were selected to include specific subset of the controls and to demonstrate specific product capabilities. Some controls capabilities were determined through examination of configuration settings.




5.10.1 “The network infrastructure shall control the flow of information between interconnected systems.”

(CJIS Information Security Officer, 2016)

Control Decision: “Determine if the information system enforces approved authorizations for

controlling the flow of information within the system and between interconnected systems based

on organization-defined information flow control policies.” AC-4 (NIST, 2013)

Findings: VMware NSX for vSphere was used for the software-defined network design of the

SDDC. VMware NSX provided Edge Services Gateways, distributed logical routers, distributed

firewalls, and distributed logical switches for the SDDC. The Edge Services Gateways were

configured with firewall, dynamic routing, network address translation (NAT), and load balancing

services. VMware NSX Edge firewall natively supported rules including IP 5-tuple configuration

with IP and port ranges for stateful inspection for all protocols. NSX firewall was determined to be

capable of Layer 2 through 3 inspection of network packets through NSX controlled virtual

interfaces. For this reason, the examination of capability to address this control focused primarily

on the technology’s ability to enforce information flow policy based on characteristics that can be

commonly found in the network packet header. Moreover, the lab demonstrated the usefulness of

the NSX firewall of the Edge Services Gateway to segment the network into security zones and to

control communications between these zones. The NSX Edge Services Gateway firewall provided

the boundary protection between each segment where policies and filtering rules were applied.

Furthermore, the Edge Services Gateway firewall could be extended to provide protection for

individual workloads whereby the distributed firewall could be assigned to the vNIC of each virtual

machine. To enable this functionality, the design included a demonstration of the capability to

dynamically assign workloads to security groups based on a selection of available variables found

in the NSX Service Composer. These defining variables allowed for the dynamic inclusion of

systems into organized security groups. A security policy was then applied to these organized

security groups with rules dictating the flow of data to and from each of the VMs. The default

security policy for these security groups was to deny all traffic and allow by exception where

policies were created to explicitly define the exceptions.

The application of security policy in the test lab was intended for demonstration of capability to

enforce authorized traffic and to block any unauthorized traffic. Security policy was demonstrated

to be applied traditionally using hierarchical policy statements with 5-tuple criteria. The policies

can enable approved authorization for transport of data between interconnected systems based

on predetermined architectural decisions.

For consideration, information flow enforcement may be best enforced through mechanisms

capable of deeper inspection of the network packets traversing the network. This extended

security capability helps to address control enhancements for information flow control. This

includes the ability to inspect the application data or payload dynamically for identification and

classification or re-classification of the data being transmitted with rules determining routing based

on this inspection process.

Summary Result: Supports Control Requirement

Control Decision: “Determine if the information system uses security attributes associated with

information source and destination objects to enforce defined information flow control policies as

a basis for flow control decisions” AC-4(1) (NIST, 2013)

Findings: The options for dynamic membership of security group, using security attributes, to

identify source and destination objects on the network for assigning security policy include:

Computer Name – including an identifying marker found in the naming convention




Virtual Switch Membership

Cluster Membership

Virtual Wire

Network

Virtual App

Datacenter

IP Sets

AD Groups

MAC Sets

Security Tag

vNIC

Virtual Machine

Resource Pool

Distributed Virtual Port Group

These attributes can be combined or nested to define individual security groups with greater

precision. In addition to dynamic membership of security group membership, security group

members can be added manually. This capability is in addition to the more traditional approach of

creating security policies based solely on source and destination IP addresses. Figure 31 and

Figure 32 illustrate the selection of criteria for the dynamic inclusion of membership to a security

group.

Figure 31: Defining Dynamic Membership




Figure 32: Selecting Objects to include by type


Control Decision: “Determine if the information system uses protected processing domains to

enforce information flow control policies as a basis for flow control decisions” AC-4(2) (NIST, 2013)

Findings: Multiple protected processing domains were established in the lab environment. There

are processing domains or trusted zones with distinct VLANs or VXLANs relative to the

infrastructure services including infrastructure management, operations management, and

consumption. Additional segmentation is in place to support the operations of the infrastructure

and include vMotion, Virtual SAN, NFS storage, vSphere Replication, and VXLAN transport zones.

To support distinct organizational workloads, there are separate processing domains for both CJI

and non-CJI systems and data. The workloads are segmented using an Edge Services Gateway

to generate unique VXLANs to segment the processing domain. The processing domains were

further segmented by functional component area for greater separation of function and control

over security.

Policies are in place to support authorized or necessary communication between processing

domains and to block all other traffic.


Boundary Protection

5.10.1.1(1) “The agency shall control access to the networks that process CJI.” (CJIS Information Security

Officer, 2016)

5.10.1.1(2) “The agency shall monitor and control communications at the external boundary of the

information system and at key internal boundaries within the system.” (CJIS Information Security Officer,

2016)” (CJIS Information Security Officer, 2016)

Control Decision: “Determine if the information system, at managed interfaces: denies network

traffic by default; and allows network traffic by exception.” SC-7(5) (NIST, 2013)




Findings: The NSX firewall policy ruleset was capable of being configured to include a default

deny-all rule for any source to any destination address. This policy was applied globally and

distributed to every virtual firewall and distributed firewall instance to include the edge boundary

for the organization as well as key internal boundaries and between adjacent virtual machines with

applied distributed firewall. This configuration capability asserts least functionality and least

privilege by only allowing communication flow between devices by explicit policy based exception.

Figure 33 is three screenshots that show the default deny all policy applied to the security groups.

The last screenshot in the series shows the default global policy for the virtual Distributed Firewall.

Figure 33: Default Rules

At the time of testing, the “Default Rule” for “Default Section Layer 3” for the distributed firewall

was set to allow with logging enabled. For an actual deployment in a CJIS controlled environment,

it is recommended that the default policy be set to block. To enable this setting, it will be important

to setup exception policies to support proper operation of the infrastructure components and the

applications that they serve. Each exception should be clearly defined with an explanation as to

the purpose of the exception.


Control Decision: “Determine if the information system only allows incoming communications

from organization-defined authorized sources to be routed to organization-defined authorized

destinations.” SC-7(11) (NIST, 2013)

Findings: Coalfire examined logical router and logical firewall configuration settings provided by

NSX Edge Gateway Services and NSX Distributed Firewall and determined that a control was in

place to identify inbound communication sources, to limit the inbound communication sources at

designated external and internal boundaries of the information system, to only permit authorized

sources, and to specifically route inbound communication only to authorized destinations. For

demonstration purposes, the lab included two major environments to represent workloads: a CJIS

environment and a non-CJIS environment. Each of these environments also included a web tier

to demonstrate the probability of a DMZ zone for external access. The non-CJIS environment

permitted communication from the Internet to the load balanced web devices in the web tier and

to the specified IP address, using a specified approved port. The access to the web tier from the

Internet could have been further tightened by specifying allowed source IP addresses.

Figure 34 is a screen capture of the firewall rule sets created for each of the security zones. The

first security zone listed is the general-purpose public security zone which does not contain CJI.

The second security zone listed, rules 6-10, represent the CJIS security zone. The security groups

represented in this security zone are inclusive of assets defined by the security groups. These

assets represent the end-user access, data processing and database components in support of

CJI.




Figure 34: Firewall Rules

For the CJIS environment, the communication to the web tier was intentionally restricted to

specified workstation zones. This was to demonstrate the capability to enable greater control of

access to sensitive and critical CJIS data. This prevented any direct Internet-based access to the

CJIS workload. Access rules with the NSX firewall were created to specify not only permitted

workstation zones, but also Active Directory user security groups.

Because this workstation zone was serviced by VMware Workspace ONE and VMware Horizon,

additional Workspace ONE policies could be created to further restrict access to the application.

Capability to restrict access at the user level is described in greater detail later in requirement 13

findings.


Control Decision: “Determine if the information system: monitors communications at the external

boundary of the information system; monitors communications at key internal boundaries within

the system; controls communication at the external boundaries of the information system; controls

communications at key internal boundaries within the system; implements subnetworks for publicly

accessible system components that are either physically separated from internal organization

networks, and/or logically separated from internal organization networks.” SC-7 (NIST, 2013)

Findings: The design of the VVD for SDDC called for the placement of NSX logical networking

constructs including the Edge Services Gateway, distributed logical router, virtual distributed

switches, logical virtual switches, and distributed virtual firewalls that enabled monitoring, packet

inspection, filtering, and control of communication both between the agency external boundary to

the Internet as well as at the boundaries of the internal information systems.

While the control for NSX was limited to Layer 2 through 3, rules were setup to allow or deny

communication between segments using these constructs. The utilization of the distributed router

and the Edge Services Gateway allowed for the isolation of publicly accessible components from

internal organization networks by creating virtual DMZ zones to contain the publicly accessible

components. Network Address Translation (NAT) was used to obfuscate the internal private

network from external discovery. Distributed logical routers, additionally, provided NAT services




for the VXLANs that distinguished workloads. This provided additional obfuscation of the overlay

networks, which supported the workloads. The combination of virtual subnets, logical routing rules,

and distributed firewalls with applicable policies applied helped to maintain boundaries between

these external and internal segments. Moreover, the inclusion of vRealize Network Insight

provided the visibility of network flows to aid with identification of gaps and unplanned policy

violations for an improved understanding of potential weaknesses in the network configuration.

Additionally, VMware NSX Edge Services Gateway logical firewalls provided a flow monitoring

feature that displayed network activity between virtual machines in the environment at the

application protocol level. Moreover, SpoofGuard policies can be setup for specific networks to

prevent IP spoofing. SpoofGuard blocks traffic that it is determines to be spoofed.

After synchronizing with the vCenter Server, NSX Manager collects the IP addresses of all the

vCenter guest VMs from VMware Tools. If a VM has been compromised, the IP address could be

spoofed and malicious transmissions could bypass firewall policies. SpoofGuard inherently trusts

MAC addresses of virtual machines collected from the VMX files and vSphere SDK. The

monitoring modes available for SpoofGuard are shown in the following screen capture of

SpoofGuard configuration settings Figure 35.

Figure 35: SpoofGuard Policy Enablement




Figure 36: SpoofGuard Default Policy Application


Control Decision: “Determine if the information system routes all networked, privileged accesses

through a dedicated, managed interface for purpose of access control and auditing.” SC-7(15)

(NIST, 2013)

Findings: With the positioning of the distributed firewall to provide protection for each workload in

the infrastructure, all traffic, whether internal or external, was able to be routed through managed

interfaces that could be enabled for access control and auditing. NSX could be integrated with

Microsoft Active Directory to support rulesets and policies that include identification of users or

members of AD security groups on the network. Thus, privileged users can be identified by

membership of security groups in Active Directory. This allows rules to be enabled to include

additional filtering, monitoring, or scrutiny of network activity associated with members of a defined

Active Directory security group.

Advanced networking security services could be service chained with NSX to provide greater

control and scrutiny of network traffic. Escalation rules can be applied to increase the scrutiny of

traffic initiated by privileged users. Through the Service Composer, rules can be set up to route

traffic to additional distributed network security services including IPS/IDS and next generation

application firewalls for deeper Layer 4 – 7 inspection. While, service chaining with partner

technologies was not specifically tested during this exercise, Coalfire participated in testing NSX

Micro-Segmentation with service chaining in a recent lab exercise. The findings can be found in

VMware NSX Micro-Segmentation Benchmark Final v1.0.


Control Decision: “The information system, in conjunction with a remote device, prevents the

device from simultaneously establishing non-remote connections with the system and

communicating via some other connection to resources in the external network.” SC-7(7) (NIST,

2013)

Findings: The Edge Services Gateway was examined for the ability to enable remote connections

to the network. This service includes an SSL VPN-Plus solution to allow remote users to connect

securely to the private network. The client configuration was found to include configuration options

for selection of tunneling mode. Full tunnel mode restricts split tunneling for the SSL VPN-Plus

user connection to the internal network. When full tunnel mode is selected, the NSX Edge Gateway

becomes the remote user’s default gateway and all traffic (VPN, local and internet) flows through

this gateway. There are options available with the configuration to exclude local subnets, which




would exclude local traffic from flowing through the VPN tunnel. Figure 37 diagrams the user

connection to internal corporate resources using SSL VPN-Plus.

Figure 37: SSL VPN-Plus

Beyond the remote connection capabilities supplied through the SSL VPN-Plus of the NSX Edge

Services Gateway, Workspace ONE provides access to internal system resources through the

virtual desktop delivery capability of Horizon View or virtual application delivery through App

Volumes. AirWatch can provide controlled access to cloud native applications and data delivered

through applications designed for mobile devices. In each of these cases, the delivery of access

to the organization’s internal resources is encapsulated in secure containers. These containers

are either hosted and delivered via a terminal session from the secure data center or delivered to

secure and encrypted space on the end user’s device. AirWatch can designate and partition space

from the user’s device and enforce encryption for that space for the protection of data contained

therein. This could allow for the security of applications and data for offline use. Moreover,

Workspace ONE can identify, among other variables, the logical, physical, and network location

of end user devices. This capability of Workspace ONE allows for the creation of variable access

policy that can be applied to limit or prevent access from less secure or unsecure logical and

physical locations.


Control Decision: “Determine if the information system, to limit the effects of information flooding

denial of service attacks manages: excess capacity, bandwidth, or other redundancy.” SC-5(2)

(NIST, 2013)

Findings: The testing of this environment was limited to the software-defined networking

components of VMware NSX and their capability to provide boundary protection and information

flow enforcement. This did not include examination of physical firewalls typically placed at the edge

of the organization’s network as a boundary between the organization and their ISP(s). Typically,

DoS and DDoS protections will be provided both by the ISP and the physical boundary protection

devices.




Coalfire participated with VMware on testing service insertion or service chaining with VMware

NSX, through Service Composer, to demonstrate enhanced security service capability with

respect to the micro-segmentation support of NSX. In these findings, it was determined that NSX

was capable of being configured through the Service Composer to further direct traffic to IPS/IDS

and or next generation application firewalls for detection of attacks occurring on the network.

These solutions are better equipped to detect certain types of attacks including information

flooding denial of service attacks.

Beyond this, VMware NSX could be configured to support quality of service (QoS) values to a

variety of traffic types as well as to more critical segments of the network. NSX supports

Differentiated Services Code Point (DSCP) values in its QoS configuration. This allows the QoS

to extend beyond the boundary of the virtual network infrastructure to the physical switching

infrastructure of the leaf switches. Typically, less secure networks may be given lower priority for

routing due to the more vulnerable nature of these networks. Figure 38 illustrates the architecture

of VMware NSX. Included in the illustration is software partner extensions that allow for service

chaining of advanced security inspection capabilities provided by antivirus, next generation

application firewalls, IDS/IPS and so forth.

Figure 38: NSX Service Chaining with 3rd Party or VMware Partner Solutions


5.10.1.1(3) “The agency shall ensure any connections to the Internet, other external networks, or

information systems occur through controlled interfaces (e.g. proxies, gateways, routers, firewalls,

encrypted tunnels).” (CJIS Information Security Officer, 2016)

Control Decision: “Determine if the information system connects to external networks or

information systems only through managed interfaces consisting of boundary protections devices

arranged in accordance with an organizational security architecture.” SC-7(c) (NIST, 2013)

Control Decision: “Determine if the information system routes [Assignment: organization-defined

internal communications traffic] to [Assignment: organization-defined external networks] through

authenticated proxy servers at managed interfaces” SC-7(8) (NIST, 2013)




Findings: VMware NSX is capable of being configured to support routing of outbound connection

to the internet through controlled and managed interfaces. VMware NSX was also determined to

be able to virtually firewall each workload individually, this allows for more granular control with

implementation of network communication rules set at individual VM level.

Also, through the configuration of policies through NSX Service Composer, advanced/enhanced

network security services can be inserted to allow for routing of outbound traffic through partner

or third party provided internet web proxies, IDS/IPS devices, and application firewalls. Several

criteria to determine and assign routing behavior can be defined in NSX.


Control Decision: “Determine if the information system blocks both inbound and outbound

communications traffic between [Assignment: organization-defined communication clients] that

are independently configured by end users and external service providers.” SC-7(19) (NIST, 2013)

Findings: This capability requires additional third-party or partner solutions to identify and block

traffic based on application data, including identification of communication protocols from

unsupported independently configured communication clients. VMware NSX is capable of being

configured to route traffic to integrate able advanced network security services such as next

generation application firewalls provided by VMware partners. It is with this service insertion that

discovery of unauthorized communication protocols can be blocked.

Summary Result: Supports Control Requirement (requires additional third-party or partner

solution)

5.10.1.1(5) “The agency shall ensure the operation failure of the boundary protection mechanisms do not

result in any unauthorized release of information outside of the information system boundary (i.e. the device

shall “fail closed” vs. “fail open”).” (CJIS Information Security Officer, 2016)

Control Decision: “Determine if the information system fails securely in the event of an

operational failure of a boundary protection device.” SC-7(18) (NIST, 2013)

Findings: Due to the distributed nature of the boundary control mechanisms provided by VMware

NSX, the distributed network services including routing, switching, and firewalls continued to

operate when the management plane failed. Failure of the NSX manager prevented additional

new policies from being established above that which was already in place. Visibility to the network

regarding information flow was also not available during the NSX manager failure. However,

established policies already distributed to the control appliances continued to operate as expected.

A failure of the control plane including Edge Services Gateway, distributed logical routers, and

logical switches blocked the further flow of information as these are necessary to enable end to

end communication, essentially failing closed. Without a functioning high availability (HA) partner,

the Edge Services Gateway would prevent the further flow of north and southbound information

on the network.

To limit the effect of unplanned outages, the information system was designed for redundancy.

Only systems with less criticality were implemented with single failure potential.


5.10.1.1(6) “The agency shall allocate publicly accessible information system components (e.g. public web

servers) to separate sub networks with separate network interfaces. Publicly accessible information system

residing on a virtual host shall follow guidance in section 5.10.3.2 to achieve separation.” (CJIS Information

Security Officer, 2016)




Control Decision: “Determine if the information system only allows incoming communications

from organization-defined authorized sources to be routed to organization-defined authorized

destinations.” SC-7(11) (NIST, 2013)

Findings: Coalfire examined logical router and logical firewall configuration settings to determine

that a control was in place to identify inbound communication sources, limit inbound

communication to authorized sources, and to specifically route inbound communications only to

authorized destinations. Coalfire tested access to and from various sources and destinations to

determine that the policies in place were sufficient to support the requirement. Attempts to access

unauthorized destinations were blocked, while attempts to access authorized destinations from

specified sources was allowed.

Publicly accessible servers or web servers in the environment were placed within a virtual DMZ.

The DMZ was protected by an Edge Services Gateway, which provided firewall protection for the

DMZ as well as load balancing for the publicly accessible web servers. Access from the web

servers to internal resources such as application servers and database servers were explicitly

allowed by policy through another set of Edge Services Gateways. No direct access to internal

assets was provided from the Internet.


Control Decision: “Determine if the organization isolates [Assignment: organization-defined

information security tools, mechanisms, and support components] from other internal information

system components by implementing separate subnetworks with managed interfaces to other

components of the system.” SC-7(13) (NIST, 2013)

Findings: Each plane of the environment was either physically, through segmentation with unique

subnet, or logically, through VLAN or VXLAN network overlay, isolated from each other. Rules to

allow routing of communication between subnets, VLANs, or VXLAN were explicitly stated for

reasons of necessary functionality, while virtual stateful firewalls provided the means to enforce

policy to specify authorized source and destination devices with authorized ports and protocols.

This allowed for proper segmentation and isolation of important information security tools,

mechanisms, and support components from other internal information system components. This

segmentation helped to prevent unauthorized tampering with network security configuration

settings. Access control to the security and management components of the environment is locked

down to limit access only to credentialed authorized personnel. The network access controls

further support this access by blocking access by Active Directory security group membership.


Partitioning

5.10.3.1 “The application, service, or information system shall separate user functionality (including user

interface services) from information system management functionality. The application, service or

information system shall physically or logically separate user interface services (e.g. public web pages)

from information storage and management services (e.g. database management).” (CJIS Information


Control Decision: “The information system separates user functionality (including user interfaces

services) from information system management functionality.” SC-2(1) (NIST, 2013)

Findings: The design of the information system logically separated user functionality from system

management functionality. This is performed at several layers. Distinct or discreet VLANs are

implemented at the physical layer to separate management from workload. Distinct VXLANs are




designated to workload component layers to separate web, application, and database functions.

Storage networks are also logically segmented with unique non-routable VLAN to isolate all

storage network traffic to storage networking purposes. The vMotion network was also segmented

with a unique VLAN.

Moreover, management and edge components were physically separated onto distinct functional

ESXi clusters. Workloads or organizational end user access environments were supported by a

separate workload cluster, which was managed by its own vCenter. The management and

workload vCenter Servers are connected; however, user access controls and network controls are

in place to limit access to authorized privilege levels. This allows for the creation of management

layers within the environment to establish separation of duties between workload administrators

and infrastructure administrators.


Virtualization

5.10.3.2 “In addition to the security control described in this policy, the following additional controls shall

be implemented in a virtual environment:

5.10.3.2(1) Isolate the hosts from the virtual machine. In other words, virtual machine users cannot access

host files, firmware, etc.” (CJIS Information Security Officer, 2016)

Control Decision: “Determine if the vSphere hosts are isolated from the virtual machines such

that virtual machine users cannot access host files, firmware, etc.” SC-2, SC-2(1) (NIST, 2013)

Findings: VMs in the environment were isolated from the hosts in the environment. VMs that

represented workloads were placed on a network segment separate from ESXi hosts to prevent

adjacent access capabilities. ESXi hosts were hardened to prevent direct access from any

machine in the environment. ESXi host lock down mode was placed on the ESXi hosts in the

environment to require all configuration to be executed through vCenter. ESXi Shell and SSH were

also disabled on the hosts to prevent any console access to the host.

Additionally, ESXi is designed to prevent any direct access from virtual machine operating systems

to host settings, files, or configuration.


5.10.3.2(3) “Virtual machines that are Internet facing (web servers, portal servers, etc.) shall be physically

separate from Virtual Machines that process CJI internally or be separated by a virtual firewall.” (CJIS

Information Security Officer, 2016)

Control Decision: “Determine that virtual machines that are Internet facing such as web servers,

portal servers, and so forth are either physically separate from virtual machines that process CJI

internally or that they are separated by virtual firewall.” SC-7 (NIST, 2013)

Findings: VMware chose to utilize virtual firewalls supplied by the NSX Edge Service Gateway to

segment Internet-facing web servers from internal servers. Micro-segmentation was provided by

the NSX virtual Distributed Firewall. These provided adequate protection between the publicly

accessible VMs and VMs that process CJI internally.


5.10.3.2(4) “Drivers that serve critical functions shall be stored within the specific virtual machine they

service. In other words, do not store these drivers within the hypervisor, or host operating system, for




sharing. Each virtual machine is to be treated as an independent system – secured as independently as

possible.” (CJIS Information Security Officer, 2016)

Control Decision: Determine that drivers that serve critical functions are stored within the specific

virtual machine they service and are not stored within the hypervisor or host operating system for

sharing. Determine that each virtual machine is treated as an independent system and secured

as independently as possible.

Findings: In this environment, utilizing ESXi for the host hypervisor, VMs in the environment are

deployed as independent systems. The VMs share a pool of hardware resources; each VM

contains its own set of virtual drivers that allows the virtual machine to act independently from

other virtual machines in the environment. ESXi provided memory hardening and kernel module

integrity to ensure the integrity of the VM use of shared compute resources and the protection of

the host from execution of malicious code. Moreover, the VMkernel mediates all use of physical

resources whereby all hardware access takes place through the VMkernel, this prevents VMs from

circumventing the isolation inherent in the architecture. Any communication that occurs by the VM

to other VMs or physical devices in the environment are required to go through managed virtual

distributed switch interfaces. Traffic between VMs is controlled and managed by the

implementation of virtual distributed firewalls, distributed logical routers, and Edge Services

Gateway. The distributed nature of these services allows policy to continually be applied to the

VM regardless of the location of the VM physically within the cluster. These capabilities were

determined to sufficiently meet the intent of separation and independence of the VM by preventing

the sharing of resources such that processes, memory, network transmissions, data storage and

so forth cannot be compromised by other VMs or the host.


5.10.3.2 “The following additional technical security controls shall be applied in virtual environments where

CJI is comingled with non-CJI:

5.10.3.2(1) Encrypt CJI when stored in a virtualized environment where CJI is comingled with non-CJI or

segregate and store unencrypted CJI within its own secure VM.

5.10.3.2(2) Encrypt network traffic within the virtual environment.” (CJIS Information Security Officer, 2016)

Control Decision: Determine if encryption is used to encrypt CJI when stored in a virtualized

environment where CJI is comingled with non-CJI or ensure that CJI is segregated and stored

within its own secure VM. Determine if network traffic is encrypted within the virtual environment.

Findings: For this lab instance, CJI was separated from non-CJI and the data was not comingled

on a single VM. Moreover, to satisfy the requirements of this policy, VMs that represented CJI

systems and data were segmented on the network to provide isolation of network traffic distinct

from that of non-CJI. This prevented the possibility of comingling data either at rest, in process, or

during transmission. Where CJI was to traverse the network and leave the internal boundary of

the CJI secure network zone, the Edge Services Gateway could be setup to provide a VPN tunnel

between network endpoints whereon encryption services for encrypting the data in transit could

be applied.


5.10.3.2 “The following are additional technical security control best practices and should be implemented

wherever feasible:

5.10.3.2(1) Implement IDS and or IPS monitoring within the virtual environment.




5.10.3.2(2) Virtually or physically firewall each virtual machine within the virtual environment to ensure that

only allowed protocols will transact.

5.10.3.2(3) Segregate the administrative duties for the host.” (CJIS Information Security Officer, 2016)

Control Decision: Determine if the implementation of the infrastructure includes the placement

of IDS and or IPS monitoring at key network managed interfaces in the virtual environment. SC-7

(NIST, 2013)

Determine if each virtual machine is capable of being physically or virtually firewalled within the

virtual environment to ensure that only allowed protocols will transact.

Determine if the environment is deployed in such a way to support the segregation of

administrative duties for the host.

Findings: The scope of this environment, being exclusively VMware solutions from an SDDC and

EUC perspective, did not include an implementation of an IDS and/or IPS solution distributed or

otherwise. However, VMware NSX is capable of being integrated with partner solutions to provide

IDS/IPS capability. This works with NSX Service Composer to enable service chaining; network

traffic can be routed to a distributed IDS/IPS sensor for enhanced filtering and inspection for

identification and/or blocking of suspicious or unwanted network activity.

VMware NSX was implemented with capability for virtually firewalling, with a stateful firewall to

support enforcement of protocol formats, every VM in an environment. This includes network

boundaries within which VMs reside as well as individually for every VM on the network. This

distributed firewall capability to enable micro-segmentation was useful for preventing network

communication between adjacent VMs on the same subnet, VLAN or VXLAN. On a traditional

network, devices on the same VLAN may be more likely to discover and access adjacent devices.

This adjacent access often increases the scope and impact of compromise by allowing an attacker

to pivot on the network until finding data or information of greater use and importance. It is also

useful for the propagation of viruses and bots that are capable of replicating to adjacent devices.

The implementation of VMware NSX distributed firewall, a stateful firewall, was shown to be

capable of being deployed to ensure that only allowed ports are accessible and protocols will

transact.

Finally, it was determined that the environment is deployed in such a way to support the

segregation of administrative duties for the host. Once the deployment was complete, all

administrative duties for the host were restricted to the use of vCenter. Host lock down mode was

enabled to prevent direct access to the host. Security roles were established within vCenter SSO

to further segregate administrative function to limit individual access to that which is necessary.

vCenter SSO was integrated with Microsoft Active Directory whereby user accounts and

credentials were defined to satisfy compliance requirements. User accounts were organized into

security groups that are linked to security roles established in vCenter.


Policy Area 13: Mobile Devices

The policy topics for Policy Area 13 were chosen for their alignment with the mobility of the criminal justice

information system agency’s representatives use case. While some topics may be pertinent to security for

a mobile workforce, they may not have been addressed due to limitations with VMware solutions to enable

control. As an example, this document does not include discussion of VMware capabilities to enable control

for Wireless protocols, specifically as they relate to wireless access points.




The findings for coverage of the VMware Workspace One solution with regard to CJIS 5.5 Mobile Devices

security policy area were specific to the devices that were selected and provided during testing. The

capability to provide coverage for compliance to the degree necessary requires an understanding of the

capabilities and limitations of various devices. Moreover, the degree to which an organization implements

mobile device management may vary from agency to agency with varying use cases within each agency.

The requirements may be unique in each agency case. For these reasons, Coalfire advises each agency

to evaluate the combination of devices with VMware Workspace ONE capabilities to determine the best fit

to meet the agency’s compliance and delivery requirements.

Scoping Note: The demonstration of capability of Workspace ONE to address CJIS 5.5 Policy Area 13 is

geared toward general configuration capabilities and determining whether the configuration capability

existed to provide a level of support to meet the policy requirement.

Bluetooth

5.13.1.3 “Organizational security policy shall be used to dictate the use of Bluetooth and its associated

devices based on the agency’s operation and business processes.” (CJIS Information Security Officer,

2016)

Control Decision: Determine what capability exists to enforce security policy requirements

regarding the use of Bluetooth.

Findings: VMware AirWatch MDM, a component of the Workspace ONE suite of solutions, has

the capability to enable numerous parameters with respect to the use of Bluetooth. This applies to

devices that are registered with the AirWatch MDM solution. Depending on the device, restrictions

can be enabled to allow or prevent the following:

Bluetooth Discoverable Mode

Bluetooth Limited Discoverable Mode

Bluetooth Pairing

Bluetooth Data Transfer

Desktop Connectivity Via Bluetooth

Enable Bluetooth Device Restrictions

Enable Bluetooth Secure Mode

Figure 39 shows an example configuration for an Android profile where options exist for the approved

configuration or restrictions on Android devices regarding the use of Bluetooth.

Figure 39: Bluetooth Restriction Capability




Various profiles can be created within AirWatch and applied to identified devices to enforce

restrictions based on the purpose and use of the specific device. For instance, devices used for

collection of sensitive evidence can have stricter Bluetooth configuration applied to reduce the risk

to the device and the data being collected; whereas, general purpose devices may be allowed

greater flexibility with respect to the use of the Bluetooth radio for connectivity to peripheral devices

or other nearby devices.


Mobile Hot Spot

5.13.1.4 “When an agency allows mobile devices that are approved to access or store CJI to function as a

Wi-Fi hotspot connecting to the Internet, they shall be configured to:

(1) Enable encryption on the hotspot

(2) Change the hotspot’s default SSID

(a) Ensure the hotspot SSID does not identify the device make/model or agency ownership

(3) Create a wireless network password (pre-shared key)

(4) Enable the hotspots port filtering/blocking features if present

(5) Only allow connections from agency controlled devices

Or have an MDM solution to provide the same security as identified in 1-5 above.” (CJIS Information


Control Decision: Determine capabilities of mobile device management solution to provide

controls to securely enable a mobile device to establish a mobile hot spot to support WiFi

connection of nearby devices to the Internet. Determine if capability exists to enable encryption on

the hotspot; change the hotspot’s default SSID that is differentiated from the identity of the device

or agency ownership; create a defined wireless network password; enable the hotspots port

filtering/blocking features; only allow connections form agency controlled devices.

Findings: It was determined that VMware AirWatch has limited capability with regard to

configuration settings applicable to the use of enabling or using mobile hot spots. With respect to

AirWatch, it is recommended that the organization establish a manual process for enabling hotspot

settings on mobile devices that require it. VMware AirWatch was only able to be configured to

block or allow enablement of a mobile hot spot for registered devices with AirWatch MDM.

Summary Result: The Technology Does NOT Support Control Requirement; requires manual

intervention by agency

Mobile Device Management (MDM)

5.13.2 “Devices that have had any unauthorized changes made to them (including but not limited to being

rooted or jail broken) shall not be used to process, store, or transmit CJI data at any time.” (CJIS Information


Control Decision: Determine if AirWatch MDM has the capability to detect and prevent devices

that have been altered with unauthorized configurations, rooted or jail broken from being used to

process, store or transmit CJI data at any time.




Findings: It was determined that VMware Airwatch MDM allowed the organization to define smart

groups with select criteria. These criteria included organizational entity, organization group, user

group, device platforms and operating systems, tags, exclusions and inclusions.

Figure 40 illustrates the setting up of a smart group to include various defining variables such as

users, user groups, devices, device types, and so forth.

Figure 40: Smart Group Configuration

Tags allow for better organization of devices in smart groups based on properties that may be

specific to the organization’s network. The tags selection in smart groups allow for the inclusion of

devices in the smart group based on organization defined tags that were applied to devices. Tags

can be applied to registered devices at any time to allow them to take on membership of smart

groups.

Additions and exclusions allow for the specific selection of devices to be added or excluded from

the smart group whether they matched the other selected criteria or not. The selection of criteria,

rather than specific device or users, allows for dynamic application of profiles, policies, and

applications to be applied to users or devices by smart group. That being said, a smart group can

be made up of specifically select AirWatch registered user’s and devices.

Device profiles, including device settings specific to the device type, can be applied to smart

groups ensuring that specified settings are enabled on the device. These applied profiles can

include configuration requirements regarding authentication strength and methods, device

restrictions, firewall, malware protection, device sync settings and more.




Figure 41, smart phone or mobile device profiles can be setup with restrictions and configuration

settings relevant to a number of policies.

Figure 41: Device Profile Configuration

Figure 42, A compliance policy can be created to support device configuration status, which

provided options to automate response for devices found to be out of compliance. The detection

capabilities for determining the status of a particular device is multi-tiered including agent

enrollment, ongoing automatic agent based background checks, on-demand background checks,

and detection capability built into deployment of enterprise applications to mobile devices.

Figure 42: Compliance Policy with Escalating Actions

The compliance engine serves as a security checkpoint providing multiple actions on devices or

users. Multiple rules can be nested with a compliance policy. Actions can be enabled for the policy

for determination of automated response for detected policy violations. These actions can be set

up for escalation with increasing severity of response. Escalation can include actions such as

notification to the device, email to the user of the device, notification to administrators or user

management, and remote wipe of the device. Furthermore, devices marked as non-compliant can

be disallowed from continued operation with the organizations applications and data.





5.13.2 “Agencies shall implement the following controls when allowing CJI access from devices running

limited feature operating systems:

(1) Ensure that CJI is only transferred between CJI authorized application and storage areas of the

device.” (CJIS Information Security Officer, 2016)

Control Decision: Determine if the VMware solution provided capability to ensure that CJI is only

transferred between CJI authorized application and storage areas of the device for limited feature

operating system devices.

Findings: It was determined that multiple configuration layers and options exist within AirWatch MDM

to provide protection of sensitive data. The following findings outline these configuration options.

Device or user profile could be configured to limit sync and storage options for the device including the

use of removable SSD, USB devices, cloud storage, and desktop synchronization (See Figure 43)

Figure 43: Sync and Storage Options for Device Configuration

Access to applications and data can be limited for the device to read only capability. This requires the

device to be online in order to access the published application or data repository that is centrally

stored in the organization’s data center or within the organization’s approved cloud service provider.

In this scenario, applications and data are never stored locally on the end-user device. The delivery

mechanisms simply provide encrypted screen images of remote desktops, applications, data, and so

forth. Beyond read only access, interactions from the mobile device are sent encrypted to the remote

desktop, application, or data. With this scenario, data is never actually stored on the mobile device.

This is delivered either through AirWatch directly using cloud native or mobile native applications

whereby AirWatch is configured to force the connection through the AirWatch gateway. Alternatively,

through integration with Horizon, the delivery can be made using Horizon.

Figure 44 illustrates possible settings that can be enabled to enforce VPN connectivity for mobile

devices in support of more secure network connections.




Figure 44: Device VPN Configuration

AirWatch was determined to be capable of configuration to require specific devices or users to

automatically connect to the organization through SSL VPN when interacting with specific applications

or data. Moreover, some types of devices can be configured to be a member of an APN. The APN is

an always on VPN connection to a specific location whereby the cellular connection is also going over

the APN and under the purview and control of the agency.

AirWatch was also determined to be capable of configuration to support data loss prevention (DLP).

Figure 45 illustrates configuration settings in support of DLP. Through application settings and policies,

security policies were capable of being enabled to prevent certain activities in applicable devices from

occurring. This includes the ability to copy and paste, enable printing, enabling camera, enable

screenshot, and so forth. Files can be watermarked by policy with a watermark of the organization’s

choosing. Files can also be limited to only being opened in specified approved applications.




Figure 45: DLP Policy Settings

Beyond these configuration capabilities, AirWatch also provided containerized data and application

access for both online and offline access to applications and data. While continuous connections to a

cellular or other data network are ideal, there may be times when circumstances prevent uninterrupted

service and therefore connection back to a secure location. Moreover, it may be important to have

access to data or to collect information during those periods of disconnection. AirWatch is capable of

encrypting the data at rest and in transit using FIPS 140-2 compliant AES-256 encryption.


5.13.2(2) “MDM with centralized administrator configured and implemented to perform at least the:” (CJIS


(i) “Remote locking of device” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch MDM was determined to be capable of providing a centralized

administrator configuration and implementation to perform remote locking of device. Additionally,

AirWatch provides the capability to allow the devices owner or user to perform a remote lock of

the device. Events initiated from the control console are logged and recorded for review. The logs

show the account that was used to initiate the remote action, the date and time of the action, the

event that was performed, and the event data or result. Both console events and device events

are recorded (See Figure 46)




Figure 46: AirWatch Administrator Options: Remote Lock

(ii) “Remote wiping of device” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch was determined to be capable of allowing administrators and users

to perform remote wiping of a registered device as shown in Figure 47.

Figure 47: AirWatch Enterprise Wipe

Figure 48: Enterprise Wipe Event Logged




(iii) “Setting and locking device configuration” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch was determined to be capable of setting and locking a device

configuration according to the available settings of the device.

(iv) “Detection of “rooted” and “jailbroken” devices” (CJIS Information Security Officer, 2016)

Findings: Using several identification criteria, VMware AirWatch was determined to be capable

of detecting “rooted” and “jailbroken” devices. However, to increase the likelihood of successful

detection, the use of the AirWatch Agent deployed to the registered device is recommended.

(v) “Enforcement of folder or disk level encryption” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch was determined to be capable of configuration to enable folder and

disk level encryption for data at rest on mobile devices using FIPS 140-2 compliant AES-256

encryption.

(vi) “Application of mandatory policy settings on the device” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch was determined to be capable of configuration to establish a

standard for settings on device, per user or both. Policy checking is performed during the

enrollment process, during regular cycles, on demand, or continually when deployed by policy as

part of an application distribution.

(vii) “Detection of unauthorized configurations” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch was determined to be capable of detecting unauthorized

configurations. The detection of unauthorized configurations, rooted or jailbroken devices, can be

addressed with escalating responses including notification of non-compliance to the device, the

user of the device, and up to and including remote enterprise wipe of the device.

(viii) “Detection of unauthorized software or applications” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch was determined to be capable of enforcing policy to devices and

users to prevent the installation of blacklisted applications, prevent the un-installation of required

applications, and allow the installation of whitelisted applications. Figure 48 illustrates possible

application control settings that can be enabled for managed devices.

Figure 49: Application Control




Figure 49, additional application restrictions were determined to be available to allow or prevent

the device app store, YouTube, non-market app installation. Restrictions were also capable of

being enforced to block access to device settings, application settings, account settings, and

developer options.

Figure 50: Additional Application Control Settings

(ix) “Ability to determine the location of agency controlled devices” (CJIS Information Security Officer,

2016)

Findings: It was determined that AirWatch has the capability to determine location of agency-

controlled devices (See Figure 51).

Figure 51: Location Finding Devices

Moreover, device location history is capable of being logged whereby a report can be generated

to show the location of the device over a specified period of time (See Figure 52).




Figure 52: Device Location History

The ability to determine location of device also provides the opportunity to set policies relative to

application and data access based on device location.

(x) “Prevention of unpatched devices from accessing CJI or CJI systems” (CJIS Information Security

Officer, 2016)

Findings: VMware AirWatch was determined to be configurable to include policies to establish

approved versions for specific devices or device groups and to validate compliance with the

approved version. Compliance policies can be setup to determine that a device is compliant if it

meets the minimum approved OS version for the device. Figure 53 illustrates compliance policy

that can be enabled for devices with respect to approved operating systems versions.

Figure 53: Compliance Policy for Approved OS version

Actions in an AirWatch compliance policy can be established based on compromise status to

continue to permit the device to participate on the network or in the case of policy failure to install

a compliance profile. For example, as part of the compliance policy action, the compliance profile

can be set to be applied over cellular or to force update over WiFi Data connections. As with other

compliance policies, escalating actions can be set up in increasing order of severity per the

organization’s specified requirements. Figure 54 shows an example of actions that can be

enforced based on the status of the device being compromised according to policy.




Figure 54: Patch Compliance Actions

(xi) “Automatic device wiping after a specified number of failed access attempts” (CJIS Information


Findings: It was determined that VMware AirWatch through enablement of device settings has

the capability to specify the device response for a specified number of failed access attempts

including automatic wiping of the device when the number of attempts exceeds the specified

maximum allowed.


Wireless Device Risk Mitigation

5.13.3 “Organizations shall, as a minimum ensure wireless devices:

5.13.3(1) “Apply available critical patches and upgrades to the operating system as soon as they become

available for the device and after necessary testing as described in Section 5.10.4.1.” (CJIS Information


Control Decision: Determine if VMware solutions were capable of enabling control to wireless

devices to address the following:

Findings: AirWatch MDM is able to detect when a device is not at the approved OS level for iOS,

Android, macOS, and Windows devices. Participating with the organization’s data and applications

can be limited based on satisfying the requirement. Compliance policy can provide notification to

the devices and the devices user indicating that an update is available and required.

For macOS and Windows wireless devices, it is recommended to use a configuration management

tool for ensuring that the devices are updated according to the organization’s update schedule.


5.13.3(2) “Are configured for local device authentication (see Section 5.13.8.1).” (CJIS Information Security

Officer, 2016)

Findings: Profiles can be created for devices within AirWatch MDM. As a part of the profile setup,

local device authentication settings and parameters can be configured. A number of parameters

that represent requirements for local device authentication can be established in the profile

including: minimum passcode length, passcode content, maximum number of failed attempts for

entering passcode, grace period for passcode change, maximum number of repeating characters,

maximum length of numeric sequences, maximum passcode age in days, passcode history,

device lock timeout settings, passcode visibility settings, biometric and fingerprint unlock settings,

storage encryption settings, SD card encryption settings, and lock screen overlay.




Values for parameters can be set according to requirements found in CJIS Security Policy 5.5 with

regard to authentication requirements. Figure 55 and Figure 56 show the configuration screen for

passcode settings for accessing the local device.

Figure 55: Profile Passcode and Local Authentication Settings

Figure 56: Additional Passcode and Local Authentication Settings





5.13.3(3) “Use advanced authentication or CSO approved compensating controls per Section 5.13.7.2.1”

(CJIS Information Security Officer, 2016)

Findings: It was determined that VMware Workspace ONE and VMware AirWatch have the

capability to support methods of advanced authentication including the use of smart cards, tokens,

and certificates to provide an additional factor for authentication above username and password

and/or passcode. Rather than rely solely on local device authentication or a single factor for

authentication, additional authentication requirements can be configured and enabled for access

to applications and data through both the Workspace ONE portal using VMware Identity Manager

and through AirWatch. When accessing and application or data from the wireless device, the user

can be prompted to provide additional authentication credentials. For AirWatch, authentication

integration can be enabled with Kerberos, AirWatch enrollment credentials, certificate, and/or

NAPPS SSO.

VMware Identity Manager supports identity federation (SSO) with AD integration and SAML

Identity Provider and Provisioning Framework. It also provides an authentication broker for third-

party strong authentication types including smart card, token, and certificate-based authentication

methods.

Figure 57: Workspace ONE Identity and Access Management Policy Settings

Providing access to traditional applications, remote desktops, cloud native applications, and

mobile applications through an organization catalog or portal also allows for greater control over

the delivery of the application. It was determined that access to applications and the degree to

which authentication was required for use of the application can be configured to be conditional.

Conditional access policies can be applied by user security group, network (whether internal,

external, over VPN etc.), and strength of authentication provided. Conditional access can also be

granted by device where access to low risk apps and data can be provided for a broader set of

devices; sensitive and critical applications and data would require greater control of the device

including the ability to provide device encryption and remote wipe capability.




Figure 58: Identity and Access Management per Application

Figure 59: Setting Policy Rule for Conditional Authentication

The combination of AirWatch with VMware Identity Manager in VMware Workspace ONE, with a

device that supports location based services, provides conditional access capability to applications

based on GPS information where geo-fencing can be enabled to limit geographical location for

where an application can be launched or data accessed.


5.13.3(4) “Encrypt all CJI resident on the device.” (CJIS Information Security Officer, 2016)

Findings: Relative to MDM control of mobile devices, VMware Workspace ONE and AirWatch

has the capability to provide device level encryption as well as encryption of resident data in a

content locker in the device.





5.13.3(5) “Erase cached information, to include authenticators (see Section 5.6.2.1) in applications, when

session is terminated.” (CJIS Information Security Officer, 2016)

Findings: It was determined that both AirWatch and VMware Horizon can be configured to prevent

caching of credential information. This can be set globally or individually on an application by

application basis. Additional settings can be enabled to require re-authentication during regular

intervals. When a user session is terminated, the user is required to re-authenticate with the next

attempt to access the application.

Summary Result: Supports Control Requirements

5.13.3(6) “Employ personal firewalls or run a Mobile Device Management (MDM) system that facilitates the

ability to provide firewall services from the agency level.” (CJIS Information Security Officer, 2016)

Findings: It was determined that AirWatch provided the means to check for the existence of a

mobile device firewall for mobile devices that are managed by AirWatch MDM. Device profiles can

be created for approved and registered organization devices with settings to validate the existence

of a firewall solution on the end user’s device. Where endpoint devices lack required endpoint

firewall solutions, AirWatch can be configured to initiate deployment of the organization’s approved

firewall solution. Firewall solutions that are supported can be found from the AirWatch

Marketplace.

A profile can be created for Windows devices with configuration options to enable the Windows

Firewall for those devices that are enrolled with AirWatch MDM. Compliance policies can be

created to check for compliance to the organization’s policy and initiate actions based on

compliance check findings.

Figure 60: MDM Firewall Settings




Another option available for protecting applications and information for remote users is to utilize

the VMware Access Point. Access Point is a gateway device that typically sits in the organization’s

DMZ between remote users and internal resources on the organization’s trusted network. Beyond

service use cases for access to remote desktops and applications with Horizon View, Access Point

was determined to be capable of providing a reverse proxy for VMware Identity Manager and a

secure gateway to AirWatch applications. Access Point provides increased control capability for

critical applications and data.

Summary Result: Supports Control Requirement2

5.13.3(7) “Employ malicious code protection or run a MDM system that facilitates the ability to provide anti-

malware services from the agency level.” (CJIS Information Security Officer, 2016)

Findings: VMware AirWatch was determined to be configuration capable for checking for the

existence of an approved anti-malware service on enrolled devices and per action to require and/or

push installation of the organization’s anti-malware solution.

For Windows devices, VMware AirWatch includes profile settings to enable and set configuration

values for Windows native Anti-Virus capability.

Figure 611: Anti-Virus Configuration Windows Desktop Profile

2 In most cases, the capability to support the requirement is conditional on device supportability. Please refer to product documentation and guidance to determine which devices are suitable for application of policy to enable control relative to policy requirements.





Patching/Updates

5.13.4.1 “Agencies shall monitor mobile devices to ensure their patch and update state is current.” (CJIS


See Findings and Results in 5.13.2 and 5.13.3 above.

Malicious Code Protection

5.13.4.2 “Agencies that allow smartphones and tablets to access CJI shall have a process to approve the

use of specific software or application on the device.” (CJIS Information Security Officer, 2016)

See Findings and Results in 5.13.3 above.

Personal Firewall

5.13.4.3 “A personal firewall shall be employed on all devices that have a full-feature operating system (i.e.

laptops, or tablets with Windows or Linux/Unix operating systems).” (CJIS Information Security Officer,

2016)


Local Device Authentication

5.13.7.1 “When mobile devices are authorized for use in accessing CJI, local device authentication shall

be used to unlock the device for use. The authenticator used shall meet the requirement in section 5.6.2.1

Standard authenticators.” (CJIS Information Security Officer, 2016)


Advanced Authentication

5.13.7.2 “When accessing CJI from an authorized mobile device, advanced authentication shall be used

by the authorized user.” (CJIS Information Security Officer, 2016)


Summary After performing an analysis of VMware’s End User Compute and Mobility Solutions (VMware Workspace

ONE, the configured VMware Validated Design for SDDC, the use cases presented in this document,

layering of organizational workloads, and configurations specific to CJIS Security Policy requirements),

Coalfire validated that the evaluated technical security control capabilities were addressed or addressable

in a manner that supports and conforms to CJIS Security Policy requirements.




Resources http://pubs.vmware.com/accesspoint-27/topic/com.vmware.ICbase/PDF/access-point-27-deploy-config-

guide.pdf

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-validated-

designs-sddc-datasheet-data-sheet.pdf

http://pubs.vmware.com/Release_Notes/en/vvd/30/vmware-validated-design-30-release-notes.html

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-introduction.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-reference-architecture.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-planning-preparation.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-regiona-deployment.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-regionb-deployment.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-distributed-firewall-configuration.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-converged-blueprints-implementation.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-microsegmentation-introduction.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-microsegmentation-reference-architecture.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-microsegmentation-planning-preparation.pdf

https://www.vmware.com/pdf/vmware-validated-design-302-it-automation-scenarios.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmware-nsx-

microsegmentation.pdf?src=vmw_so_vex_cyola_760

http://pubs.vmware.com/accesspoint-27/topic/com.vmware.ICbase/PDF/access-point-27-deploy-config-guide.pdf

http://pubs.vmware.com/accesspoint-27/topic/com.vmware.ICbase/PDF/access-point-27-deploy-config-guide.pdf

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-validated-designs-sddc-datasheet-data-sheet.pdf

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-validated-designs-sddc-datasheet-data-sheet.pdf

http://pubs.vmware.com/Release_Notes/en/vvd/30/vmware-validated-design-30-release-notes.html

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-introduction.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-reference-architecture.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-planning-preparation.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-regiona-deployment.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-regionb-deployment.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-distributed-firewall-configuration.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-sddc-converged-blueprints-implementation.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-microsegmentation-introduction.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-microsegmentation-reference-architecture.pdf

https://www.vmware.com/pdf/vmware-validated-design-30-microsegmentation-planning-preparation.pdf

https://www.vmware.com/pdf/vmware-validated-design-302-it-automation-scenarios.pdf




Acknowledgements VMware would like to recognize the efforts of the VMware product, marketing, legal, and sales teams that

contributed to this paper and to the VMware Compliance and Cyber Risk Solutions Program team. VMware

would also like to recognize Coalfire Systems, Inc., www.coalfire.com/Partners/VMware, and Intel

Corporation, www.intel.com/vmware, for their industry guidance.

Coalfire Systems, Inc., a leading security and compliance advisory and audit firm, provided the guidance

and control interpretation described herein. Intel Corporation and VMware have collaborated for over a

decade to bring optimized and trusted solutions to enterprises worldwide.

About Coalfire Coalfire (Coalfire Systems, Inc.) is the trusted leader in cybersecurity risk management and compliance

services. Coalfire integrates advisory and technical assessments and recommendations to the corporate

directors, executives, boards, and IT organizations for global brands and organizations in the technology,

cloud, healthcare, retail, payments, and financial industries.

Coalfire’s approach addresses each businesses’ specific vulnerability challenges, developing a long-term

strategy to prevent security breaches and data theft. With offices throughout the United State and Europe,

Coalfire was recently named one of the top 20 Most Promising Risk Management Solution

Providers. www.coalfire.com

Disclaimer

*VMware solutions are designed to help organizations address various regulatory compliance requirements. This document is

intended to provide general guidance for organizations that are considering VMware solutions to help them address such

requirements. VMware encourages any organization that is considering VMware solutions to engage appropriate legal,

business, technical, and audit expertise within their specific organization for review of regulatory compliance requirements. It

is the responsibility of each organization to determine what is required to meet any and all requirements. The information

contained in this document is for educational and informational purposes only. This document is not intended to provide legal

advice and is provided “AS IS”. VMware makes no claims, promises or guarantees about the accuracy, completeness, or

adequacy of the information contained herein. Nothing that you read in this document should be used as a substitute for the

advice of an actual Cyber Security auditor or competent legal counsel.

http://www.intel.com/vmware

http://www.coalfire.com/

DOCUMENT TITLE HERE VMWARE VVD FOR SDDC & WORKSPACE ONE COMPLIANCE CAPABLE SOLUTION FOR CJIS 5.5

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com Copyright © 2016 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.