ALMACENAMIENTO MAGNETO-ÓPTICO

Majzik (2005) establishes the links between fault with system reliability, availability, safety, and security by the following dedactions. First, if we can prevent fault from occurring, we can then attain system reliability. Second,

if we keep fault within a specified tolerance level, we can then attain system

availability. Third, if we remove fault, then we can assure system safety. And,

finally, if we get good at forecasting fault and acting on it, then we assure

system security.

We have stated several times, and this is an emphasis, that 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 many more risks on systems through software vulnerability, than hardware faults.

In his paper Why.do.Computers.Stop.and.What.Can.be.Done.About.It?, Gray

(1986) classified software faults into Bohrbugs and Heisenbugs. Bohrbugs are essentially permanent design faults and hence almost deterministic in

nature. This makes them easy to identify and fix. Heisenbugs, on the other

hand, belong to the class of temporary internal faults and are intermittent. They are permanent faults whose conditions of activation occur rarely or are not easily reproducible. Hence, they cause transient and intermittent failures that may not recur if the software is restarted. Heisenbugs faults are, there-

operational phase is more likely to experience failures caused by Heisenbugs, than due to Bohrbugs.

In their book.The.19.Deadly.Sins.of.Software.Security, Howard, LeBlanc, and Viega (2005) list software faults as the most deadly faults for software products. These 19 faults are:

1. Buffer overflows

2. Format string problems 3. SQL injection

4. Command injection

5. Failure to handle errors 6. Cross-site scripting

7. Failing to protect network traffic

8. Use of “magic” URLs and hidden forms 9. Improper use of SSL

10. Use of weak password-based systems 11. Failing to store and protect data 12. Information leakage

13. Improper file access

14. Integer range errors

15. Trusting network address information 16. Signal race conditions

17. Unauthenticated key exchange

18. Failing to use cryptographically strong random numbers 19. Poor usability

Of all types of software faults, Neumann (1993) considers improper encap- sulation, inheritance of unnecessary privileges, and inadequate enforcement

of polymorphism as 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. Although software, as the main component of computer systems, causes most of the system faults, humanware also comes close to software.

According to Davis (1985), 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 software. If Davis’ observation is true, then computer security and, hence, system software security greatly depends on the education of system devel- opers and knowledgeable users.

Safety

Recent advances in computer technology have resulted in computer applica- tions 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 within system safety is software execution within a prescribed context so as not to contribute to hazards or risk, either by outputting faulty values and timing or by failing to detect and respond to hardware failures that may cause a system to go into a hazardous state. According to Leveson (1995), 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 en- vironments, no one software product can conform to all of the requirements in all of the 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 (1993), whereas the requirement for a rate of failure occurrences 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 practices, which include control techniques, application of various types of safety analysis during the develop- ment 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 environment.

Software.Quality

Until recently, software was produced in house to meet the needs of the or- ganization or business. This changed and, in fact, has changed several times. First, software production was commercialized when system requirements started to evolve, becoming more and more complex. Big software houses started out small, but these were soon acquired by bigger ones, until they were a few monstrous ones left. This was supposed to improve quality. But as we all know now, they did not. Business interests took over. To make the safety problem more complex, two recent developments have made the problem worse. These are outsourcing and object-oriented programming.

Object-Oriented Programming

Object-oriented programming was meant to liberate software development from its static days to a more dynamic and robust development process that reduced development time because parts could be re-used. At least for a time, this was dear; that is, until we understood the problem it created. It allowed foreign code to freely enter trusted code in the name of re-use. Interface re-

quirements and specifications were ignored, as long as it worked. The result

of it all has driven down software quality.

Outsourcing

Perhaps the biggest threat to software quality at the moment is outsourcing. Software outsourcing is software for hire. Quality issues are bargained and many times compromised. When we outsource software, we are never sure of its quality. Outsourced software is like outsourced t-shirt—who will ever care about quality.