A few months ago we installed a burglar alarm in our house. The company sent a trustworthy employee to do the installation, and he set the whole thing up for us. With sensors all over the house, the system even knows when someone opens a door, and can sense the difference between our dog and a burglar - well that is what the man told us and who are we to disagree? Along with the system comes an impressive panel that allows us to switch it on, and off, and do all kinds of clever things. It is all described in the excellent documentation, although we cannot understand how to use it. The biggest challenge is changing the code to get access to switch it off. We did try it once but gave up. Fortunately the helpful engineer set it all up for us so we do not need to worry - or should we?
So, when we go on holiday and switch it on, the friendly company that monitors our house knows that we are away. The taboo topic between my wife and I remains the code. Is the trustworthy employee still employed? We simply do not know.
It seems that we are not alone in this concern about unchanged code. It appears that many, if not all, IT auditors, CSOs, and IT security staff, live daily with the fear of the 'never expiring password' being exposed. It is the unspoken taboo - the wide open back door in every corporate network today, affecting every business-critical application.
When, for example, a user accesses a web-based application through a portal, a lot of activity takes place behind the scenes to present information to the user. This information is stored on systems and databases in your organisation. In order to access these resources, the portal uses service accounts created on the systems.
The door is wide open
The challenge of securing, managing and sharing the service accounts is a major issue for IT departments in your organisation. The service account passwords that enable applications to communicate with each other present one of the biggest security back doors.
In order for these applications to get access to data, they have to log on to the systems and applications that store the data, and, since the credentials to log on are in the application, they are embedded in the code. Now, since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never change. So what is the big deal, you might ask? Well there are a number of things.
Firstly you have the problem of the never expiring password on a system which is accessible by administrators and anyone else who might have privileged access to a system. The problem is more acute when a company is relying on hosting services from a third party. Your applications are accessing valuable business-critical data thousands of times a day, using the same user ID and password. In fact there might very well be hundreds of applications all accessing using the same credentials. And since the applications do not have any integrated security such as VPN (virtual private network) technology, the passwords to these accounts are often stored in clear text (not encrypted), thus becoming visible to developers, support staff and anyone that has access to the application code.
Secondly, because these passwords are often hard coded within the applications, resetting a service account password becomes a complex process involving changes to application code, compilation, and in some cases a long process of transferring the code from development, to QA, to production. In some cases this change might require downtime for the application, a scenario that is unacceptable in cases of confidential information.
Thirdly, auditing is virtually impossible because the credentials that are embedded in the application, although in theory only accessible to the application, can actually be used by any developer who has access to the code. So if, for example, a person were to log in using the credentials, it would be impossible to discover this through a simple audit check.
Finally, the most serious aspect of this is that the user ID and password are known by developers and support staff and can be used for personal access to the resources. And in many cases those credentials are known by third party developers who have been contracted to develop the applications for your organisation. So access to your business data is ultimately in the hands of developers who may be thousands of miles away.
It is likely that your organisation has gone to unprecedented efforts to secure your access as a user, using all kinds of innovative technology, but at the same time forgetting, or possibly choosing to ignore, the fact that unauthorised personnel including ex-employees, MSP staff and off-shore developers, have the keys to open up your most valuable assets.
The good news is that there are solutions available to allow you once and for all to face up to this taboo and eliminate the threat. The solution is digital vaulting technology. It means that no organisation needs to be exposed to risks in this area. Regardless of the platform, the technology is available to ensure that your applications will never again require the never expiring password. But the first step in solving the problem is admitting that it exists.
Calum Macleod is European director of Cyber-Ark, www.cyber-ark.com
