Why Privileged Passwords, Applications and Scripts Are a Ticking Time Bomb

In my last blog, I discussed the need to discover every privileged password on your network. The process involves looking at all of the obvious places where elevated privileges may be needed – services, directories, daemons, firewalls, etc. Much, if not all, of that discovery is performed on commodity systems, applications, services, and devices, which makes it a bit easier, given scripts, APIs, and privileged password management applications exist to help find privileged password use. But, in the case of custom, in-house applications and scripts, it’s a completely different discussion. While the need to pull the passwords used in under management is the same, it’s difficult, if not impossible, to know where they are being used. Think about it – any member of your IT staff can decide they want to build themselves a script using an admin account and password. Tick… Tock. Tick… Tock. Because they know the password, you really can’t stop it from running rampant. And in the case of custom applications, credentials are hard-coded into applications, shifting the balance of power from IT to the developer completely – you can’t change the password… ever without first getting the developer to modify it in the code. Tick-tock. Tick-tock. Tick-tock. If IT does nothing to change the behavior, these static passwords will get repeatedly used, further lessening IT’s ability to control where that password is stored and used. Eventually, because passwords in scripts and applications are coded in clear text, a quick edit of a script or not so quick reverse engineering of an application will give an unauthorized person the privileged password. Boom. The only way to accomplish managing passwords in scripts is to have a third party solution that first can centrally store the passwords used and, second, has a means by which scripts and applications can call into that store asking for use of that password. By using this kind of solution, you’d accomplish a few things:

• You’ve shifted the balance of power – The scripter or developer no longer has control over the password’s use; IT does.
• You’ve obfuscated the password’s value – By using a programmatic call for the password (assuming some level of security based on IP address, etc.), the password remains completely hidden and only available to the proper machines.
• You can better secure the password – Besides putting the password under management and hiding it, you now can change it as often as policy deems appropriate, keeping that account far more secure than when it remained static and sitting in the open.

While it’s not an easy step to make, bringing privileged passwords within scripts and application under control is necessary. Solutions do exist to replace the credentials themselves with API calls, allowing the writer of the code to have full ability to use the credentials, but without the security mess of them running rampant with the credentials themselves. If you would like to learn best practices on application password management, check out chapter 2 of our new ebook – Six Critical Capabilities of Password Management. There’s more to come!