Twelve Steps to Tightening Up Security at NASABy Baselinemag | Posted 2005-10-01 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
A step-by-step guide to how NASA's trying to plug the holes in its security without locking out the external experts on which it relies.
NASA is aiming to tighten up access to its information systems in a project called the NASA Integrated Services Environment. Work on the project began in December 2003, combining several other projects that were already underway. To ensure that it's not working in isolation, the space agency enlisted outsiders as well as NASA officials to critique the project. Participants on the review team, which met in May, included Baseline technology editor David F. Carr, three NASA space center CIOs and a NASA scientific computing manager. Here's what the group thought NASA should do:
1. Analyze the gap between NASA's official project management process and the way the Integrated Services Environment project has been managed overall. Some steps, such as establishing baseline expectations and performing design reviews, appear to have been skipped or performed out of order.
2. Replicate directory services data to each NASA center, or to a nearby location, which would help maximize performance and reliability. Relying on connections to a central directory service over the wide-area network seems an unnecessary risk.
3. Be aware of Internet privacy issues, especially since NASA has begun collecting personal information from citizens over its public Web portal, as part of an E-Authentication initiative.
4. Anticipate the system's impact on manpower and budgets. Center personnel have not been given a clear understanding of the workflow that will be built into the account management system for processes like suspending and deleting accounts on computers and applications.
5. Better define the process for creating new online identities, particularly for users such as university scientists who log in remotely to retrieve data. Spell out who can sponsor a remote user for an account, who can approve the account, and what responsibility those people take for the user's legitimacy.
6. Better define the account suspension and closure process. Make clear how the closure process will be tied into the checkout process for personnel with ID badges who leave or transfer. For remote users, consider tighter account expiration dates, forcing these users to renew their account before it is suspended.
7. Give guidance to developers and system administrators on how to integrate with the new identity and account management system. As soon as possible, go through the process with them, including one or more examples of application integration, as a way of developing baseline metrics for migration costs and effort, as well as training and documentation.
8. Provide more specific documentation of the relationships between the systems that manage the identities of system users, including how data moves among them. Put these data flows in the context of three or four scenarios such as initial enrollment.
9. Establish configuration control boards responsible for reviewing planned system changes and anticipating the impact of those changes, before the changes are made. (At the time of our review, this had been done for the new security badge system, but not for the account management system.)
10. Establish a high-level, agencywide steering board for the identity management initiative. The existing Agency CIO Board could serve this purpose.
11. Look for an application that demonstrates the value of unified identity management. Find some way of showing that the effort required is worth the trouble.
12. Give center CIOs a better picture of the communications, integration, staffing and financial impact of implementing the ID management system at their locations.