Our development team is interested in establishing a password-checkout system in which a shared username/password can be "checked out" of a vault by multiple persons, but our security team is concerned about a lack of accountability. How would you go about validating credential usage? Could you use the IP addresses of users' client devices?
The short answer to approaching a password checkout system is asking the security team to manage the checkout process, but this is normally impractical for large organizations. In reality, this is a two-step process. The first step is the checkout process itself; during which the credentials are stored in some type of enterprise password storage vault, hard token storage, or even written down and sealed in envelopes. Whatever method of retrieval is used, there needs to be a paper trail to indicate who checked out the credentials, the amount of time spent doing so, and, most importantly, why these credentials were needed. Regardless, it’s important to keep in mind that just because the individual had a good reason to check out the credential, this process doesn’t guarantee that’s what the credentials were used for.
This is where a second process for credential validation is needed. This process involves monitoring the credential usage. Once again, there are several ways to do this. I personally would use an enterprise log management system that would allow me to view logs from my systems to detect and report on privileged user activities. However, what I can see depends on the detail of the log file. For example, one log shows what source IP address the privileged user used and the destination IP address and port he or she connected to; something most routers and firewall tools can do as well. Conversely, on a sensitive application server I would turn on fine-grained auditing so the actual commands that were entered by the privileged user are revealed.
Despite all these efforts, monitoring only provides the “evidence” of what occurred. Organizations still need knowledgeable people who can look at this data and say, “Yes, the user who checked out the credential was assigned to do so.” Therefore, enterprises not only need to put a monitoring process in place with the appropriate tools and level of activity monitoring; but more importantly, and sometimes the most difficult part of this process, it’s also necessary to have the knowledge to correlate and make decisions based on whether or not the actions were appropriate for the activity.
In addition to these two processes, it’s important to remember that there are additional security solutions that should be applied. Organizations should limit the number of ways by which privileged users can get into a system. If a development team is coming in remotely to do work, they should be limited to encrypted connections. For example, SSL VPN or IPSec tunnels, or ideally admittance from locally segmented LANS with access only to the development systems, are approaches. This will prevent any potential snoopers on the network ports from capturing the credentials from the privileged users’ sessions. It’s also important to limit when and who can work off-hours, to ensure only trusted and well-vetted administrators are on the network during non-business hours.
It is important to remember that if an organization doesn’t currently have a monitoring tool, there are other ways to monitor the users. The methods decided on all depend on how paranoid an enterprise’s security team is. With the team’s prior knowledge, it’s possible to install a keystroke logging tool to capture input. These former hacker tools are now being used by organizational security personnel to monitor activities on sensitive and privileged accounts. Organizations may also require that fine-grain auditing and logging be turned on for the duration of the session. This approach would be best for long-term access. If an organization is severely paranoid, it’s possible to use the “two-key” process, where two privileged users or the user and a knowledgeable security person sit at a terminal and one does the work while the other monitors all activities.
Finally, not to be forgotten is the principal that, “Good people generally do good things.” The security team should train and work with the organization's development team to emphasize the ideology that, as Spiderman’s uncle put it, “With great power comes great responsibility.”
This was first published in December 2011