|
|
|
|
|
|
Homeland Security: The Trust Factor in Software Development Dateline: Sometime in the near future. Scenario: Someone with access to the emergency response (fire/police) dispatch equipment in a major city in the U.S., Europe, Australia, or Japan enters "# * 9 1 1 # *" (or any other normally unused sequence) on the system keypad. A count-down timer begins inside each and every inter-connected device system-wide running OS 2004-03-27-R2. Two hours after the person who entered the code leaves work (and the country) each of the devices displays the text message: "Osama Lives" on the screen and locks up. All attempts to re-boot using this version of the operating system fail. Roll-back to the previous version is successful, but it takes two hours for all command center consoles and ten more hours to re-program all fleet vehicles (fire trucks, police cars) and all hand-held devices ("smart" radios). During the first two hours multiple explosions occur at "soft targets" throughout the city. Hospitals are overwhelmed with casualties. Several banks are robbed. Key city leaders (mayor, police chief, fire chief) are murdered or sustain incapacitating injuries. The general population begins to flee the city. A fire-storm reminiscent of the Great Chicago Fire spreads through the city - hundreds dead, thousands homeless, millions of dollars in property loss. Is this fictional account an exaggeration of what could happen? Absolutely - because there would be no need for a person to activate such a process by entering a code! As I read through the March 2004 Communications of the ACM entitled "Homeland Security" I repeatedly wondered when I would find articles on path coverage analysis or concordance analysis and concordance delta analysis. No such luck. Don't get me wrong - we absolutely must guard against Internet based attacks described in detail in the many excellent articles. Unfortunately, we must look inside as well as outside our systems. The threat described above comes not only from our sub-contractors and out-source partners, but from those we "trust" within our development community as well. The most relevant article in the March issue was: “Who is Liable for Bugs and Security Flaws in Software”, by Michael A. Cusumano. While discussing the “open system” nature of the Internet Michael commented: “… a determined villain – a terrorist or hacker – will find a way into the system.” The “way into the system” does not have to be from the outside. A March 17th article on Computerworld.com entitled: “Q&A: Quality software means more secure software”, by Gary McGraw contains the following quote from Mr. McGraw: “Software security relates entirely and completely to quality. You must think about security, reliability, availability, dependability - at the beginning, in the design, architecture, test and coding phases, all through the software life cycle.” Once again, an excellent article, but no mention of the possibility of attack from the inside. Remember, the 9/11 attackers were not trained to fly outside the “system”, but inside. We should assume there are terrorist cell members inside our development world – not enough to be paranoid, but enough to be cautious. Path coverage analysis has long been considered an unnecessary and time consuming option by managers in the software development world. Criticism of this analysis included: 1) “Why waste our valuable time testing paths in the code not exercised during regression testing?” 2) “If someone presses some weird key sequence and their device re-boots - who cares?” 3) “So we have "dead code" - as long as it does not cause a memory problem it doesn't matter.” Here is an example from the real world: software complexity/risk analysis performed during 2003 at a major communications company in the United States resulted in a ten-fold increase in the number of test cases required for code provided by another major U.S. company. This ten-fold increase in test cases still did not provide full path coverage, but was judged to be "sufficient". If someone were to place a few harmful lines within a million line code base, who would ever know – unless 100% path coverage analysis were required to be performed across the aggregate component/sub-system/system. For example, code containing an instruction to re-boot the system after some specified future date would never be exercised during “normal” regression testing. Path coverage analysis, however, would reveal this set of instructions as untested. Either a test case would need to be created to execute the path (setting the system clock forward if a valid need existed), or as in this case, the person analyzing the untested paths would discover the harmful code – “Hey, why is there a re-boot here? What is this date? WHO WROTE THIS?” Concordance analysis would provide a discrete list of words used in the creation of the code base. Common words could be omitted from the analysis as could reserve words for the language. Some high-risk words could be highlighted - do curse words belong in our code? How about "Jesus", “Yahweh”, or “God”? (Don't forget - there are fringe ultra-conservative groups right here in the good-old U.S.A.) Of course we accept "Osama", "Sadam", etc. as words we might want brought to our attention. "Die", "kill", and many other words could be used in a positive or negative context, but should be worth reviewing. Are the questionable words really in the code or has someone made some inappropriate comments? Concordance delta analysis would indicate words added to the code concordance since the last version. Should we care? What if the word "ransom" were the only word added (i.e. all the other words used to modify the code were already contained in the previous concordance)? We should be interested in knowing why this particular word was added. You are absolutely right if you are thinking this is just the tip of the iceberg. What about broken words and phrases - "Y o u w i l l a l l d i e" would pass the concordance test. What about other languages? What about images - an "Osama" image perhaps? The point is - we can never protect to the maximum extent, but we are not protecting to any minimum level of "due diligence". Do I think all software should be subjected to this degree of scrutiny - absolutely not. I do think our critical infrastructure systems (communications, financial, transportation, etc.) as well as our government systems – federal (DoD, DoE, IRS, etc.) as well as important systems for each State should undergo some level of scrutiny. As we create tools, processes, and engineering experience for this type of analysis I would expect a migration from our most critical systems to those less critical. We will end up doing what we should have been doing all along – developing good code. Unfortunately there is no “silver bullet” here – security is not free. I know there are commercial tools supporting the path coverage analysis portion of my concerns. Adding a concordance generating module to any parser should not take much effort. I have been hesitant to identify this potential threat and have attempted to quietly raise this issue. I did contact the risk group at the major communications company mentioned above, but the answer I received indicated a complete lack of understanding of this issue. As I read each article in the magazine I also wondered if our enemies were reading the same articles and using the information to increase their understanding of our security systems. We all know the level of sophistication level of viruses and worms has increased over time. We must expect the threats to our code development efforts to increase as well. In closing, perhaps an analogy to our last major hurdle would be appropriate – Y2K. We expended billions “fixing” poorly designed systems in order to prevent massive system failure at a fixed point in time. We now face a problem of similar magnitude but without the benefit of knowing the deadline. Only our enemies know. Keep up the good work, there is a long way to go. |
|
Send mail to
webmaster@d50.org with
questions or comments about this web site.
|
