By David F. Carr  |  Posted 2005-10-01 Email Print this article Print

NASA has 80,000 employees, and works with more than twice as many scientists and other outsiders. The problem: Those log-ins could be used to access the agency's computer systems after the users have left, retired—or died.

: Account Management Made Easy">

DAY 2: Account Management Made Easy

The new account management system is in many ways the heart of the NISE project. Through the combination of a computer application, Sun Identity Manager, and a set of procedures about who can create or delete accounts, the account system aims to impose order on identity management at NASA.

Project team leader Mark Silverstein, a gangly 35-year NASA veteran, hopes the system will ultimately make his life easier. On day two of the review, he is our star witness.

One of the first things he tells us is that, as an information security specialist who also manages NASA's intrusion detection and incident response, "I get audited a lot." Someone from the NASA inspector general's office always seems to be poking around, looking to nail him on some system vulnerability he has overlooked.

Maybe that's why this review panel does not strike fear in his heart. Besides, the account management project should arm him with better answers the next time the auditors come calling.

The critical question that would be tough to answer today: Who has user access rights on NASA's network?

"If someone asked, 'Who has rights on your machine or your application?' we could answer that pretty well," Silverstein says. The administrator for that server, or that application, could pull up a list of the users. But what about many different servers and applications that all have their own administrators?

"To do it for a center would be tricky. To do it for the agency would be impossible," Silverstein says.

Kearns assures him that things aren't so different in the corporate world, where identity management is often in a similar state of confusion and where tighter auditing standards are spurring efforts to change that. "There's a lot of scrambling going on," Kearns says.

NASA's new account management system will funnel requests for account additions and changes through the Sun Identity Manager, which will make sure they are reflected in the Sun enterprise directory. So there will be a central record of each user, and the applications that user can access.

Ideally, each request for a user account will go through an automatic workflow, prompting the appropriate managers to give their approval, and then the account will be automatically generated on the target application. 8

8 Sometimes automatic account creation won't be possible, because no out-of-the-box interface to the application is available and creating a custom adapter isn't cost effective. In those cases, the application administrator will be notified to create, modify or delete accounts manually.

To keep changes from falling through the cracks, there will also be a reconciliation process to keep the central directory in sync with the accounts that actually exist on each system. The outcome should be a comprehensive systemwide picture of NASA user accounts.

So the next time the auditors come calling, Silverstein will be able to hand them detailed reports on what accounts were created, on which systems, and who authorized them.

Even so, technology is not necessarily the linchpin to success, according to Silverstein. Account management is just as much about management as technology. Each center will have to assign an account administration official to oversee the account management implementation for that center. The centers will also need several associate account administrators, who will use Sun Identity Manager to process the day-to-day requests for account updates. Once created within the computer system, those accounts will be routed to the appropriate managers for approval.

The process that a request will follow will vary depending on the user—a badged civil servant, a contractor, or a scientist in another country interacting with NASA over the Internet—and the sensitivity of the application. The application allows for zero to 20 manager approvals, beyond a basic clerical review.

For contractors and civil servants, the creation of an online identity will start when they are issued a security badge, which triggers the generation of a record in the central identity database, a NASA unique identifier, and an LDAP directory record with the individual's location information and e-mail address. The account management system controls the process of assigning that person accounts on specific applications. For a virtual user such as a scientist to be allowed remote access, the process begins with a sponsor who vouches for that person.

The identity database and LDAP directory are already live, and the account management system is scheduled to go live this month.

The panel's toughest questions to Silverstein are about the roles of the people, rather than the machines. We ask: Who are the people sponsoring and approving accounts? What responsibility do they bear for sponsoring a user account for someone who shouldn't get one? Yes, we know the details will vary, but at what level of management will these approvals typically be granted?

Vickie Pendergrass, the Goddard CIO, notes that today the sponsor for a virtual user can be "any civil servant." That doesn't mean the request will be approved, but any NASA employee can start the process. It would be hard to find one rule for whom the sponsor should be that would work in every instance, she says.

Still, this could be a chance to tighten up the process. Kennedy's Hevey points out that for Department of Defense systems, the sponsor and all those who grant approval for an account are part of a "chain of authority," meaning that "you can tie accountability all the way back up the chain."

For every link in the chain, NASA should be looking to "guard against people rubber-stamping these approvals," agrees Portia Dischinger, the project manager working with physical security on the new badge approval system.

The new account management system also needs to do a better job of removing users from the system. If an employee gets fired for cause, or otherwise leaves on bad terms, administrators know they have to be diligent about turning off all of that person's accounts. That's just the network equivalent of having security workers box up your stuff and escort you out of the building.

But what about the employee who quietly retires? Silverstein explains that there is already a checkout process employees follow when they leave or transfer to another facility, with a checklist they must complete showing they have turned in their keys and so forth. Telling the account administrators to deactivate your system log-ins could just be another item on that list, he reasons. Santiago says removal from the payroll system can also be used to trigger account deactivation.

The bigger issue revolves around contract workers, who are often here one day, gone the next. They may have been diverted to another contract temporarily, they may have been reassigned permanently, or they may no longer work for that particular company. Often, no one within NASA knows which is the case. The agency is going to have to be more diligent about insisting that contract employers do a better job of notifying NASA of these changes so accounts can be suspended or deleted as appropriate.

We continue to grill the NASA officials: What about virtual users? Should a university scientist granted a remote access account on a NASA system keep that account forever? How should the agency go about eliminating these accounts when they are no longer needed, or no longer being used? Another way of weeding out unused accounts is to monitor for inactivity—if months have passed since the last log-in, maybe the account should be deactivated.

Santiago suggests that a better way would be to build account management requirements into the research agreements NASA has with universities, making someone there responsible for notifying the agency of changes—so it knows who has left the university and who is just away for the summer. Expiration dates will also be important, but their length will vary with the sensitivity of the data managed by each application, he says.

Yet Greenwood urges a general tightening of account expiration dates, saying that should solve a lot of orphan account problems.

David F. Carr David F. Carr is the Technology Editor for Baseline Magazine, a Ziff Davis publication focused on information technology and its management, with an emphasis on measurable, bottom-line results. He wrote two of Baseline's cover stories focused on the role of technology in disaster recovery, one focused on the response to the tsunami in Indonesia and another on the City of New Orleans after Hurricane Katrina.David has been the author or co-author of many Baseline Case Dissections on corporate technology successes and failures (such as the role of Kmart's inept supply chain implementation in its decline versus Wal-Mart or the successful use of technology to create new market opportunities for office furniture maker Herman Miller). He has also written about the FAA's halting attempts to modernize air traffic control, and in 2003 he traveled to Sierra Leone and Liberia to report on the role of technology in United Nations peacekeeping.David joined Baseline prior to the launch of the magazine in 2001 and helped define popular elements of the magazine such as Gotcha!, which offers cautionary tales about technology pitfalls and how to avoid them.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters