Privileged Identity Management Part 2

What do I want to be able to do in an ideal world?

• handle the administrative rights somehow differently but with the same control environment around them as regular users. I need to implement a user management control environment for the accounts which is able to log changes to them.
• identify which of the administrators used a shared account at a certain time interval.
• visually see what happened during an admin session and I want to be able to search in the commands the admin typed in or used anyhow. I want to log the sessions.
• implement a solution which is as transparent as possible.
• automatically change the passwords for the accounts based on company password policies (maybe there are different policies for the different systems).
• define time intervals in which an admin can log on.
• define one-time passwords for some accounts.
• define accounts which require four-eye provision.
• replace sudo with something which is built-in to the PUM environment.
• create customized reports of access to accounts, systems and commands.
• send and receive email notification and ticketing system integration of some events.
• replace hard-coded passwords in applications to integrate them into the PUM solution.

There are several concepts and solutions for managing administrative accounts but almost everybody suffers somehow, who does not have a specific product for this problem. Some of them try to implement custom software and scripts to manage these and some of them just look at somewhere else when the question arise and try to ignore the problem. And my opinion is that this is not just their fault. The products on the market were developed with a different mindset which was not really based on security. The security functions are implemented just to be able to fulfill some compliance requirements but they are not really help the administration of the admin accounts who are gods in the system. The suggestion of the vendors are: not to use the admin accounts - because they do not want to deal with these kind of issues at the moment. Unfortunately some other vendors (well, not some rather than most of them) does not develop with security in focus so they just say: you will need administrative user account to run this program or service (just think about Oracle in windows, default mysql install in windows…). Perhaps some of them gives the opportunity to configure their product to be secure but the default configurations are not really are. The administrators of these systems are usually overloaded and they are happy if they could install the software to run as expected and do not really have time and affinity to secure it. Security is always a tradeoff and they do not want more problems than they have already.

The general way of things is the audit or the penetration test comes (in the worst case the hacker comes) and reveals some big issues in the configurations which are recommended to be modified. At this point the administrators are usually in a big trouble because they have to read after all settings recommended by the audits and their main task is to keep the systems going. They have to TEST it in a TEST ENVIRONMENT!!! What? Who have that kind of environment? Usually nobody - just the banks. Even they don’t have the identical systems in the test environment or it is even worse when they believe they have and it turns out during the implementation that they were not identical.