As any member of the business community today can tell you, data security is a big deal. Protecting your organization’s security is everyone’s responsibility, and the habits individuals develop in maintaining that vigilance at work can make a big difference when considered collectively.
Password Security Risks in a Data Centre Environment
According to research, data breaches are set to cost the global economy as much as $2 trillion by 2020. And that doesn’t even take into account reputation risk for companies who don’t safeguard the data of their customers, due to poor corporate and network security. Although denial-of-service attacks can be costly, the report said criminals stealing business or personal records has a far greater impact on the economy — even if there’s no immediate financial gain from the theft. Every data centre needs a robust security strategy, especially as concerns passwords.
The good news? There’s a lot you can do it ensure passwords in a data centre are managed, including some quick wins that can help begin your journey to a more secure environment.
Get on the Hunt
First, go through your data centre and find all your devices–not just your critical servers, routers and switches, but also the little appliances that were installed for a specific solution and possibly forgotten over the years. The majority of these systems come with a default user id and password. A quick google search will reveal the default passwords for most systems (ie: admin/password). Change these passwords as soon as possible. Don’t forget your console and ILO passwords as these represent great doors into your environment.
Eliminate Vulnerabilities
There are certain accounts that are prime targets for attacks and misuse. On Windows, I recommend you disable your Administrator account (rid 500). This account should only be utilized for initial setup and as a disaster recovery account. Set a unique password, store this in a protected vault then disable the account.
Similarly, on SQL, alter the SA login to have a strong password, rename the account, then disable the login. It should be noted that in some SQL versions, service packs rely on the SA login, so you may need to have a process where you rename account, apply update, then rename accounts again for optimal security. Don’t forget root on your Unix servers. Depending on your flavor of Unix, you have the ability to –lock the root password, disable it ‘!’ and deny all remote logins to this account.
For normal operations, each person who administers the systems needs his or her own administrative account. They are accountable for their individual accounts. Avoid utilizing generic accounts.
Service accounts and application specific user ids sometimes cannot be avoided. If they exist in the environment and cannot be removed or disabled, you can make them safer by denying login ability to the accounts. This allows them to function within the environment but prevents anyone from using them as an access point.
Change is the Only Constant with Passwords
It is fundamental to security in a data centre that you change passwords on a routine basis. Consider investing in a password vault solution: a top of the line solution can be configured to update the passwords automatically within an environment. If you choose not to implement one, there is still a lot you can do. Even entry level vaults will help you store your secrets in a secure environment in case they are required. It should also give you the ability to audit who knows your secrets. This information allows you to prioritize password resets in the event of administrator changes.
Sometimes changing passwords is not straight forward and involves updating fields in application consoles. If at all possible, automate the process. If not, ensure you document these steps and store them with the password information in your vault so you don’t have to reverse engineer the requirements when it comes time to change the password again. Most importantly, if you are resetting an application password within an unknown environment for the very first time, try and schedule a reboot. Sometimes a password is only referenced during boot time and it is very difficult to debug if the first reboot occurs months after the password is originally reset.
These are only a few ideas—and I’d love to hear more from you. I invite your comments.
Recent Comments