How Positive Performance Security Technology Could Have Saved Columbia
By Roy D. Follendore III
Copyright (c) 2003 by RDFollendoreIII
February 4, 2003
We have a historical event of an organization whose performance could have been affected by the introduction of a philosophy of positive security performance solutions.
The shuttle Columbia (STS-107) was ultimately lost in 2003 because of organizational failures that failed to properly manage safety engineering measures. How do I know this? Technical security and reliability are two sides of the same coin. A fundamental justification for technical security is individual, organizational and systems reliability. Columbia was first flown into orbit in 1981 and was the oldest shuttle. It had a history of 5 times the number of structural failures than any of the other shuttles. This includes internal hydrogen leaks and wiring failures. In addition, there were more detectable software errors in the last year than all of the other years combined. All of this taken together was symptomatic of an aging system problem. This disaster should have been expected. Of course a lot of reputable people did make a lot of noise about these things. Their noise did not make it through. The NASA management solution was to completely ignore these concerns and eliminated the problem of messengers bringing bad news. Their executive issues were settled even as the unsolved catastrophic problems were preserved. In the mean time Moore's law continues to complicate matters.
The number of problems that became obfuscated simply became accelerated. As faster and faster computers replace old ones and begin to run far more sophisticated code and as older systems and sub systems are stressed and wear unevenly, the technological overlay becomes more and more complex, and more difficult to properly manage safely. Organizational systems on the other hand, must allocate resources over the longer term so that less and less management emphasis and importance is seen necessary to put on potentially increasingly critical problems. With less problems, less money to perform missions are thought to be required. The mission requirements and the organizational performance essentially become competitive with each other. To compensate for budgeting gaps, safety engineering issues that may have once been deemed critical are given reduced sensitivity. This is exactly the same kind of long term organizational problems that can be found within the field of technical security today. A system of technical security measures could have been designed blown the whistle on the encroachment of Columbia's eventual critical disaster. Like a fire alarm in a building, a technical security system could have been made available to employees so that their communication was given increasing priorities.
But just as the expectations and concerns of safety systems were represented incorrectly, so too were the possibilities for new applications of security which might have saved the day. Once again the issue is not the technology but the problem of using the technology correctly with respect to the best possible organizational solutions. At issue is that fact that organizations and technology are not masters of each other, they are partners.
Organizations performing critical and complex potentially catastrophic work in stochastic environment can not be safely operated in terms of a politically managed top down wiring diagram over the long term. The delegation of roles and responsibilities must change appropriately as operations evolve. The safety and security processes of organizations should therefore be thought of as a dynamic system that symbiotically evolves.
Technical security measures that prevent bad guys from access can also be used to functionally change an organizational model and enforce the optimum dynamics of organizations as they perform. This means that things like budgetary decisions can be kept from becoming totally optimized for management efficiencies rather than engineered systems reliability and safety effectiveness.
In the case of the Columbia tragedy, a positive performance based security solution within the NASA organization could have enforced the requirement for critical safety resource issues to be handled properly.
Because that did not happen, it meant that safety could not exist under mission agenda oriented management. Like security Directors, safety and quality control Directors would have been a management peer. It had the technical security team would have been partners in NASA productivity.
Regardless of what caused the cataclysmic failure of Columbia systems to perform, it was an organizational failure that denied the services of the shuttle fleet. Such failures come down to a management failure to do the right thing at the right moment. It comes down to that question: What were we thinking?
While we tend to think of telecommunication security only in terms of point to point data services, technical security is really about the quality of service. But the whole point of all such systems is to provide the means to take and improve physical action by organizations. Because it involves the protection and proper utilization of knowledge, a primary part of the technical security solution is to preserve the opportunities to solve critical unsolved problems within the organizational agenda. Within telecommunication security this takes place through measures of integrity and security of knowledge, content dissemination and transaction control. The technical security paradigm must be changed to reflect this.
Copyright (c) 2001-2007 RDFollendoreIII All Rights Reserved