One of the common problems is that an outsider will find a vulnerability in a computer system. An “outsider” is a person who does not have an employee relationship or a contractual relationship with the company or organization with the problem. The problem is how does the outsider report the problem without getting in trouble him or herself, but in such a way that the problem gets dealt with? The problem is complicated because this procedure must not create a process by which a Bad Guy can escape the consequences of his or her actions. The steps are:
Examine your own motives, and if they are suspect, stop.
Find out who is in a position to receive such a report
What the report should contain and what should be left out.
Checking the report
Delivering the report
Ultimately, the process of reporting the vulnerability is a human process and not a technical one; many of the key decisions will be made by people who do not understand computers very well and the remediation will be made by people who are already overworked. This essay is motivated by discussions of first principles of ethics; any technical discussion is really secondary to the main point. So hopefully, this essay should be accessible to both computing professionals and others.
People are motivated by all sorts of things, money, fear, fame, glory, the urge to do The Right Thing, revenge, etc. Why do you want to report a problem? If you don't know, or aren't sure, then stop reading this essay and do a little self-analysis, because intent is key for a lot of discussions about ethics.
If you are interested in making money from the vulnerability, then do not proceed. There is no ethical way you can exploit a security vulnerability for money. Consider all of the superheroes in fictional literatures: they are either broke (Consider Peter Parker, a.k.a Spider Man), or they are independently wealthy (Bruce Wayne, Batman; Brett Reed, a.k.a The Green Hornet), or they have jobs that keep them reasonably financially secure (Clark Kent a.k.a Superman). But they never take money for doing Good Deeds. Neither do Boy Scouts, nor does the U.S. Coast Guard (who are borderline superheroes themselves). So if you are interested in either extorting money (Pay me or I'll publish the vulnerability on the USENET) or contracting (If you'll sign a contract, I'll fix not only this vulnerability but take care of all your computing security needs), your goal is ethically indefensible: stop reading this essay, you're wasting your time.
If you are trying to break in and get caught, then the explanation that you found the possibility of a vulnerability and wanted to investigate further before reporting is going to ring hollow. Sorry - this paper doesn't give you a "pass".
You might be interested in developing a reputation. This is common with people who are in school or just out of school. I understand that there is a lot of pressure to Do Something to stand out from the crowd. I understand further that the technical description for the current economy is “it sucks”. However, reporting vulnerabilities is not going to accomplish your goal. If you want to develop a reputation, the best way to do so is to join professional organizations such as SANS and write papers (such as this one), give speeches, and lead seminars. Most professional organizations will waive dues or give you a deep discount if you plead poverty, I know SANS will (Actually, I don't know that – but you damn well better give discounts on dues on the impoverished who want to join!). Membership in a professional organization, and getting your name on a byline is a great way to enhance your reputation. But not by reporting problems. That will come.
However, you might be an employee of a company with a vulnerability, and you might be aware that a Bad Guy could shut down your business. Or you could be a customer or a supplier that is worried that a valuable business partner could go down the tubes. This is fear, and it can be a powerful motivator. These are legitimate motivations.
Or you might be genuinely motivated to Do The Right Thing. This paper was motivated, in part, because somebody dumped a problem in my lap and expected me to Do Something about it. This person was (is) a friend of mine – friendship is about loyalty and mutual support, so my friend's problems can be my problems.
If you fall into one of these latter two categories, then read on.
The first step is finding out who should get the report. Some organizations are astonishingly lax about their computer security: everybody has the root password (UNIX), the administrator password (MS-Windows), or the system password (OpenVMS). Other organizations have a sysadmin, but the sysadmin reports to lots of different people. One organization had the sysadmin in marketing! However most organizations recognize the importance of good system administration and have a sysadmin staff and a manager who runs them. In general, you want to go to the system administrator and his or her manager at the same time.
Some organizations have designated security organizations or persons. If so, then these people are the logical place to report the problem. They will do the investigation and contact the relevant people: that's their job. They are the proper point of contact if they exist for this organization.
The report of the vulnerability should be good expository writing, and cover the 5 W's: who, what, where, when, why, and how. Specifically:
Who are you and what is your relationship to the organization?
What is the problem?
Where is the problem?
When did you discover the problem?
How did you find the problem?
Why is the problem a problem?
Also, there are some things that must not go in the report: insults, ultimatums, and unfair comparisons.
Your objective in writing the report is bring the problem to the attention of the organization, so that they will Do The Write thing about it. If you write to them anonymously, then they will either ignore you as a crank or an eccentric or else they will panic. Neither response is proper. So tell them who you are and what you are to them, which will reassure them and make it easier for them to query you if they need clarification
Tell 'em what the problem is. If the problem needs more investigation, then say so. However, it is not your job to do that investigation unless they specifically ask you to.
Which computer or which computers are suffering from the vulnerability? Is it a network problem? Do you know that the problem is on one machine and suspect it might be on others? That's okay – say what you know and what you suspect.
Although most people assume that the time between discovering the problem and reporting the problem will be short, that isn't necessarily the case. For example, I was examining some old server logs for a technical problem and I discovered that I had been hit by the nimbda virus three weeks ago. So I reported that three weeks ago, my machine had been hit by your machine which looks like it was infected by nimda, and I have not been hit since.
This is important because it tends to exonerate you if you are doing something innocuous (I was examining my own server logs) or incriminate you if you are doing something else (I was running nmap on random IP addresses looking for machines with port 111 exposed). It also helps the sysadmin test his or her own machine to verify that the problem still exists and also that he or she has fixed it properly.
Let's face it: a lot of sysadmins are not as knowledgable as you are. It's hard to run a system and keep up with all the bug fixes and patches. Also run backups, monitor the firewall logs, implement the new stuff, fix the old stuff, etc. So don't assume that the sysadmin knows what you are writing about. The description doesn't have to be very long, it could be as simple as “For more information, refer to this web site...”, or “here is the article in SANS that describes the problem in more detail”.
Do not insult the sysadmin. If he or she is honest, then they will send your message to their management. Don't make that hard for them. System administration is a hard job already.
Do not issue an ultimatum (“If you don't fix this problem, then Bad Guys will break into your server tonight and fill the registry with random ones and zeroes”). That is terrifying and it makes you look bad.
Unfair comparisons are – well - unfair. Don't write that the local bank does a better job of security than your non-profit does: the bank ought to have better security than the non-profit does. Not that non-profits should be wide-open, they shouldn't, but banks have been doing security for a long time, and they are really good at it.
Don't moralize. If you don't think much of online pornography, then don't send a message that says "you deserve to be cracked" to a porn provider. Do not send "It is the will of Allah" to an Israeli site. If you are a student at the University of Washington, do not audit sites at Washington State and vice versa. This also means, and I hate to write this, that reports of vulnerabilities are not good places for Anti-Microsoft diatribes, no matter how richly deserved it might be. To be fair, then, do not write that "Software is worthy what you paid for it" to an open-source site.
It's always a good idea to run the report past a trusted friend. The friend should be given this paper or a synopsis of this paper. Then ask the friend – does this report do what this paper says it should do? Are my motivations just? Are there hidden insults? Is it clear?
Ideally, you should be able to identify the system administrator and the person they work for. Send an E-mail message to both. If possible, use the return receipt requested feature in your E-mail program. Be sure that you identify yourself and your E-mail address, in other words, do not use an anonimizer nor a mangled anti-spamming address. If you doing this report for honorable reasons, then assume your recipients are going to respond honorably as well.
After you have examined your motives, figured out who to contact, written the report, checked the report, and delivered the report, what next?
Aside from checking that the mail message has been delivered, that's it. Really. Every organization has to decide what their security stance is going to be, and it depends on the business processes and the business cases that their management makes. The department of Defense, for example, forbids any connection between computers with classified information and the internet. They accept the inefficiencies that this policy entails in exchange for the extra security. A company might be doing file transfers with business partners using NetBUI or NFS (I would hope not, but that's the case in many places). You might have also found a honey pot, and it might be their policy not to respond to reports of assaults on the honey pot. So, you've done your good deed for the day, now let go and move on.