Responsibility and Blame in Computer Security – 3. Blame – The Research Center on Computing & Society

Text-only Version

Dorothy E. Denning

3. Blame

Blame arises whenever something goes wrong and a person is held responsible. In common usage, blame also carries with it three additional connotations:

The accuser has assessed that the responsible party has produced significant negative consequences for the accuser or for others by his or her action (or inaction).
The accuser seeks to have the responsible party forced to make good (undo the negative consequences) or to be punished.
The accuser sees some violation of moral principles in the responsible party’s action.

Thus, being blamed can produce negative consequences to the person blamed, for example, a lost job or friend, lost trust, fewer opportunities, fines, or imprisonment. A person can attempt to minimize such consequences by taking actions that avoid possible failures, and by taking care of the negative consequences of failures that happen anyway. For example, a person can make promises only after assessing that they can be fulfilled, re-negotiate agreements when something happens that makes fulfilling a promise impossible, make sure that all agreements are clear, be informed about relevant laws and practices, and avoid conflicting obligations. If something does go wrong, the person can make reparations and attempt to undo the negative consequences. A person who lives according to these principles is usually characterized as responsible, reliable, and trustworthy.

We can use the distinctions for responsibility and failure to determine who may be responsible in a situation involving computer misuse, and why the breach of security may have happened. Here we will consider the case of an unauthorized break-in by a “cracker.”

3.1 Responsibilities

We will first consider how each type of responsibility relates to several players: the cracker, system manager, users on the system that was cracked, and the vendor.

Moral: Most people agree that break-ins are unethical, though some crackers argue they are not because they expose vulnerabilities. Crackers also argue that simple break-ins do not hurt anyone.
Formal contracts: The system manager is not likely to be under formal contract to provide security. The vendor, however, may have contractual stipulations about correctly representing the security features of the system, about delivering a system satisfying certain criteria for trusted systems, or about delivering fixes to security flaws once they are discovered.
Informal agreements: The system manager may have agreed to take responsibility for the security of the system. However, it is possible that nobody in the organization ever seriously considered security and no agreement was made.
Laws and regulations: The cracker is held responsible for abiding by the computer crime laws that prohibit unauthorized access.
Standard practices: The system manager may be held responsible for knowing the standard practices in the computer security community and following these practices on the system. Users may be held responsible for following security practices adopted by the organization, for example, about passwords.
Declarations: The system manager may have said he or she would take responsibility for the security of the system, even if the person’s boss never asked the manager to do so.

3.2 Causes of Failure

We next consider ways in which each type of failure could explain the break-in. This list is by no means exhaustive, and we invite the reader to consider other possible explanations.

Incompetence: The system manager may have been unfamiliar with the steps needed to secure the system, unable to install or implement necessary security mechanisms, or unable to manage his or her commitments. The employees of the vendor may have been incompetent at delivering a system that meets its specifications or at distributing fixes in a timely fashion.
Insincerity: The system manager may have been insincere when taking on obligations. The vendor may have intentionally overrated the security of the system.
Blindness: The security manager may have been unaware of the particular vulnerability that the cracker exploited, but capable of fixing it had he or she known. The users may not have known about the security practices of the organization and chosen easily cracked passwords. The vendor may have been blind to some of the vulnerabilities in its system. The cracker may have been blind to the consequences of his or her actions on others and ultimately on himself or herself. Many crackers do not realize the cost of their actions in terms of lost time and money to the organization, and lost opportunities for their own future arising from the negative assessments made of them by society.
Vagueness: The concept of “computer security” is vague unless accompanied by a precise and clear security policy. All of the players may have made a different interpretation of security. The security standards given to users may have been unclear.
Conflicts: The manager may have had conflicting obligations, or accepted some risk in order to provide the users with desired functionality. The manager may have lacked adequate resources to fully protect the system. The employees of the vendor may have had similar conflicts.
Unforeseen circumstances: The manager may have installed a system change that inadvertently introduced a vulnerability that nobody had anticipated.
Impossibility: It is not possible to provide fully secure systems under almost any interpretation of security.

3.3 Taking Responsibility

The preceding analysis shows who is likely to be blamed after a break-in, and the possible explanations for security failure. The break-in could lead to negative consequences to the cracker, to the system manager and his or her organization, and to the vendor. The organization may suffer losses of time and money spent recovering from the break-in and lost credibility with its customers. The vendor may suffer lost credibility for its products.

By taking responsibility, people in the organization can attempt to avoid the losses that can otherwise result. The system manager’s boss can make sure the manager is competent and willing to take responsibility for the security of the system, and that he or she has the necessary resources to do so. The system manager can make sure that he or she stays informed about vulnerabilities, that users are informed about security practices, that all passwords are well chosen, that fixes are installed promptly, and so forth. Similarly, employees working for the vendor can take responsibility for the security of their products and for their correct installation and use.

Taking responsibility, however, also has its costs. For the organization, it includes money spent on security that might otherwise go into improvements in performance or functionality on the system, better customer service, investment in new products or services, or higher salaries. For the vendor, it includes the extra cost of developing more secure products, and the cost of making sure the systems are properly installed and maintained. Again, these costs may cut into other programs, such as the development of the next generation of machines.

In deciding whether to take responsibility for avoiding break-ins or other types of computer misuse, one must evaluate these advantages and disadvantage. The organization using computers must consider its assets, the cost of each type of misuse, the cost of security, what its competition is doing, and so forth. The vendor must likewise consider the cost of providing systems with certain security features, and the effect of that on its position in the marketplace. Neither of these are simple decisions. The decisions are complicated by a lack of clear standards for computer security and a general sentiment that it is not possible to have 100 percent security.

4. Summary

I have given a set of distinctions relating to responsibility and failure that allow us to investigate situations in which something goes wrong or could go wrong. These distinctions were then used to analyze a computer break-in in order to discover who might be blamed for the break-in and possible explanations behind their failure to meet their responsibilities. The analysis of this particular situation could be taken deeper, and it could be broadened to consider other types of computer misuse and the responsibilities of other players such as researchers, the government, standards organizations, and so forth. The real value of performing such an analysis is not in pinning the blame and punishing the culprit. Humans must satisfy many conflicting and challenging obligations, and do so out of considerable blindness. In this context, faults are common and compassion is essential. The value of the analysis is in the learning that takes place. By finding the areas of fault, we can design new human practices or computer systems that better meet our objectives. If a system is broken into, then the system manager’s boss could fire the manager. A better strategy might be to send the manager to a computer security course, enroll the manager in a professional organization for security managers, hire a consultant for a day, relieve the manager of certain responsibilities, give the manager additional resources to do the job, or send the manager to a course on managing promises.

The distinctions also provide road maps for assessing our own responsibilities. If we all used them more, we would be better able to observe the domains in which we are not living up to our responsibilities. We could avoid many situations that lead to blame and negative consequences for ourselves and others.

Georgetown University

Acknowledgments

I am grateful to Peter Denning and Steve Steinberg for their comments on an earlier version of this paper.

End Notes

1. Neumann, P., “Computer Security and Human Values” in Terrell Ward Bynum, Walter Maner, and John L. Fodor, eds, Computing Security, Research Center on Computing & Society, 1992, pp. 1-30. (See above.)

2. Denning, D., “Hacker Ethics” in Terrell Ward Bynum, Walter Maner, and John L. Fodor, eds, Computing Security, Research Center on Computing & Society, 1992, pp. 59-64. (See below.)

Back to the top

Go to: Computer Crime, Computer Security and Human Values – Citarella

Home > Research Resources > Computing Security > Responsibility and Blame in Computer Security

The Research Center on Computing & Society
at Southern Connecticut State University
501 Crescent Street • New Haven, CT 06515
Director: (203) 392-6790 • e-mail: webmaster@computerethics.org

© 2000 – 2007 – Research Center on Computing & Society