How should privileged accounts be secured in both Linux and Windows?

Question

I have recently started work in application security at a mid-sized firm, having transitioned away from 5+ years in security consulting (pentesting, etc). One of the biggest challenges I see here from the start are that security scanners and other tools use root/Administrator access, since that is what vendors had told them to use, most likely because of the ease of configuration. I really don't like this idea. For instance, Nexpose and Nessus are both configured to use root and Administrator.

My question - What are the best practices in terms of governing access to these privileged accounts? My initial thought is to have a type of password-vault system, that solely knows the passwords to the system. Then, a user can "check out" the root/Administrator password as needed" For Nessus in particular, only a few commands are run as root, so I think it would make sense just to create a standard user, and add it to the sudoers file while only allowing those specific commands.

Thanks!

Answer 1

If you are looking for a centralized group or user manager there are many commercial apps out there to accomplish this.

On your linux boxes disable login as root and make the users log in as themselves. If the box authenticates to LDAP or AD you will have a record of such transactions. You will still need to give that user specific rights on the box. Using sudo once logged into the box also makes auditing and tracking easier.

Not knowing how your company is structured and divided up make the question harder to answer. Security, Server Admins, Application Managers are separate divisions where I am employed. App managers do not have Admin rights to run such tools only Server Admins do. Server Admins while they can add/remove/delete local accounts on a box cannot alter AD/LDAP. Security audits all the servers to obtain what local accounts are on a specific box and need people to justify their use.

Using a generic user login can leave your system wide open with no way to determine who caused the issue. It is better to lock it all down and give access as needed then to assume people will be honest and new screw things up. It is more work for you but it will allow you to sleep better at night. More importantly you have never lived until you find one of your servers has been compromised and the CIO wants to know why.

Answer 2

At the site of my current employer one of the many security measures in place are break glass accounts which can only be accessed using a privileged session monitor that records all activity.

For specific systems the password management of all privileged accounts is handed over to an external password vault application and even the administrators don't know the root/Administrator/DB-owner etc. passwords.

In the cases where the clearly defined RBACs are insufficient and root/Administrator/etc. access is required, the admin requests access, after approval by the security operations team (four eyes principle, audit trail with change/incident number) and via the password vault an SSH or RDP is started with the correct credentials from the vault. The admin does not receive a cleartext copy of the password stored in the vault. The SSH or RDP session can be monitored and is recorded for the desired audit trail. After the session is closed the vault application will change the password again.

Of course the actual security of such procedures depend to large extend on the quality and security consciousness of your configuration management, event monitoring and general maturity of your operations team.

The risk you run (actually the reality) is that resolution of incidents and even scheduled work will take significantly longer, but at least you'll have an excellent audit trail of why so!