Before creating a policy, it is essential to onboard users, devices, and applications as objects into Elisity Cloud Control Center.
Once populated, an administrator will reference these objects in policy logic and group them using policy constructs. Policy constructs, such as Asset Groups, help simplify and scale Elisity policy and will be covered in a later section.
Users are identities that are referenceable objects in Elisity policy for granular security control and, in some cases, also used for remote Elisity Connect client authentication. An administrator can onboard users into Cloud Control Center by several means, including local database, Active Directory, and identity providers (i.e., Okta, Azure Identity).
NOTE: Remote Elisity Connect clients cannot authenticate against users onboarded via Active Directory. Only local databases and Identity providers are supported for remote Elisity Connect client authentication. Only a single identity provider can be enabled at a time. In addition, if you configure Active Directory or an Identity Provider for user onboarding, the local database will be disabled.
Onboarding a user via local database is as simple as navigating to the Users section on the left pane of Cloud Control Center, selecting Onboard User, and then selecting “Add Local User.” Multiple users can be added in bulk through a .xlsx file by selecting “Add Multiple Users.” Fill out the required details, and while optional, it is good practice to define the user’s Department, Title, and Criticality. These three attributes can be leveraged during policy creation for flexible identity-based policies. You can also add the user to an asset group, a construct detailed later in this guide; after filling out the form click Submit.
To onboard a user through Active Directory or an Identity Provider, click the link here to follow our implementation guides.
Once a user has been onboarded, user attributes such as AD groups and Title can be viewed and leveraged in your policy logic by clicking the name. Other information such as how the user was discovered, applied policy, log on and off times, IP addresses, and much more can also be displayed. Lastly, detailed analytics about the user behavior, such as denied flows, policy violations, traffic flows, and login activities, are also provided.
Applications are referenceable objects in Elisity policy and allow an administrator to specify which resources are the relative source and destinations for the policy logic. Three different applications exist in the Elisity platform: pre-defined DPI-based, AWS-based, and custom-defined applications. Elisity pre-defines thousands of applications in Cloud Control Center based on our deep packet inspection engine, which can be used to define the type of application or protocol traffic flow the rule is to match on. AWS deployed applications and their cloud native tag can be dynamically learned and easily leveraged within a policy as sources and destinations. Lastly, custom applications can be manually defined by an administrator and leveraged in policy in a similar fashion to how AWS applications are. Custom applications can live anywhere including on-premise and in the cloud.
You can view all the pre-defined DPI based applications by navigating to the Application section on the left pane of Cloud Control Center. Clicking on an application name exposes more details about the application type, application category, and policy or application analytics.
If your organization hosts applications in AWS cloud, Elisity offers seamless API based automation to connect, discover and onboard those cloud hosted applications into the Elisity fabric.
To onboard AWS hosted applications navigate to the Policy Fabric section on the left pane of Cloud Control Center and select Access Service. At the top right-hand side of the page, select Private Cloud.
Once selected, if no AWS accounts have been integrated, you will be presented with a page to input your AWS account details. Select “Add Account Information” and follow the tool tip instructions to collect and input the required information for Cloud Control Center to integrate with AWS. Click Submit once completed. Cloud Control Center supports the integration of multiple AWS accounts for cross account security and connectivity.
NOTE: The last required field, AWS Account ID is your organization’s AWS account ID, not the ID provided in the tool tip instructions. The latter is used for Role ARN creation only.
Cloud Control Center, via API calls to AWS cloud, will parse all regions and VPCs and present them to you for onboarding. You can navigate through all regions and their respective VPCs by selecting the region name on the left side of the screen.
Select “protect” on the VPC with the applications you want to onboard into Cloud Control Center and then select Review and Submit.
Confirm the submission after reviewing the details.
Cloud Control Center will instantiate an Elisity Cloud Edge within the VPC, modify the route tables and security groups and attract traffic to be placed onto the Elisity fabric so that any Elisity connected entity can access the resource with respect to the deployed security policy. Elisity Cloud Edges can be monitored and managed from Cloud Control Center by navigating to Policy Fabric on the left pane and then by selecting Elisity Edge.
The process can take some time; however, the UI will notify you once onboarding is completed and the VPC will then show as “protected”
After the VPC has been onboarded, all the applications hosted in that VPC will show up under the application section of Cloud Control Center with their instance ID as their name.
TIP: Filter the output to only show AWS and Static applications by selecting “Applications and Static Instances” at the top of the page.
Selecting the instance ID under the name column will open a window with more detail about the AWS application including what policy, if any, it was mapped to, IP addresses, AMI information, and Application Name (cloud native tag). Application Name is a powerful way to reference a cloud hosted application in Elisity policy as Cloud Control Center will immediately recognize changes made to application name when the cloud native tag is modified.
NOTE: For Application Name to populate and be available for consumption when building policy, you must assign a tag to the application in AWS using the following format:
Applications not pre-defined in Cloud Control Center or hosted on AWS cloud can be onboarded manually. When defining a static application, it is important to understand that Cloud Control Center will require that you first configure a “Site”. A “Site” can either be on-premises or in the cloud. The only requirement is that the “Site” has support for terminating a standards-based IPsec tunnel from the Elisity Access Service (EAS). The application is then mapped to the “Site” when defining the application statically so that Elisity knows which IPsec tunnel to forward traffic through to reach the resource.
To configure a Site, first navigate to the Policy Fabric section on the left pane of Cloud Control Center and select Site View. Select “Add Site” and then choose your site type and select next.
Give the site a name and select which Elisity Access Service point-of-presence you want the VPN to be built from. At this point you can also create a new EAS point-of-presence if you would like the VPN built to a location closer to where the application is hosted. Elisity supports both static routing and dynamic routing using BGP. Fill in the required details to build the VPN and select Submit.
After the Site is configured, the VPN tunnel status and learned routes can be viewed and configuration details can be downloaded.
If devices and applications have already been mapped to the site, those details can be viewed by clicking the Devices or Applications tab at the top of the page within the context of the Site View section of Cloud Control Center.
Now that the Site has been configured, you can move on to defining the static application. Navigate to the Applications section of the left pane in Cloud Control Center and then select Add Application or if you wish to onboard multiple applications at the same time you can select Add Multiple Applications.
An application can be identified by its IP Address or Fully Qualified domain name (hostname) or groups of Applications can be identified by the Subnet IP they can be reached at. Fill out the mandatory fields such as Application Name, Onboard by, Site Name, FQDN/IP Address or Subnet Group, and ports. Optionally, you can specify which Asset Group, a policy construct we will go over later in this document, this application should be a part of.
Once the application has been statically defined select the application name in the list of applications to view additional details such as which policies it is associated with, which Site it is mapped to and much more.
Devices are referenceable objects in Elisity policy and allow an administrator to specify which resources are relative source and destinations for the policy logic. The Elisity Cognitive Trust platform provides several ways to onboard devices including dynamic OT/IoT/IoMT discovery, Active Directory, Claroty, and static definition.
Elisity Cloud Control Center has access to a continuously updating catalogue of thousands of devices. If you connect an OT/IoT/IoMT device to the network, through several network layer mechanisms and catalogue mapping, Elisity can dynamically discover what the device is, the manufacturer of the device, the device type, and other metadata that can then be referenced during policy creation.
If your organization wishes to integrate Cloud Control Center with Claroty, a leader in OT discovery and management, to onboard devices, see this link for instructions.
Devices such as PCs and mobile phones can also be discovered through means such as DHCP, HTTP User agent, and Active Directory. Devices connecting into the Elisity fabric via the Elisity Connect client will also be discovered and automatically added to device inventory in Cloud Control Center.
Devices that are not discovered dynamically can be onboarded into Cloud Control Center in a static fashion. To add a static device, navigate to devices section on the left pane of Cloud Control Center and select Onboard Device. Either select Add Device to onboard a single device or Add Multiple Devices to onboard many at the same time.
Fill out the mandatory fields such as Device Name, Onboard by, Site Name, FQDN/IP Address or Subnet Group, and any of the optional attributes such as MAC Address, Device Class and Device type. Optionally, you can specify which Asset Group, a policy construct we will go over later in this document, this device should be a part of. Many of the attributes you can define on a per device basis can be referenced during policy creation for different levels of match criteria granularity.
After you have onboarded a statically defined device you can see all the details about that device by clicking its name.