.NET Web Services and RPAs

ConnectionStrings embedded into web.config and appSettings.json files is a common problem across organisations. More often than not, database credentials are reused across multiple integrations (each time being awarded even more privilege). Eventually the problem becomes that each time the SQL account is reused, the password is written into another config file, making it more and more difficult to ever change. This is a risk most organisations tend to live with.

It is possible, however, to adopt a different approach using Privilege Vault where each integration will have its own unique database account. And, IBM Security Verify Privilege Vault will rotate the password every X days. Under this model, each integration has a unique database account with only enough privileges to do its very specific tasks, allowing you to control access down to the table, column and rows.

While it is possible to re-write your application to interface with Privilege Vault using the SDK to pull the latest password from Privilege Vault each time your application wants to connect to the database, I also recognise that isn’t always a practical approach. Every company has one or more applications you cannot recompile. Or, an integration where change management is tightly controlled and referencing another library or this level of code change would require retesting the whole solution which would be no small undertaking.

With that in mind, I am going to instead focus on options that do not require you to re-write your applications. This allows you to introduce password rotation into your existing applications adding a level of security that wasn’t there previously.

.NET Web Services

Generally these are high volume web services who’s database connections only last as long as the web request. Having C# pull the latest password from Privilege Vault each time will slow your application down considerably as you wait for responses from the Privilege Vault APIs.

Here we can instead use a feature in Privilege Vault called Dependencies (click here). In Privilege Vault dependencies are one or more actions triggered after a remote password change.

In this case, we would use the Remote File (Regex Replace) to update the connection string in the appSettings.json or web.config file. Then use the Application Pool Recycle to recycle the application pool so that the web application pulls the latest connection string from the web.config or appSettings.json file.

Below is an example of the Regex you would use for the Remote File (Regex Replace) step:

"DefaultConnection"(?:[^\n]+)?Server=database.server.name;(?:[^\n]+)?User Id=webAppName-webserver;(?:[^\n]+)?Password=([^\;]+)\;

Ideally you will have the same web service hosted on two web servers for high availability.

This is not a requirement, but you will see in the example above I include the webserver name in the SQL credentials. Personally, I think you should create a SQL account for each web server, and each SQL credential should have a separate rotation schedule a few days apart. A breach on one web server does not impact the other web servers in the cluster. It also means if an issue occurs while rotating your credential, it only impacts a single web server, rather than the whole cluster.

RPAs / Scheduled Tasks

Robotic Process Automations are generally scheduled processes that perform one or more actions almost always developed to integrate one or more systems together. Given that these tend to be the once-per-hour (or less frequent) actions, I’ve seen a number of different approaches taken for secret management for RPAs.

For those where security requirements are extremely high, you could have the initial step in your RPA be to pull the latest password from Privilege Vault, perform the RPA, then the last step is to tell Privilege Vault to rotate the password. This means no password needs to be stored on the host server, because the Privilege Vault CLI is used to pull the latest password at runtime.

Another option would be an approach similar to what we did for Web Services where within Privilege Vault a dependency is used to update the appSettings.json or app.config file(s).

What happens if the password is changed mid-thread?

This is almost always the first push back you receive from developers. In summary, they have a long-running process and they are worried Privilege Vault will change the SQL credentials while their integration is still running.

In short, this isn’t a valid concern.

First, you would schedule the password rotation to happen at a time when your scheduled RPA is not likely to be running.

Secondly (and let’s take Privilege Vault out of the picture for a moment) every integration you develop needs to be fault tolerant. If within your application you are looping through a list of items performing a database update each time, there is always a possibility that the database server can go offline at any time. All integrations need to be developed with this in mind. So, in summary, your response should be that the same error handling developers put in place within their integration to protect it from a fault in the network should also protect you in the very unlikely event that a password is changed in the middle of an RPA. If that doesn’t settle their nerves, you have a bigger problem you need to be concerned about and a code peer review would be a good idea.