How secure is your Clarify environment?
Is your Clarify environment the exception to most of the security policies your IT organization has implemented? Do you have to manage special rules, privileges and procedures around day-to-day operational management of your Clarify database? With regards to security do you find yourself saying “I wish we could get our Clarify system to do that”?
You’re not alone. Throughout the last several years we have seen IT organizations mandate more stringent IT security policies across their infrastructure and applications, to achieve a higher degree of security. If your company has been keeping up with newer releases of their enterprise solutions, the security that comes with those has allowed you to meet most if not all of these policy requirements.
More and more companies are moving forward with implementing some or all of the following, to meet new security demands:
- tougher password complexity rules
- shorter password expiration timeframes
- account lockout mechanisms
- multi-factor authentication
- tighter networking and firewall security
- “least privilege”/role-based access control
- data encryption
If the above list looks like a list of best practices for IT security, you’re right…it’s a pretty good start. Thinking through the list above, how does your Clarify environment stack up to these challenges? If I were a betting man (and everyone knows I am), some if not most of the following are probably true:
- Your Clarify users use passwords that do not meet even basic password complexity requirements
- Your Clarify users have probably NEVER had to change their password
- Your Clarify users can have as many tries as needed to guess a password to login
- Your Clarify administrator probably changes or resets passwords using RDBMS tools, rather than the Clarify client
- If your Clarify administrator does use the Clarify client to reset passwords, users are not forced to change their password after the first login attempt
- Your Clarify database is accessible using default ports
- Your DBA team has compromised their database servers and databases by having to give out the ‘sa’ credentials to the Clarify administrator.
The point of the exercise above is to bring to light how little security there is within the Clarify/Amdocs product suite. From the mid-90s to the mid-00s, security was just not at the forefront as it is today. While I have not seen Amdocs 8.x, every version prior to that, in my opinion, is extremely limited with its security capabilities.
Getting your Clarify environment to meet these security standards is going to be tough, as the application frankly just doesn’t support it. For example, let’s take a look at password complexity. Clarify does not support it, however MS SQL Server 2008 by default enforces the password policies of the server or domain controller to which the server is a member. So, how does Clarify handle this? Quite frankly – it doesn’t. If your network domain, like most these days, is set to require a minimum length for a password, special characters, capital letters, numbers, etc., the database password policies are enforced by default. If you attempt to change a Clarify user’s password that does not meet these rules, the Clarify client does not handle it and reports back strange errors, and the password is not changed. What most Clarify customers have to do, is UNCHECK this option, so the Clarify client behaves appropriately. This is not an ideal solution when you are trying to enforce password security.
Another example, has to do with resetting a user’s password. I have never understood the ‘Change Password’ feature in Clarify. You must enter your current password, followed by the new password, and confirm it. This seems odd to me. Most people would never change their password unless prompted to, and I would bet in most instances when a user changes a password, it is because they forgot what it was. This ‘Change Password’ feature quite honestly does me no good. If I forgot it, how would I know what the current one is. On top of that – you have to already be logged in to get to this option! So, a user must ask a system administrator to reset their password, should they forget what it is. At this point, the system administrator changes it, enters it into the application and has to communicate this to the end user. This problem is two-fold: 1) the administrator now knows the password for this user, and 2) in order to communicate it, it has probably been emailed in clear text. Both of these situations would be a security violation in most organizations.
About the only thing Clarify does support with regards to security is password expiration. Within a Privilege Class, you can set the password duration to a number of days before it expires and the user is forced to change their password. This works well and we recommend at minimum this for every Privilege Class you use,
Now, for some even better news…Dovetail can implement tighter security for your Clarify environment.
Our applications handle stricter enforcement of password policies and can accommodate your rules to meet password complexity. Our applications utilized a password reset feature that takes the administrator out of the equation altogether, effectively providing a ‘Forgot Password’ capability to the end user community without involving an administrator, while adhering to best practice security standards. For Dovetail customers who have completely migrated from Clarify software, we can show you how to further lock down your database access, making DBAs much happier and helping you satisfy your overall IT security goals.
Dovetail has recognized the limitations of the Clarify/Amdocs suite and addressed these security issues to provide our customers with an overall more secure environment. If you are tired of your Clarify environment being the black sheep within your IT organization, contact us and we can steer you in the right direction.
