CyberArk is a comprehensive cybersecurity platform that offers solutions for a multitude of security issues, including privileged access management (PAM). It provides a secure method to store, rotate, and isolate credentials, as well as monitor and manage privileged access.
CyberArk’s Privileged Access Management (PAM) platform involves several components. Let’s go over each of them in detail:
Vault: The Vault is the secure repository of sensitive credentials and secrets. The Vault’s security is ensured via multiple layers of protection, including encryption, isolation, and robust access controls. The Vault runs on a secure, hardened server with minimal access. It should be installed in a secure and highly available environment since it is the foundation of the PAM solution.
Central Policy Manager (CPM): This component is responsible for password management – it changes, verifies, and reconciles privileged account credentials according to the policy defined in the system. It provides the automated password rotation feature essential for maintaining password security. CPM requires a secure server to run and needs network access to the Vault and the systems it manages passwords for.
Password Vault Web Access (PVWA): This is the main web interface for users and administrators. Users can request and check out passwords, while administrators use PVWA to manage the system and define access policies. PVWA requires a secure web server and needs network access to the Vault. It should be installed in a high-availability configuration to ensure users can always access the system.
Privileged Session Manager (PSM): This component isolates the user workstation environment from the target systems to prevent the direct use of privileged credentials and reduce the risk of credential theft. PSM records all privileged sessions for auditing purposes. PSM requires a secure server and access to the Vault and the PVWA. It needs to be configured in such a way that it can reach all target systems the users need to connect to.
Privileged Threat Analytics (PTA): This is a security intelligence system that analyzes privileged user behavior and provides alerts on high-risk activities. PTA collects data from various sources and uses machine learning algorithms to detect anomalies and potential threats. It requires a server to run and needs access to the Vault and possibly other data sources in your network.
Application Identity Manager (AIM): This component is designed to eliminate the need for hard-coded credentials in applications, scripts, and other non-human identities. It includes two parts:
- A Central Credential Provider, a web service that retrieves credentials from the Vault
- Agents installed on application servers that retrieve credentials from the Central Credential Provider.
AIM needs a server for the Central Credential Provider, and the agents need to be installed on all servers running the AIM applications.
All these components generally require secure and robust servers, ideally in a high-availability configuration. They must be securely networked with proper access controls, and all servers should be regularly patched and monitored for potential security issues. CyberArk also requires a database server (like MS SQL Server) to store its data. Lastly, CyberArk administrators need a good understanding of cybersecurity, networks, and the systems they protect to configure and manage the solution properly.
DATA FLOWS
IIS
An IIS server avoiding the use of passwords in the web.config files:
Let’s assume the IIS server uses CyberArk’s Application Identity Manager (AIM) to avoid using hardcoded credentials in the web.config file.
Step-by-step, the flow would look something like this:
1. An application hosted on the IIS server must authenticate to another system (like a database server).
2. Instead of the application retrieving the credentials from the web.config file, it calls the local CyberArk AIM Agent with a specific identifier for the required credentials.
3. The AIM agent contacts the CyberArk Central Credential Provider (CCP) with the request.
4. The CCP authenticates the AIM Agent and the request, then it contacts the CyberArk Vault to retrieve the required credentials.
5. The Vault retrieves the required credentials and sends them back to the CCP.
6. The CCP sends the credentials back to the AIM Agent.
7. The AIM Agent provides the credentials to the application.
8. The application uses these credentials to authenticate to the other system.
In this scenario, the application never needs to store credentials in the web.config file, which makes the solution more secure and helps maintain regulatory compliance.
AD
Windows AD authenticating users using the CyberArk Vault:
When Active Directory (AD) users are authenticated via CyberArk Vault, the flow will look like this:
1. A user navigates to the CyberArk PVWA (Password Vault Web Access) portal on their web browser.
2. The user enters their AD credentials to log in to the PVWA.
3. The PVWA sends the login request to the CyberArk Vault.
4. The Vault sends the provided credentials to the Active Directory Domain Controller for validation.
5. The Domain Controller verifies the user credentials and sends back a response to the Vault.
6. If the credentials are correct, the Vault acknowledges the successful login and sends a message back to the PVWA.
7. The PVWA grants access to the user based on their assigned permissions.
By centralizing privileged access management, CyberArk provides an extra layer of security, control, and visibility over sensitive credentials.
EXAMPLE IIS AND AIM
Here’s an example of an IIS web.config file that includes configuration settings for integrating CyberArk’s Application Identity Manager (AIM):
{configuration}
{appSettings}
{!-- Other app settings here --}
{add key="VaultFile" value="C:\Path\to\Vault.ini" /}
{add key="GWFile" value="C:\Path\to\GWFile.txt" /}
{add key="HomePage" value="Default.aspx" /}
{add key="CustomerLogoURL" value="https://example.com/logo.png" /}
{add key="ConfigurationCredentialFile" value="C:\Path\to\ConfigurationCredentials.xml" /}
{add key="ConfigurationSafeName" value="MyConfigSafe" /}
{add key="LogFolder" value="C:\Path\to\LogFolder\" /}
{add key="ApplicationID" value="PVWA_Instance1" /}
{add key="FullVersionEnabled" value="Yes" /}
{add key="MobileVersionEnabled" value="Yes" /}
{add key="RSADecodeUserName" value="Yes" /}
{add key="maxRequestLength" value="10000" /}
{add key="executionTimeout" value="90" /}
{add key="AdvancedFIPSCryptography" value="No" /}
{add key="maxJsonLength" value="5000" /}
{add key="PSMConnectionTimeout" value="60" /}
{add key="LoadBalancerClientAddressHeader" value="X-Client-IP" /}
{add key="EnableThrottling" value="No" /}
{add key="MaxCPUUsage" value="90" /}
{add key="MaxRequestPerProcessor" value="8" /}
{add key="NoOfSecondsBetweenSamples" value="15" /}
{add key="MinNoOfFailedConsecutiveSamples" value="8" /}
{!-- AIM related settings --}
{add key="AIMWebServiceURL" value="https://example.com/AIMWebService" /}
{add key="AIMWebServiceTimeout" value="30" /}
{add key="AIMWebServiceProxy" value="None" /}
{/appSettings}
{!-- Other configuration settings here --}
{system.web}
{!-- Other system.web settings here --}
{httpModules}
{add name="AIMHttpModule" type="CyberArk.AIM.WebService.HttpModule, AIMWebService" /}
{/httpModules}
{/system.web}
{system.webServer}
{!-- Other system.webServer settings here --}
{modules}
{add name="AIMHttpModule" type="CyberArk.AIM.WebService.HttpModule, AIMWebService" /}
{/modules}
{/system.webServer}
{/configuration}
In this example, the AIM-related settings are added within the `{appSettings}` section of the web.config file:
• `AIMWebServiceURL`: Specifies the URL of the AIM web service.
• `AIMWebServiceTimeout`: Specifies the timeout value (in seconds) for the AIM web service requests.
• `AIMWebServiceProxy`: Specifies the proxy settings for the AIM web service, if required. Set it to “None” if no proxy is needed.
Additionally, the AIM HTTP module is added to both the `{system.web}` and `{system.webServer}` sections of the web.config file to enable the AIM integration:
• `{httpModules}` section within `{system.web}`: Registers the AIM HTTP module for traditional ASP.NET applications.
• `{modules}` section within `{system.webServer}`: Registers the AIM HTTP module for IIS integrated pipeline mode applications.
Please note that the specific settings and values may vary based on your environment and AIM configuration. Ensure that you update the values accordingly to match your AIM web service URL, timeout, and proxy settings, if applicable.