Homeland Security?

Imagine in the near future someone who has 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 20040327R2.  Two hours after the person who entered the code leaves work (and the country) the system displays the message "Osama Lives" on every display connected to the system and locks up.  All attempts to re-boot using this version of the OS fail.  Roll-back to the previous version is successful, but 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.  Several politicians are murdered.  The general population begins to flee the city.

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 the 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 - and unfortunately the described threat comes not only from our sub-contractors and out-source partners, but from those we "trust" within our development community as well.

Path coverage analysis has long been a joke in the software development world.  Some of the criticisms of this analysis were: 1) Why waste our valuable time testing paths in the code that are not used during regression testing?  2) If someone presses some weird 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.  The proof - software complexity analysis performed in 2003 at a major communications company in the U.S. resulted in a required ten-fold increase in the number of test cases performed on 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".

I know of no one who has ever performed concordance analysis or concordance delta analysis.  Do curse words belong in our code?  How about "Jesus"?  (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. might not belong in our code.  "Die", "kill", and many other words could be used in a good or bad contact, but may be worth reviewing.  What words have been added to the code since the last version?  Do we care?  What if the word "ransom" were 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?  The point is - we can never protect to the maximum extent, but we are not protecting to any minimum level of "due diligence".

Keep up the good work, there is a long way to go.