These days administrators are under increasing workloads with limited resources to get work done. Thankfully, scripting allows administrators to automate common tasks to meet the rising demand and make life just a bit easier. Coffee helps too, but I digress.
PowerShell to the rescue! Or should I say Stack Overflow to the rescue? We have all downloaded or been inspired by a script found on that site at least once. C’mon, you know it’s true.
Stack Overflow knows this as well—in a 2021 study, Stack Overflow reported that over a two-week period, one-in-four users who viewed a question on the site then copied text within five minutes. Subsequently, 40.6 million copy commands were executed by readers across 7.3 million posts and comments.
This massive number of scripts copied from Stack Overflow readers can’t be good for cybersecurity. Why? Because Microsoft details that bad actors are increasingly focusing on searching public code repositories for exposed credentials. If an administrator simply copies a script from a public forum that includes bad practices such as embedded credentials, the admin could now have unauthorized access to the organization which embedded the credentials.
As a PAM industry leader, Delinea™ is focused on making sure you understand your entire privileged attack surface. So why would administrators or developers alike embed credentials in plain text in the first place?
Let’s answer this question next and examine best practices when embedding authentication in scripts against Delinea’s Secret Server.
Your authentication choices matter
In the real world, customers commonly need to script. For example, one Delinea customer needed to move upwards of 50,000 secrets into specific folders within Secret Server to apply appropriate security policies. The script needs to run each day automatically to find secrets stored in the wrong location within the vault, then move the secrets to the proper location. This is a straightforward process on the surface.
Since the script requires automation, what methods does the administrator have available to authenticate and ensure the script has the proper permissions to execute?
Well, the path of least resistance for the administrator under a time crunch would be to find a sample PowerShell script and hardcode credentials in the script, then move on. Nothing to worry about here since the script will be kept within the internal network. Right?
As with most things, taking the path of least resistance does not produce the best outcome. Remember the Mirai malware?
A common practice by bad actors is to find a way into the front door of an organization by way of social engineering, leveraging MFA fatigue, or purchasing stolen credentials on the dark web. These bad actors then look to move laterally by scanning the internal corporate network to find privileged accounts. In this case, a bad actor would love to find a PowerShell script with embedded credentials that would allow the bad actor to move around an organization’s network undetected.
Here are two fundamental points on password rotation to keep in mind:
Delinea’s Secret Server contains built-in capabilities to update found hard-coded credentials, however, that does not mean this approach mitigates risk.
Let’s dig into Delinea’s recommendations for securely embedding authentication when using a script to run an automated process against Secret Server.
Recommended Authentication Methods
Delinea recommends two methods to address authentication requirements for automated scripts:
- Use Windows Authentication if using on-premises Secret Server
- Use the Secret Server Software Development Kit for DevOps (SDK)
- Other orchestration tools like Chef or Jenkins can be used as well
Both approaches will ensure application passwords or tokens can be vaulted away and force scripts to call the credential from a centralized vault.
Let’s look a closer look at the SDK option as this is the preferred method when scripting against Secret Server. We at Delinea use the SDK method internally for our own Secret Server deployment.
The Preferred Automated Scripting Method: Secret Server Software Development Kit (SDK)
Secret Server customers can leverage the .NET SDK library that uses the Secret Server REST API along with a .NET Core CLI SDK Client. This means as an administrator you can leverage the SDK for a custom application or for scripts that need access to secrets without having to write code to directly access the REST API. Remember, we want to make the administrator’s life easier, not harder.
SDK is the preferred method when scripting because it provides a least privilege approach by:
- Automatically storing the remote server and credentials in an encrypted file used to acquire an OAuth token, as well as configuring an expiration time for the OAuth token. This is critical, with the default expiration time being 20 minutes
- Retrieving a secret from the vault
The SDK Client is a .NET Core console application that is installed on a DevOps machine with a matching set of credentials called SDK Client Accounts. These SDK Client Accounts do not have implicit permissions in Secret Server itself but can be associated with an application user account that is stored in the vault. Note that SDK Client Accounts can only use the REST API and cannot interactively log on to ensure least privilege and zero standing privilege for the identity used.
To further strengthen an organization’s security posture, administrators can allow machines based on IP address. When configured, the SDK will send a REST request. Delinea’s Secret Server then examines the machine’s IP address and the permissions set via a rule set. This process occurs before authenticating the account used when checking out a secret.
Now let’s bring this back to the administrator that wants to move secrets into specific folders within Secret Server to apply appropriate security policies.
The administrator will first need to:
- configure Secret Server to communicate with the SDK
- install the SDK Client
- initialize the SDK Client
- configure your script to call the SDK Client to acquire a token
These steps will ensure that Secret Server validates the information and that the IP address matches any configured restrictions.
Key Takeaways
The steps outlined in this article will go a long way to prevent breaches and bad actors from lateral movement if a credential is compromised.
When properly configured and the human element properly trained on best practices, PAM will ensure secrets are safely vaulted and Just-in-Time (JIT) access implemented.
When scripting against Secret Server, remember to:
- Use MFA everywhere for identities
- Always use an account that has limited permissions
- Never store credentials or tokens in plain text
- Use a service account for application access that is restricted from interactively logging in
- Always set a short expiration period for tokens (default is 20 minutes)
Following these tips will remove the need to rely on standing access and overprivileged credentials, granting machine identities access as required while leveraging secure DevOps practices.
We proudly serve our customers by delivering a resilient PAM platform to increase organizational security all while ensuring administrators have an easy means to mitigate risk through task automation against a robust API. Now, time to find some coffee and relax.
