NASA Still Has No Effective Information Security Program
Final Memorandum, Federal Information Security Modernization Act: Fiscal Year 2016 Evaluation (IG-17-002; A-16-009-00)*
“*In preparation for public release, selected portions of this report containing sensitive security information have been redacted under exemption (b)(7)(E) of the Freedom of Information Act (FOIA).
NASA received 27 out of 100 possible maturity level points, indicating that overall it has not yet implemented an effective information security program.”
If you want a good discussion of computer security try the NIST Digital Authentication Guideline . It is laudably practical and to the point.
The problem with the NASA IG report, and with NASA IT in general, is that there is a great deal of discussion of administration and management and little or no discussion of actual security measures, the human factors problems they cause, and the exploits used to defeat them.
“In this review, we found NASA has not defined and communicated across the Agency the identities and responsibilities of ISCM stakeholders or how it will integrate ISCM activities with Agency risk tolerance, the threat environment, and business or mission requirements. In addition, we found NASA has not yet identified and defined the qualitative and quantitative performance measures it will use to assess the effectiveness of its ISCM program, achieve situational awareness, and control ongoing risk. NASA has also not defined its processes for collecting and considering lessons learned to improve ISCM processes. “
Similarly the Transition Report. I’m mystified with the obsession over management.
I’ve been thinking about that, and it may be a combination of three things. First, most of the real work is very technical and specialized. Second, it involves a large number of specialties mixed together at a fairly low level. Even a relatively small project, like a flight instrument, will involve mechanical engineering (structural, thermal, etc.), electrical engineering (digital and analogue), software development (flight and ground data processing), etc. And, third, no one wants to be the person whose mistake wrecks a half-billion dollar spacecraft or hurts an astronaut.
The first two of those issues means that, at a very low level, managers may (and often are) supervising work they don’t really know much about. A programmer working for Google can be promoted into management and go quite far while still supervising programmers. A NASA programmer can’t be prompted to far into management before he’s supervising electrical and mechanical engineers. Dealing with that while still avoiding mistakes ends up (at least as NASA does it) becoming all about process and procedures. If asked, “How could you let the technicians use a solder containing tin?” the computer-programer-turned-manager would probably say the same thing most people would (“huh?”) Expecting him to know that sort of detail about something outside his specialty would be asking a lot. He would, however, be expected to know his institution has an approved list of parts and materials, and that he’s supposed to make sure the technician only uses things on the approved list.
Even if you are talking about a low enough level for the managers to be familiar with the technical details (probably groups or teams of only a dozen or so people), they are still interacting with other teams and groups doing work they don’t know much about. The people designing the rocket engine probably don’t know and don’t care that a microchannel plate detector is basically a thin, fragile piece of glass. The instrument builder probably doesn’t know how to build a rocket which doesn’t shake the payload too badly. But if you want the detector to survive launch, some sort of communication between them is necessary. That gets dealt with by written requirements and interface control documents.
So, I think all that creates a situation where managers get focused on process, procedures, appropriate documentation, etc. at a very early stage in their careers. That may make them more detached from the nuts-and-bolts details of the work than in other organizations, and that may happen earlier in their career.
Now think about who writes those reports you’re talking about, and who the intended audience is. It’s not too surprising they are all about how to manage the work, not how to do it.
You may very well feel that’s a dysfunctional way to do things, and I don’t think I’d disagree. The problem is that this approach evolved to deal with very real problems. I’m honestly not sure what to do about it (Expecting managers to know all the technical details would mean you could only promote, well, rocket scientists.) Worse, I really don’t think many people from middle management up actually consider this to be a problem.
I agree with your assessment of the problem. Yet we need a better solution. If you look at the unusual people that were leaders of very aerospace development programs that were successful, (Kelly Johnson (SR-71), Ed Hienemann (A-4), John Boyd (F-16), Werner von Braun (Saturn V), they often combined technical expertise, financial discipline, management insight and political savvy.