Secure BlueCat root access credentials with CyberArk

Minimizing downtime and securing root access credentials for critical web management tools like DNS, DHCP, and IPAM (DDI) is a critical requirement for any security practitioner.  Every second that queries go unresolved means lost revenue, lost work time, and other serious business impacts.  By definition, the use of root access credentials involves risk.  Appropriate precautions need to be taken in order to ensure that access is not misused.

While the DDI protocols were designed to be redundant for the exact purpose of avoiding downtime, there are other things you can do to keep systems up and running even in the event of a failure. For instance, BlueCat recommends the implementation of failover-friendly architectures like the separation of recursive and authoritative DNS layers. BlueCat also provides various forms of high availability as a feature of its core DDI management platform.

Even after you’ve implemented the standard controls, there is a further level of risk management that goes beyond the DDI features and architectures BlueCat directly uses to minimize downtime.  Occasionally, our customers want to dip into the technological depths of our product to do some routine de-bugging or customization.

Root access to BlueCat DDI solutions

BlueCat provides this “root” access so users can make the changes they need without the hassle (and time) of going through our customer care system.  In comparison, some DDI vendors do not provide root access to its products.  (There is a GUI-based workaround that allows expanded access to certain areas, but it does not grant true root privileges.)  This is a key difference between BlueCat and its main competitor – we offer the flexible, open approach which DDI administrators have come to expect.

While root access is a key benefit of BlueCat over other DDI solutions, it naturally leads to questions about how that root access can be secured and properly managed.  Since root access can be used to make significant changes in how systems work, it is necessary to both control who has that access and monitor how it is used.

Protecting BlueCat root access credentials with CyberArk

Protecting the credentials required for root access also forms a key part of multiple regulatory compliance regimes.  For example, financial institutions adhering to PCI DSS requirement 10 must ensure that all actions taken through a root access password are logged.  Controls on root access are mentioned throughout the NIST 800-53 security standard as well.

CyberArk offers the industry-leading solution for discovering, managing, and securing privileged access. CyberArk’s privileged access solutions protect root access credentials and satisfy compliance requirements around logs associated with their use.  CyberArk holds the root access credentials in an encrypted, tamper-proof vault and is able to provide separate credentials to administrators based on policy.

When these separate credentials are used in a system like BlueCat, CyberArk logs all of the activity and changes in an auditable format. All sessions are automatically recorded, monitored for anomalous use, and stored in the vault. CyberArk also uses real-time threat detection to automatically block known malicious commands, offering further protection against the misuse of this privileged access.

CyberArk has always been able to protect root access credentials in BlueCat’s DDI management solutions.  Recently we made that connection official by joining CyberArk’s C³ Alliance partner program.

Since our main competitor does not allow root access, the vendor does not offer an integration with Cyberark.

How to connect BlueCat to your CyberArk instance

Adding BlueCat to your CyberArk instance is quick and easy.  Here’s how:

Start in the CyberArk web-based interface by selecting “Add Account”.

Then select the “*NIX” system type.

Select “Unix via SSH”.

Select the appropriate Safe – in this case, “BlueCat Appliances”.

Provide the root access credentials to provide CyberArk with initial access.

Clicking on the new account shows additional information. (Note that the account must be verified prior to use.)

Once verified, a user can select the option to “connect” to the appliance account.