Proper privilege management is crucial with automation. Automation has the power to perform multiple functions across many different systems. When automation is deployed enterprise-wide, across sometimes siloed teams and functions, enterprise credential management can simplify adoption of automation — even complex authentication processes can be integrated into the setup seamlessly, while adding additional security in managing and handling those credentials.

Depending on how users have defined them, users can craft Ansible Playbooks that require access to credentials and secrets that have wide access to organizational systems. These are necessary to systems and IT resources to accomplish their automation tasks, but they’re also a very attractive target for bad actors. In particular, they are tempting targets for advanced persistent threat (APT) intruders. Gaining access to these credentials could give the attacker the keys to the entire organization.

Most breaches involve stolen credentials, and APT intruders prefer to leverage privileged accounts like administrators, service accounts with domain privileges, and even local admin or privileged user accounts.

You’re probably familiar with the traditional attack flow: compromise an environment, escalate privilege, move laterally, continue to escalate, then own and exfiltrate. It works, but it also requires a lot of work and a lot of time. According to the Mandiant Report, median dwell time for an exploit, while well down from over 400 days in 2011, remained over 50 days in 2019. However, if you can steal privileged passwords or the API keys to a сloud environment, the next step is complete compromise. Put yourself into an attacker’s shoes: what would be more efficient? 

While Ansible Tower, one of the components of Red Hat Ansible Automation Platform, introduced built-in credentials and secret management capabilities, some may have the need for tighter integration with the enterprise management strategy. CyberArk works with Ansible Automation Platform, automating privileged access management (PAM), which involves the policies, processes and tools that monitor and protect privileged users and credentials.

 

Why Privileged Access Management Matters 

Technologies like cloud infrastructure, virtualization and containerization are being adopted by organizations and their development teams alongside DevOps practices that make the need for security practices based on identity and access management critical. Identity and access management isn't just about employees; it includes managing secrets and access granted to applications and infrastructure resources as well.

A PAM solution ideally handles the following key tasks for your organization:

  • Continuously scan an environment to detect privileged accounts and credentials. 
  • Add accounts to a pending list to validate privileges.
  • Perform automated discovery of privileged accounts and credentials.
  • Provide protected control points to prevent credential exposure and isolate critical assets.
  • Record privileged sessions for audit and forensic purposes.
  • View privileged activity by going directly to specified activities and even keystrokes.
  • Detect anomalous behavior aiming to bypass or circumvent privileged controls, and alert SOC and IT admins to such anomalies.
  • Suspend or terminate privileged sessions automatically based on risk score and activity type.
  • Initiate automatic credential rotation based on risk in the case of compromise or theft.

The common theme in the preceding functions is automation. There’s a reason for that: Automation is not just a “nice to have” feature. It’s absolutely essential to PAM. Large organizations may have thousands of resources that need privileged access, and tens of thousands of employees who may need various levels of privilege to get their work done. Even smaller organizations need to monitor and scale privileged access as they grow. Automated PAM solutions handle the trivial aspects of identity and access management so your team can focus on business goals and critical threats. 

Automation is what you use to:

  • Onboard and discover powerful secrets, where you auto-discover secrets, put them in a designated vault and trigger rotation, just to be on the safe side.
  • Apply compliance standards, such as auto-disabling certain network interfaces. 
  • Harden devices via OS- and network-level controls — like blocking SSH connections as root.
  • Track and maintain configurations.

And, of course, automation becomes indispensable in the remediation and response (R&R) stage. When you’re under attack, the absolute worst-case scenario is having to undertake manual R&R. We’ve seen many times — as you probably have — that it puts security and operations teams at odds with each other, and makes both of these look at development as a source of continuous trouble. 

Security can, and should, exist as code. Integrating Ansible with CyberArk implements security-as-code, which allows security, operations and developers to work in sync as your “first responder” group, giving them the time and peace of mind to meaningfully respond to the threat — and likely to find a way to prevent it from recurring.

 

Automatically Respond to Threats

For most teams, keeping a constant watch on every detail of privileged access is unsustainable and hard to scale. The default reaction is often to simply lock down access, making growth and development difficult. PAM automation can make responding to threats much more scalable. Your team can focus on setting identity and access parameters, and let automated tools apply those rules to daily access needs. 

For example, Ansible Automation Platform, working with CyberArk Response Manager (CARM), can respond to threats automatically by managing users, security policies and credentials based on preconfigured parameters. CARM is part of the CyberArk PAM Collection, developed as part of the Ansible security automation initiative. 

At a high level, the CARM algorithm works like this:

1. An event is detected. For example:
  • A user leaves the company
  • User credentials get compromised
  • An email address gets compromised
2. An automated workflow is triggered
3. A credential is retrieved to authenticate CyberArk
4. The relevant module is invoked:
  • cyberark_user
  • cyberark_policy
  • cyberark_account
  • cyberark_credential
5. A remediation is performed through the module

Depending on the specifics of the detected threat and the CyberArk platform configuration, the security action might be to, for example:

  • Reset a user’s credentials or disable the user so that the user must reset their password.
  • Enhance or relax a security policy or workflow.
  • Trigger a credential rotation, in which a vaulted credential is rotated.

As your environment goes about its daily business of deploying, testing and updating payloads, as well as processing and maintaining data, security operators can use Ansible to automatically call CARM  to perform the security actions, and then CARM also performs them automatically. 

Automating threat responses that previously required human intervention now serves as the basis for proactive defense in depth.

Credential retrieval is the first step in many scenarios using Ansible and CARM. This step is performed by the cyberark_credential module of the cyberark.pas Collection. The module can receive credentials from the Central Credential Provider. That way, we can obviate the need to hard code the credential in the environment:

- name: credential retrieval basic
  cyberark_credential:
    api_base_url: "http://10.10.0.1"
    app_id: "TestID"
    query: "Safe=test;UserName=admin"

As can be seen in this example, a target URL needs to be provided in addition to the application ID authorized for retrieving the credential. 

The central parameter is the query: it contains the details of the object actually being queried, in this case the “UserName” and “Safe”. The query parameters depend on the use case, and possible values are “Folder”, “Object”, “Address”, “Database” and “PolicyID”. 

If you are more familiar with the CyberArk API, here is the actual URI request that is created out of these parameter values:

{ api_base_url }"/AIMWebService/api/Accounts?AppId="{ app_id }"&Query="{ query }

The return value of the module contains — among other information — the actual credentials, and can be reused in further automation steps.

A more production-level approach is to also encrypt the communication to the API via client certificates:

- name: credential retrieval advanced
  cyberark_credential:
    api_base_url: "https://components.cyberark.local"
    validate_certs: yes
    client_cert: /etc/pki/ca-trust/source/client.pem
    client_key: /etc/pki/ca-trust/source/priv-key.pem
    app_id: "TestID"
    query: "Safe=test;UserName=admin"
    connection_timeout: 60
    query_format: Exact
    fail_request_on_password_change: True
    reason: "requesting credential for Ansible deployment"

Now, let’s look at an example where the detected “bad” event requires rotation of account credentials. With the help of the cyberark_account module, we can change the credentials of the compromised account. The module supports account object creation, deletion and modification using the PAS Web Services SDK.

    - name: Rotate credential via reconcile and provide new password
      cyberark_account:
        identified_by: "address,username"
        safe: "Domain_Admins"
        address: "prod.cyberark.local"
        username: "admin"
        platform_id: WinDomain
        platform_account_properties:
            LogonDomain: "PROD"
        secret_management:
            new_secret: "Ama123ah12@#!Xaamdjbdkl@#112"
            management_action: "reconcile"
            automatic_management_enabled: true
        state: present
        cyberark_session: "{{ cyberark_session }}"

In this example, we changed the password for the user “admin”. Note that the authentication is handled via the cyberark_session value, which is usually obtained from the  cyberark_authentication module.

 

Next Steps

In this post, you learned how CyberArk and Ansible Automation Platform joined forces to protect privileged accounts, which are the most attractive targets to APT intruders. The integration not only makes your system and data more secure, but it also increases the degree of automation.

If you want to test this solution, install the CyberArk PAS solution and get busy configuring CARM

If you prefer, you can get in touch with CyberArk experts and the Red Hat Ansible team for advice specific to your case. You can schedule a CyberArk demo or CyberArk DNA risk assessment, which provides a detailed view of your environment to help locate privileged accounts and credentials and discover system vulnerabilities you might not otherwise be aware of. You can also download a free Ansible Automation Platform evaluation.

To dive a bit deeper into the Ansible/CyberArk realm on your own, here are some useful resources:


About the author

As Global Director of System Engineering for CyberArk, Brandon Traffanstedt serves as a technical adviser and subject matter expert on privileged access and securing emergent technologies. With over 10 years in the combined spaces of information security, development, and systems engineering, Brandon has architected security solutions for some of CyberArk's largest global customers.

Read full bio