Security / Robot managing assets/credentials


#1

Hi all,

We identified the risk that the persons who are managing the assets (credentials for applications) and the persons that manage the credentials of Robot-user, can use these credentials anonymously and login to systems they are not allowed to login to.

I think I can make a Robot that changes his own password (for application or WindowsID) but can the robot update the orchestrator with this new password? So change an asset-value and change the Robot Credentials.

If we can build a robot like that, no human knows the passwords of the robot and there the identified risk is gone.

Hope anybody can help me.

Greets

Robert


Regarding security
#2

@badita @aksh1yadav @ovi


#3

Hello,

if you have a good use of Roles settings in Orchestrator, you should be able to achieve not to allow the Robot Manager to Edit robots credential.
Note that even an Admin will not have access to a Robot Password once it was entered (it will be encrypted and the field value will be hidden.
Same thing applies to Assets Credentials.

If you have a person/services having a specific role (or acces level) responsible for maintaining robot credentials, only this one will “know” the credentials when they will enter them the first time.
Also not that every changes that you be applied to robot configuration/assets should be auditable under the “Audit” Menu option on the top right menu option.

Cheers,


#4

Hi Robert,

First, you cannot make a robot change it’s own values in Orchestrator if it’s connected to Orchestrator(Busy robot cannot be edited). I wouldn’t recommend it because of the dynamic selectors of the web application(but you could try it).

As @Florent_Salendres said, Roles are useful in this case.


#5

Alternatively you can use CyberArk for storing robot credentials. But you’ll end up with the same problem (an admin can retrieve the password). We are considering this for future developments.

@Florent_Salendres answer makes sense. In an enterprise environment you are able to track/audit who changed the password and also what IP have been used to RDP connect to the robot.


#6

Sorry for reviving an old thread, but we’re having pushback on this in our working environment. We were supposed to be getting CyberArk, but that project has been delayed many times.

I understand that the robot credentials can be managed by someone with that role. However, what we’re concerned about is that the person who manages those credentials can now log into the application as the robot - I’m not sure how to prevent that?


#7

Hi,

We managed by dividing the password.

I know part 1, my collegue knows part 2.

Setting up the robot in orchestrator is done by the 2 of us. Once you filled the password and save the credentials, you cannot see them anymore.

In this case, nobody can logon by it’s own. Tou always need 2 people.

This is also approved by the security officers.

Greets

Robert


#8

Thanks for the reply Robert.

How do you stop the person that knows the robots username and password from logging in directly to the applications?

E.g. Person A is responsible for managing the password the robot uses to log in to Application A because the password must be changed every 90 days. What prevents Person A from logging to Application A directly, by using the robot credentials?


#9

We also splitted these passwords.

So we have an asset in orchestrator (credential) with username/password of that application.

When setting the password, 2 people are needed.

When setting the asset, again these 2 people are needed.

Each 90 days there is an action to change the password of the application and changing the asset. (again with 2 people)

What we are planning to do is to make a robot for applications. A robot can change it’s own password for an application AND change the asset in the orchestrator. But then nobody knows the password anymore. If there is something wrong with the robot between setting the new password in the application and changing the asset, you have to reset the password manualy.


#10

Thank you for your patience and multiple replies!

I’m still having trouble wrapping my head around how this works. When you say it requires 2 people, does that mean that the robot has 1 password, composed of 2 parts?

So robot password = Password1234

Person 1 knows the first part “Password” and Person 2 knows the second part “1234”. So both Person 1 and Person 2 physically go on the same computer at the same time to type in the credentials in orchestrator and the application? Then this same process is repeated as needed for new applications or when passwords need to be updated?

What we are planning to do is to make a robot for applications. A robot can change it’s own password for an application AND change the asset in the orchestrator. But then nobody knows the password anymore. If there is something wrong with the robot between setting the new password in the application and changing the asset, you have to reset the password manualy.

This would be ideal, but not sure how to do it either.


#11

Person 1 knows the first part “Password” and Person 2 knows the second part “1234”.

So both Person 1 and Person 2 physically go on the same computer at the same time to type in the credentials in orchestrator and the application? Then this same process is repeated as needed for new applications or when passwords need to be updated?

Yes. This is how we do it now.