Adrian Crenshaw

    I originally wrote this for a class, but decide to post this on my website (hell, content is content). I’ve edited it somewhat to more closely reflect my views. Business ethics is sometimes not ethics at all, but "public relations containment". The layout was specified by the class, so it may look a little odd to some of my readers. If nothing else, this could be useful for other students having to write a similar paper.

• Software companies and system designers, hence forth revered to as vendors for brevity
• Security researchers
• Companies that purchase and implement software and systems (here after referred to as "business clients" for the sake of brevity)
• End users of the software and systems, because of the potential size of this group it should be considered full public disclosure and I will frequently refer to them as the "general public" throughout this paper
• Criminals

• Security researchers (this will be the focus as that is who is asking the question)
• Law makers
• Software companies and system designers
• Companies that purchase and implement software and systems
• End users of the software and systems, but this category is assumed to encompass the whole world

    As security researchers we have the choice to reveal vulnerabilities in software and systems in many different ways, and to different extents. There is a whole menu of options on how much to reveal about the vulnerability, who to reveal it to and when. For the sake of clarity, let’s create such a menu:

Amount of disclosure:

1. No disclosure (keep all details a secret)
2. Partial disclosure (give enough information for end users and business clients to mitigate vulnerabilities, but hopefully not enough for criminals to attack systems)
3. Full disclosure of all details

Who to disclose to:

1. Software companies and system designers
2. Other security researchers
3. Business clients
4. End users

When to disclose:

1. Immediately
2. After the vulnerability has been fixed
3. After the Software companies or system designers have had adequate time to address the problem, regardless of whether or not the problem is fixed

    Multiple choices can be made from each list, and choices on each list are not mutually exclusive. We could choose full disclosure for one category of stakeholder, and limited or no disclosure to another. Also, when the disclosures happen can be selected by stakeholder category. Under different circumstances, varying amounts of discloser to different stakeholder categories at different times may be appropriate.

    Because there are so many permutations, let’s narrow the options down to four common courses of action in the security industry. Since there is some ambiguity, I will try my best to explicitly define the terms, other researchers may have differing definitions. Asking "What is responsible disclosure" to security researchers is a little like asking "What is God?" to a bunch of philosophers/theologians, you will get all sorts of answers back.

As soon as the vulnerability is know, all details are full published to the public.

    The security researcher keeps the vulnerability to themselves. One might wonder why a researcher would want to do this, after spending all of the time to find the vulnerability. Two main reasons come to mind. First, there may be legal issues with disclosing it, and the researcher fears the reaction of the system developers. A second is that the researcher may want a vulnerability in their arsenal that they can use and know has not been fixed. These are known as "zero days" or "0-days" in the industry since it has been zero days since the problem has been patched. It should be noted there is some ambiguity with the term 0-day as well, as the term is sometimes used for a vulnerability that is known to the public/vendor but not patched yet, and sometimes the vulnerability is unknown to anyone but a very small group. 0-days are quite useful to criminal attackers because of their high likely hood of working, and on the legal side professional pen-testers (experts hired to act as attackers by a company to check for vulnerabilities) may use them as well.

    Only the vendor, and perhaps some corporate clients, are told about the vulnerability.

There is much debate on how to define "Responsible Full Disclosure", but a few of the general principle include:

1. Tell the vendor about vulnerability and give them time to fix it (sometimes referred to as giving them time to patch).
2. Let the public know enough so that the risk can be mitigated, but hopefully not enough so that criminals can use the vulnerability in an attack.
3. Once the vulnerability has been patched you may release the full details.
4. If the vendor ignores the researcher during step one, a partial or full disclosure to the public may be in order to force their hand into fixing the issue.

Now let’s apply some of the models of ethical testing to these four options.

It is my personal opinion that all these models fall far short of being really useful, but people involved in "business ethics" seem to love them.

1. Have you defined the problem accurately?

    For this question all four possible courses of action seem to have the same answer. As I understand the problem, yes, it seems to have been defined accurately. Different types of vulnerabilities will add variance to the problem however.

2. How would you define the problem if you stood on the other side of the fence?

    There are so many fences here that the answer is complicated. I’ll have to break it down by the four courses of action, and how they might see the other courses of action.

How Immediate Full and Public Disclosure proponents might see the other courses of action:

How Complete Nondisclosure proponents might see the other courses of action:

How Limited Disclosure proponents might see the other courses of action:

How Responsible Full Disclosure proponents might see the other courses of action:

3. How did this situation occur in the first place?

    With all courses of action the answer to this question is pretty much the same. The vendors made a mistake or a compromise in the design of their system or software that lead to a security vulnerability. Now the question is what is in the public’s best interest with regards to keeping the damages to a minimum.

4. To whom and to what do you give your loyalty as a person and as a member of the corporation?

    This would depend greatly on who is answering. The ethical answer would seem to be loyalty to the public good. The question is: how is the public best served in this decision. I’m not sure that all of the proponents of the four courses of action have the same loyalties. This will be made somewhat clearer in step 5. While in might be somewhat cynical, this would seem to be the loyalties of the different proponents.

5. What is your intention in making this decision?

    The answer to this question is highly dependent on the course of action.

6. How does this intention compare with the probable results?

    I can only judge this based on my past experience in the security field, but the following seem like likely outcomes.

7. Whom could your decision or action injure?

8. Can you discuss the problem with the affected parties before you make your decision?

9. Are you confident that your position will be as valid over a long period of time as it seems now?

    This question will have to be answered base on my personal experience in the field. It should be noted that actually proponents of each of the courses of action are likely to feel differently.

10. Could you disclose without qualm your decision or action to your boss, your CEO, the board of directors, your family, society as a whole?

    The following would be my reaction if I was to follow the course of action specified.

11. What is the symbolic potential of your action if understood? Misunderstood?

12. Under what conditions would you allow exceptions to your stand?

    It should be noted that the threat of litigation is likely to change any of these groups’ stands. Barring that, these seem to be the likely circumstances under which the proponents of the different courses of action would change their selection.

Now let’s move on to a different model to test with.

1. Is it legal?

    Ok, right here and now, I’ve got to say I dislike this model since I see ethics and law being only tenuously connected. Still, let’s go with it. The answer for all courses of action is a tentative yes, however there are exceptions which I will cover more in the legal in the section of this paper. The specifics of the vulnerability, and how it was found, greatly change the legality of the matter.

2. Is it balanced?

3. How does it make me feel?

    Ok, so I’ve applied two of the common ethical models, now for my personal thought processes on how to make a decision on what is ethical when it comes to disclosure. At times, giving the world information about a vulnerability could be like giving a lighter and an espresso to a five year old, fun to watch if it’s not in your neighborhood, but still a bad idea. That said, trying to keep secrets about vulnerabilities, or forbidden knowledge in general for that matter, is like the proverbial Genie in the bottle. If one person can figure it out, so can another. I feel everyone knowing something helps even the playing field, especially form a mitigation standpoint, and is better than letting only an elite few have the knowledge. Still, there are some things I would not want to reveal to the world until I had time to mitigate the damage they could cause (making sure that hyped up five year old was playing in an asbestos room, EPA not withstanding).

    Of the four courses of action listed, only two seem to possibly be ethical by normal standards: "Limited Disclosure" and "Responsible Full Disclosure." Of the two, Responsible Full Disclosure seems the most balanced for its effect on the various stakeholders. Both have their potential ethical issues:

    Of those two options for course of action, I would choose Responsible Full Disclosure, but would want the following steps followed:

1. After the vulnerability is understood, give the vendor a reasonable amount of time to fix the vulnerability.
2. If the vulnerability is severe and likely to be exploited before the vendor has a chance to fix it, then give enough information to the public so they may mitigate the threat.
3. If the vendor does not wish to fix the problem, or is taking an unreasonable amount of time, and the vulnerability is likely to be discovered by others in the mean time, then immediately give enough information to the public so they may mitigate the threat.
4. Publish full information about the vulnerability so that future system designers can learn from it.