Is Your IT Staff Sharing Passwords (e.g. root, oracle, etc.)? This Could Spell Big Trouble... Very Big Trouble

Thursday, January 21, 2010

As many of my blog readers may recall, for the last year or so I have been banging on the "superuser privilege management" drum which is all about "trusting, but verifying" what privileged users (e.g. systems administrators, DBAs, etc.) and their accounts (e.g. root) can do and auditing actions taken by those privileged/superusers. Failure to adequately manage privilege accounts has led to dramatic headlines of internal threats (such as the Fannie Mae incident) as well as court cases (such as the Andritz decision) ruling against companies who did not take appropriate actions in the area of privileged/super user management.

Up to now these incidents have been based on actual actions and the impact of those actions taken by privileged insiders. It was with a great deal of interest that I read in Network World that a financial services firm had to notify 1.2 million customers of a data breach — not because they found an actual breach of data, but because six usernames and passwords have been shared by administrators over the last 10 ten years. In other words, because of this sharing of passwords, the potential was there for a breach to occur, and the financial firm in question (Lincoln Financial) felt compelled to trigger an undoubtedly embarrassing and costly investigation and subsequent disclosure to regulators and the public that a breach could occur because of this internal practice. The gory details can be found in this letter posted to the New Hampshire Department of Justice's web site.

This chain of events was triggered by an unidentified person complaining to the Financial Industry Regulatory Authority ("FINRA") that Lincoln Financial ("LFS") shares usernames and passwords to a portfolio information system that contained personal information such as Social Security Numbers and transaction details. The tipster also provided an actual username and password. According to the letter, FINRA declined to inform Lincoln Financial "whether it had received the common username and password from a current employee of LFS or some other party."

[Note that Network World incorrectly refers to FINRA as a "federal regulator." In fact, FINRA is not a federal agency, but, per Wikipedia, is "not part of the U.S. government and is not a government agency—it is a private corporation that performs market regulation under contract with brokerage firms and trading markets."]

So what does this mean? Well … if you are a financial or securities firm (and no doubt there are other government or non-government agencies that would care about this stuff for other industries), and someone inside or outsides knows that you are sharing usernames and passwords, they can simply can go to http://www.finra.org/Investors/ProtectYourself/p118628, spend about five minutes typing in a complaint, and boom your firm may find itself having to spending hundreds of thousands of dollars investigating this practice and probably millions in terms of dealing with the impact of the disclosure of this practice. And you will not even know who lodged this complaint to begin with.

So hopefully if you were not motivated before, you are motivated now to do something about superuser privilege management!

Where to start? Per the guidance I quote from Gartner here, stop the practice of sharing accounts and get people to use their personal accounts. We heartily agree. That's one of the benefits of DirectControl in that it provides the ability for users to login as themselves (i.e. their Active Directory account) vs. sharing a root/super-user account. In other words, there is significant value in having the IT staff who login to a UNIX box (e.g. sys admins, DBAs, web developers, etc.) to administer the system to login as themselves using their AD credentials. Otherwise they will share the root account, the oracledba account, etc. And in order to ensure that they don't continue to use privileged local accounts, customers need to create new passwords for these accounts and make sure they have a process to manage the passwords over time. DirectControl does this by mapping these local accounts to an AD account so that the AD password, which is under AD password policy controls, must be used for any access to these accounts.

The net net is that having people do stuff as themselves (i.e. their AD username) delivers more accountability and reduces sharing of root / superuser accounts and their passwords. And of course by having users login onto their apps and UNIX boxes with their AD credentials (vs. using a different identity store other than AD) you get the benefits of single sign-on, single place to administer the user account (e.g. disable them), etc. And the nice thing is by using the Centrify approach of leveraging AD across a heterogeneous environment you can leverage an existing infrastructure (and investment) and also leverage existing skillsets when it comes to disabling an account, resetting a password, etc.

From there, what are the next steps in addressing this problem? Granularly control what a superuser can do on a given system, and audit their actions. It's that simple, and that's exactly what our other two solutions, DirectAuthorize and DirectAudit, let you do. And again you can do all of this with Centrify by leveraging a technology you already have — Active Directory.