Continued part 1, part 2 of ebook Ethical and social issues in the information age (Fifth edition) provide readers with content about: software issues - risks and liabilities; computer crimes; new frontiers for computer ethics - artificial intelligence; new frontiers for computer ethics - virtualization and virtual reality; new frontiers for computer ethics - cyberspace;... Please refer to the part 2 of ebook for details!
8 Software Issues: Risks and Liabilities Learning Objectives After reading this chapter, the reader should be able to: Explain the limitations of software testing as a means to ensure correctness and reliability Describe the differences between correctness, reliability, and safety Discuss the potential for hidden problems in reuse of existing software components Describe current approaches to manage risk and characterize the strengths and shortcomings of each Outline the role of risk management in software systems design Scenario Who Will Pay the Price for Flawed Software? Peter Efon works as a programmer for a major software company The company, Cybersoft, is launching itself to be a major Internet-based platform developer and it is soon to launch a Web initiative Peter is involved in the development of a crucial component of the initiative The company has trust in Peter for he has worked for it since he left college 15 years ago Since his arrival at the company, Peter has pioneered a number of major software development projects Peter has followed, and is very much aware of, the losses suffered by other businesses due to defective software He even knows that in 2000, US companies suffered a whopping $100 billion loss due to bad software He and his company, Cybersoft, are determined to target quality as the major focus of their new Web initiative Peter dreams of the success of the Web initiative and the recognition it might bring both to his company and him However, a few days before the launch of the much-awaited initiative, as Peter makes his final quality checks, he discovers a flaw in the core component of the initiative whose magnitude he could not determine To so would mean a few weeks delay at best, a major blow to the company’s efforts The company had mounted an advertising blitz on all major media outlets Even a few weeks delay would cause major financial losses and the public’s loss of confidence in the right company This must never happen Peter decides to see to it Discussion Questions Is Peter Efon wrong? What damage would Cybersoft have suffered had there been a delay? What you think would have been the right course of action for Peter and Cybersoft? Can you estimate the damage? J.M Kizza, Ethical and Social Issues in the Information Age, Texts in Computer Science, DOI 10.1007/978-1-4471-4990-3_8, © Springer-Verlag London 2013 157 158 8.1 Software Issues: Risks and Liabilities Definitions Software is a set of computer programs made up of a sequence of short commands called instructions that tell the computer what to Normally software is in two forms: either built into the computer’s more permanent memory, called ROM (readonly memory), or loaded on demand at runtime in less permanent but more volatile memory called RAM (random access memory) A software producer, or developer, creates or develops a set of programs to meet the specifications of a user, if there is a contract, or of a specific problem if it is a general software Developers are either individuals working alone or companies such as Microsoft, which employs hundreds of software engineers including analysts and programmers Software buyers, or customers, obtain the finished software from the developer to satisfy a need, basing their decision on developer claims The buyer may be an individual or a company In this chapter, we focus on the issues that arise out of the relationship between the developer and the buyer, including claims, user expectations, and the legal ramifications that may follow an unhealthy relationship The discussion touches on standards, reliability, security, safety, quality of software, quality of service of software products, causes of software failures, developer and buyer protection, and techniques for improving software quality Let us begin by defining these terms 8.1.1 Standards Software developers must convey to buyers’ satisfaction that their products are of high quality The buyer, however, has little leverage in disputing the claims of the developer in these areas because there is no single universally acceptable and agreed upon measure of software standards But there are universal basic standards that a software product must meet Such standards include the mutually agreed upon criteria and expectations of the buyer In this case, the law imposes such standards, and if the product does not live up to them, the buyer has the right to pursue legal action There is no one criterion that can be used to measure software standards but rather a collection of criteria such as development testing, verification and validation of software, and the programmer’s professional and ethical standards 8.1.1.1 Development Testing According to Richard Hamlet [1], “programs are complex, hard to understand, hard to prove, and consequently often riddled with errors.” But might not a small set of tests on a program pinpoint problems? Answering yes to this question has been the driving force behind testing, which helps reveal the discrepancies between the model being used and the real situation Testing tries to assure that the program satisfies its specifications and it detects and prevents design and implementation faults But testing is limited by an exponential number of states, which makes exhaustive testing very expensive and unworkable for large projects Thus, a number of other selective testing techniques are being used One such technique is development testing, which consists of a series of random tests on the software 8.1 Definitions 159 during the development stage However, the use of mathematical techniques in developmental testing, which seems to offer good assurances and is widely used, does not ensure error-free code Neither does refocusing verification of code to the underlying algorithm and basic computation, because not all errors may be in these areas So testing alone does not eliminate all the bugs 8.1.1.2 Verification and Validation The process of verification and validation (V&V) involves static formal mathematical techniques such as proof of correctness and dynamic techniques such as testing to show consistency between the code and the basic initial specifications It works from the specifications of the software and develops tests that can show that software under review is faulty Tests are randomly chosen But as any programmer will tell you, as the level of programming gets lower and lower toward machine code, software bugs get harder and harder to detect, and no amount of V&V is able to prevent those bugs from falling through the cracks 8.1.2 Reliability Unlike hardware products whose reliability is measurable from age and production quantities, software reliability cannot be measured by wear and tear nor can it be measured by copies produced at manufacture time, although experience has shown that it exhibits some degree of stochastic properties on unpredictable input sequences A software product can fail to deliver expected results because of an unexpected input sequence Reliability of software can, therefore, be defined in relation to these input sequences According to Parnas et al [2], reliability of software is the probability that such a software does not encounter an input sequence that leads to failure A software product, therefore, is reliable if it can continue to function on numerous unpredictable input sequences Other measures of reliability include the number of errors in the code But this also is difficult to take as a good measure because a program with fewer errors is not necessarily more reliable than one with many Because no system can be certified as error-free, including software systems, there have been numerous cases and will continue to be, in which systems have and will fail the reliability standards Consider the example of the Denver International Airport baggage system [3] When the city of Denver, Colorado, wanted to replace Stapleton International Airport, they contracted an automated baggage company, BAE Automated Systems of Dallas, to design and build a baggage delivery system When BAE delivered the system, it failed all initial tests Bags flew out of carts, and jams were frequent After a number of failed test runs, and knowing they were running out of time, city officials hired another firm, which recommended a smaller, less expensive, but working manual system to run as a stand-alone alongside the automated system When it opened, the airport was $2 billion over budget due to the delay caused mostly by this system In his book Computer-Related Risks, Peter Neumann gives numerous examples of system failures due to unreliable products [4] Like standards, reliability is 160 Software Issues: Risks and Liabilities another very difficult concept for a buyer or customer to understand because there are no universally accepted criteria for ascertaining the reliability of a product 8.1.3 Security In Sect 5.3, we discussed the general concepts of system security including information security In this section, we focus on software security As computer technology makes giant advances, our dependence on it increases and so our security concerns as more and more of the vital information that used to be secured under lock and key is now on giant computer disks scattered on numerous computer systems Software is an integral part of a computer system, and the security of such a system depends on its hardware but even more so on the software component There are more security attacks on systems through software “holes” than hardware, mainly through piracy, deletion, and alteration of programs and data A computer system software is secure if it protects its programs and data—in other words, if it does not contain trapdoors through which unauthorized intruders can access the system According to Neumann [5], improper encapsulation, inheritance of unnecessary privileges, and inadequate enforcement of polymorphism are the most common sources of software security flaws Polymorphism is a state or a condition of passing through many forms or stages Software development passes through many different forms In addition to these as common causes of system insecurity is the human element A computer system software can be protected from undetected modification through strong and sound design principles, enforcement of proper encapsulation, separation of all privileges, and ethical education of system developers and users about security issues The human and probably ethical side to system security, according to Ahl David [6], is that most computer crimes are not committed by hackers but by trusted employees, programmers, managers, clerks, and consultants in the company who know and can manipulate the working of the software If David’s observation is true, then computer security and hence system software security greatly depend on the education of system developers and knowledgeable users 8.1.4 Safety Recent advances in computer technology have resulted in wider computer applications in previously unthinkable areas such as space exploration, missile and aircraft guidance systems, and life-sustaining systems In these areas, the safety of software has become one of the most prominent components of the whole security system Such a system cannot afford an accident or an error because of software failure without dire consequences to human life, property, and the environment A software system is unsafe if a condition is created whereby there is a likelihood of an accident, a hazard, or a risk The function of software safety in system safety is that software executes within a prescribed context so as not to contribute to hazards or risk either by outputting faulty values and timing or by 8.1 Definitions 161 failing to detect and respond to hardware failures that may cause a system to go into a hazardous state According to Nancy Leveson [7], software safety depends on the design and environment in which such software is used So software that is considered safe in one environment may be unsafe in another Because software is designed and produced by different people in different environments and used in different applications in a variety of environments, no one software product can conform to all requirements in all environments; in other words, one cannot assume that because a software product is hazard-free in one environment, it is hazard-free in all environments For example, according to Strigini and Littlewood [8], whereas the requirement for rate of occurrence of failures as a dependability measure is appropriate in systems that actively control potentially dangerous processes, the same measure is not as appropriate for life-critical processes in which the emphasis is on failure-free survival In the final analysis, good and safe software depends on good programming practice, which includes control techniques, application of various types of safety analysis during the development cycle, and evaluation of the effectiveness of these techniques Whether these techniques are enough depends on the chosen and acceptable risk level, which tends to vary with the application environments [9] For other dependability measures, consult Littlewood’s article 8.1.5 Quality The emergence of a global software market, the establishment of powerful software development warehouses in different countries, and the improving standards of global software have all brought software quality to the forefront of software issues A software product has quality if it maintains a high degree of excellence in standards, security, safety, and dependability Many software vendors are starting to develop and apply quality improvements techniques such as total quality management (TQM) A TQM technique that tries to improve software quality through a software development process known as the software quality function development (SQFD) represents a movement from the traditional techniques of TQM to the software development environment by focusing on improving the development process through upgrades in the requirement solicitation phase [10] This technique focuses on this phase because software problems occur when user requirements are misunderstood, which causes overruns of development costs Introducing design techniques that focus on user specification in this early phase leads to fewer design changes and reduces transfer errors across design phases 8.1.6 Quality of Service For a product, and in particular, a software product, quality of service (QoS) means providing consistent, predictable service delivery that will satisfy customer application requirements The product must have some level of assurance that the 162 Software Issues: Risks and Liabilities customer’s service requirements can be satisfied For example, in the case of the Internet, QoS would mean that the network elements like routers and hosts expect a high level of assurance that its traffic and service requirements can be satisfied This requirement and expectations are important because the working and the architecture of the Internet are based on “dumb” network concept, which at its simplest involves two smart end routers, one transmitting and one receiving and no intelligence in between Then datagrams with source and destination addresses traverse a network of routers independently as they move from the sender to the receiver IP provides only an addressing mechanism and nothing else It provides no guarantees of the delivery of any independent datagram in the network So QoS is needed in network protocols 8.2 Causes of Software Failures Failure or poor performance of a software product can be attributed to a variety of causes, most notably human error, the nature of software itself, and the environment in which software is produced and used 8.2.1 Human Factors In the human factor category, poor software performance can be a result of: Memory lapses and attentional failures: For example, someone was supposed to have removed or added a line of code, tested, or verified but did not because of simple forgetfulness Rush to finish: The result of pressure, most often from management, to get the product on the market either to cut development costs or to meet a client deadline, rushing can cause problems Overconfidence and use of nonstandard or untested algorithms: Before algorithms are fully tested by peers, they are put into the product line because they seem to have worked on a few test runs Malice: Software developers, like any other professionals, have malicious people in their ranks Bugs, viruses, and worms have been known to be embedded and downloaded in software as is the case with Trojan horse software, which boots itself at a timed location As we will see in Sect 8.4, malice has traditionally been used for vendetta, personal gain (especially monetary), and just irresponsible amusement Although it is possible to safeguard against other types of human errors, it is very difficult to prevent malice Complacency: When either an individual or a software producer has significant experience in software development, it is easy to overlook certain testing and other error control measures in those parts of software that were tested previously in a similar or related product, forgetting that no one software product can conform to all requirements in all environments 8.3 163 Risk 8.2.2 Nature of Software: Complexity Both software professionals and nonprofessionals who use software know the differences between software programming and hardware engineering It is in these differences that many of the causes of software failure and poor performance lie Consider the following: Complexity: Unlike hardwired programming in which it is easy to exhaust the possible outcomes of a given set of input sequences, in software programming, a similar program may present billions of possible outcomes on the same input sequence Therefore, in software programming, one can never be sure of all the possibilities on any given input sequence Difficult testing: There will never be a complete set of test programs to check software exhaustively for all bugs for a given input sequence Ease of programming: The fact that software programming is easy to learn encourages many people with little formal training and education in the field to start developing programs, but many are not knowledgeable about good programming practices or able to check for errors Misunderstanding of basic design specifications: This affects the subsequent design phases including coding, documenting, and testing It also results in improper and ambiguous specifications of major components of the software and in ill-chosen and poorly defined internal program structures As we already discussed in Sect 8.1.4, the environment in which a software product is produced and tested has a great bearing on its safety 8.3 Risk The first step in understanding the nature of software is to study the concept of risk, software risk in particular However, before we define risk, let us define hazard A hazard is a state or set of conditions of a system or an object that, together with other conditions in the environment of the system, or object, will lead inevitably to an accident [7] According to Leveson, hazard has two components: severity and likelihood of occurrence These two form the hazard level Risk is a hazard level together with the likelihood of an accident to occur and the severity of the potential consequences [7] Risk can also be defined in simpler terms as the potential or possibility of suffering harm or loss—danger, in short Peter Neumann defines risk as a potential problem, with causes and effects [4] Risk can be both voluntary, with activities that we knowingly decide to undertake, or involuntary with activities that happen to us without our prior consent or knowledge as a result of nature’s actions such as lightning, fires, floods, tornados, and snowstorms Since our focus here is on the big picture of the dangers of software in particular and computer systems in general, we will leave the details of the definitions at that How does risk play in software? Because we have defined risk as a potential problem with causes and effects, software risks, therefore, have causes and effects Among the 164 Software Issues: Risks and Liabilities causes of software risks are poor software design, a mismatch of hardware–software interfaces, poor support, and maintenance Others include [11]: • Personnel shortfalls • Unrealistic schedules and budgets • Developing the wrong functions and properties • Developing the wrong user interface • Continuing stream of requirement changes • Shortfalls in externally furnished components • Shortfalls in externally performed tasks • Real-time performance shortfalls • Straining computer-science capabilities Because computers are increasingly becoming a part of our lives, there are numerous ways computers and computer software in particular affect our lives In many of these encounters, there is risk involved For example, computers are used in medical care and delivery, in power generation and distribution, in emergency services, and in many other facets of life So wherever we are, be it at work, on the way to or from work, or in our own homes, where there is direct or indirect use of computer software, there is always a risk of an accident to occur For example, there is no way for a system manager to predict how and when a system failure or attack by hackers or viruses will occur As our world become increasingly engulfed with computer and telecommunication networks, networkrelated threats by hackers, viruses, system overloads, and insider misuse are increasing to such a level that the risk involved is shaping the way we work Appropriate and effective measures need to be taken to deal with risk Let us look at some here 8.3.1 Risk Assessment and Management Risk management is a process to estimate the impact of risk It is an approach for system managers to measure the system’s assets and vulnerabilities, assessing the threat and monitoring security For software, we look at risk management both during the design phase and during use Risk is an important aspect of the design process Because it is so important, two constituent components must be included These are assessment and control To implement these two components, there must be a requirement that no software project may be delivered or accepted until and unless a risk assessment or risk control evaluation has been carried out on it There must be documentation of the probability and consequences of hazards and accidents to help figure out what the risks are and what to about them The assessment aspects in the documentation should involve a list of all the potential dangers that are likely to affect the project, the probability of occurrence and potential loss of each item, and how each item ranks among all the listed items The control component in the documentation should consist of [11]: • Techniques and strategies to mitigate the highest ordered risks • Implementation of the strategies to resolve the high-order risks factors 8.3 165 Risk • Monitoring the effectiveness of the strategies and the changing levels of risk throughout the design process After the design process, when software is in use, risk management then involves the following phases: assessment, planning, implementation, and monitoring 8.3.1.1 Assessment This involves identifying the software’s security vulnerabilities and may consist of a variety of techniques including question and answer, qualitative assessment, or methodology and calculation A simple equation for calculating risk is Risk = Assets´ Threats´ Vulnerabilities 8.3.1.2 Planning Planning involves outlining the policies for security management 8.3.1.3 Implementation A good implementation may seek to match the security needs of the system with all available security tools 8.3.1.4 Monitoring Risk management is an ongoing process that needs constant monitoring This helps to determine the necessary changes and new security applications to the system The monitoring tools must be chosen based on the nature and applications of the system being protected For example, if the system being protected is a network, the tools may include a firewall as well as intrusion detection and network forensics software 8.3.2 Risks and Hazards in Workplace Systems The workplace is only second to our homes in the amount of time we spend there For most people with nine to five work schedules, work comprises about 40 h of the 168-h week When you figure in commuting to and from work and other work-related activities, we spend on the average 84 h a week at home Because we spend so much time outside our homes and in close contact with people from all walks of life and most often work with workplace machinery and people, which we call workplace systems, there is always a high risk associated with these systems, as well as with the commute to and from work In a workplace environment, accidents resulting from this three-faceted model of hardware, software, and humanware are caused by the intertwining of the components whereby each part affects the others According to Leveson [7], an accident is then a coincidence of factors related to one another through this intertwining Each component’s contribution to system accidents depends on the environment the system is in Different environments may cause different types 166 Software Issues: Risks and Liabilities of accident In some accidents, software may contribute more than the other two, while in others, humanware may contribute more, especially in cases where there is lack of effective training of the human component There is a perception that humanware is more prone to errors in workplace systems than both hardware and software According to Leveson, most workplace accidents are caused by what she calls a safety culture due to humanware—a general attitude and approach to safety consisting of overconfidence, complacency, placing low priority on safety, and accepting flawed resolutions of conflicting goals To these we also add poor employee training and poor employee morale In workplace systems where there is a transient human component, overlooking the human component for a critical-safety decision-making process may result in high-risk system safety This perception is enhanced by the credibility problem and the myth about computers People still hold the computer dear that it is more reliable and creates less risk, that software testing eliminates software errors, that increased software reliability automatically implies increased safety, and that reusing software increases its safety level All these are myths Software safety is as unpredictable as its counterpart, the humanware For those with such perception, there is good news The development of intelligent computer technology and communication devices may lessen the human component in the workplace However, this does not mean that workplace systems will be error-free It will, however, shift the burden on software since hardware errors are more readily predictable than those by humanware and software Hardware errors can easily be located and fixed Software errors, on the other hand, may take many hours before they are found, and fixing them may take even longer Yet software systems are becoming even more complex with complicated codes and tight delivery schedules 8.3.3 Historic Examples of Software Risks In the maiden days of the “Wonder Machine,” risk and vulnerability of both the computer user and data were not a problem Software was unknown, the way we know it today, because it was embedded Also, the computing system consisted more of hardware than software, and projects were small As systems became smaller and less dependent on hardware, software came out of the hardware, and projects became bigger, complex, and more dependent on software and humanware Then the problems of risk and vulnerabilities set in Ever since then, major system mishaps in hardware, software, and humanware have been recorded that have given us a glimpse of the development of computer systems and the long road that system safety, vulnerability, and risk have taken In his book Computer-Related Risks [4], Peter G Neumann, for many years the moderator of the online Internet group, “the Risk Forum,” and contributor to ACM’s “Inside Risk,” has documented a wide collection of computer mishaps that address problems in reliability, safety, security, and privacy issues in day-to-day computer activities ... and clevis in the region of the joint’s O-rings was no more than 0.008 in and the average gap would have been 0.004 in (d) With a tang-to-clevis gap of 0.004 in. , the O-ring in the joint would... of the space program The combination of these and other matters surrounding the accident, including problems within NASA, forced President Ronald Regan to appoint a commission of inquiry into the. .. 13,000? ?20 ,000 rads instead of the normal 20 0 rads Anything over 500 rads can cause death The Therac? ?25 used a software upgrade of the older model of the Therac–6 The manufacturers of the Therac? ?25 ,