|
|
|
 |
||||||||||||||||||||||||||||||||||||||||||||||||
"A funny thing happened to me on the way to the theatre..." This timeless phrase reminds us that it always worth recounting some true stories and anecdotes at the outset of a serious activity. It enables us to impart some of our experiences that led us in some way to the conclusions that we have drawn. There are six such stories. They concern:
At the end of eachstory we make some observations, which we summarise after recounting all the stories.
The plane taxied back to the safety of the apron well away from the terminal building. Some one hour later, after rolls and water had been served to the passengers, the passengers were told that the flight would not proceed that day. We were at the back of the aircraft and were held there because another passenger had to be taken to hospital. Eventually we were disembarked, passed back through immigration and customs where we waited for about another hour to be allocated a room to stay the night. We were then put into an un-air-conditioned bus where the luggage was stacked onto the back seats and down the aisle. The bus took us to our hotel – Sugar Beach, about an hour’s drive from the airport. Some people complained vehemently that the bus had no air-conditioning – we were just glad to be alive and thankful that BA knew what to do. The hotel greeted us with a welcoming smile, a refreshing drink and checked us in without fuss. We had the afternoon to ourselves. England had just won the World Rugby Cup and it was gorgeously hot and sunny. We could relax for a few hours despite, as we had just been informed, that we would be woken up at the ungodly hour of 4am to get back to the airport. We were also told that BA would not pay for alcoholic drinks. We understood that, settled in and had some lunch, it being about 2.30pm by this time.
At the airport we again queued for the X-ray machine, the check-in and immigration. Amused that we now had two exit stamps in our passports we waited and waited. It was then announced that the Captain had performed his pre-flight checks and had grounded the aircraft as the same cockpit warning lights were lit. This was indeed an unexpected surprise, as rumours had it that an engineer had been flown from London to certify the repairs and they had passed! We gathered around the gate, however many hundreds of passengers we were, to hear the Captain address us personally. We wanted to shake his hand and thank him for putting our safety first, but others were clearly unhappy. “Are we dead?” we heard someone say. “No”, came a comforting reply “we practice until we all get it right, then we take off”. The Captain spoke reassuringly through his megaphone. He explained the situation with the engine and informed us that there were two alternatives. One to fly out another aircraft from South Africa, the second to stay a further night in Mauritius while a new aircraft was flown out from the UK. BA provided us with a voucher for some food. We never heard the announcement about which option had been chosen but as others on the plane had left the waiting area, we gathered that it was the second alternative. We went back through immigration and again queued to get our allocated hotel room. We were bussed to the same hotel and met there by BA staff. Three buses were required to get us there, and we arrived at sundown.
Now, of course, being Monday there were two flights with the same BA 122 number and the people waiting for the Monday flight got muddled up with the people for the delayed Saturday flight. The tanoy call to board mentioned the delayed flight but gave a date not the day, which was unclear to those who had not been delayed. The different coloured boarding cards allowed the people to be sorted out but it caused delay in the line to board. The Captain proudly announced on the tanoy that all was well and we would board in 10 minutes so we lined up. Some 1 hour later we eventually boarded - no one seemed to know what the hold up had been. When we got home we discovered that the BA London information had been telling the people collecting us that the fight was OK on the Sunday, which it was not and on the Monday that there was only one flight! Fortunately we had a mobile phone so kept our families informed! BA had given many passengers a form to complete. We had to ask for ours on the aircraft. We completed it and duly sent it off. BA replied, apologising and offering us a complementary round-trip ticket to any destination of our choice. The letter formally confirmed the delay for insurance purposes and acknowledged that the passengers should have been kept better informed, that matter having been already taken up with Senior Management in order to avoid a recurrence. Observations In business terms the event was “One of our aircraft has broken down in the Indian Ocean”; the impacts, iter alia, being “air crash”, “increased costs” and “customer dissatisfaction”. BA’s concern for aircraft safety is undisputed, and the steps taken to avoid the “air crash” impact clearly took priority over every thing else. Having done so, however, the poor communications and apparent succession of short-term decisions gave an appearance (at least at the time) of minimising “increased costs” over “customer dissatisfaction”. The apparent short-term decisions were:
Had it been decided to fly out an aircraft from the UK immediately, and to keep everyone informed with a single plan that is guaranteed, would it given greater customer satisfaction? As the people on the receiving end, we think “yes”. Would it have cost more? As things turned out, probably not, probably considerably less! Thus, as the story unfolds, we see an apparent balancing act between the costs of doing things to mitigate/fix the problem and the financial ramifications of the resulting impacts. Part of this balancing act is getting the priority ordering of the impacts right. We invited BA to read the story above before publication. They correctly pointed out that the story recounts our experiences of what happened. It does not necessarily reflect what BA intended to happen. We must remember that for much of the time we were in the hands of BA's agents, rather than BA itself, and the agents may or may not have carried out BA's instructions in the way BA had intended. We do not know how much of the groundside disorganisation was due to the Airport and the handling agent and beyond BA's control. Perhaps BA paid for the bus that never turned up, as well as footing the bill for all the taxis called to replace it. Perhaps BA asked for air-conditioned buses. If BA was making risk management decisions in London based on "safety first, customer second, cost third", perhaps, like us, it had inadequate information. A free air ticket to anywhere in the world is a pretty magnificent gesture of compensation - but not the best way to achieve "safety first, customer second, cost third". In this example, the combination of on-board electronics and pilot competence clearly illustrates the ICS was able to detect the initial event in sufficient time for something sensible to be done about it. It also shows that in cases such as this very fast reactions are required. Subsequently we find:
Overall the plan, which started so well, seemed to fall apart the longer the delay in the flight took and the more different people were involved. We deduce that the ICS's ability to cope with the consequences of further complications after the initial event was poor and may have involved decisions made without full information or without full consideration of the overall impact.
Credit card fraud has existed for as long as credit cards have existed. The payment associations (VISA, MasterCard etc) are pretty much on the ball and use quite sophisticated techniques to track down the culprits whist protecting their members' customers. Until recently, however, making suggestions on how to improve security pretty much fell on deaf ears. To the mind of a security practitioner, the amount of money that was regularly lost due to fraud seemed infinitely large compared to the cost of the information security services that were being offered to combat the problem. What seemed stranger was the argument that the loss was small fry compared to the billions of dollars that were being transacted every day. In other words, it was an acceptable risk. However, with the widespread introduction of "chip and PIN", it would appear that the risk is no longer acceptable. Chip and PIN means using a smart card with cardholder authentication provided through a traditional 4-digit PIN. The GlobalPlatform technology serves as a good, well thought out example in the context of dynamically reconfigurable smart cards. Compared to a magnetic stripe card, the smart card is significantly harder to clone and persuade to divulge its secrets (e.g. the PIN). GlobalPlatform cards are able to defend themselves against attack and can communicate with the Card Issuer. Thus:
Thus the objective of chip and PIN is to reduce the number of attempted fraudulent transactions, by introducing a more reliable cardholder authentication mechanism, that is also extremely difficult to tamper with. Observations By itself chip and PIN will not, and cannot, reduce the set of attempted fraudulent transactions to zero. It will not stop the thief who guesses the PIN, or found it conveniently written down in the gentleman's wallet. It will not stop the genuine cardholder from spending more than the Card Issuer is willing to lend them. Other controls, which already exist such as authorisation limits, are necessary to do that. What is does do, however, is (a) decrease the time between the event (attempted unauthorised use) and its detection; (b) increase the reliability of that detection. In the event that someone forges the cardholder's signature sufficiently well for the shop keeper not to notice, the point at which the unauthorised use of the card is discovered could be days after the transaction has taken place. The goal of chip and PIN is to render such detection virtually instantaneous. Thus the decrease the time between the event and its detection afforded by chip and PIN is significant. It detects the event so fast that all subsequent activity, which would otherwise lead to the occurrence of some adverse impact, is prevented. It is therefore a preventive control. In contrast, the controls that traditionally spot fraudulent activity detect the event too late, the impact having already occurred. The cost of rolling out chip and PIN is not insignificant, but so is the cost of credit card fraud. The introduction of chip and PIN shows that the balance between the cost of control and the cost of impact has shifted in favour of greater control.
An organisation had built a brand new European Headquarters which conformed to the best practice for construction and Health and Safety regulations. The building was equipped with sprinklers and extinguishers as well as being constructed with fire proof material. Clearly these matters form part of the ICS of the organisation in that they were costs incurred to guard against the unlikely eventuality of a fire, even though most were compulsory to comply with regulations. In addition, following previous experiences with fires the organisation had in place a tested recovery system for the head office IT systems and applications and procedures for dealing with personnel issues, the press, loss adjusters etc in case of disasters. In effect they had in place an ICS including BCP, some of which was in place and some tested but only activated as required. Unfortunately there was a small fire in one wing of the building and the fire procedures were invoked including calling the fire brigade. During the course of setting up the fire fighting equipment the wrong water valves were used and the sprinkler system was inadvertently turned off; the result was that the fire spread rapidly in the roof space to the whole building. Now there was a disaster, not merely an inconvenience because the Head office had to be relocated urgently, which was not part of any extant plan! Observation Controls do not always work as intended, and in this case with potentially catastrophic consequences.
The Audit Practices Board (APB) presents an interesting example of acceptable risk. Basically, the example concerns a small advertising agency. Small adverts are placed for cash and the company accepts the risk the £5,000 worth of cash transactions may be lost per annum, for whatever reason. The APB example argues that the cost of the controls necessary to assure each transaction would be disproportionate to the value of the transactions. The problem of such loses is subsequently ignored. Our question is "How does the company know when the loss becomes £5,001?" Surely, that ought to be an unacceptable risk! Observations What the APB example fails to argue concerns when this acceptable risk becomes an unacceptable risk, i.e. when the loss becomes £5,001. First, of course, you need a way to determine when it does. A reconciliation, each month, of the cash received versus the advertisements would serve this purpose. It would highlight the total loss, albeit being unable to identify the particular transactions concerned. However, it is the total that we are interested in at this stage of control. If the reconciliation, performed at the end of month 11, shows that the loss is £4,580 then the loss remains acceptable (as it is just on target to come under £5,000) and the company can be satisfied with its decisions. If the same loss in reported at the end of month 1, then the company ought to be concerned that its acceptable loss is in danger of becoming an unacceptable loss in month 2, and ought therefore to take action accordingly. Once again, it is necessary for the ICS to detect the event (in this case the metamorphosis of acceptable to unacceptable risk) in sufficient time for something to be done about it.
At a meeting, our client's IT manager asked why his networks had just been the victim of a well known virus. We asked some questions and sent him off to find the answers. During his absence, a colleague remarked that for some time his laptop had been reporting that its anti-virus library was not up-to-date. Others quickly reported the same. The IT manager reported back. Anti-virus library upgrades were being received in a timely manner by the server but due to a software problem they were not being distributed to any other computer on the network. The software had stopped functioning 3 months ago! With another client, we asked some questions to determine whether the anti-virus libraries were up-to-date. They were, save for all the directors' laptops. Further investigation revealed that they were scheduled for a regular update every day at 05:30. No director had ever docked their laptop at that the unearthly hour in the morning. Their libraries were two years out of date! We asked about their new web-surfing controls. The QA manager, a railway model hobbyist, proudly announced that it prevented him access to his hobby sites, and having been denied once he had never tried again. We asked him to try once more, and guess what - he had access. The software had stopped working. Observation These stories remind us that controls do not always work as intended and from time to time they fail, but does anyone ever check!
We were always taught as young computer programmers of the urgency of discovering your mistakes early on in the development lifecycle. A design error found at the design stage is usually quicker and less expensive to fix than if it is discovered by the client when the system is operational! - but that depends on who is paying. For example, much of the UK government procurement for software intensive projects prior to the early 90's was performed on a time and materials basis, and quite often overran with a corresponding escalation of costs, which the client paid for. The joke at the time concerned a conversation between a small boy and a genie. The boy wanted to get rich. The genie replied "I'll make you a sultan". The boy asked to be made richer, and the genie would offer a more powerful position. Following some iteration the boy insisted that he wanted to get really, really rich, whereupon the genie would reply "I'm sorry, but there are no vacant positions for defence contractor". Thus, the regime of time and materials contracts for many government procurements came to an end. The initial shift was to fixed price, and in many cases, even for small contracts (<£100K), there was a requirement for a risk analysis. Thus the client:
This dramatic shift of risk ownership from client to contractor met with some problems, not least what to do if the error was made by the client. This resulted in other procurement strategies, such as the Private Finance Initiative, where the risk is shared. Observations Quality controls are equally part of the ICS as are financial, security and environmental controls. The thrust of good software engineering techniques is generally towards detecting errors early enough in the development lifecycle to do something, without disproportionate expenditure of resource, to correct them. Even so, there is a cost of which has to be balanced against the cost of failure.
Our observations in respect of each of these stories have much in common. They are:
Of these the most significant is that the time taken to detect the event must be fast enough for something to be done to prevent or otherwise mitigate the ensuing impacts. Referring back to our opening remarks on corporate scandals, we ask whether there were any controls in place to detect the initiating event(s). If so, then clearly they were unable to prevent the consequent actions that led to such disastrous impacts, but could they have done so? If the answer is truly no, then could they have detected any of the events in sufficient time for someone to have done something to arrest the situation? Perhaps they did, but no one took any notice, or, as we would like to believe, failed to recognise the significance. Armed with an understanding of our fundamental theory and some tricks of the trade, such as event-impact analysis, perhaps they would. Interested? Then read on ...
|
|||||||||||||||||||||||||||||||||||||||||||||||||
|
18 March, 2004 |
|
