It seems 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. It is virtually certain that there is not a single business critical application in your company that isn’t wide open. Do you ever wonder how it is that information such as credit card details, personal data, intellectual property, seems to always be so vulnerable. You would think that companies had adequate security precautions to stop this happening, and yet it continues to be a problem.
So where is this wide open back door? In every one of your applications.
When, for example, a user accesses a web based application through a Portal, behind the scenes an awful lot of activity takes place to present the 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 to access the data.
The challenge of securing, managing and sharing the service accounts becomes a major overhead issue for IT departments and application managers in your organisation. The Service Account Passwords that enable applications to communicate with each other must also be managed as they present one of the biggest security backdoors.
In order for these applications to get access to data, they have to “logon” to the systems and applications that store the data, and since the credentials to logon 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 changes. So what’s 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 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/scripts, a reset of 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 result in or 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 they can actually be used by any developer who has access to the code. So if for example a person was 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 this user ID and password is known by developers and support staff and can be used for personal access to the resources. And in many cases today those credentials are know by off-shore 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 from tokens to digital certificates, and at the same time forgetting or possibly choosing to ignore that unauthorized personnel including ex-employees, MSP staff, off-shore developers, have the keys to open up your most valuable assets.The good news is that there are solutions available that will allow you to once and for all face up to this unspoken taboo and eliminate this threat.
The solution is digital vaulting technology. It means that no organisation today needs to feel a sense of being exposed to risks in this area. Regardless of the platform, the technology is available today to ensure that all your applications will never again require the never expiring password, but the first step in solving the problem is to face up to the unspoken taboo in your organisation and do something about it.
How to Change JKS KeyStore Private Key Password
Use following keytool command to change the key store password >keytool -storepasswd -new [new password ] -keystore [path to key stor...
-
AIX Environment Procedures The best way to approach this portion of the checklist is to do a comprehensive physical inventory of the server...
-
Java Keytool Commands for Creating and Importing keystore files: These commands allow you to generate a new Java Keytool keystore file, crea...