Protegrity AI Enterprise Edition

• 1: Installation
• 1.1: Overview of installation
• 1.2: System Requirements
• 1.3: Partitioning of Disk on ESA
• 1.4: Installing the ESA
• 1.4.1: Installing the ESA On-Premise
• 1.4.2: Installing ESA on Cloud Platforms
• 1.4.3: Installing ESA on VMware
• 1.4.3.1: Creating an OVA Template
• 1.4.3.2: Creating a Virtual Machine using OVA template
• 1.4.3.3: Installing the ESA on the Virtual Machine
• 1.5: Configuring the ESA
• 1.6: Configuring Load Balancer
• 1.7: Verifying the ESA installation from the Web UI
• 1.8: Initializing the Policy Information Management (PIM) Module
• 1.9: Configuring the ESA in a Trusted Appliances Cluster (TAC)
• 1.10: Creating an Audit Store Cluster
• 2: Configuration
• 2.1: Sending logs to an external security information and event management (SIEM)
• 2.2: Configuring a Trusted Appliance Cluster (TAC) without Consul Integration
• 2.3: Configuring the IP Address for the Docker Interface
• 2.4: Configuring ESA features
• 2.4.1: Rotating Insight certificates
• 2.4.2: Updating the IP address of the ESA
• 2.4.3: Updating the domain name of the ESA
• 2.4.4: Updating the hostname of the ESA
• 2.4.5: Updating Insight custom certificates
• 2.4.6: Removing an ESA from the Audit Store cluster
• 2.5: Identifying the protector version
• 3: Upgrading ESA to v10.2.0
• 3.1: System and License Requirements
• 3.2: Upgrade Paths to ESA v10.2.0
• 3.3: Prerequisites
• 3.4: Upgrading ESA to v10.2.0
• 3.4.1: Upgrading ESA from v9.1.0.x
• 3.4.2: Upgrading ESA from v9.2.0.x
• 3.4.3: Upgrading ESA from v10.0.x
• 3.4.4: Verifying the ESA Patch Installation
• 3.4.5: Verifying the health of Trusted Appliance Cluster
• 3.5: Restoring to the Previous Version of ESA
• 3.5.1: Restoring to the Previous Version of ESA On-premise
• 3.5.2: Restoring to the Previous Version of ESA Cloud platforms
• 3.5.3: Restoring to the Previous Version of ESA VMWare
• 4: Enterprise Security Administrator (ESA)
• 4.1: Protegrity Appliance Overview
• 4.2: Installing ESA
• 4.3: Logging Into ESA
• 4.4: Command-Line Interface (CLI) Manager
• 4.4.1: Accessing the CLI Manager
• 4.4.2: CLI Manager Structure Overview
• 4.4.3: Working with Status and Logs
• 4.4.3.1: Monitoring System Statistics
• 4.4.3.2: Viewing the Top Processes
• 4.4.3.3: Working with System Statistics (SYSSTAT)
• 4.4.3.4: Auditing Service
• 4.4.3.5: Viewing Appliance Logs
• 4.4.3.6: Viewing User Notifications
• 4.4.4: Working with Administration
• 4.4.4.1: Working with Services
• 4.4.4.2: Setting Date and Time
• 4.4.4.3: Managing Accounts and Passwords
• 4.4.4.4: Working with Backup and Restore
• 4.4.4.5: Setting Up the Email Server
• 4.4.4.6: Working with Azure AD
• 4.4.4.6.1: Configuring Azure AD Settings
• 4.4.4.6.2: Enabling/Disabling Azure AD
• 4.4.4.7: Accessing REST API Resources
• 4.4.4.7.1: Using Basic Authentication
• 4.4.4.7.2: Using Client Certificates
• 4.4.4.7.3: Working with JSON Web Token (JWT)
• 4.4.4.7.3.1: Using JWT
• 4.4.4.7.3.2: Generating JWT for REST APIs
• 4.4.4.7.3.3: Refreshing JWT for REST APIs
• 4.4.4.8: Securing the GRand Unified Bootloader
• 4.4.4.8.1: Enabling the Credentials for the GRUB Menu
• 4.4.4.8.2: Disabling the GRUB Credentials
• 4.4.4.9: Working with Installations and Patches
• 4.4.4.9.1: Add/Remove Services
• 4.4.4.9.2: Uninstalling Products
• 4.4.4.9.3: Managing Patches
• 4.4.4.10: Managing LDAP
• 4.4.4.10.1: Working with the Protegrity LDAP Server
• 4.4.4.10.2: Changing the Bind User Password
• 4.4.4.10.3: Working with Proxy Authentication
• 4.4.4.10.4: Configuring Local LDAP Settings
• 4.4.4.10.5: Monitoring Local LDAP
• 4.4.4.10.6: Optimizing Local LDAP Settings
• 4.4.4.11: Rebooting and Shutting down
• 4.4.4.12: Accessing the OS Console
• 4.4.5: Working with Networking
• 4.4.5.1: Configuring Network Settings
• 4.4.5.2: Configuring SNMP
• 4.4.5.2.1: Configuring SNMPv3 as a USM Model
• 4.4.5.2.2: Configuring SNMPv3 as a TSM Model
• 4.4.5.3: Working with Bind Services and Addresses
• 4.4.5.3.1: Binding Interface for Management
• 4.4.5.3.2: Binding Interface for Services
• 4.4.5.4: Using Network Troubleshooting Tools
• 4.4.5.5: Managing Firewall Settings
• 4.4.5.6: Using the Management Interface Settings
• 4.4.5.7: Ports Allowlist
• 4.4.6: Working with Tools
• 4.4.6.1: Configuring the SSH
• 4.4.6.1.1: Specifying SSH Mode
• 4.4.6.1.2: Setting Up Advanced SSH Configuration
• 4.4.6.1.3: Managing SSH Known Hosts
• 4.4.6.1.4: Managing Authorized Keys
• 4.4.6.1.5: Managing Identities
• 4.4.6.1.6: Generating SSH Keys
• 4.4.6.1.7: Configuring the SSH
• 4.4.6.1.8: Customizing the SSH Configurations
• 4.4.6.1.9: Exporting/Importing the SSH Settings
• 4.4.6.1.10: Securing SSH Communication
• 4.4.6.2: Clustering Tool
• 4.4.6.2.1: Creating a TAC using the CLI Manager
• 4.4.6.2.2: Joining an Existing Cluster using the CLI Manager
• 4.4.6.2.3: Cluster Operations
• 4.4.6.2.4: Managing a site
• 4.4.6.2.5: Node Management
• 4.4.6.2.5.1: Show Cluster Nodes and Status
• 4.4.6.2.5.2: Viewing the Cluster Status using the CLI Manager
• 4.4.6.2.5.3: Adding a Remote Node to a Cluster
• 4.4.6.2.5.4: Updating Cluster Information using the CLI Manager
• 4.4.6.2.5.5: Managing Communication Methods for Local Node
• 4.4.6.2.5.6: Managing Local to Remote Node Communication
• 4.4.6.2.5.7: Removing a Node from a Cluster using CLI Manager
• 4.4.6.2.5.8: Uninstalling Cluster Services
• 4.4.6.2.6: Trusted Appliances Cluster
• 4.4.6.2.6.1: Updating Cluster Key
• 4.4.6.2.6.2: Redeploy Local Cluster Configuration to All Nodes
• 4.4.6.2.6.3: Cluster Service Interval
• 4.4.6.2.6.4: Execute Commands as OS Root User
• 4.4.6.3: Working with Xen Paravirtualization Tool
• 4.4.6.4: Working with the File Integrity Monitor Tool
• 4.4.6.5: Rotating Appliance OS Keys
• 4.4.6.6: Managing Removable Drives
• 4.4.6.7: Tuning the Web Services
• 4.4.6.8: Tuning the Service Dispatcher
• 4.4.6.9: Working with Antivirus
• 4.4.6.10: Forwarding system logs to Insight
• 4.4.6.11: Rotating Insight certificates
• 4.4.6.12: Applying Audit Store Security Configuration
• 4.4.6.13: Setting the total memory for the Audit Store Repository
• 4.4.6.14: Forwarding audit logs to Insight
• 4.4.6.15: Exporting alerting configurations
• 4.4.6.16: Importing alerting configurations
• 4.4.7: Working with Preferences
• 4.4.7.1: Viewing System Monitor on OS Console
• 4.4.7.2: Setting Password Requirements for CLI System Tools
• 4.4.7.3: Viewing user notifications on CLI load
• 4.4.7.4: Minimizing the Timing Differences
• 4.4.7.5: Setting a Uniform Response Time
• 4.4.7.6: Limiting Incorrect root Login
• 4.4.7.7: Enabling Mandatory Access Control
• 4.4.7.8: FIPS Mode
• 4.4.7.9: Basic Authentication for REST APIs
• 4.5: Web User Interface (Web UI) Management
• 4.5.1: Working with the Web UI
• 4.5.2: Description of ESA Web UI
• 4.5.3: Working with System
• 4.5.3.1: Working with Services
• 4.5.3.2: Viewing information, statistics, and graphs
• 4.5.3.3: Working with Trusted Appliances Cluster
• 4.5.3.4: Working with Backup and restore
• 4.5.3.4.1: Working with OS Full Backup and Restore
• 4.5.3.4.2: Backing up the data
• 4.5.3.4.3: Backing up custom files
• 4.5.3.4.4: Exporting the custom files
• 4.5.3.4.5: Importing the custom files
• 4.5.3.4.6: Working with the custom files
• 4.5.3.4.7: Restoring configurations
• 4.5.3.4.8: Viewing Export/Import logs
• 4.5.3.5: Scheduling appliance tasks
• 4.5.3.5.1: Viewing the scheduler page
• 4.5.3.5.2: Creating a scheduled task
• 4.5.3.5.3: Scheduling Configuration Export to Cluster Tasks
• 4.5.3.5.4: Deleting a scheduled task
• 4.5.4: Viewing the logs
• 4.5.5: Working with Settings
• 4.5.5.1: Working with Antivirus
• 4.5.5.1.1: Customizing Antivirus Scan Options
• 4.5.5.1.2: Scheduling Antivirus Scan
• 4.5.5.1.3: Updating the Antivirus Database
• 4.5.5.1.4: Working with Antivirus Logs
• 4.5.5.2: Configuring Appliance Two Factor Authentication
• 4.5.5.2.1: Working with Automatic Per-User Shared-Secret
• 4.5.5.2.2: Working with Host-Based Shared-Secret
• 4.5.5.2.3: Working with Remote Authentication Dial-up Service (RADIUS) Authentication
• 4.5.5.2.4: Working with Shared-Secret Lifecycle
• 4.5.5.2.5: Logging in Using Appliance Two Factor Authentication
• 4.5.5.2.6: Disabling Appliance Two Factor Authentication
• 4.5.5.3: Working with Configuration Files
• 4.5.5.4: Working with File Integrity
• 4.5.5.5: Managing File Uploads
• 4.5.5.6: Configuring Date and Time
• 4.5.5.7: Configuring Email
• 4.5.5.8: Configuring Network Settings
• 4.5.5.8.1: Managing Network Interfaces
• 4.5.5.8.2: NIC Bonding
• 4.5.5.9: Configuring Web Settings
• 4.5.5.9.1: General Settings
• 4.5.5.9.2: Session Management
• 4.5.5.9.3: Shell in a box settings
• 4.5.5.9.4: SSL cipher settings
• 4.5.5.9.5: Updating a protocol from the ESA Web UI
• 4.5.5.10: Working with Secure Shell (SSH) Keys
• 4.5.5.10.1: Configuring the authentication type for SSH keys
• 4.5.5.10.2: Configuring inbound communications
• 4.5.5.10.3: Configuring outbound communications
• 4.5.5.10.4: Configuring known hosts
• 4.5.6: Managing Appliance Users
• 4.5.7: Password Policy for all appliance users
• 4.5.7.1: Managing Users
• 4.5.7.1.1: Adding users to internal LDAP
• 4.5.7.1.2: Importing users to internal LDAP
• 4.5.7.1.3: Password policy configuration
• 4.5.7.1.4: Edit users
• 4.5.7.2: Managing Roles
• 4.5.7.3: Configuring the proxy authentication settings
• 4.5.7.4: Working with External Groups
• 4.5.7.5: Configuring the Azure AD Settings
• 4.5.7.5.1: Importing Azure AD Users
• 4.5.7.5.2: Working with External Azure Groups
• 4.6: Trusted Appliances Cluster (TAC)
• 4.6.1: TAC Topology
• 4.6.2: Cluster Configuration Files
• 4.6.3: Deploying Appliances in a Cluster
• 4.6.4: Cluster Security
• 4.6.5: Reinstalling Cluster Services
• 4.6.6: Uninstalling Cluster Services
• 4.6.7: FAQs on TAC
• 4.6.8: Creating a TAC using the Web UI
• 4.6.9: Connection Settings
• 4.6.10: Joining an Existing Cluster using the Web UI
• 4.6.11: Managing Communication Methods for Local Node
• 4.6.12: Viewing Cluster Information
• 4.6.13: Removing a Node from the Cluster using the Web UI
• 4.7: Appliance Virtualization
• 4.7.1: Xen Paravirtualization Setup
• 4.7.1.1: Pre-Conversion Tasks
• 4.7.1.2: Paravirtualization Process
• 4.7.2: Xen Server Configuration
• 4.7.3: Installing Xen Tools
• 4.7.4: Xen Source – Xen Community Version
• 4.8: Appliance Hardening
• 4.8.1: Open listening ports
• 4.9: VMware tools in appliances
• 4.10: Increasing the Appliance Disk Size
• 4.11: Mandatory Access Control
• 4.11.1: Working with profiles
• 4.11.2: Analyzing events
• 4.11.3: AppArmor permissions
• 4.11.4: Troubleshooting for AppArmor
• 4.12: Accessing Appliances using Single Sign-On (SSO)
• 4.12.1: What is Kerberos
• 4.12.1.1: Implementing Kerberos SSO for Protegrity Appliances
• 4.12.1.1.1: Prerequisites
• 4.12.1.1.2: Setting up Kerberos SSO
• 4.12.1.1.3: Logging to the Appliance
• 4.12.1.1.4: Scenarios for Implementing Kerberos SSO
• 4.12.1.1.5: Viewing Logs
• 4.12.1.1.6: Feature Limitations
• 4.12.1.1.7: Troubleshooting
• 4.12.2: What is SAML
• 4.12.2.1: Setting up SAML SSO
• 4.12.2.1.1: Workflow of SAML SSO on an Appliance
• 4.12.2.1.2: Logging on to the Appliance
• 4.12.2.1.3: Implementing SAML SSO on Azure IdP - An Example
• 4.12.2.1.4: Implementing SSO with a Load Balancer Setup
• 4.12.2.1.5: Viewing Logs
• 4.12.2.1.6: Feature Limitations
• 4.12.2.1.7: Troubleshooting
• 4.13: Sample External Directory Configurations
• 4.14: Partitioning of Disk on an Appliance
• 4.14.1: Partitioning the OS in the UEFI Boot Option
• 4.14.2: Partitioning the OS with the BIOS Boot Option
• 4.15: Working with Keys
• 4.16: Working with Certificates
• 4.17: Managing policies
• 4.18: Working with Insight
• 4.18.1: Understanding the Audit Store node status
• 4.18.2: Working with Audit Store nodes
• 4.18.3: Working with Audit Store roles
• 4.18.4: Working with Discover
• 4.18.5: Overview of the dashboards
• 4.18.6: Viewing the dashboards
• 4.18.7: Viewing visualizations
• 4.18.8: Viewing visualization templates
• 4.19: Maintaining Insight
• 4.19.1: Working with alerts
• 4.19.2: Index lifecycle management (ILM)
• 4.19.3: Viewing policy reports
• 4.19.4: Verifying signatures
• 4.19.5: Using the scheduler
• 4.20: Installing Protegrity Appliances on Cloud Platforms
• 4.20.1: Installing ESA on Amazon Web Services (AWS)
• 4.20.1.1: Verifying Prerequisites
• 4.20.1.2: Obtaining the AMI
• 4.20.1.3: Loading the Protegrity Appliance from an Amazon Machine Image (AMI)
• 4.20.1.3.1: Creating an ESA Instance from the AMI
• 4.20.1.3.2: Configuring the Virtual Private Cloud (VPC)
• 4.20.1.3.3: Adding a Subnet to the Virtual Private Cloud (VPC)
• 4.20.1.3.4: Finalizing the Installation of Protegrity Appliance on the Instance
• 4.20.1.3.4.1: Logging to the AWS Instance using the SSH Client
• 4.20.1.3.4.2: Finalizing an AWS Instance
• 4.20.1.4: Backing up and Restoring Data on AWS
• 4.20.1.5: Increasing Disk Space on the Appliance
• 4.20.1.6: Best Practices for Using Protegrity Appliances on AWS
• 4.20.1.7: Running the Appliance-Rotation-Tool
• 4.20.1.8: Working with Cloud-based Applications
• 4.20.1.8.1: Configuring Access for AWS Resources
• 4.20.1.8.2: Working with CloudWatch Console
• 4.20.1.8.2.1: Integrating CloudWatch with Protegrity Appliance
• 4.20.1.8.2.2: Configuring Custom Logs on AWS CloudWatch Console
• 4.20.1.8.2.3: Toggling the CloudWatch Service
• 4.20.1.8.2.4: Reloading the AWS CloudWatch Integration
• 4.20.1.8.2.5: Viewing Logs on AWS CloudWatch Console
• 4.20.1.8.2.6: Working with AWS CloudWatch Metrics
• 4.20.1.8.2.7: Viewing Metrics on AWS CloudWatch Console
• 4.20.1.8.2.8: Disabling AWS CloudWatch Integration
• 4.20.1.8.3: Working with the AWS Cloud Utility
• 4.20.1.8.3.1: Storing Backup Files on the AWS S3 Bucket
• 4.20.1.8.3.2: Set Metrics Based Alarms Using the AWS Management Console
• 4.20.1.8.4: FAQs for AWS Cloud Utility
• 4.20.1.8.5: Working with AWS Systems Manager
• 4.20.1.8.5.1: Setting up AWS Systems Manager
• 4.20.1.8.5.2: FAQs on AWS Systems Manager
• 4.20.1.8.6: Troubleshooting for the AWS Cloud Utility
• 4.20.2: Installing ESA on Google Cloud Platform (GCP)
• 4.20.2.1: Verifying Prerequisites
• 4.20.2.2: Configuring the Virtual Private Cloud (VPC)
• 4.20.2.3: Obtaining the GCP Image
• 4.20.2.4: Converting the Raw Disk to a GCP Image
• 4.20.2.5: Loading the Protegrity ESA Appliance from a GCP Image
• 4.20.2.5.1: Creating a VM Instance from an Image
• 4.20.2.5.2: Creating a VM Instance from a Disk
• 4.20.2.5.3: Accessing the Appliance
• 4.20.2.6: Finalizing the ESA Installation on the Instance
• 4.20.2.7: Deploying the Instance of the Protegrity Appliance with the Protectors
• 4.20.2.8: Backing up and Restoring Data on GCP
• 4.20.2.9: Increasing Disk Space on the Appliance
• 4.20.3: Installing Protegrity Appliances on Azure
• 4.20.3.1: Verifying Prerequisites
• 4.20.3.2: Azure Cloud Utility
• 4.20.3.3: Setting up Azure Virtual Network
• 4.20.3.4: Creating a Resource Group
• 4.20.3.5: Creating a Storage Account
• 4.20.3.6: Creating a Container
• 4.20.3.7: Obtaining the Azure BLOB
• 4.20.3.8: Creating Image from the Azure BLOB
• 4.20.3.9: Creating a VM from the Image
• 4.20.3.10: Accessing the Appliance
• 4.20.3.11: Finalizing the Installation of Protegrity Appliance on the Instance
• 4.20.3.12: Accelerated Networking
• 4.20.3.13: Backing up and Restoring VMs on Azure
• 4.20.3.14: Deploying the ESA Instance with the Protectors
• 4.21: Architectures
• 4.21.1: Logging architecture
• 4.21.2: Overview of the Protegrity logging architecture
• 5: Key Management
• 5.1: Protegrity Key Management
• 5.2: Key Management Web UI
• 5.3: Working with Keys
• 5.4: Key Points for Key Management
• 5.5: Keys-Related Terminology
• 5.6: Key Store Management
• 5.6.1: Support Matrix
• 5.6.2: Configuring the ESA with HSMs supporting PKCS#11 Interface
• 5.6.3: Configuring the ESA with the Thales Luna HSM
• 5.6.4: Configuring the ESA with Thales Data Protection on Demand (DPoD) HSM
• 5.6.5: Configuring the ESA with AWS Key Management System (KMS)
• 5.6.6: Configuring the ESA with Google Cloud KMS
• 5.6.7: Configuring the ESA with Azure Key Vault Managed HSM
• 5.6.8: Switching Key Stores
• 5.6.9: Troubleshooting
• 5.6.10: TAC Replication of Key Store-specific Files and Certificates
• 6: Certificate Management
• 6.1: Certificates in the ESA
• 6.2: Certificate Requirements
• 6.3: Certificate Management in ESA
• 6.3.1: Certificate Repository
• 6.3.2: Uploading Certificates
• 6.3.3: Uploading Certificate Revocation List
• 6.3.4: Manage Certificates
• 6.3.5: Changing Certificates
• 6.3.6: Changing CRL
• 6.4: Certificates in DSG
• 6.5: Replicating Certificates in a Trusted Appliance Cluster
• 6.6: Insight Certificates
• 6.7: Validating Certificates
• 7: Protegrity REST APIs
• 7.1: Accessing the Protegrity REST APIs
• 7.2: View the Protegrity REST API Specification Document
• 7.3: Using the Common REST API Endpoints
• 7.4: Using the Policy Management REST APIs
• 7.5: Using the Encrypted Resilient Package REST APIs
• 8: Protegrity Data Security Platform Licensing
• 8.1: Obtaining a Validated License
• 8.2: Non-Licensed Product
• 8.3: Cluster Licensing
• 9: Troubleshooting
• 9.1: Policy and Key Audit logs
• 9.2: Known issues for the Audit Store
• 9.3: ESA Error Handling
• 9.3.1: ESA Upgrade Readiness Patch Error Messages and Resolutions
• 9.3.2: Common ESA Logs
• 9.3.3: Common ESA Errors
• 9.3.4: Understanding the Insight indexes
• 9.3.5: Understanding the index field values
• 9.3.6: Index entries
• 9.3.7: Log return codes
• 9.3.8: Policy Management Errors
• 9.3.9: Protectors security log codes
• 9.3.10: Additional log information
• 9.4: Known Issues for the td-agent
• 9.5: Known Issues for Protegrity Analytics
• 9.6: Known Issues for the Log Forwarder
• 9.7: Deprecations
• 10: Intellectual Property Attribution Statement
• 11: Policy Management
• 11.1: Protegrity Data Security Methodology
• 11.2: Policy Components
• 11.2.1: Data Elements
• 11.2.1.1: Example - Creating a Token Data Element
• 11.2.1.2: Example - Creating a FPE Data Element
• 11.2.1.3: Example - Creating a Data Element for Unstructured Data
• 11.2.2: Alphabets
• 11.2.3: Masks
• 11.2.3.1: Example - Creating a Mask from a Template
• 11.2.4: Trusted Applications
• 11.2.4.1: Linking Data Store to a Trusted Application
• 11.2.5: Data Stores
• 11.2.5.1: Configuring Allowed Servers
• 11.2.5.2: Export Keys
• 11.2.5.3: Adding Trusted Applications to the Data Store
• 11.2.5.4: Adding Policies to the Data Store
• 11.2.6: Member Sources
• 11.2.6.1: Configuring Member Sources
• 11.2.6.1.1: Configuring Active Directory Member Source
• 11.2.6.1.2: Configuring File Member Source
• 11.2.6.1.3: Configuring LDAP Member Source
• 11.2.6.1.4: Configuring POSIX Member Source
• 11.2.6.1.5: Configuring Azure AD Member Source
• 11.2.6.1.6: Configuring Database Member Source
• 11.2.7: Roles
• 11.2.7.1: Role Refresh Modes
• 11.2.7.2: Adding Members to a Role
• 11.2.7.2.1: Filtering Members in a Role
• 11.2.7.2.1.1: Filtering Members from AD and LDAP Member Sources
• 11.2.7.2.1.2: Filtering Members from Azure AD Member Source
• 11.2.7.3: Managing Members in a Role
• 11.2.7.4: Searching Members
• 11.2.7.5: Searching Member Access
• 11.3: Policy Management
• 11.3.1: Creating Policies
• 11.3.2: Adding Data Elements to Policy
• 11.3.3: Adding Roles to Policy
• 11.3.4: Configuring Policy Permissions
• 11.3.4.1: Permission Conflicts
• 11.3.4.1.1: Inheriting Permissions
• 11.3.5: Deploying Policies
• 11.4: Policy Management Dashboard
• 11.5: Package Deployment
• 11.6: Legacy Features
• 12: Model Architecture
• 12.1: Overview
• 12.2: Model Architecture
• 12.2.1: Deployment with Default Audit Logging Flow to ESA
• 12.2.2: Deployment with Audit Logging Flow to External SIEM
• 12.2.3: Network Architecture Overview
• 12.2.4: Enterprise Security Administrator (ESA)
• 12.2.4.1: Infrastructure Requirements
• 12.2.4.2: Installing and Configuring ESA
• 12.2.4.3: ESA Upgrade Scenarios
• 12.2.4.3.1: Upgrading ESA
• 12.2.4.4: External Keystore Configuration
• 12.2.4.5: Scheduler Tasks
• 12.2.4.6: Backup and Restore
• 12.2.4.7: Insight
• 12.2.5: Recommended Traffic Manager
• 12.2.6: Disaster Recovery
• 12.2.6.1: Promoting Secondary ESA to Primary ESA
• 12.2.7: Fault Tolerance
• 12.2.8: Security
• 12.2.8.1: Open Ports
• 12.2.8.2: Certificate Requirements
• 12.2.8.3: FIPS Compliance Requirements
• 12.2.8.4: Users and Password Policy
• 12.2.8.5: File Integrity Monitoring
• 12.2.8.6: Delete Default System Certificates
• 12.2.8.7: Uninstall Consul
• 12.2.9: Data Security Gateway (DSG)
• 12.2.9.1: Installing and Configuring DSG
• 12.2.9.2: Upgrading ESA with DSG
• 12.2.10: Upgrading ESA with 9.1.0.0/10.x Protectors
• 12.2.11: Upgrading ESA with DSGs and 9.1.0.0/10.x Protectors
• 12.2.12: Standard Protectors
• 12.2.13: Forwarding Logs to External SIEM

1 - Installation

1.1 - Overview of installation

Audience

The installation steps is intended for the following stakeholders:

• Security professionals like security officers who are responsible for protecting business systems in organizations. They plan and ensure execution of security arrangement for their organization.
• System administrators and other technical personnel who are responsible for implementing data security solutions in their organization.
• System Architects who are responsible for providing expert guidance in designing, development and implementation of enterprise data security solution architecture for their business requirements.

Protegrity Data Security Platform

The Protegrity Data Security Platform is a comprehensive source of enterprise data protection solutions. Its design is based on a hub and spoke deployment architecture.

The Protegrity Data Security Platform has following components:

Enterprise Security Administrator (ESA) – that handles the management of policies, keys, monitoring, auditing and reporting of protected systems in the enterprise.

Data Protectors – that protect sensitive data in the enterprise and deploy security policy for enforcement on each installed system. Policy is deployed from ESA to the Data Protectors. The Audit Logs of all activity on sensitive data are reported and stored in the Audit Store cluster on the ESA.

General Overview

The following diagram shows the general overview of various Protegrity products.

1.2 - System Requirements

The following table lists the supported components and their compatibility settings.

The following table lists the minimum hardware configurations.

Certificate Requirements

Certificates are used for secure communication between the ESA and protectors. The certificate-based communication and authentication involves a client certificate, server certificate, and a certifying authority that authenticates the client and server certificates.

The various components within the Protegrity Data Security Platform that communicate with and authenticate each other through digital certificates are:

• ESA Web UI and ESA
• Insight
• ESA and Protectors
• Protegrity Appliances and external REST clients

Protegrity client and server certificates are self-signed by Protegrity. However, these can be replaced by certificates signed by a trusted and commercial CA. These certificates are used for communication between various components in ESA.

Licensing Requirements

Ensure that a valid license is available before upgrading. After migration, if the license status is invalid, then contact Protegrity Support.

1.3 - Partitioning of Disk on ESA

BIOS is amongst the oldest systems used as a boot loader to perform the initialization of the hardware. UEFI is a comparatively newer system that defines a software interface between the operating system and the platform firmware. The UEFI is more advanced than the BIOS and most of the systems are built with support for UEFI and BIOS.

Disk Partitioning is a method of dividing the hard drive into logical partitions. When a new hard drive is installed on a system, the disk is segregated into partitions. These partitions are utilized to store data, which the operating system reads in a logical format. The information about these partitions is stored in the partition table.

There are two types of partition tables, the Master Boot Record (MBR) and the GUID Partition Table (GPT). These form a special boot section in the drive that provides information about the various disk partitions. They help in reading the partition in a logical manner.

Depending on the requirements, the size of the partitions in a physical volume can be extended to accommodate all the logs and other ESA related data. The Logical Volume Manager (LVM) can be utilized to increase the partitions in the physical volume. Using LVM, manage hard disk storage to allocate, mirror, or resize volumes.

In ESA, the physical volume is divided into the following three logical volume groups:

• Partitioning the OS in the UEFI Boot Option

• Partitioning the OS with the BIOS Boot Option

1.4 - Installing the ESA

The ESA appliance can be installed on any of the following platforms.

• On-premise (ISO)
• Cloud platforms
  • Amazon Web Services (AWS)
  • Microsoft Azure
  • Google Cloud Platform (GCP)
• VMWare (OVA)

1.4.1 - Installing the ESA On-Premise

1. Starting the installation

To install the ESA:

1. Insert the ESA installation media in the system disk drive.

2. Boot the system from the disk drive.

   The following screen appears.

   

3. Press ENTER to start the installation.

   The following screen appears.

   

   The system will detect the number of hard drives that are present. If there are multiple hard drives, then it will allow you to choose the hard drive where you want to install the OS partition and the /opt partition.

   If there are multiple hard drives, then the following screen appears.

   

   For storing the operating system-related data, select the hard drive where you want to install the OS partition and select OK.

   The following screen appears.

   

   For storing the logs, configuration data, and so on select the hard drive where you want to install the /opt partition and select OK.

2. Selecting Network Interface Cards (NICs)

The Network Interface Card (NIC) is a device through which appliances, such as, the ESA or the DSG, connect to each other on a network. You can configure multiple network interface cards (NICs) on the appliance.

The ethMNG interface is generally used for managing the appliance and ethSRV interface is used for binding the appliances for using other services.

For example, the appliance can use the ethMNG interface for the ESA Web UI and the ethSRV interface for enabling communication with different applications in an enterprise.

The following task describes how to select management interfaces.

To select multiple NICs:

1. If there are multiple NICs, then the following screen appears.

   

2. Select the required NIC for management interface.

3. Choose Select and press ENTER.

3. Configuring Network Settings

After selecting the NIC for management, you configure the network for the ESA. During the network configuration, the system tries to connect to a DHCP server to obtain the hostname, default gateway, and IP addresses for the ESA. If the DHCP is not available, then you can configure the network information manually.

To configure the network settings:

1. If the DHCP server is configured, then the following screen containing the network information appears.

   

2. If the DHCP server is not available, then the following screen appears.

   

   The Network Configuration Information screen appears.

3. Select Manual and press ENTER.

   The following screen appears.

   

   1. Select DHCP / Static address to configure the DHCP / Static address for the ESA and choose Edit.

   2. Select Static address and choose Update.

   3. If you want to change the hostname of the ESA, then perform the following steps.

      1. Select Hostname and select Edit.
      2. Change the Hostname and select OK.

   4. Select Management IP to configure the management IP address for the ESA and choose Edit.

      

      1. Add the IP address assigned to the ethMNG interface. This IP address configures the ESA to use the Web UI.
      2. Enter the Netmask. The ethMNG interface must be connected to the LAN with this Netmask value.
      3. Select OK.

   5. Select Default Route to configure the default route for the ESA and press Edit.

      

      1. Enter the IP address for the default network traffic.
      2. Select Apply.

   6. Select Domain Name and press Edit.

      

      1. Enter the Domain Name. For example, protegrity.com.
      2. Press Apply.

   7. Select Name Servers and press Edit.

      

      1. Add the IP address of the name server.
      2. Press OK.

   8. If you want to configure the NTP, then perform the following steps.

      1. Select Time Server (NTP), and press Edit.
      2. Add NTP time server on a TCP/IP network.
      3. Select Apply.

4. Select Apply.

   The network settings are configured.

4. Configuring Time Zone

After you configure the network settings, the Time Zone screen appears. This section explains how to set the time zone.

To set the Time Zone:

1. On the Time Zone screen, select the time zone.

   

2. Press Next.

   The time zone is configured.

5. Configuring the Nearest Location

After configuring the time zone, the Nearest Location screen appears.

To Set the Nearest Location:

1. On the Nearest Location screen, enter the nearest location in GMT or UTC.

   

2. Press OK.

   The following screen appears.

   

   This screen also allows you to update the default settings of date and time, keyboard manufacturer, keyboard model, and keyboard layout.

6. Updating the Date and Time

To Update the Date and Time:

1. Press SPACE and select Update date and time.

2. Press ENTER.

   The following screen appears.

   

3. Select the date.

4. Select Set Date and press ENTER.

   The next screen appears.

   

5. Set the time.

6. Click Set Time and press ENTER.

   The date and time settings are configured.

7. Updating the Keyboard Settings

To Update the Keyboard Settings:

1. Select Update Keyboard or Console settings.

2. Press ENTER.

3. Select the vendor and press the SPACEBAR.

   

4. Select Next.

   If you select Generic, then a window with the list of generic keyboard models appears.

5. Select the model you use and press Next.

   

6. On the next window, select the keyboard language. The default is English (US).

   

7. Select Next.

8. On the next window, select the console font. The default is Lat15-Fixed16.

   

9. Press Next.

   A confirmation message appears.

10. Press OK to confirm.

    

8. Configuring GRUB Settings

On the ESA, GRUB version 2 (GRUB2) is used for loading the kernel. If you want to protect the boot configurations, then you can secure it by enforcing a username and password combination for the GRUB menu.

During installation for the ESA on-premise, a screen to configure GRUB credentials appears. If you want to protect the boot configurations, then you can secure it by enforcing a username and password combination for the GRUB menu. While installing the ESA v9.2.0.0, you can secure the GRUB menu by creating a username and setting password as described in the following task.

To configure GRUB settings:

1. From the GRUB Credentials page, press the SPACEBAR to select Enable.

   

   By default the Disable is selected. If you continue to choose Disable, then the security for the GRUB menu is disabled. It is recommended to enable GRUB to secure the ESA.

   You can enable this feature from the CLI Manager after the installation is completed. On the CLI Manager, navigate to Administration > GRUB Credential Settings to enable the GRUB settings.

   For more information about GRUB, refer to the section Securing the GRand Unified Bootloader (GRUB).

2. Select OK.

   The following screen appears.

   

3. Enter a username in the Username text box.

   Note:

   The requirements for the Username are as follows:

   • It should contain a minimum of three and maximum of 16 characters
   • It should not contain numbers and special characters

4. Enter a password in the Password and Re-type Password text boxes.

   Note:

   The requirements for the Password are as follows:

   • It must contain at least eight characters
   • It must contain a combination of alphabets, numbers, and printable characters

5. Select OK and press ENTER.

   A message Credentials for the GRUB menu has been set successfully appears.

   

6. Select OK.

9. Setting up Users and Passwords

Only authorized users can access the ESA. The Protegrity Data Security Platform defines a list of roles for each user who can access the ESA. These are system users and LDAP administrative users who have specific roles and permissions. When you install the ESA, the default users configured are as follows:

• root: Super user with access to all commands and files.
• admin: User with administrative privileges to perform all operations.
• viewer: User who can view, but does not have edit permissions.
• local_admin: Local administrator that can be used when the admin user is not accessible.

After completing the server settings, the Users Passwords screen appears that allows you set the passwords for the users.

To set the LDAP Users Passwords:

1. Add the passwords of the users.

   Note: Ensure that the passwords for the users comply with the password polices.

   For more information about the password policies, refer to the section Password Policy Configuration in the Protegrity Enterprise Security Administrator Guide 9.2.0.0.

2. Select Apply.

   The user passwords are set.

10. Licensing

After the ESA components are installed, the Temporary License screen appears. This system takes time. It is recommended to wait for few minutes before proceeding.

Note: After the ESA is installed, you must apply for a valid license within 30 days.

For more information about licenses, refer Licensing.

11. Installing Products

In the final steps of installing the ESA, you are prompted to select the components to install.

To select products to install:

1. Press space and select the necessary products to install the following products.

   

2. Click OK.

   The selected products are installed.

3. After installation is completed, the following screen appears.

   

4. Select Continue to view the CLI Login screen.

1.4.2 - Installing ESA on Cloud Platforms

This section describes installing the ESA on Cloud platforms, such as, Amazon Web Services (AWS), Azure, or Google Cloud Platform (GCP). For installing the ESA on cloud platforms, you must mount the image containing the ESA on a cloud instance or a virtual machine. After mounting the image, you must run the finalization procedure to install the ESA components.

Installing ESA on AWS

The following steps must be completed to run an ESA on AWS:

1. Verifying the prerequisites.
2. Obtaining the AMI.
3. Creating an instance of the ESA from the AMI.
4. Configuring the various inbound and outbound ports in the VPC.
5. Logging to the AWS instance using the SSH Client.
6. Finalizing the AWS instance.
7. Logging into ESA.

Installing ESA on Azure

The following steps must be completed to run an ESA on Azure:

1. Verifying the prerequisites.
2. Creating a Resource Group.
3. Creating a Storage Account.
4. Creating a Container.
5. Obtaining the Azure BLOB.
6. Create an image from the BLOB.
7. Create a VM from the image.
8. Accessing the ESA.
9. Finalizing the installation of ESA on the instance.
10. Logging into ESA.

Installing ESA on GCP

The following steps must be completed to run an ESA on GCP:

1. Verifying the prerequisites.
2. Configuring the Virtual Private Cloud (VPC).
3. Obtaining the GCP Image.
4. Converting the Raw Disk to a GCP Image.
5. Loading the ESA from a GCP Image.
6. Finalizing the installation of ESA on the instance.
7. Logging into ESA.

1.4.3 - Installing ESA on VMware

This section describes the process to install the ESA using an OVA template.

For more information about the compatible VMware version, refer to the Release Notes of the relevant release.

1.4.3.1 - Creating an OVA Template

Perform the steps to create an Open Virtual Appliance (OVA) template:

1. Log in to the VMware Client console.

2. Navigate to Inventories > VMs and Templates.

3. From the left navigation pane, select the required project.

4. Right-click the project name and select Deploy OVF Template….
   The Deploy OVF Template screen appears.

5. From Select an OVF template, select the preferred method to upload the .ova file.
   The .ova file can be accessed using the URL or by uploading a local file.

6. Click Next.

7. From Select a name and folder, enter the name of the virtual machine in the Virtual machine name field and select the location for virtual machine. Click Next.

8. From Select a destination compute resource, select the required compute resource. Click Next.

9. From Review details, verify the publisher, download size, and size on disk. Click Next.

10. From Select storage, select the required disk formats, VM Storage Policy, Show datastores from Storage DRS clusters, and datastore to store the deployed OVF or OVA template.

11. Click Next.

12. From Select network, select the required network. Click Next.

13. From Ready to complete, verify the details and click Finish.

    This may take sometime to successfully complete the creation of virtual machine. Ensure to proceed only once the virtual machine is created successfully.

14. After the instance is successfully created, from the left navigation pane, select the virtual machine name.

15. Right-click the virtual machine name and select Convert to Template.
    A Confirm Convert dialog box appears.

16. Click Yes.

    The OVA template is successfully created.

1.4.3.2 - Creating a Virtual Machine using OVA template

Perform the steps to create a virtual machine using the OVA template:

1. Navigate to Inventories > VMs and Templates.

2. From the left navigation pane, select the required project.

3. Select the required OVA template.

4. Right-click the template name, and select New VM from This Template.

5. From Select a name and folder, enter the name of the virtual machine in the Virtual machine name field and select the location for virtual machine. Click Next.

6. From Select a destination compute resource, select the required compute resource. Click Next.

7. From Select storage, select the required storage.
   Select the required disk formats, VM Storage Policy, Show datastores from Storage DRS clusters, and datastore to store the deployed OVF or OVA template.

8. Click Next.

9. From Select clone options, select the required clone options.

10. If the Customize the operating option is selected, then the Customize guest OS screen appears.
    Configure the required OS for the virtual machine. Click Next.

11. If the Customize this virtual machine’s hardware option is selected, then the Customize hardware screen appears.
    Configure the required hardware for the virtual machine. Click Next.

12. From Ready to complete, verify the details and click Finish.

    The virtual machine is created successfully.

1.4.3.3 - Installing the ESA on the Virtual Machine

1. Starting the installation

Ensure that the virtual machine is powered on before starting the installation process.

To install the ESA:

1. Select the virtual machine.

2. Click LAUNCH WEB CONSOLE.

2. Configuring Network Settings

After selecting the NIC for management, configure the network for the ESA. During the network configuration, the system tries to connect to a DHCP server to obtain the hostname, default gateway, and IP addresses for the ESA. If the DHCP is not available, then you can configure the network information manually.

To configure the network settings:

1. If the DHCP server is configured, then the screen containing the network information appears.

2. If the DHCP server is not available, then the Network Configuration Information screen appears.

3. Select Manual and press ENTER.

   1. Select DHCP / Static address to configure the DHCP / Static address for the ESA and choose Edit.

   2. Select Static address and choose Update.

   3. If you want to change the hostname of the ESA, then perform the following steps.

      1. Select Hostname and select Edit.
      2. Change the hostname and select OK.

   4. Select Management IP to configure the management IP address for the ESA and select Edit.

      1. Add the IP address assigned to the ethMNG interface. This IP address configures the ESA to use the Web UI.
      2. Enter the Netmask. The ethMNG interface must be connected to the LAN with this Netmask value.
      3. Select OK.

   5. Select Default Route to configure the default route for the ESA and select Edit.

      1. Enter the IP address for the default network traffic.
      2. Select Apply.

   6. Select Domain Name and select Edit.

      1. Enter the domain name. For example, protegrity.com.
      2. Select Apply.

   7. Select Name Servers and select Edit.

      1. Add the IP address of the name server.
      2. Select OK.

   8. To configure the NTP, then perform the following steps.

      1. Select Time Server (NTP), and press Edit.
      2. Add NTP time server on a TCP/IP network.
      3. Select Apply.

4. Select Apply.

   The network settings are configured.

3. Configuring Time Zone

After you configure the network settings, the Time Zone screen appears.

To set the Time Zone:

1. On the Time Zone screen, select the time zone.

2. Select Next.

   The time zone is configured.

4. Configuring the Nearest Location

After configuring the time zone, the Nearest Location screen appears.

To Set the Nearest Location:

1. On the Nearest Location screen, select the nearest location.

2. Select OK.
   The Initial Server Settings screen appears.
   This screen also allows you to update the default settings of date and time, keyboard manufacturer, keyboard model, and keyboard layout.

3. Edit the required settings. Select OK.

5. Updating the Date and Time

To Update the Date and Time:

1. Press SPACE and select Update date and time.

2. Press ENTER.

3. Select the date.

4. Select Set Date and press ENTER.

5. Set the time.

6. Click Set Time and press ENTER.

   The date and time settings are configured.

6. Configuring GRUB Settings

On the ESA, GRUB version 2 (GRUB2) is used for loading the kernel. If you want to protect the boot configurations, then you can secure it by enforcing a username and password combination for the GRUB menu.

During installation for the ESA on-premise, a screen to configure GRUB credentials appears. If you want to protect the boot configurations, then you can secure it by enforcing a username and password combination for the GRUB menu. While installing the ESA, the GRUB menu can be secured by creating a username and setting password as described in the following task.

To configure GRUB settings:

1. From the GRUB Credentials page, press the SPACEBAR to select Enable.

   By default the Disable is selected. If you continue to choose Disable, then the security for the GRUB menu is disabled. It is recommended to enable GRUB to secure the ESA.

   You can enable this feature from the CLI Manager after the installation is completed. On the CLI Manager, navigate to Administration > GRUB Credential Settings to enable the GRUB settings.

   For more information about GRUB, refer to the section Securing the GRand Unified Bootloader (GRUB).

2. Select OK.

3. Enter a username in the Username text box.

   The requirements for the Username are as follows:

   • It should contain a minimum of three and maximum of 16 characters.
   • It should not contain numbers and special characters

4. Enter a password in the Password and Re-type Password text boxes.

   The requirements for the Password are as follows:

   • It must contain at least eight characters.
   • It must contain a combination of alphabets, numbers, and printable characters.

5. Select OK and press ENTER.

   A message Credentials for the GRUB menu has been set successfully appears.

6. Select OK.

7. Setting up Users and Passwords

Only authorized users can access the ESA. The Protegrity Data Security Platform defines a list of roles for each user who can access the ESA. These are system users and LDAP administrative users who have specific roles and permissions. When you install the ESA, the default users configured are as follows:

• root: Super user with access to all commands and files.
• admin: User with administrative privileges to perform all operations.
• viewer: User who can view, but does not have edit permissions.
• local_admin: Local administrator that can be used when the admin user is not accessible.

After completing the server settings, the Users Passwords screen appears that allows you set the passwords for the users.

To set the LDAP user passwords:

1. Add the passwords of the users.

   Ensure that the passwords for the users comply with the password polices.

   For more information about the password policies, refer Password Policy Configuration

2. Select Apply.

   The user passwords are set.

8. Licensing

After the ESA components are installed, the Temporary License screen appears. This screen takes time. It is recommended to wait for few minutes before proceeding.

After the ESA is installed, you must apply for a valid license within 30 days.

For more information about licenses, refer Licensing.

9. Installing Products

In the final steps of installing the ESA, select the components to install.

To select products to install:

1. Press space to select and install the required products.

2. Click OK.

   The selected products are installed.
   After installation is completed, the Welcome to Protegrity Appliance screen appears.

3. Select Continue to view the CLI Login screen.

1.5 - Configuring the ESA

Configuring authentication settings

User authentication is the process of identifying someone who wants to gain access to a resource. A server contains protected resources that are only accessible to authorized users. When accessing any resource on the server, the server uses different authentication mechanism to confirm the identity.

The authentication can be configured using any of the following methods.

• Basic Authentication
• Client Certificates
• JSON Web Token (JWT)
• Proxy Authentication
• Single Sign-On (SSO)

Configuring accounts and passwords

The current password can be changed from the CLI Manager. The CLI Manager includes options to change passwords and permissions for multiple users.

For more information on configuring accounts and passwords, refer to section Accounts and Passwords Management.

Configuring Syslog

The Appliance Logs are available for Protegrity Appliances, such as, the ESA or the DSG. The Appliance Logs tool can be differentiated into appliance common logs and appliance-specific logs. Syslog is a log type that is common for all appliances.

For more information about configuring syslog, refer the section Working with Logs.

Configuring external certificates

External certificates or digital certificates are used to encrypt online communications securely between two entities over the Internet. It is a digitally signed statement that is used to assert the online identities of individuals, computers, and other entities on the network, utilizing the security applications of Public Key Infrastructure (PKI). Public Key Infrastructure (PKI) is the standard cryptographic system that is used to facilitate the secure exchange of information between entities.

For more information on configuring certificates, refer Uploading Certificate Revocation List.

Configuring SMTP

The Simple Mail Transfer Protocol (SMTP) setting allows the system to send emails. An email server can be set up that supports the notification features in Protegrity Reports.

To configure SMTP from Web UI:

1. Login to the ESA.

2. Navigate to Settings > Network.

3. Click the SMTP Settings tab.

   The following screen appears.

   

   For more information about configuring SMTP, refer Email Setup.

Configuring SNMP

Using Simple Network Management Protocol (SNMP), you can query the performance data.

By default, due to security reasons, the SNMP service is disabled. To enable the service and provide its basic configuration (listening address, community string) the SNMP tool available in the CLI Manager can be used.

To initialize SNMP configuration:

1. Login to the CLI Manager.

2. Navigate to Networking > SNMP Configuration.

3. Enter the root password to execute the SNMP configuration and click OK.

   

   The following screen appears.

   

   You can also start the SNMP Service from the Web UI. Navigate to System > Services to start the SNMP service.

   For more information about configuring SNMP, refer Configuring SNMP.

1.6 - Configuring Load Balancer

Deploying ESAs on multiple sites

In case of a fault tolerance architecture, ESAs are deployed at multiple sites. To manage the protector requests towards ESA, ensure that a Layer-4 Proxy or Load Balancer or a DNS Switch is used.

1.7 - Verifying the ESA installation from the Web UI

To verify the ESA installation from the Web UI:

1. Login to the ESA Web UI.

   The ESA dashboard appears.

   

2. Navigate to System > Information.

   The screen displaying the information of your system appears.

3. Under the Installed Patches area, the ESA_10.2.0 entry appears.

4. Navigate to System > Services and ensure that all the required services are running.

1.8 - Initializing the Policy Information Management (PIM) Module

To initialize the PIM module:

1. In a web browser, enter the ESA IP address in the window task bar.

2. Enter the Username and Password.

3. Click Sign in.

   The ESA dashboard appears.

4. Navigate to Policy Management > Dashboard.

   The following screen to initialize PIM appears.

   

5. Click Initialize PIM.

   A confirmation message appears.

6. Click OK.

   The Policy management screen appears.

1.9 - Configuring the ESA in a Trusted Appliances Cluster (TAC)

The following figure illustrates the TAC setup.

1. TAC is established between the primary ESA A and the secondary ESAs, ESA B and ESA C.

   For more information about TAC, refer here.

2. Data replication for policies, forensics, or DSG configuration takes place between all the ESAs.

   For more information about replication tasks, refer here.

3. The Audit Store cluster is enabled for the ESAs.

   For more information about enabling Audit Store Cluster, refer here.

4. All the ESAs are added as a part of the Audit Store Cluster.

   For more information about adding an ESA to the Audit Store Cluster, refer here.

1.10 - Creating an Audit Store Cluster

The Audit Store cluster is a collection of nodes that process and store data. The Audit Store is installed on the ESA nodes. The logs generated by the Appliance, such as, ESA or DSG, and Protector machines are stored in this Audit Store. The logs are useful for obtaining information about the nodes and the cluster on the whole. The logs can also be monitored for any data loss, system compromise, or any other issues with the nodes in the Audit Store cluster.

An Audit Store cluster must have a minimum of three nodes with the Master-eligible role due to following scenarios:

• 1 master-eligible node: If only one node with the Master-eligible role is available, then it is elected the Master, by default. In this case, if the node becomes unavailable due to some failure, then the cluster becomes unstable as there is no additional node with the Master-eligible role.
• 2 master-eligible nodes: A cluster where only two nodes have the Master-eligible role, then both have the Master-eligible role at the minimum to be up and running for the cluster to remain functional. If any one of those nodes becomes unavailable due to some failure, then the minimum condition for the nodes with the Master-eligible role is not met and cluster becomes unstable. This setup is not recommended for a multi-node cluster.
• 3 master-eligible nodes and above: In this case, if any one node goes down, then the cluster can still remain functional because the cluster requires a minimum of two nodes with the Master-eligible role.

Completing the Prerequisites

Ensure that the following prerequisites are met before configuring the Audit Store Cluster. Protegrity recommends that the Audit Store Cluster has a minimum of three ESAs for creating a highly-available multi-node Audit Store cluster.

1. Prepare and set up three ESAs.

2. Create the TAC on the first ESA. This will be the Primary ESA.

3. Add the remaining ESAs to the TAC. These will be the secondary ESAs in the TAC. For more information about installing the ESA, refer here.

Creating the Audit Store Cluster on the ESA

Initialize the Audit Store only on the first ESA or the Primary ESA in the TAC. This also configures Insight to retrieve data from the Audit Store. Additionally, the required processes, such as, td-agent, is started and Protegrity Analytics is initialized. The Audit Store cluster is initialized on the local machine so that other nodes can join this Audit Store cluster.

Perform the following steps to initialize the Audit Store.

1. Log in to the ESA Web UI.

2. Navigate to Audit Store > Initialize Analytics.

   The following screen appears.

   

3. Click Initialize Analytics.

   Protegrity Analytics is now configured and retrieves data for the reports from the Audit Store. The Index Lifecycle Management screen is displayed. The data is available on the Audit Store > Dashboard tab.

   

4. Verify that the following Audit Store services are running by navigating to System > Services:

   • Audit Store Management
   • Audit Store Repository
   • Audit Store Dashboards
   • Analytics
   • td-agent

Adding an ESA to the Audit Store Cluster

Add multiple ESAs to the Audit Store cluster to increase the cluster size. In this case, the current ESA is added as a node in the Audit Store cluster. After the configurations are completed, the required processes are started and the logs are read from the Audit Store cluster.

The Audit Store cluster information is updated when a node joins the Audit Store cluster. This information is updated across the Audit Store cluster. Hence, nodes must be added to an Audit Store cluster one at a time. Adding multiple nodes to the Audit Store at the same time using the ESA Web UI would make the cluster information inconsistent, make the Audit Store cluster unstable, and would lead to errors.

Ensure that the following prerequisites are met:

• Ensure that the SSH Authentication type on all the ESAs is set to Password + PublicKey. For more information about setting the authentication, refer here.
• Ensure that the Audit Store cluster is initialized on the node that must be joined.
• The health status of the target Audit Store node is green or yellow.
• The health status of the Audit Store node that must be added to the cluster is green or yellow.

To check the health status of a node, log in to ESA Web UI of the node, click Audit Store > Cluster Management > Overview, and view the Cluster Status from the upper-right corner of the screen. For more information about the health status, refer here.

1. Log in to the Web UI of the second ESA.

2. Navigate to Audit Store > Initialize Analytics.

   The following screen appears.

   

3. Click Join Cluster.

   The following screen appears.

   

4. Specify the IP address or the hostname of the Audit Store cluster to join. Use hostname only if the hostname is resolved between the nodes.

   Ensure that Protegrity Analytics is initialized and the Audit Store cluster is already created on the target node. A node cannot join the cluster if Protegrity Analytics is not initialized on the target node.

5. Specify the administrator username and password for the Audit Store cluster. If required, select the Clear cluster data check box to clear the Audit Store data from the current node before joining the Audit Store cluster. The check box will only be enabled if the node is a re-purposed ESA and has data, that is, if the Audit Store was earlier installed on the ESA.

Selecting this check box will delete the existing data on the re-purposed ESA before adding it to the Audit Store.

6. Click Join Cluster.

   A confirmation message appears as shown in the following figure.

   

7. Click Dismiss.

   The Index Lifecycle Management screen appears as shown in the following figure.

   

8. Repeat the steps to add the remaining ESAs as required. Add only one ESA at a time. After adding the ESA, wait till the cluster becomes stable. The cluster is stable when the cluster status indicator turns green.

Verifying the Audit Store Cluster

View the Audit Store Management page to verify that the configurations were completed successfully using the steps provided here.

1. Log in to the ESA Web UI.

2. Navigate to the Audit Store > Cluster Management > Overview page.

3. Verify that the nodes are added to the cluster. The health of the nodes must be green.

   

Updating the Priority IP List for Signature Verification

Signature verification jobs run on the ESA and use the ESA’s processing time. Update the priority IP list for the default signature verification jobs after setting up the system. By default, the primary ESA will be used for the priority IP. If there are multiple ESAs in the priority list, then additional ESAs are available to process the signature verifications jobs. This frees up the Primary ESA’s processor to handle other important tasks.

For example, if the maximum jobs to run on an ESA is set to 4 and 10 jobs are queued to run on 2 ESAs, then 4 jobs are started on the first ESA, 4 jobs are started on the second ESA, and 2 jobs will be queued to run till an ESA job slot is free to accept and run the queued job.

For more information about scheduling jobs, refer here.

For more information about signature verification jobs, refer here.

Use the steps provided in this section to update the priority IP list.

1. Log in to the ESA Web UI.

2. Navigate to Audit Store > Analytics > Scheduler.

3. From the Action column, click the Edit icon () for the Signature Verification task.

4. Update the Priority IPs filed with the list of the ESAs available separating the IPs using commas.

5. Click Save.

6. Enter the root password, to apply the updates.

2 - Configuration

2.1 - Sending logs to an external security information and event management (SIEM)

This is an optional step.

The following options are available for forwarding logs from the Protector:

• The default setup, that is, ESA.
• Sending logs to the ESA and a SIEM.

In addition to the ESA or the ESA and a SIEM, logs can be sent to the Amazon CloudWatch. For more information about configuring Amazon CloudWatch, refer to Working with CloudWatch Console.

In the default setup, the logs are sent from the protectors directly to the Audit Store on the ESA using the Log Forwarder on the protector.

For more information about the default flow, refer Logging architecture.

To forward logs to the ESA and the external SIEM, the td-agent is configured to listen for protector logs. The protectors are configured to send the logs to the td-agent on the ESA. Finally, the td-agent is configured to forward the logs to the required locations.

Ensure that the logs are sent to the ESA and the external SIEM using the steps provided in this section. The logs sent to the ESA are required by Protegrity support for troubleshooting the system in case of any issues.

An overview architecture diagram for sending logs to Insight and the external SIEM is shown in the following figure.

Forward the logs generated on the protector to Insight and the external SIEM using the following steps. Ensure that all the steps are completed in the order specified.

1. Set up td-agent to receive protector logs.

2. Send the protector logs to the td-agent.

3. Configure td-agent to forward logs to the external endpoint.

1. Setting up td-agent to receive protector logs

Configure the td-agent to listen to logs from the protectors and to forward the logs received to Insight.

To configure td-agent:

1. Add the port 24284 to the rule list on the ESA. This port is configured for the ESA to receives the protector logs over a secure connection.

   For more information about adding rules, refer Adding a New Rule with the Predefined List of Functionality.

   1. Log in to the CLI Manager of the Primary ESA.

   2. Navigate to Networking > Network Firewall.

   3. Enter the password for the root user.

   4. Select Add New Rule and select Choose.

   5. Select Accept and select Next.

   6. Select Manually.

   7. Select TCP and select Next.

   8. Specify 24284 for the port and select Next.

   9. Select Any and select Next.

   10. Select Any and select Next.

   11. Specify a description for the rule and select Confirm.

   12. Select OK.

2. Open the OS Console on the Primary ESA.

   1. Log in to the CLI Manager of the Primary ESA.

   2. Navigate to Administration > OS Console.

   3. Enter the root password and select OK.

3. Enable td-agent to receive logs from the protector.

   1. Navigate to the config.d directory using the following command.

      cd /opt/protegrity/td-agent/config.d
      

   2. Enable the INPUT_forward_external.conf file using the following command. Ensure that the certificates exist in the directory that is specified in the INPUT_forward_external.conf file. If an IP address or hostname is specified for the bind parameter in the file, then ensure that the certificates are updated to match the host name or IP address specified.

      mv INPUT_forward_external.conf.disabled INPUT_forward_external.conf
      

4. Optional: Update the configuration settings to improve the SSL/TLS server configuration on the system.

   1. Navigate to the config.d directory using the following command.

      cd /opt/protegrity/td-agent/config.d
      

   2. Open the INPUT_forward_external.conf file using a text editor.

   3. Add the list of ciphers to the file. Update and use the ciphers that are required. Enter the entire line of code on a single line and retain the formatting of the file.

      <source>
        @type forward
        bind <Hostname of the Primary ESA>
        port 24284
        <transport tls>  
          ca_path           /mnt/ramdisk/certificates/mng/CA.pem
          cert_path         /mnt/ramdisk/certificates/mng/server.pem
          private_key_path  /mnt/ramdisk/certificates/mng/server.key 
          ciphers "ALL:!aNULL:!eNULL:!SSLv2:!SSLv3:!DHE:!AES256-SHA:!CAMELLIA256-SHA:!AES128-SHA:!CAMELLIA128-SHA:!TLS_RSA_WITH_RC4_128_MD5:!TLS_RSA_WITH_RC4_128_SHA:!TLS_RSA_WITH_3DES_EDE_CBC_SHA:!TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA:!TLS_RSA_WITH_SEED_CBC_SHA:!TLS_DHE_RSA_WITH_SEED_CBC_SHA:!TLS_ECDHE_RSA_WITH_RC4_128_SHA:!TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"
        </transport>
      </source>
      

   4. Save and close the file.

5. Restart the td-agent service.

   1. Log in to the ESA Web UI.

   2. Navigate to System > Services > Misc > td-agent.

   3. Restart the td-agent service.

6. Repeat the steps on all the ESAs in the Audit Store cluster.

2. Sending the protector logs to the td-agent

Configure the protector to send the logs to the td-agent on the ESA or appliance. The td-agent forwards the logs received to Insight and the external location.

To configure the protector:

• 10.x
• 9.2.x and 9.1.x recertified
• 9.1.x

3. Configuring td-agent to forward logs to the external endpoint

As per the setup and requirements, the logs forwarded can be formatted using the syslog-related fields and sent over TLS to the SIEM. Alternatively, send the logs without any formatting over a non-TLS connection to the SIEM, such as, syslog.

The ESA has logs generated by the appliances and the protectors connected to the ESA. Forward these logs to the syslog server and use the log data for further analysis as per requirements.

For a complete list of plugins for forwarding logs, refer to https://www.fluentd.org/plugins/all.

Before you begin: Ensure that the external syslog server is available and running.

The following options are available, select any one of the options based on the requirements:

• Option 1: Forwarding Logs to a Syslog Server
• Option 2: Forwarding Logs to a Syslog Server Over TLS

Option 1: Forwarding Logs to a Syslog Server

To forward logs to the external SIEM:

1. Open the CLI Manager on the Primary ESA.

   1. Log in to the CLI Manager of the Primary ESA where the td-agent was configured in Setting Up td-agent to Receive Protector Logs.

   2. Navigate to Administration > OS Console.

   3. Enter the root password and select OK.

2. Navigate to the /products/uploads directory using the following command.

   cd /products/uploads
   

3. Obtain the required plugins files using one of the following commands based on the setup.

   • If the appliance has Internet access, then run the following commands.

     wget https://rubygems.org/downloads/syslog_protocol-0.9.2.gem
     

     wget https://rubygems.org/downloads/remote_syslog_sender-1.2.2.gem
     

     wget https://rubygems.org/downloads/fluent-plugin-remote_syslog-1.0.0.gem
     

   • If the appliance does not have Internet access, then complete the following steps.

     1. Download the following setup files from a system that has Internet and copy them to the appliance in the /products/uploads directory.
        • syslog_protocol-0.9.2
        • remote_syslog_sender-1.2.2
        • fluent-plugin-remote_syslog-1.0.0
     2. Ensure that the files downloaded have the execute permission.

4. Prepare the required plugins files using the following commands.

   1. Assign the required ownership permissions to the software using the following command.

      chown td-agent *.gem
      

   2. Assign the required permissions to the software installed using the following command.

      chmod -R 755 /opt/td-agent/lib/ruby/gems/3.2.0/
      

   3. Assign ownership of the .gem files to the td-agent user using the following command.

      chown -R td-agent:plug /opt/td-agent/lib/ruby/gems/3.2.0/
      

5. Install the required plugins files using one of the following commands based on the setup.

   • If the appliance has Internet access, then run the following commands.

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install syslog_protocol
     

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install remote_syslog_sender
     

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install fluent-plugin-remote_syslog
     

   • If the appliance does not have Internet access, then run the following commands.

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install --local /products/uploads/syslog_protocol-0.9.2.gem
     

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install install --local /products/uploads/remote_syslog_sender-1.2.2.gem
     

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install --local /products/uploads/fluent-plugin-remote_syslog-1.0.0.gem
     

6. Update the configuration files using the following steps.

• 10.x
• 9.2.x and 9.1.x recertified
• 9.1.x

7. Restart the td-agent service.

   1. Log in to the ESA Web UI.

   2. Navigate to System > Services > Misc > td-agent,

   3. Restart the td-agent service.

8. Repeat the steps on all the ESAs in the Audit Store cluster.

9. Check the status and restart the rsyslog server on the remote SIEM system using the following commands.

   systemctl status rsyslog
   systemctl restart rsyslog
   

The logs are now sent to Insight on the ESA and the external SIEM.

Option 2: Forwarding Logs to a Syslog Server Over TLS

To forward logs to the external SIEM:

1. Open the CLI Manager on the Primary ESA.

   1. Log in to the CLI Manager of the Primary ESA where the td-agent was configured in Setting Up td-agent to Receive Protector Logs.

   2. Navigate to Administration > OS Console.

   3. Enter the root password and select OK.

2. Navigate to the /products/uploads directory using the following command.

   cd /products/uploads
   

3. Obtain the required plugin file using one of the following commands based on the setup.

   • If the appliance has Internet access, then run the following command.

     wget https://rubygems.org/downloads/fluent-plugin-syslog-tls-2.0.0.gem
     

   • If the appliance does not have Internet access, then complete the following steps.

     1. Download the fluent-plugin-syslog-tls-2.0.0.gem set up file from a system that has Internet and copy it to the appliance in the /products/uploads directory.
     2. Ensure that the file downloaded has the execute permission.

4. Prepare the required plugin file using the following commands.

   1. Assign the required ownership permissions to the installer using the following command.

      chown td-agent *.gem
      

   2. Assign the required permissions to the software installation directory using the following command.

      chmod -R 755 /opt/td-agent/lib/ruby/gems/3.2.0/
      

   3. Assign ownership of the software installation directory to the required users using the following command.

      chown -R td-agent:plug /opt/td-agent/lib/ruby/gems/3.2.0/
      

5. Install the required plugin file using one of the following commands based on the setup.

   • If the appliance has Internet access, then run the following command.

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install fluent-plugin-syslog-tls
     

   • If the appliance does not have Internet access, then run the following command.

     sudo -u td-agent /opt/td-agent/bin/fluent-gem install --local /products/uploads/fluent-plugin-syslog-tls-2.0.0.gem
     

6. Copy the required certificates on the ESA or the appliance.

   1. Log in to the ESA or the appliance and open the CLI Manager.

   2. Create a directory for the certificates using the following command.

      mkdir -p /opt/protegrity/td-agent/new_certs
      

   3. Update the ownership of the directory using the following command.

      chown -R td-agent:plug /opt/protegrity/td-agent/new_certs
      

   4. Log in to the remote SIEM system.

   5. Using a command prompt, navigate to the directory where the certificates are located. For example, cd /etc/pki/tls/certs.

   6. Connect to the ESA or appliance using a file transfer manager. For example, sftp root@ESA_IP.

   7. Copy the CA and client certificates to the /opt/Protegrity/td-agent/new_certs directory using the following command.

      put CA.pem /opt/protegrity/td-agent/new_certs
      put client.* /opt/protegrity/td-agent/new_certs
      

   8. Update the permissions of the certificates using the following command.

      chmod -r 744 /opt/protegrity/td-agent/new_certs/CA.pem
      chmod -r 744 /opt/protegrity/td-agent/new_certs/client.pem
      chmod -r 744 /opt/protegrity/td-agent/new_certs/client.key
      

7. Update the configuration files using the following steps.

• 10.x
• 9.2.x and 9.1.x recertified
• 9.1.x

8. Restart the td-agent service.

   1. Log in to the ESA Web UI.

   2. Navigate to System > Services > Misc > td-agent,

   3. Restart the td-agent service.

9. Repeat the steps on all the ESAs in the Audit Store cluster.

10. Check the status and restart the rsyslog server on the remote SIEM system using the following commands.

```
systemctl status rsyslog
systemctl restart rsyslog
```

The logs are now sent to Insight on the ESA and the external SIEM over TLS.

2.2 - Configuring a Trusted Appliance Cluster (TAC) without Consul Integration

For more information about creating a TAC, refer to the section Trusted Appliances Cluster (TAC).

Note: If the node contains scheduled tasks associated with it, then you cannot uninstall the cluster services on it. Ensure that you delete all the scheduled tasks before uninstalling the cluster services.

Note: If you are uninstalling the Consul Integration services, then the Consul related ports and certificates are not required.

To uninstall cluster services, perform the following steps.

1. Remove the appliance from the TAC.

2. In the CLI Manager, navigate to Administration > Add/Remove Services.

3. Press ENTER.

4. Select Remove already installed applications.

5. Select Cluster-Consul-Integration v0.2 and select OK.

   The integration service is uninstalled.

6. Select Consul v1.0 and select OK.

   The Consul product is uninstalled from your appliance.

After the Consul Integration is successfully uninstalled, then the Cluster labels, such as, Consul-Client and Consul-Server are not available.

To manage the communication between various nodes in a TAC, you can use the communication blocking mechanism.

For more information about the communication blocking mechanism, refer to the section Connection Settings.

2.3 - Configuring the IP Address for the Docker Interface

From ESA v9.0.0.0, the default IP addresses assigned to the docker interfaces are between 172.17.0.0/16 and 172.18.0.0/16. If your have a VPN or your organization’s network configured with the IP addresses are between 172.17.0.0/16 and 172.18.0.0/16, then this might cause conflict with your organization’s private or internal network resulting in loss of network connectivity.

Note: Ensure that the IP addresses assigned to the docker interface must not conflict with the organization’s private or internal network.

To verify if there is any IP conflict between docker interface and organization’s private or internal network, run the following command to see the current IP range of the organization’s private or internal network.

ip addr show ethMNG

If the network’s subnet overlaps with Docker’s default range, a conflict exists.

In such a case you can reconfigure the IP addresses for the docker interface by performing the following steps.

To configure the IP address of the docker interfaces:

1. Remove docker_gwbridge network using the following command.

   docker network rm docker_gwbridge
   

2. In the /etc/docker/daemon.json file, enter the non-conflicting IP address range.

   Note:

   You must separate the entries in the daemon.json file using a comma (,). Before adding new entries, ensure that the existing entries are separated by a comma (,). Also, ensure that the entries are enlisted in the correct as shown in the following example .

   "bip": "10.200.0.1/24",
   "default-address-pools":
   [
     {"base":"10.201.0.0/16","size":24}
   ]
   

   Warning:

   If the the entries in the file are not mentioned in the format specified in step 3, then the restart operation for docker service fails.

3. Restart the docker service using the following command.

   /etc/init.d/docker restart
   

   The docker service is restarted successfully.

4. Check the status of the docker service using the following command.

   /etc/init.d/docker status
   

5. Verify the updated IP for the docker service using the following command.

   ip addr show docker0
   

   The IP address of the docker interfaces are changed successfully.

2.4 - Configuring ESA features

2.4.1 - Rotating Insight certificates

These steps are only applicable for the system-generated Protegrity certificate and keys. It is recommended to upload and update custom certificates on the ESA. For updating custom certificates, refer here.

If the ESA Protegrity certificates are rotated, then the Audit Store certificates must be rotated.

• Single-Node Cluster
• Multi-Node Cluster

2.4.2 - Updating the IP address of the ESA

Perform the steps on one system at a time if multiple ESAs must be updated.

Updating the IP address on the Primary ESA

Update the ESA configuration of the Primary ESA. This is the designated ESA that is used to log in for performing all configurations. It is also the ESA that is used to create and deploy policies.

Perform the following steps to refresh the configurations:

1. Recreate the Docker containers using the following steps.

   1. Open the OS Console on the Primary ESA.

      1. Log in to the CLI Manager on the Primary ESA.
      2. Navigate to Administration > OS Console.
      3. Enter the root password.

   2. Stop the containers using the following commands.

      /etc/init.d/asrepository stop
      /etc/init.d/asdashboards stop
      

   3. Remove the containers using the following commands.

      /etc/init.d/asrepository remove
      /etc/init.d/asdashboards remove
      

   4. Update the IP address in the config.yml configuration file.

      1. In the OS Console, navigate to the /opt/protegrity/auditstore/config/security directory.

         cd /opt/protegrity/auditstore/config/security
         

      2. Open the config.yml file using a text editor.

      3. Locate the internalProxies: attribute and update the IP address value for the ESA.

      4. Save and close the file.

   5. Start the containers using the following commands.

      /etc/init.d/asrepository start
      /etc/init.d/asdashboards start
      

2. Update the IP address in the asd_api_config.json configuration file.

   1. In the OS Console, navigate to the /opt/protegrity/insight/analytics/config directory.

      cd /opt/protegrity/insight/analytics/config
      

   2. Open the asd_api_config.json file using a text editor.

   3. Locate the x_forwarded_for attribute and update the IP address value for the ESA.

   4. Save and close the file.

3. Apply security configurations. This step should be performed only once from any node, after all updates have been applied to all nodes in the cluster.

   1. Open the ESA CLI.

   2. Navigate to Tools.

   3. Run Apply Audit Store Security Configs.

4. Monitor the cluster status.

   1. Log in to the Web UI of the Primary ESA.

   2. Navigate to Audit Store > Cluster Management.

   3. Wait till the following updates are visible on the Overview page.

      • The IP address of the Primary ESA is updated.
      • All the nodes are visible in the cluster.
      • The health of the cluster is green.

      Alternatively, monitor the log files for any errors by logging into the ESA Web UI, navigating to Logs > Appliance, and selecting the following files from the Enterprise-Security-Administrator - Event Logs list:

      • insight_analytics
      • asmanagement
      • asrepository

Updating the IP Address on the Secondary ESA

Ensure that the IP address of the ESA has been updated. Perform the steps on one system at a time if multiple ESAs must be updated.

Perform the following steps to refresh the configurations:

1. Recreate the Docker containers using the following steps.

   1. Open the OS Console on the Secondary ESA.

      1. Log in to the CLI Manager on the Secondary ESA.
      2. Navigate to Administration > OS Console.
      3. Enter the root password.

   2. Stop the containers using the following commands.

      /etc/init.d/asrepository stop
      /etc/init.d/asdashboards stop
      

   3. Remove the containers using the following commands.

      /etc/init.d/asrepository remove
      /etc/init.d/asdashboards remove
      

   4. Update the IP address in the config.yml configuration file.

      1. In the OS Console, navigate to the /opt/protegrity/auditstore/config/security directory.

         cd /opt/protegrity/auditstore/config/security
         

      2. Open the config.yml file using a text editor.

      3. Locate the internalProxies: attribute and update the IP address value for the ESA.

      4. Save and close the file.

   5. Start the containers using the following commands.

      /etc/init.d/asrepository start
      /etc/init.d/asdashboards start
      

2. Update the IP address in the asd_api_config.json configuration file.

   1. In the OS Console, navigate to the /opt/protegrity/insight/analytics/config directory.

      cd /opt/protegrity/insight/analytics/config
      

   2. Open the asd_api_config.json file using a text editor.

   3. Locate the x_forwarded_for attribute and update the IP address value for the ESA.

   4. Save and close the file.

3. Apply security configurations. This step should be performed only once from any node, after all updates have been applied to all nodes in the cluster.

   1. Open the ESA CLI.

   2. Navigate to Tools.

   3. Run Apply Audit Store Security Configs.

4. Monitor the cluster status.

   1. Log in to the Web UI of the Primary ESA.

   2. Navigate to Audit Store > Cluster Management.

   3. Wait till the following updates are visible on the Overview page.

      • The IP address of the Secondary ESA is updated.
      • All the nodes are visible in the cluster.
      • The health of the cluster is green.

      Alternatively, monitor the log files for any errors by logging into the ESA Web UI, navigating to Logs > Appliance, and selecting the following files from the Enterprise-Security-Administrator - Event Logs list:

      • insight_analytics
      • asmanagement
      • asrepository

2.4.3 - Updating the domain name of the ESA

Updating the domain name on the Primary ESA

Update the configurations of the Primary ESA. This is the designated ESA that is used to log in for performing all configurations. It is also the ESA that is used to create and deploy policies.

Ensure that the domain name of the ESA has been updated.
In the hostname field, if special characters are to be used, then only hyphen (-) is supported.

Perform the steps on one system at a time if multiple ESAs must be updated.

Perform the following steps to refresh the configurations:

1. Update the domain name in the configuration files.

   1. Open the OS Console on the Primary ESA.

      1. Log in to the CLI Manager on the Primary ESA.
      2. Navigate to Administration > OS Console.
      3. Enter the root password.

   2. Update the repository.json file for the Audit Store configuration.

      1. Navigate to the /opt/protegrity/auditstore/management/config directory.

         cd /opt/protegrity/auditstore/management/config
         

      2. Open the repository.json file using a text editor.

      3. Locate and update the hosts attribute with the new domain name as shown in the following example.

         "hosts": [
             "protegrity-esa123.protegrity.com"
           ]
         

      4. Save and close the file.

   3. Update the repository.json file for the Analytics configuration.

      1. Navigate to the /opt/protegrity/insight/analytics/config directory.

         cd /opt/protegrity/insight/analytics/config
         

      2. Open the repository.json file using a text editor.

      3. Locate and update the hosts attribute with the new domain name as shown in the following example.

         "hosts": [
             "protegrity-esa123.protegrity.com"
           ]
         

      4. Save and close the file.

   4. Update the opensearch.yml file for the Audit Store configuration.

      1. Navigate to the /opt/protegrity/auditstore/config directory.

         cd /opt/protegrity/auditstore/config
         

      2. Open the opensearch.yml file using a text editor.

      3. Locate and update the network.host and the http.host attributes with the new domain name as shown in the following example. If required, uncomment the line by deleting the number sign (#) character at the start of the line.

         ...
         <existing code>
         ...            
         network.host:
         - protegrity-esa123.protegrity.com
         ...
         <existing code>
         ...
         http.host:
         - protegrity-esa123.protegrity.com
         

      4. Save and close the file.

   5. Update the opensearch_dashboards.yml file for the Audit Store Dashboards configuration.

      1. Navigate to the /opt/protegrity/auditstore_dashboards/config directory.

         cd /opt/protegrity/auditstore_dashboards/config
         

      2. Open the opensearch_dashboards.yml file using a text editor.

      3. Locate and update the opensearch.hosts attribute with the new domain name as shown in the following example.

         opensearch.hosts: [ "https://protegrity-esa123.protegrity.com:9201" ]
         

      4. Save and close the file.

   6. Update the OUTPUT.conf file for the td-agent configuration.

      1. Navigate to the /opt/protegrity/td-agent/config.d directory.

         cd /opt/protegrity/td-agent/config.d
         

      2. Open the OUTPUT.conf file using a text editor.

      3. Locate and update the hosts attribute with the new domain name as shown in the following example.

         hosts protegrity-esa123.protegrity.com
         

      4. Save and close the file.

   7. Update the INPUT_forward_external.conf file for the external SIEM configuration. This step is required only if an external SIEM is used.

      1. Navigate to the /opt/protegrity/td-agent/config.d directory.

         cd /opt/protegrity/td-agent/config.d
         

      2. Open the INPUT_forward_external.conf file using a text editor.

      3. Locate and update the bind attribute with the new domain name as shown in the following example.

         bind protegrity-esa123.protegrity.com
         

      4. Save and close the file.

2. Recreate the Docker containers using the following steps.

   1. Open the OS Console on the Primary ESA, if it is not opened.

      1. Log in to the CLI Manager on the Primary ESA.
      2. Navigate to Administration > OS Console.
      3. Enter the root password.

   2. Stop the containers using the following commands.

      /etc/init.d/asrepository stop
      /etc/init.d/asdashboards stop
      

   3. Remove the containers using the following commands.

      /etc/init.d/asrepository remove
      /etc/init.d/asdashboards remove
      

   4. Start the containers using the following commands.

      /etc/init.d/asrepository start
      /etc/init.d/asdashboards start
      

3. Rotate the Audit Store certificates on the Primary ESA. Use the IP address of the local node, which is the Primary ESA and the Lead node, while rotating the certificates.

   For the steps to rotate Audit Store certificates, refer here.

4. Update the unicast_hosts.txt file for the Audit Store configuration.

   1. Open the OS Console on the Primary ESA.

   2. Navigate to the /opt/protegrity/auditstore/config directory using the following command.

      cd /opt/protegrity/auditstore/config
      

   3. Open the unicast_hosts.txt file using a text editor.

   4. Locate and update the domain name.

      protegrity-esa123
      protegrity-esa123.protegrity.com
      

   5. Save and close the file.

5. Monitor the cluster status.

   1. Log in to the Web UI of the Primary ESA.

   2. Navigate to Audit Store > Cluster Management.

   3. Wait till the following updates are visible on the Overview page.

      • The IP address of the Primary ESA is updated.
      • All the nodes are visible in the cluster.
      • The health of the cluster is green.

      It is possible to monitor the log files for any errors by logging into the ESA Web UI, navigating to Logs > Appliance, and selecting the following files from the Enterprise-Security-Administrator - Event Logs list:

      • insight_analytics
      • asmanagement
      • asrepository

Updating the domain name on the Secondary ESA

Update the configurations of the Secondary ESA after the domain name of the ESA has been updated.

Perform the steps on one system at a time if multiple ESAs must be updated.

Perform the following steps to refresh the configurations:

1. Update the domain name in the configuration files.

   1. Open the OS Console on the Secondary ESA.

      1. Log in to the CLI Manager on the Secondary ESA.
      2. Navigate to Administration > OS Console.
      3. Enter the root password.

   2. Update the repository.json file for the Audit Store configuration.

      1. Navigate to the /opt/protegrity/auditstore/management/config directory.

         cd /opt/protegrity/auditstore/management/config
         

      2. Open the repository.json file using a text editor.

      3. Locate and update the hosts attribute with the new domain name as shown in the following example.

         "hosts": [
             "protegrity-esa456.protegrity.com"
           ]
         

      4. Save and close the file.

   3. Update the repository.json file for the Analytics configuration.

      1. Navigate to the /opt/protegrity/insight/analytics/config directory.

         cd /opt/protegrity/insight/analytics/config
         

      2. Open the repository.json file using a text editor.

      3. Locate and update the hosts attribute with the new domain name as shown in the following example.

         "hosts": [
             "protegrity-esa456.protegrity.com"
           ]
         

      4. Save and close the file.

   4. Update the opensearch.yml file for the Audit Store configuration.

      1. Navigate to the /opt/protegrity/auditstore/config directory.

         cd /opt/protegrity/auditstore/config
         

      2. Open the opensearch.yml file using a text editor.

      3. Locate and update the network.host and the http.host attributes with the new domain name as shown in the following example. If required, uncomment the line by deleting the number sign (#) character at the start of the line.

         ...
         <existing code>
         ...
         network.host:
         - protegrity-esa456.protegrity.com
         ...
         <existing code>
         ...
         http.host:
         - protegrity-esa456.protegrity.com
         

      4. Save and close the file.

   5. Update the opensearch_dashboards.yml file for the Audit Store Dashboards configuration.

      1. Navigate to the /opt/protegrity/auditstore_dashboards/config directory.

         cd /opt/protegrity/auditstore_dashboards/config
         

      2. Open the opensearch_dashboards.yml file using a text editor.

      3. Locate and update the opensearch.hosts attribute with the new domain name as shown in the following example.

         opensearch.hosts: [ "https://protegrity-esa456.protegrity.com:9201" ]
         

      4. Save and close the file.

   6. Update the OUTPUT.conf file for the td-agent configuration.

      1. Navigate to the /opt/protegrity/td-agent/config.d directory.

         cd /opt/protegrity/td-agent/config.d
         

      2. Open the OUTPUT.conf file using a text editor.

      3. Locate and update the hosts attribute with the new domain name as shown in the following example.

         hosts protegrity-esa456.protegrity.com
         

      4. Save and close the file.

   7. Update the INPUT_forward_external.conf file for the external SIEM configuration. This step is required only if an external SIEM is used.

      1. Navigate to the /opt/protegrity/td-agent/config.d directory.

         cd /opt/protegrity/td-agent/config.d
         

      2. Open the INPUT_forward_external.conf file using a text editor.

      3. Locate and update the bind attribute with the new domain name as shown in the following example.

         bind protegrity-esa456.protegrity.com
         

      4. Save and close the file.

2. Recreate the Docker containers using the following steps.

   1. Open the OS Console on the Secondary ESA, if it is not opened.

      1. Log in to the CLI Manager on the Secondary ESA.
      2. Navigate to Administration > OS Console.
      3. Enter the root password.

   2. Stop the containers using the following commands.

      /etc/init.d/asrepository stop
      /etc/init.d/asdashboards stop
      

   3. Remove the containers using the following commands.

      /etc/init.d/asrepository remove
      /etc/init.d/asdashboards remove
      

   4. Start the containers using the following commands.

      /etc/init.d/asrepository start
      /etc/init.d/asdashboards start
      

3. Rotate the Audit Store certificates on the Secondary ESA. Perform the steps on the Secondary ESA using the IP address of the Primary ESA, which is the Lead node, for rotating the certificates.

   For the steps to rotate Audit Store certificates, refer here.

4. Update the unicast_hosts.txt file for the Audit Store configuration.

   1. Open the OS Console on the Primary ESA.

   2. Navigate to the /opt/protegrity/auditstore/config directory using the following command.

      cd /opt/protegrity/auditstore/config
      

   3. Open the unicast_hosts.txt file using a text editor.

   4. Locate and update the domain name.

      protegrity-esa456
      protegrity-esa456.protegrity.com
      

   5. Save and close the file.

5. Monitor the cluster status.

   1. Log in to the Web UI of the Primary ESA.

   2. Navigate to Audit Store > Cluster Management.

   3. Wait till the following updates are visible on the Overview page.

      • The IP address of the Secondary ESA is updated.
      • All the nodes are visible in the cluster.
      • The health of the cluster is green.

      Monitor the log files for any errors by logging into the ESA Web UI, navigating to Logs > Appliance, and selecting the following files from the Enterprise-Security-Administrator - Event Logs list:

      • insight_analytics
      • asmanagement
      • asrepository

2.4.4 - Updating the hostname of the ESA

Updating the hostname on the Primary ESA

Update the configurations of the Primary ESA. This is the designated ESA that is used to log in for performing all configurations. It is also the ESA that is used to create and deploy policies.

Ensure that the hostname of the ESA has been updated.
In the hostname field, if special characters are to be used, then only hyphen (-) is supported.

Perform the steps on one system at a time if multiple ESAs must be updated.

Perform the following steps to refresh the configurations:

1. Rotate the Audit Store certificates on the Primary ESA. Use the IP address of the local node, which is the Primary ESA and the Lead node, while rotating the certificates.

   For the steps to rotate Audit Store certificates, refer here.

2. Monitor the cluster status.

   1. Log in to the Web UI of the Primary ESA.

   2. Navigate to Audit Store > Cluster Management.

   3. Wait till the following updates are visible on the Overview page.

      • The IP address of the Primary ESA is updated.
      • All the nodes are visible in the cluster.
      • The health of the cluster is green.

      It is possible to monitor the log files for any errors by logging into the ESA Web UI, navigating to Logs > Appliance, and selecting the following files from the Enterprise-Security-Administrator - Event Logs list:

      • insight_analytics
      • asmanagement
      • asrepository

Updating the hostname on the Secondary ESA

Update the configurations of the Secondary ESA after the hostname of the ESA has been updated.

Perform the steps on one system at a time if multiple ESAs must be updated.

Perform the following steps to refresh the configurations:

1. Rotate the Audit Store certificates on the Secondary ESA. Perform the steps on the Secondary ESA using the IP address of the Primary ESA, which is the Lead node, for rotating the certificates.

   For the steps to rotate Audit Store certificates, refer here.

2. Monitor the cluster status.

   1. Log in to the Web UI of the Primary ESA.

   2. Navigate to Audit Store > Cluster Management.

   3. Wait till the following updates are visible on the Overview page.

      • The IP address of the Secondary ESA is updated.
      • All the nodes are visible in the cluster.
      • The health of the cluster is green.

      Monitor the log files for any errors by logging into the ESA Web UI, navigating to Logs > Appliance, and selecting the following files from the Enterprise-Security-Administrator - Event Logs list:

      • insight_analytics
      • asmanagement
      • asrepository

2.4.5 - Updating Insight custom certificates

These steps are only applicable for custom certificate and keys. For rotating Protegrity certificates, refer here.

For more information about Insight certificates, refer here.

• Single-Node Audit Store Cluster
• Multi-Node Audit Store Cluster

2.4.6 - Removing an ESA from the Audit Store cluster

Before you begin:

• If an external SIEM is configured, ensure that the machine is available and running.
• Verify if the scheduler task jobs are enabled on the ESA using the following steps:
  1. Log in to the ESA Web UI.
  2. Navigate to System > Task Scheduler.
  3. Verify whether the following tasks are enabled on the ESA.
     • Update Policy Status Dashboard
     • Update Protector Status Dashboard

Perform the following steps to remove the ESA node:

1. From the ESA Web UI, click Audit Store > Cluster Management to open the Audit Store clustering page.

   The Overview screen appears.

   

2. Click Leave Cluster.

   A confirmation dialog box appears. The Audit Store cluster information is updated when a node leaves the Audit Store cluster. Hence, nodes must be removed from the Audit Store cluster one at a time. Removing multiple nodes from the Audit Store cluster at the same time using the ESA Web UI would lead to errors.

3. Click YES.

   The ESA is removed from the Audit Store cluster. The Leave Cluster button is disabled and the Join Cluster button is enabled. The process takes time to complete. Stay on the same page and do not navigate to any other page while the process is in progress.

   

4. If the scheduler task jobs were enabled on the ESA that was removed, then enable the scheduler task jobs on another ESA in the Audit Store cluster. These tasks must be enabled on any one ESA in the Audit Store cluster. Enabling on multiple nodes might result in a loss of data.

   1. Log in to the ESA Web UI of any one node in the Audit Store cluster.
   2. Navigate to System > Task Scheduler.
   3. Enable the following tasks by selecting the task, clicking Edit, selecting the Enable check box, and clicking Save.
      • Update Policy Status Dashboard
      • Update Protector Status Dashboard
   4. Click Apply.
   5. Specify the root password and click OK.

After leaving the Audit Store cluster, the configuration of the node and data is reset. The node will be uninitialized. Before using the node again, Protegrity Analytics needs to be initialized on the node or the node needs to be added to another Audit Store cluster.

2.5 - Identifying the protector version

Perform the following steps to identify the PEP server version of the protector:

1. Log in to the ESA.

2. Navigate to Policy Management > Nodes.

3. View the Version field for all the protectors.

3 - Upgrading ESA to v10.2.0

3.1 - System and License Requirements

The following table lists the supported components and their compatibility settings.

The following table lists the minimum hardware configurations.

The following partition spaces must be available.

Software Requirements

Ensure that the software requirements are met before upgrading the appliance.

• The ESAs must be available on one of the following versions.
  • ESA v9.1.0.x
  • ESA v9.2.0.x
  • ESA v10.0.1 + v10.0.2 HF
  • ESA v10.1.0 + v10.1.1 HF
• At least three ESAs must be in a Trusted Appliance Cluster (TAC).
• At least three ESAs must be in the Audit Store Cluster.

Installation Requirements

The ESA_PAP-ALL-64_x86-64_10.2.0.UP.2632.pty patch file is available.

Ensure to download the latest patch for the respective version from the My.Protegrity portal.

For more information about the latest build number and the patch details, refer to the Release Notes of the respective patch.

Licensing Requirements

Ensure that a valid license is available before upgrading. If the license status is invalid, then contact Protegrity Support.

3.2 - Upgrade Paths to ESA v10.2.0

*indicates all the available hotfix and security patches on the platform version.

For example, to upgrade from the ESA v9.0.0.0 to the ESA v10.2.0, install the patches as follows:

1. ESA v9.1.0.x
2. ESA v10.2.0

For more information about upgrading the ESA to v10.2.0, refer Upgrading to v10.2.0.

Before installing any patch, refer to the Release Notes from the My.Protegrity portal.

The following table provides the recommended upgrade paths to the ESA v10.2.0.

To check the current version of the ESA:

1. From the ESA Web UI, navigate to System > Information.
   The current patch installed on the ESA is displayed.
2. Navigate to the About page to view the current version of the ESA.

For more information about:

• Upgrading to previous ESA versions, refer the Upgrade Guide for the respective versions on My.Protegrity portal.
  

• Applying the DSG patch on the ESA, refer Extending ESA with DSG Web UI in the Protegrity Data Security Gateway User Guide for the respective version.

3.3 - Prerequisites

Before you begin

It is recommended to download and run the ESA Readiness patch from the My.Protegrity.com portal. This patch verifies if the ESA satisfies the upgrade requirements.
After applying the ESA Readiness patch, if there are any errors, then ensure these errors must be resolved before applying the Upgrade patch.
For more information about the error Messages and resolutions, refer ESA Upgrade Readiness Patch Error Messages and Resolutions.

After all the conditions from the readiness patch are satisfied, perform the following steps.

Verifying the GPG Public Key

The GPG Public Key used to sign Debian packages embedded in Protegrity appliances expired on April 9, 2024. The appliances installed before this date will continue to function, however issues will occur when upgrading or applying any maintenance patches to these appliances.

To avoid any potential issues, it is recommended to apply the PAP_PAP-ALL-64_x86-64_Generic.V-6.pty patch to extend the expiry date of the GPG Public Key used to sign Debian packages embedded in Protegrity appliances. This patch must be applied before applying maintenance releases or upgrading the ESA.

The following table lists the appliances and the affected versions.

For more information, refer the following GPG Public Key Expiration announcement on My.Protegrity.com portal.

https://my.protegrity.com/notifications/GPG-notification#_New_Installations

Verifying the Presence of DTP/DTP2 Data Elements

If the DTP/DTP2 is present in the algorithm property of a data element while upgrading the ESA to v10.2, then the upgrade script fails. The following error message appears:

ERROR: Found unsupported DTP data elements

Perform the following actions:

1. Reprotect data with a new data element that does not have DTP/DTP2 formatting.
2. Remove the data elements that contain DTP/DTP2 algorithm.

This prevents the data loss that occurs during the upgrade. The DTP/DTP2 data elements are now unsupported.

For more information about the data elements to be used, contact Protegrity Support.

Verifying the Presence of FPE Data Elements with Left and/or Right in Clear Settings

If the format-preserving encryption (FPE) data elements with Left and Right settings are present when you upgrade the ESA to v10.2, then the upgrade script fails. The following error message appears:

ERROR: FPE Data Element(s) with characters in clear ('From Left' / 'From Right') are no longer supported on the target version.  
   Please consult the documentation or Protegrity staff for guidance. 
   Data Element(s) affected: <List of affected data elements>

Perform the following actions:

1. Reprotect data with a new data element that does not have Left and Right settings.
2. Remove the data elements that contain Left and Right settings.

This prevents the data loss that occurs during the upgrade. The FPE data elements with Left and Right settings are now unsupported.

For more information about the data elements to be used, contact Protegrity Support.

Accounts

An account with administrative privileges must be active.

Backup and Restore

The OS backup procedure is performed to backup files, OS settings, policy information, and user information. Ensure that the latest backup is available before upgrading to the latest version.

If the patch installation fails, then you can revert the ESA to a previous version. Ensure to backup the complete OS or export the required files before initiating the patch installation process.

Backup operation must be performed on each ESA. While restoring the ESA using a backup, it must be done using the backup created for the same ESA. Do not use the same backup file to restore multiple ESAs.

Full OS backup

The entire OS must be backed up to prevent data loss. This allows the OS to be reverted to a previous stable configuration in case of a patch installation failure. This option is available only for the on-premise deployments.

The Full OS Backup/Restore features of the Protegrity appliances is available only for the on-premise deployments. It is not available for virtual machines created using an OVA template and cloud-based virtual machines.

Perform the following steps to backup the full OS configuration:

1. Log in to the ESA Web UI.
2. Navigate to System > Backup & Restore > OS Full, to backup the full OS.
3. Click Backup.

The backup process is initiated. After the OS Backup process is completed, a notification message appears on the ESA Web UI Dashboard.

Creating a snapshot for cloud-based services

A snapshot represents a state of an instance or disk at a point in time. Use a snapshot of an instance or a disk to backup and restore information in case of failures. Ensure that the latest snapshot is available before upgrading the ESA.

A snapshot of an instance or a disk can be created on the following platforms:

• Amazon Web Services (AWS)

• Microsoft Azure

• Google Cloud Platform (GCP)

Validating Custom Configuration Files

Complete the following steps if you modified any configuration files.

• Review the contents of any configuration files. Verify that the code in the configuration file is formatted properly. Ensure that there are no additional spaces, tabs, line breaks, or control characters in the configuration file.

• Back up any custom configuration files or modified configuration files. If required, use the backup files to restore settings after the upgrade is complete.

• Validate that the backup files are created with the details appended to the extension, for example, .conf_backup, .conf_bkup123, or .conf_current_build_number.

While using protectors below version 10.x, if any changes are made to the ulimit, then the changes are retained after the ESA upgrade is completed successfully.

Enabling the local_admin Permissions

Ensure to configure the required permissions for the local_admin user.

To change local_admin account permissions:

1. Login to the CLI Manager.

2. Navigate to Administration > Accounts and Passwords > Manage Passwords and Local-Accounts > Change OS local_admin account permissions.

3. In the dialog box displayed, in the Password field, enter the local_admin password.

4. Select OK.

5. Specify the permissions for the local_admin. You can either select SSH Access, Web-Interface Access, or both.

6. Select OK.

External SIEM running

If an external SIEM is configured, ensure that the system is running and reachable during the upgrade.

3.4 - Upgrading ESA to v10.2.0

Before you begin

Ensure that the ESA is upgraded prior to upgrading the protectors.

3.4.1 - Upgrading ESA from v9.1.0.x

When ESA is upgraded from v9.1.0.x, then the process is completed over two phases.
During Phase 1, the Kernel, OS, and other components are upgraded. After the Phase 1 is completed, the system restarts automatically.

After the system restarts, Phase 2 begins automatically and the critical components of ESA are upgraded.

It is recommended to wait for a few minutes before logging in to the ESA using SSH, to view the upgrade progress.

If logging into the system using SSH is attempted immediately after the system restarts, then an error with Invalid Credentials appears. This may occur while LDAP upgrade is in process.

After the upgrade is successful, the system restarts automatically. After the system restarts, log in to the ESA using the CLI Manager or Web UI. When using the SSH, it is recommended to wait for a few minutes before logging in to the ESA.

While upgrading the ESA from v9.1.0.x, the entire process takes approximately 45 minutes. A temporary downtime is expected, resulting in limited access or intermittent interruptions.
Additionally, the time taken for creating the backup depends on the actual size of the data which is being backed up. The time taken for the backup is excluded from the upgrade process.

Uploading the patch using the CLI Manager

Perform the following steps to upload the patch from the CLI Manager:

1. Log in to the ESA CLI Manager with administrator credentials.
2. Navigate to Administration > OS Console to upload the patch.
3. Enter the root password and click OK.
4. Upload the patch to the /products/uploads directory using the FTP or SCP command.