Security guards at the Museum of Anthropology within the University of British Columbia certainly learnt a lesson that maybe the “computer is always right”sometimes.
Imagine the scene where a burgler phones you up and tells you not to worry if you hear the sound of your windows smashing, there is nothing to worry about. Then minutes later you hear your windows smashing but think and do nothing about it, meantime the burgler is busy removing all your vaulables. This is just what happened at the Museum where security guards got a phone call appearently from the CCTV camera company telling them not to worry if some alarms go off as the camera system is faulty. Indeed, later that day alarms did go off but they were ignored…. while burglers got away with everything.
The full story is here. A great example of social engineering.
Related Post
Noted in a recent edition of the Risks Digest, a bloke who lives in Needlepoint Lane and cannot use Amtrak’s automated parcel tracking as the website beleives he is entering a PO Box address instead of a real one. It seems, according to Amtrak who know about this bug, that the data entry detects the ‘po’ within Needlepoint and treats it as if it is referring to a PO Box.
A simple and silly mistake, I thought bugs like this and indeed prgramming mistakes like this, would not be made these days anymore.
Related Post
Slashdot ran a story this morning about the state of NASAs computers in the shuttle, the idea that you will never see a shuttle in space over the new year.
It is interesting as it does demonstrate that a simple new requirement (or I suppose in this case a requirement that was possibly missed out during the design) can turn into quite a lengthy task when it comes to Software Testing. In this case there might be minimal or no development work required, but a lot of investigation, simulations and code reviews in order to determine the risk. Add to this and the idea that I’m sure computer systems on the shuttle are duplicated a number of times and have independent software systems designed, written, and tested by independent teams - so add this into the risk equation.
It should all in theory work fine, or at least the internals should as they would no-doubt all be working on a number of ticks or a number of seconds since a certain time, with any luck all database records would be using the same concept. Computers have no concept of dates or timezones, they just know it has been x number of ticks since a key time in history. Â But it is when they have to convert their handy time tracking format into something that humans can understand, or they need to convert an input from a human into something that makes more sense to them, that they might come a bit unstuck. Â It is then up to the mercy of the programmer a lot of the time to make sure they sanitise the inputs and the outputs, and it is when something a bit strange it doesn’t just give up.
For NASA, think about the “customer impact” against the “business sense”. There may, or may not, be a bug or bugs when the year wraps over to a new one, it occurs only once a year. The shuttle have been flying since the mid to late 1970s and during this time they have not had to have a shuttle in space over the new year. Maybe because of this worry, but all the same it has not greatly affected space flight. So, the business sense of investigating this possible problem is quite low, it has not been a critical problem before. Added to this all the hundreds of programmers and ex-programmers that have worked on the software for NASA in the past, working on source code spanning nearly 30 years in no doubt a mixture of assember, C, you never know if you might find a bit of Java in there too! Huge amount of effort then for a low business sense and low customer impact possible problem.
A full risk analysis would surely show little gain for high effort = leave it alone.
Related Post
