From: Michael Puchol Date: Thu Mar 28, 2002 0:59pm Subject: Re: Trojan vendor dishes the Dirt Whaaaa??? > "The only reason it is of interest now is because someone got hold of > a marketing presentation that was not for public disclosure. In fact, > the product's existence was not meant to be public knowledge," he > said, adding that "if we find that person we will file a criminal > complaint through the Secret Service". This crap has been on their site for months (maybe even years), for anyone to see - I cannot believe they're saying this... > James said that he would "love to demonstrate the tool", but since > vnunet.com is not an officially recognised law enforcement agency, he > could not. Demonstrate a trojan? There are plenty out there in the wild, just ask NAI or other competent antivirus firm to make a demo, they have quite a collection. > The reputation of Codex has been called into question after it was > revealed by UK news website theregister that company chief executive > Frank Jones is a convicted felon and known fraudster currently on > probation for illegal possession of surveillance devices. 'nuff said. > James was forced to acknowledge that the only reason Dirt is > undetectable by antivirus software is because no antivirus company > has ever seen it, and that it could only be used as a "last resort" > tool after obtaining a court order. If it actually exists, and if its actually used by anyone, which I doubt (both counts) it won't be long until an antivirus company sees it, and then that's it. > As for the ability to bypass firewalls, done by killing the process > in the operating system, there is no explanation as to how it attacks > the firewall in the first place. Any decent firewall will prevent access to and from an outside network, and will signal any attempt to do so. And, if the trojan does what it says, then what better symptom as to it's presence than your firewall spontaneously shutting itself down? > However, Paul Rogers, network security analyst at MIS, who has met > the company, said he was very impressed with the standard of > keyloggers Codex offered, but as he had not seen Dirt in action, he > remained sceptical. Yes, they could fool someone with only basic computing skills, but that's that. Anyway, a pile of cow dung. With flies around it. Cheers, Mike 5074 From: James M. Atkinson Date: Thu Mar 28, 2002 9:49pm Subject: A Perfect Spy A Perfect Spy March 27, 2002 Is George Trofimoff one of the greatest spies ever to betray America, or a loyal army officer who spent a career defending this country? One thing is sure: Col. Trofimoff, retired from the U.S. Army Reserve, is the highest ranking American officer ever convicted of espionage. Last summer, a federal judge sent him to prison for life. During his trial, prosecutors called Trofimoff the perfect spy. He was perfect, they said, because of the extraordinary crime he managed to pull off without ever getting caught. Interviewed by 60 Minutes II correspondent Scott Pelley in a Florida prison, Trofimoff, 74, calls himself "a patriot that served this country for 46 years and a half or 47 years." His story is intertwined with the bloody history of Europe. The Trofimoff family was Russian. He says his grandparents were murdered in the revolution and, as a boy in World War II, he was rescued by American GIs. When Trofimoff joined the U.S. army to fight the communists that murdered his grandparents, he left behind a brother, Igor, who became a clergyman and was a cardinal in the Russian Orthodox Church. Trofimoff spent his career in military intelligence. He was so far above suspicion that he was put in charge of a house in Nuremberg, Germany, where American intelligence would interview defectors from the Soviet Union. The interrogation center contained a library of classified information, everything the U.S. knew about the Soviet Union that interrogators used in questioning defectors. Then in 1992, a Soviet KGB clerk named Vasili Mitrokhin defected and claimed that one of the U.S. interrogation centers was being looted by a spy. He handed over KGB records that showed the stolen American secrets exceeded 80 volumes - 50,000 pages taken over 25 years. Christopher Andrew, a Cambridge University professor who helped British intelligence analyze Mitrokhin's revelations, says the information included military intelligence operations planned and carried out by the United States against the Soviet Union. Mitrokhin didn't have the name of the traitor, but the Soviet files he delivered described the spy as a "career American intelligence officer." And the courier who carried the secrets was a "clergyman" in the Russian Orthodox church. "An American officer who gave it to the Soviets through a Russian priest. And that fit me like a glove. No question about it," says Trofimoff who often met his brother in Germany. "My brother was traveling outside the Soviet Union," he says. "So I have no doubt in my mind that the KGB had their eyes on him. And controlled him in a way." In 1994, Trofimoff and his brother were arrested by the Germans, an arrest based solely on the sketchy description in Mitrokhin's KGB archive. The brothers were released immediately. A judge said there was no evidence that they were the men described in the files. Cleared, Trofimoff left Germany to retire in Melbourne, Fla., where he bought a house on Patriot Drive and settled into a quiet retirement. Then on July 10, 1997, he received a hand-delivered letter from "friends" in the Russian embassy. One of them, Igor Galkin, wrote and phoned from the embassy repeatedly seeking a meeting and offering him money. Trofimoff tells Pelley he thought his brother's church was trying to send him money through Russia's Washington embassy. Trofimoff was in debt and once told his brother he needed cash. So Trofimoff agreed to meet Galkin in Florida. Galkin was an undercover FBI agent and there was a hidden camera in the room. Galkin turned the conversation to military intelligence and asked Trofimoff whether he had ever met KGB agents in Europe. For six hours, the conversation rolled out like a confession with Galkin asking what documents, Trofimoff had stolen from the interrogation center. Trofimoff says he invented a story because he believed if he pretended to be a retired spy, the Russian church would have reason give him money "At the time, I wanted to convince him that I worked for the KGB," Trofimoff tells Pelley. "I can't explain the logic behind it anymore. My major logic was, I need money, they need a reason to help me. They need a justification, so I'm going to try to provide them with that. And that's what I did." At his trial, prosecutors called a star witness, Gen. Oleg Kalugin of the Soviet KGB, who told the jury the names of KGB agents who worked with Trofimoff. They were the same names Trofimoff remembered in one of those phone calls with the FBI undercover agent. But Trofimoff tells Pelley, "I have never met any of these people anywhere. And when I picked those names, I just happened to pick them." In his testimony, Kalugin said he arranged a meeting with Trofimoff in Bad Ischl, Austria, about 150 miles from Nuremberg. Kalugin wrote about this unnamed American spy in his memoirs, but there are key differences between the story he told on the stand and the one in the book. Among other things, the book says there were several meetings and in a different city. Trofimoff says Kalugin is lying. "If you look at the entire trial, they don't have single piece of evidence, except Kalugin," says Trofimoff. "It's what Kalugin says against what I say." But Trofimoff himself said plenty to the undercover FBI agents. He explains this, saying "Kalugin says a lot of things in this book and he admits he lied, right? Now, I said a lot of things during the interview with Galkin, which I admit were lies. If they believed Kalugin's lies were lies, why don' t they believe my lies were lies? You see?" The jury believed the prosecution. Prosecutors said Trofimoff took the files from the interrogation center little by little, photographed them, and gave the film to his brother. They said the motive was money, but they also admitted it was a perfect crime. There's no physical evidence, just the word of a former KGB general. Since this all began, the Communists have fallen and his brother has died. But Trofimoff maintains his innocence. "I can't say something that I don't know," he says. "Because I have never, never had anything to do with them. And I will repeat that until I die, or until I clear my name." © MMII, CBS Worldwide Inc. All Rights Reserved. -- -------------------------------------------------------------------------------------------------- The First, The Largest, The Most Popular, and The Most Complete TSCM, Bug Sweep, Spy Hunting, and Counterintelligence Site on the Internet. -------------------------------------------------------------------------------------------------- James M. AtkinsonPh: (978) 546-3803 Granite Island GroupFax: (978) 546-9467 127 Eastern Avenue #291http://www.tscm.com/ Gloucester, MA 01931-8008mailto:jmatk@t... -------------------------------------------------------------------------------------------------- "...three shall be the number to count, and the number to be counted shall be three.....four shall thou not count......five is right out". - M. Python -------------------------------------------------------------------------------------------------- 5075 From: James M. Atkinson Date: Thu Mar 28, 2002 9:50pm Subject: FBI to divulge more Carnivore details http://news.com.com/2102-1023-870028.html FBI to divulge more Carnivore details By Gwendolyn Mariano Staff Writer, CNET News.com March 27, 2002, 1:40 PM PT Privacy advocates have won another round in their fight to gain access to more information about the FBI's Carnivore e-mail surveillance system. A federal judge this week ordered the FBI to expand its search for records about Carnivore, also known as DCS1000, technology that is installed at Internet service providers to monitor e-mail from criminal suspects. The court denied a motion for summary judgment and ordered the FBI to produce within 60 days "a further search" of its records pertaining to Carnivore as well as a device called EtherPeek, which manages network traffic. The FBI has defended Carnivore by assuring the public that it only captures e-mail and other online information authorized for seizure in a court order, but the Electronic Privacy Information Center (EPIC) has voiced concerns over potential abuse. EPIC sued the FBI, the investigative arm of the Justice Department, in July 2000 under the Freedom of Information Act so it could examine Carnivore-related documents. EPIC "has raised a 'positive indication' that the FBI may have overlooked documents in other FBI divisions, most notably the offices of the General Counsel and Congressional and Public Affairs," U.S. District Judge James Robertson wrote in his order. The court order marks the latest chapter in EPIC's ongoing legal battle with the Justice Department. The lawsuit could have significant implications for the government's tactics of monitoring Internet use in federal investigations. According to the order, the FBI had completed its processing of EPIC's FOIA request, producing a search of 1,957 pages of material but releasing only 1,665 pages to EPIC. The privacy group claimed those records were inadequate, saying they only addressed technical aspects of Carnivore, not legal and policy implications. EPIC General Counsel David Sobel said the FBI and Justice Department have been "very grudging" about the Carnivore information they are willing to release. "A new court-supervised search is likely to result in the release of a lot of significant new information, particularly because the information that we're likely to get now is material dealing with the Justice Department and the FBI's assessment of the legal issues raised by the use of Carnivore," Sobel said. "I think now--especially after Sept. 11 when these kinds of techniques are likely to increase in use--it's even more important that information be made public and how the techniques are being used and how the Justice Department sees the legal issues." In September 2000, the Justice Department commissioned IIT Research Institute, an arm of the Illinois Institute of Technology, to undergo a review of Carnivore. Two months later, the institute released its findings, saying the technology "protects privacy and enables lawful surveillance better than alternatives." The report said Carnivore provides investigators with no more information than is permitted by a given court order and that it poses no risk to Internet service providers. The Justice Department and FBI could not be immediately reached for comment. -- -------------------------------------------------------------------------------------------------- The First, The Largest, The Most Popular, and The Most Complete TSCM, Bug Sweep, Spy Hunting, and Counterintelligence Site on the Internet. -------------------------------------------------------------------------------------------------- James M. AtkinsonPh: (978) 546-3803 Granite Island GroupFax: (978) 546-9467 127 Eastern Avenue #291http://www.tscm.com/ Gloucester, MA 01931-8008mailto:jmatk@t... -------------------------------------------------------------------------------------------------- "...three shall be the number to count, and the number to be counted shall be three.....four shall thou not count......five is right out". - M. Python -------------------------------------------------------------------------------------------------- 5076 From: James M. Atkinson Date: Mon Mar 25, 2002 9:15pm Subject: Sex scandal sparks run on spy cameras in China http://www.nationalpost.com/news/world/story.html?f=/stories/20020322/415172.html Sex scandal sparks run on spy cameras in China 'Friend' videotaped liaison Araminta Wordsworth National Post Sales of mini-cameras are booming in China in the wake of a sex scandal on the other side of the Taiwan Strait in which a politician was secretly filmed romping with her married boyfriend. Many of the cameras, which sell for as little as 100 yuan (about $20), are being snapped up by people who apparently hope to check up on their spouse's activities, the China Daily reported yesterday. The sudden enthusiasm for spying on loved ones is generally credited to the travails of Chu Mei-feng, a former Taipei city councillor who was secretly filmed by a Linda Tripp-like friend having sex with a married lover. The "friend," Kuo Yu-long, sold the 40-minute tape to a local tabloid magazine, Scoop Weekly, which packaged the steamy hijinks on a CD given away with an issue just before Christmas. It was a runaway best-seller. Although the magazine was quickly forced to withdraw the CD, pirated copies are selling for as much as $45 and are even available in China. News of the liaison was also heavily featured on mainland Chinese Web sites. Apart from providing titillating reading, the saga also alerted consumers as to how mini-cameras could be used for spying. China Daily said it found the handy devices selling for between 100 yuan and 3,000 yuan at one electrical appliance store in the southern city of Guangzhou. "I wholesaled more than 400 micro-cameras last month," the owner told the paper. He said some people were buying the cameras to oversee their spouse's activities, while stores and businesses were also using them as security devices. For anxious spouses, the dealer recommended a wireless model that was able to pick up signals within one kilometre. The suddenly growing interest in the mini-cameras is causing some concern in China among those who believe it could pose a major challenge to privacy. "Residents feel unsafe as this method has been used to expose aspects of people's private lives," said Weng Weiquan, a member of the National People's Congress, China's parliament. But there is little people can do except sue if their privacy has been violated, since China has no regulations supervising the sale of surveillance equipment, the paper said. In Taiwan, it is a different story. Ms. Kuo and her co-conspirators, who include a former mayor of the city of Hsinchu and the magazine's owners, have been charged with behaviour detrimental to public morale, theft and document forgery. They face jail terms of up to four years. As for Ms. Chu, the scandal has given her a whole new career. She has written a book about her liaisons with six lovers, given countless media interviews and done a stint as a radio disc jockey. Last week, she travelled to Singapore for a series of pop concerts, which netted her about $129,000. The neophyte performer, who admits she does not sing very well, said she was nervous as she took the stage, but drew courage from her supporters. "If I do not stand up for those who supported and love me, I will be letting them down." awordsworth@n... -- -------------------------------------------------------------------------------------------------- The First, The Largest, The Most Popular, and The Most Complete TSCM, Bug Sweep, Spy Hunting, and Counterintelligence Site on the Internet. -------------------------------------------------------------------------------------------------- James M. AtkinsonPh: (978) 546-3803 Granite Island GroupFax: (978) 546-9467 127 Eastern Avenue #291http://www.tscm.com/ Gloucester, MA 01931-8008mailto:jmatk@t... -------------------------------------------------------------------------------------------------- "...three shall be the number to count, and the number to be counted shall be three.....four shall thou not count......five is right out". - M. Python -------------------------------------------------------------------------------------------------- 5077 From: Matthew Paulsen Date: Fri Mar 29, 2002 6:32am Subject: Bin Laden used Compact M to dial murder http://www.vnunet.com/News/1130426 Bin Laden used Compact M to dial murder By James Middleton [26-03-2002] Satellite phone records reveal terrorists' moves Phone records for Osama bin Laden were released last week, revealing London and the Home Counties as a hot bed of Al-Qaeda activity. Over 260 calls were made from a satellite phone in Afghanistan between 1996 and 1998 to around 27 numbers in Britain, including calls to terrorist agents and known sympathisers, as well as some inexplicable calls to bizarrely unconnected numbers. Records which have come to light since the trial of the four Al-Qaeda terrorists accused of bombing US embassies in Kenya and Tanzania, show that bin Laden made use of a satellite phone purchased on the credit card of Dr Saad al Fagih, a 45 year-old surgeon who heads the London-based Movement for Islamic Reform in Arabia. The phone in question was a £10,500 Inmarsat Compact M satellite phone with an all weather external antenna and battery and a block of 3,000 pre-paid minutes. Marketing blurb for the phone claims that the Compact M is the "smallest, lightest Inmarsat satellite telephone available and is the ideal communication tool when you don't know where your travels will take you". Over 200 calls were made to the London homes of Khaled al Fawwaz and Ibrahim Eidarous, two Al-Qaeda sympathisers now in prison awaiting extradition to the US for their part in the US embassy bombings. Al Fawwaz kept a note of the satellite phone number in his address book under the name 'Atef'. Muhammad Atef, bin Laden's right hand man, apparently also used the phone to direct Al-Qaeda's operations. According to The Sunday Times, bin Laden stopped using the phone two months after members of the terrorist body bombed the two US embassies in Africa. Apparently he suspected his movements were being traced through the phone and possibly switched to another. One of the more bizarre calls, lasting three minutes, was to a ground floor council flat in Erith, Kent in December 1996. Michelle Urquart, its occupant, is a housewife who lived there with her three children. After the UK, the countries bin Laden called most frequently were Yemen - where terrorists bombed destroyer USS Cole in October 2000 - Sudan, Iran, Azerbaijan, Pakistan, Saudi Arabia and Italy, where police thwarted a poison gas attack on the US embassy earlier this year. Only six calls were made to the US. Iraq is noticeable by its absence on the records. Again this may be because bin Laden suspected his calls were being traced. Calls to the satellite phone number 00873 682 505 331 are met with a "your call cannot be connected" message. vnunet.com has previously reported that bin Laden and the Taleban were customers of Inmarsat, until their accounts were terminated in 2000. 5078 From: James M. Atkinson Date: Mon Mar 25, 2002 9:16pm Subject: Chinese cameras spying on spouses http://news.bbc.co.uk/hi/english/world/asia-pacific/newsid_1885000/1885218.stm Thursday, 21 March, 2002, 11:37 GMT Chinese cameras spying on spouses ======================================= "Residents feel unsafe as this method has been used to expose aspects of people's private lives" Weng Weiquan ======================================= The cameras are easily hidden http://news.bbc.co.uk/olmedia/1885000/images/_1885218_afp_camera300.jpg Mini spy cameras are the latest consumer 'must-have' in southern China, as spouses try to keep tabs on partners and shops keep an eye on theft, according to the China Daily. The state-controlled newspaper said the cameras, which can be easily hidden from sight, were "selling like hot cakes" in south China's Guangdong Province. Officials are worried the cameras could be used intrusively to spy on people and expose their peccadilloes, the paper said. Worries about the cameras even reached China's National People's Congress, where deputy Weng Weiquan called for laws to stop secret filming. "Residents feel unsafe as this method has been used to expose aspects of people's private lives," he said. Taiwan scandal Spy cameras shot into public consciousness after one was used in Taiwan to film a politician having sex with her married lover. Ms Chu's latest performance Taipei City councilwoman Chu Mei-feng was forced from office after the film, which was made without her knowledge, was widely circulated. She has since resurfaced as a pop singer, appearing last week in concert in Singapore. Videos of her sexual performance, reproduced on to optical disks, have been selling well across China and other Asian countries. China Daily said it found spy-cameras selling for between 100 yuan ($12) to 3,000 yuan ($360) in one Guangzhou shop. "I wholesaled more than 400 micro-cameras last month," one dealer told the paper. The dealer said some people were buying the cameras to oversee their spouse's activities, while shops and businesses were also using them as security devices. For anxious spouses, the dealer recommended one wireless camera that was able to pick up signals within one kilometre. -- -------------------------------------------------------------------------------------------------- The First, The Largest, The Most Popular, and The Most Complete TSCM, Bug Sweep, Spy Hunting, and Counterintelligence Site on the Internet. -------------------------------------------------------------------------------------------------- James M. AtkinsonPh: (978) 546-3803 Granite Island GroupFax: (978) 546-9467 127 Eastern Avenue #291http://www.tscm.com/ Gloucester, MA 01931-8008mailto:jmatk@t... -------------------------------------------------------------------------------------------------- "...three shall be the number to count, and the number to be counted shall be three.....four shall thou not count......five is right out". - M. Python -------------------------------------------------------------------------------------------------- 5079 From: Steve Uhrig Date: Fri Mar 29, 2002 8:33am Subject: Re: Bin Laden used Compact M to dial murder Once upon a midnight dreary, Matthew Paulsen pondered, weak and weary: > Satellite phone records reveal terrorists' moves > Phone records for Osama bin Laden were released last week, revealing > London and the Home Counties as a hot bed of Al-Qaeda activity. Over > 260 calls were made from a satellite phone in Afghanistan between 1996 > and 1998 to around 27 numbers in Britain, including calls to terrorist > agents and known sympathisers, as well as some inexplicable calls to > bizarrely unconnected numbers. We knew this BEFORE 9/11. I was and am working Sigint on this matter. Here is an article with some info on what we were doing and knew BEFORE the world knew his name. We had him on Inmarsat months before 9/11, and trying to unravel the networks of shill/shell companies he had set up all in a circle back to each other was frustrating but rather fun once we started to see the pattern. http://www.business2.com/articles/mag/print/0,1643,17511,00.html The full article in the printed copy of the magazine had a lot more specific details than the excerpt above. Steve ******************************************************************* Steve Uhrig, SWS Security, Maryland (USA) Mfrs of electronic surveillance equip mailto:Steve@s... website http://www.swssec.com tel +1+410-879-4035, fax +1+410-836-1190 "In God we trust, all others we monitor" ******************************************************************* 5080 From: A Grudko Date: Fri Mar 29, 2002 8:25am Subject: Bin Laden - Humour, unrelated to Easter. NO REFLECTION ON MY FRIEND MATTHEW WHO POSTED THIS.... Interesting but it is just the usual journalistic 'sleight of hand' to turn ten off-the-wire words into a 600 word column. - Original Message ----- > Phone records for Osama bin Laden were released last week, revealing London > and the Home Counties as a hot bed of Al-Qaeda activity. > Over 260 calls were made from a satellite phone in Afghanistan between 1996 > and 1998 to around 27 numbers in Britain, including calls to terrorist > agents and known sympathisers, as well as some inexplicable calls to > bizarrely unconnected numbers. Perhaps the media should find a reporter who can count over 260. OK, let's take 269 - that's an average of about one call every 3 days to the UK. > Over 200 calls were made to the London homes of Khaled al Fawwaz and Ibrahim > Eidarous, two Al-Qaeda sympathisers now in prison awaiting extradition to > the US for their part in the US embassy bombings. So that leaves 'over' 60 calls to 'bizarrely unconnected numbers'. Do the media expect terrorists to only phone sequential numbers? Even international terrorists order take away pizza and book cinema tickets. 60 calls in 730 days = one every 13 days or so. Golly gosh, that is really earth shattering. > Apparently he suspected his movements were being traced through the phone > and possibly switched to another. Aparantly? This is not a fool. He is running rings around Bush, Powell, Blair etc. Megatonnes of munitions are being thrown at Afghanistan and he's on the phone to his Mum making fun of the west. Of course he suspected it. His phone switched to another! Amazing - no wonder with such advanced technology he is able to evade the combined allied forces. At that rate my teenage daughters could take over Quantico tomorrow and Langly on Sunday. Imagen the damage if OBL ever gets hold of a cell phone.... > One of the more bizarre calls, lasting three minutes, was to a ground floor > council flat in Erith, Kent in December 1996. Michelle Urquart, its > occupant, is a housewife who lived there with her three children. The Homo Office released this transcript: "Err, Hello, Salaam." "Wot" "This is Osama - I saw your add in the December 1996 Hustler - sorry, post is a bit slow to these caves" "Wot?" "Is that Mistress Susan?" "No, I'm Michelle" "Is Mistress Susan there?" "Wot?" "I've been a bad boy and I want to be spanked" And so forth for 3 minutes. Bizarre indeed - anyone in the Home Office can tell you that Mistress Susan retired last year! ;-) This reporter gives no substance to his/her reporting. It is blatant sensationalism of the type that creates the imaginary 'facts' we all see circulated on the net. > After the UK, the countries bin Laden called most frequently were Yemen - > where terrorists bombed destroyer USS Cole in October 2000 - Sudan, Iran, > Azerbaijan, Pakistan, Saudi Arabia and Italy, where police thwarted a poison > gas attack on the US embassy earlier this year. Only six calls were made to > the US. Oh oh. Now it gets serious. Were these calls to the Trilateral commission? Louis Farrakan? Pres. GW Bush? Mohammed Ali? Pres. Hillary Clinton? Bartv Simpson? The NBA? The CIA. > Iraq is noticeable by its absence on the records. Again this may be because > bin Laden suspected his calls were being traced. Or they would not pay for collect calls. A totally specious train of thought - why bring Iraq into it if it was not there! > Calls to the satellite phone number 00873 682 505 331 are met with a "your > call cannot be connected" message. If I was OBL I'd be complaining about this shocking service and suing Imarsat. Typical of a capitalist imperialst expansionist Service Provider. :-) On the other hand, if I was the ISP or reporter I'd publicise 00873 682 505 331 - a pay to dial number - and watch the money roll in from curious folks round the world. Andy Grudko D.P.M., Grad I.S, (S.A.) - Grudko Associates - www.grudko.com , Est. 1981 International business intelligence and investigations - ICQ 146498943 Johannesburg (+27 11) 465 9673 - 465 1487 (Fax), Pretoria (+27 12) 244 0255 - 244 0256 (Fax) SACI, WAD, CALI, SAMLF, UKPIN, AFIO (OS), IWWA, PRETrust, AmChamCom When you need it done right - first time 5081 From: Richard Gray Date: Sun Mar 24, 2002 3:32pm Subject: Spy Software Detection Help Is there any software that will detect logging and spyware programs installed on a computer? Ricky _________________________________ Richard T. Gray Jr. Legal Investigator License No. 1914-050896-LA Gray & Associates, LLC PO Box 2368 Crowley, LA 70527 337-785-0046 Voice 800-394-8216 Fax www.la-pi.com ricky@l... "When you need to know!" -----Original Message----- From: Marko Radovic [mailto:radovic_marko@y...] Sent: Friday, March 22, 2002 2:12 AM To: TSCM-L@yahoogroups.com Subject: [TSCM-L] ISO 17799 Hello, I would like to thank all the pepople who privided help and information cocerning ISO 17799 standard. Any additional information about standard is welcome. Marko __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com Yahoo! Groups Sponsor ADVERTISEMENT ======================================================== TSCM-L Technical Security Mailing List "In a multitude of counselors there is strength" To subscribe to the TSCM-L mailing list visit: http://www.yahoogroups.com/community/TSCM-L It is by caffeine alone I set my mind in motion. It is by the juice of Star Bucks that thoughts acquire speed, the hands acquire shaking, the shaking is a warning. It is by caffeine alone I set my mind in motion. =================================================== TSKS Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service . [Non-text portions of this message have been removed] 5082 From: Steve Uhrig Date: Fri Mar 29, 2002 2:46pm Subject: No free lunch The below is clipped from another list, and what pisses me off is that is is 100% true. I made a specific note in my daytimer. I last reset all this crap on yahoogroups on Jan 21st, to off. This morning I checked, and every bloody one was turned back on. I don't believe I have signed up with any new groups or made any changes to my account since Jan 21st which would give these clowns license to change all my preferences. We pay for use of their servers and service a lot more than by the advertising tag line appended to all our messages. I may research the personal email addresses and fax numbers of the owners of yahoogroups, and make sure a sufficient portion of the spam I receive is forwarded directly to them. If I put a mind to it, I can uncover their addresses as fast as they change them, and let them see what it feels like. ============================ Yahoo has apparently made a sneaky change to everybody's "Marketing Preferences," changing all their "No's" to "Yes," the result of which will be a load of spam. To change it back: Go to Yahoo Groups (http://groups.yahoo.com) and sign in. Go to My Groups and click on Account Info, verify your password if it asks you to, and your Yahoo ID card comes up. Click on 'Edit your Marketing Preferences' and change all those Yea's back to No's. Click Save Changes. ==================== Steve ******************************************************************* Steve Uhrig, SWS Security, Maryland (USA) Mfrs of electronic surveillance equip mailto:Steve@s... website http://www.swssec.com tel +1+410-879-4035, fax +1+410-836-1190 "In God we trust, all others we monitor" ******************************************************************* 5083 From: Date: Fri Mar 29, 2002 10:17am Subject: Re: Spy Software Detection Help In a message dated 3/29/02 8:01:52 AM Pacific Standard Time, laspy1@y... writes: << Is there any software that will detect logging and spyware programs installed on a computer? >> http://www.hushmail.com/spycop/ 5084 From: Matthew Paulsen Date: Fri Mar 29, 2002 3:27pm Subject: RE: Spy Software Detection Help A large list of applications used for anti-spyware. http://download.cnet.com/downloads/1,10150,0-10001-103-0-1-7,00.html?tag=src h&qt=spyware&cn=&ca=10001 -----Original Message----- From: MACCFound@a... [mailto:MACCFound@a...] Sent: Friday, March 29, 2002 1:17 PM To: TSCM-L@yahoogroups.com Subject: Re: [TSCM-L] Spy Software Detection Help In a message dated 3/29/02 8:01:52 AM Pacific Standard Time, laspy1@y... writes: << Is there any software that will detect logging and spyware programs installed on a computer? >> http://www.hushmail.com/spycop/ Yahoo! Groups Sponsor ADVERTISEMENT ======================================================== TSCM-L Technical Security Mailing List "In a multitude of counselors there is strength" To subscribe to the TSCM-L mailing list visit: http://www.yahoogroups.com/community/TSCM-L It is by caffeine alone I set my mind in motion. It is by the juice of Star Bucks that thoughts acquire speed, the hands acquire shaking, the shaking is a warning. It is by caffeine alone I set my mind in motion. =================================================== TSKS Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed] 5085 From: DrPepper Date: Fri Mar 29, 2002 3:31pm Subject: Re: No free lunch JMA, , , , THIS is exactly what I was talkikng about, , , , And I see that I am stil recieveing TSCM. Ron C. Steve Uhrig wrote: > The below is clipped from another list, and what pisses me off is that is > is 100% true. > > I made a specific note in my daytimer. I last reset all this crap on > yahoogroups on Jan 21st, to off. > > This morning I checked, and every bloody one was turned back on. > > I don't believe I have signed up with any new groups or made any changes > to my account since Jan 21st which would give these clowns license to > change all my preferences. > > We pay for use of their servers and service a lot more than by the > advertising tag line appended to all our messages. > > I may research the personal email addresses and fax numbers of the owners > of yahoogroups, and make sure a sufficient portion of the spam I receive > is forwarded directly to them. If I put a mind to it, I can uncover their > addresses as fast as they change them, and let them see what it feels > like. > > ============================ > > Yahoo has apparently made a sneaky change to everybody's "Marketing > Preferences," changing all their "No's" to "Yes," the result of which > will be a load of spam. To change it back: > > Go to Yahoo Groups (http://groups.yahoo.com) and sign in. Go to My > Groups and click on Account Info, verify your password if it asks you to, > and your Yahoo ID card comes up. Click on 'Edit your Marketing > Preferences' and change all those Yea's back to No's. Click Save Changes. > > ==================== > > Steve > > ******************************************************************* > Steve Uhrig, SWS Security, Maryland (USA) > Mfrs of electronic surveillance equip > mailto:Steve@s... website http://www.swssec.com > tel +1+410-879-4035, fax +1+410-836-1190 > "In God we trust, all others we monitor" > ******************************************************************* > > > ======================================================== > TSCM-L Technical Security Mailing List > "In a multitude of counselors there is strength" > > To subscribe to the TSCM-L mailing list visit: > http://www.yahoogroups.com/community/TSCM-L > > It is by caffeine alone I set my mind in motion. > It is by the juice of Star Bucks that thoughts acquire speed, > the hands acquire shaking, the shaking is a warning. > It is by caffeine alone I set my mind in motion. > =================================================== TSKS > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -- Dr Pepper aka WB6GKI in the High Desert of California. Check out my LIVE Hamshack Cam at: http://www1.iwvisp.com/DrPepper/ham/ham.htm 5086 From: James M. Atkinson Date: Mon Mar 25, 2002 9:13pm Subject: FBI Moves To Prevent Espionage http://www.guardian.co.uk/uslatest/story/0,1282,-1605657,00.html FBI Moves To Prevent Espionage Saturday March 23, 2002 1:10 AM WASHINGTON (AP) - Since capturing a spy in its ranks, the FBI has reduced the number of agents with access to sensitive intelligence and conducted hundreds of polygraphs that have identified possible problems with about 10 employees, officials said. Senior FBI officials said the intensified focus on preventing espionage also has increased the number of disciplinary cases in the last six months involving employees. No new espionage suspects have been identified, officials said. Most matters have been referred to the FBI's Office of Professional Responsibility, which investigates internal wrongdoing, the officials said. ``Our goal is to bring the culture along to the point where security is considered part of the daily operations,'' said Ken Senser, a CIA employee who was brought over to the FBI in 1999 to improve internal security. He now oversees the FBI's new security division. Over the last six months, the FBI has reduced by hundreds the number of employees who have access to Sensitive Compartmented Information (SCI), which is even more sensitive than top secret intelligence. Roughly half of the FBI's 28,000 employees held SCI clearance at times before the number was reduced. Officials said the new, lower figure is classified, but only employees with a need to know such information for their immediate jobs now hold the high-level clearance. ``We focused on the numbers of people who had access to SCI and actually we were able to reduce that number noticeably,'' Senser said. Former CIA and FBI Director William Webster is wrapping up a massive review of the FBI's internal security in the aftermath of the Robert Hanssen spy case. The senior agent spied for Russia for more than a decade without U.S. detection. While awaiting Webster's recommendations, the FBI agreed to answer questions earlier this week from The Associated Press about some of the changes and findings already made. FBI officials said they have conducted more than 700 polygraphs of FBI agents and workers with access to the most sensitive information and have identified a small number whose tests raised flags, such as possible deception, that warranted additional scrutiny. Officials said the number was just over 1 percent of those tested - just under 10 workers. They declined to be more specific, citing ongoing investigations and personnel privacy. Officials said that some workers whose polygraphs raise initial concerns about deception may eventually be cleared because things like medical conditions can cause anomalies on the tests. But they described a broad effort to remake the FBI's internal security procedures. Assistant FBI Director John Collingwood said internal security for too long was not given the priority and emphasis it needed inside an agency whose primary focus was catching criminals and which relied on a family oriented system of trust. ``We have failed to do those basic things, as mundane as they may seem, that are vital, and that are becoming increasingly vital, in today's world,'' Collingwood said. In March 2001 as the bureau was still reeling from the breadth of Hanssen's espionage, then-Director Louis Freeh announced several changes that included increased use of polygraphs. New Director Robert Mueller has gone even further, reorganizing the entire structure of the FBI to put added emphasis on terrorism prevention and improved internal security. FBI officials said a key focus will be on a multiyear project to craft new computer systems that will detect suspicious activity as it is occurring rather than years later. The goal eventually is to provide FBI supervisors with regular reports ``that says these are 10 things that happened last night that you ought to look into that are causes of some concern,'' Senser said. In the interim, every FBI field office has created a security council to routinely review issues of security and sensitive intelligence in day-to-day operations. The sharper focus on security isn't limited to the FBI. The Justice Department this month enacted tighter restrictions against foreigners working on computer systems at the department. Officials indicated they may allow foreigners to continue working on some current projects if they determine there is ``an acceptable level of risk,'' according to an internal memo. ``Waivers will be granted only in exceptional and unique circumstances,'' but foreigners would never be allowed to work on classified technology systems at Justice, the memo said. ^--- On the Net: FBI: http://www.fbi.gov Guardian Unlimited © Guardian Newspapers Limited 2002 -- -------------------------------------------------------------------------------------------------- The First, The Largest, The Most Popular, and The Most Complete TSCM, Bug Sweep, Spy Hunting, and Counterintelligence Site on the Internet. -------------------------------------------------------------------------------------------------- James M. AtkinsonPh: (978) 546-3803 Granite Island GroupFax: (978) 546-9467 127 Eastern Avenue #291http://www.tscm.com/ Gloucester, MA 01931-8008mailto:jmatk@t... -------------------------------------------------------------------------------------------------- "...three shall be the number to count, and the number to be counted shall be three.....four shall thou not count......five is right out". - M. Python -------------------------------------------------------------------------------------------------- 5087 From: James M. Atkinson Date: Fri Mar 29, 2002 8:38pm Subject: THE 2002 U.S. BIG BROTHER AWARDS CALL FOR NOMINATIONS THE 2002 U.S. BIG BROTHER AWARDS On April 18, 2002, Privacy International will hold the fourth U.S. "Big Brother Awards" to name and shame the public and private sector individuals and organizations which have done the most to invade personal privacy in the United States in the past year. Three distinctive "Orwell" statutes of a golden boot stomping a head will be presented to the government agencies and officials, companies and initiatives which have done most to invade personal privacy in the previous year. A "lifetime achievement" award will also be presented to the organization that has systematically invaded privacy over a long period of time. Previous "winners" include The Federal Bureau of Investigation, the National Security Agency, DoubleClick, ChoicePoint, The FAA's BodyScan system, the Department of Commerce and Microsoft. The judging panel, consisting of lawyers, academics, consultants, journalists and civil rights activists, are inviting nominations from members of the public. Nominations can be made directly from the site: http://www.privacyinternational.org/bigbrother/us2002/ Privacy International will post the 'most popular' current nominations on its' site. "Brandeis" awards will be also be given out to champions of privacy. The Brandeis Award is named after US Supreme Court Justice Louis Brandeis, who is considered the father of American privacy law, describing privacy as "the right to be left alone." The awards are given to those have done exemplary work to protect and enhance privacy. Previous winner include Phil Zimmermann, creator of PGP, Beth Givens, founder of the Privacy Rights Clearing House and Robert Ellis Smith, editor of the Privacy Journal. The Big Brother Awards are now in their fourth year. There have been ceremonies in the UK, the US, Germany, Austria, Switzerland, Hungary, France, Denmark and the Netherlands. This event will mark the 20th ceremony. Further information can be found at on the PI website at http://www.privacyinternational.org/bigbrother/. The initiator of the awards, Privacy International, was founded in 1990, and campaigns on a wide range of privacy issues across the world. More information on Privacy International is available at: http://www.privacyinternational.org/ The ceremony will be held at the Cathedral Hill Hotel in San Francisco, Cal at the 2002 Computers, Freedom and Privacy Conference. More information on CFP 2002 is available at: http://www.cfp2002.org/ -- -------------------------------------------------------------------------------------------------- The First, The Largest, The Most Popular, and The Most Complete TSCM, Bug Sweep, Spy Hunting, and Counterintelligence Site on the Internet. -------------------------------------------------------------------------------------------------- James M. AtkinsonPh: (978) 546-3803 Granite Island GroupFax: (978) 546-9467 127 Eastern Avenue #291http://www.tscm.com/ Gloucester, MA 01931-8008mailto:jmatk@t... -------------------------------------------------------------------------------------------------- "...three shall be the number to count, and the number to be counted shall be three.....four shall thou not count......five is right out". - M. Python -------------------------------------------------------------------------------------------------- 5088 From: Steve Uhrig Date: Fri Mar 29, 2002 9:01pm Subject: More on Yahoo SPAM Here's a copy of the press release about Yahoo! changing your email preferences without telling you about it, posted to the Usenet newsgroup news.admin.net-abuse.email by a former Yahoo! employee. This was NOT sent to list owners or moderators (or Yahoo users). Wonder why? Steve ------------------------ From: Derek Balling Newsgroups: news.admin.net-abuse.email Subject: Yahoo - Where "No" means "Not Now" Date: Thu, 28 Mar 2002 06:55:16 -0500 According to: http://biz.yahoo.com/djus/020327/200203272215000735_1.html Yahoo will now be requiring users - even those who have previously opted out of mailings from the company, to go and re-edit their preferences because the default option on a plethora of new e-mail categories is "to get spammed". So if you signed up for an account three years ago, said "don't e-mail me" and promptly forgot about the account, prepare for an onslaught of e- mail that you may not easily be able to get rid of if you don't remember the account particulars. "The company is essentially using this requirement to promote its newer services. For instance, users who signed up for Yahoo two or three years ago -- and who opted out of promotional e-mails at the time -- might not be aware that Yahoo has upgraded its job-listings service with the recent acquisition of HotJobs Ltd., Ms. Srinivasan said. Now, when they edit their marketing preferences, they can decide whether to receive information about "finding a job or an employee." Ms. Srinivasan pointed out that users will have 60 days to edit their preferences. Also, she said it was the first time Yahoo has required users to edit preferences in company history." So what Ms. Srinija is saying is "we can't spam these folks because they deliberately told us they didn't want to hear from us, and that screws up our marketing strategy, so since the economy is in a flat-spin headed out to sea, and we need cash, we're going to ignore their explicit preferences and start spamming them in 60 days unless they come back and tell us 'No, I really meant it, stay out of my mailbox'" ======================== ******************************************************************* Steve Uhrig, SWS Security, Maryland (USA) Mfrs of electronic surveillance equip mailto:Steve@s... website http://www.swssec.com tel +1+410-879-4035, fax +1+410-836-1190 "In God we trust, all others we monitor" ******************************************************************* 5089 From: Steve Uhrig Date: Fri Mar 29, 2002 9:10pm Subject: Re: THE 2002 U.S. BIG BROTHER AWARDS Once upon a midnight dreary, James M. Atkinson pondered, weak and weary: > CALL FOR NOMINATIONS > THE 2002 U.S. BIG BROTHER AWARDS > On April 18, 2002, Privacy International will hold the fourth U.S. > "Big Brother Awards" to name and shame the public and private sector > individuals and organizations which have done the most to invade > personal privacy in the United States in the past year. About ten years ago, these clowns named my company as one of the most heinous participants in human rights violations in Indonesia. That info has been circulated all over the web, to many dozens of websites, and will not die. I contacted the joker who runs this outfit, provided him with verifiable data that all our dealings with the Government of Indonesia were legitimate intelligence matters. They ignored me, never replied, never corrected their error. Incorrect information and accusations are still circulating all over the web. We still maintain a facility in Jakarta. Don't take them seriously. "Lawyers, academics, consultants, journalists and civil rights activists" on the panel. That should say it all. Pathetic morons who need to see their names in lights, and give each other awards. Steve ******************************************************************* Steve Uhrig, SWS Security, Maryland (USA) Mfrs of electronic surveillance equip mailto:Steve@s... website http://www.swssec.com tel +1+410-879-4035, fax +1+410-836-1190 "In God we trust, all others we monitor" ******************************************************************* 5090 From: Steve Uhrig Date: Fri Mar 29, 2002 10:49pm Subject: Telephone Line cleaning this Monday, 04/01/2002 : NOTE: Telephone Line cleaning this Monday, 04/01/2002 CONTACT: Richard Schvanski, Corporate Communications SOUTHCOAST BELLCOM TO CLEAN PHONE AND INTERNET ACCESS LINES Los Angeles, CA - March 28, 2002 - Southcoast Bellcom, a subsidiary of PCG Communications, is preparing to join telephone companies throughout the U.S. in a nationwide "cleaning" of all phone and telecom lines this Sunday. "We do this about every 10 years," said a Richard Schvanski, spokesperson for the National Telephone Association. "Over time, dust collects in the lines and this leads to weak connections and static, as well as to broken and slow Internet connectivity." To clean the lines, Schvanski said, all telephone companies will use air compressors at their central locations in each city to blow a blast of air through phone lines and cable networks. The 10-minute process will cause dust to blow through telephone receivers, fax and answering machines, and both traditional PC and DSL modems in homes and offices throughout the U.S. Schvanski explained that most people are being urged to set a newspaper under their telecom device before going to bed Sunday night. The cleaning will be done between 2 a.m. and 4 a.m. so as to disturb as few people as possible, he said. In the past, the spokesperson said, some people have put a plastic baggy over their telephone's handset to catch the dust, or wrapped the handset with a cloth to keep dust from getting on their furniture. Cell phones, pagers, and other wireless devices are not affected. Customers experiencing problems should visit the Southcoast Bellcom Web Troubleshooting page at: http://www.southcoastbellcom.com,1002,987asp@216.118.65.161//404/index.ht ml ************ So if you are located in the Continental US, and have any problems with your telephone line(s) or dial-up internet access THIS MONDAY, APRIL 1st, you've been notified! Steve ******************************************************************* Steve Uhrig, SWS Security, Maryland (USA) Mfrs of electronic surveillance equip mailto:Steve@s... website http://www.swssec.com tel +1+410-879-4035, fax +1+410-836-1190 "In God we trust, all others we monitor" ******************************************************************* 5091 From: James M. Atkinson Date: Fri Mar 29, 2002 10:54pm Subject: Spy camera found in women's toilet in Kallang http://straitstimes.asia1.com.sg/singapore/story/0,1870,111248,00.html? Spy camera found in women's toilet in Kallang A WOMAN got the shock of her life on Wednesday when she noticed a tiny camera staring down from the false ceiling of her toilet cubicle. The victim spotted the camera in the cubicle located in Block 155, Kallang Way and rushed out crying for help. Her colleagues removed the camera, which has a lens no bigger than a five-cent coin. -- SHIN MIN The printing company employee rushed out to her office next door crying for help, reported Shin Min Daily News. Her colleagues later removed the camera from the toilet on the seventh floor of Block 155, Kallang Way. The block is part of an industrial estate. The remote-controlled camera had a lens no bigger than a five-cent coin. Its electricity source came from a power socket above the ceiling. Mr Mo Zeliang, 41, an employee of the printing company, said the culprit was likely to be nearby or could even have been someone from the building because he believed the camera had a limited range for the transmission of images. The seven-storey building has more than 10 toilets for women, he said. Unlike the seventh floor, the workers on the other floors were mostly men, he said. The printing company, which occupies most of the seventh floor, has more than 20 women employees, out of some 60 workers. The women who were interviewed by the Chinese daily said that they used the toilets at least four to five times a day. In recent years, there have been several cases where men were caught filming or peeping at women in toilets. A 24-year-old National University of Singapore student was jailed three weeks in September 2000 for filming a woman student urinating. In July that year, a 35-year-old man who filmed two women friends secretly while they used the bathroom in his flat was jailed two months. In May 1999, a 43-year-old forklift driver was sentenced to three months' jail for watching two women tenants shower in the bathroom of his flat through a closed-circuit television camera. -- -------------------------------------------------------------------------------------------------- The First, The Largest, The Most Popular, and The Most Complete TSCM, Bug Sweep, Spy Hunting, and Counterintelligence Site on the Internet. -------------------------------------------------------------------------------------------------- James M. AtkinsonPh: (978) 546-3803 Granite Island GroupFax: (978) 546-9467 127 Eastern Avenue #291http://www.tscm.com/ Gloucester, MA 01931-8008mailto:jmatk@t... -------------------------------------------------------------------------------------------------- "...three shall be the number to count, and the number to be counted shall be three.....four shall thou not count......five is right out". - M. Python -------------------------------------------------------------------------------------------------- 5092 From: Richard Gray Date: Mon Mar 25, 2002 10:50pm Subject: Contract for Low threat sweep When I gain enough knowledge to begin offering low threat sweeps, is there a contract that limits liability for high technology devices missed by the sweep? Ricky _________________________________ Richard T. Gray Jr. Legal Investigator License No. 1914-050896-LA Gray & Associates, LLC PO Box 2368 Crowley, LA 70527 337-785-0046 Voice 800-394-8216 Fax www.la-pi.com ricky@l... "When you need to know!" -----Original Message----- From: Matthew Paulsen [mailto:mpaulsen6@a...] Sent: Monday, March 25, 2002 10:20 AM To: tscm-l@yahoogroups.com Subject: [TSCM-L] Internet Draft - Responsible Vulnerability Disclosure Worth a read. May make companies legally liable for not fixing security holes. http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosu re-0 0.txt Internet Engineering Task Force Steve Christey INTERNET-DRAFT MITRE Valid for six months Chris Wysopal Category: Best Current Practice @stake, Inc. February 2002 Responsible Vulnerability Disclosure Process draft-christey-wysopal-vuln-disclosure-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract New vulnerabilities in software and hardware products are discovered and publicized on a daily basis. The disclosure of vulnerability information has been a divisive topic for years. During the process of disclosure, many vendors, security researchers, and other parties follow a variety of unwritten or informal guidelines for how they interact and share information. Some parties may be unaware of these guidelines, or they may intentionally ignore them. This state of affairs can make it difficult to achieve a satisfactory outcome for everyone who uses or is affected by vulnerability information. The purpose of this document is to describe best practices for a responsible disclosure process that involves vulnerability reporters, product vendors or maintainers, third parties, the security community, and ultimately customers and users. Christey & Wysopal Expires August 2002 [Page 1] Internet-Draft Responsible Vulnerability Disclosure February 2002 Table of Contents 1 Introduction and Purpose ....................................... 3 1.1 Background ................................................... 3 1.2 Major Roles in Disclosure .................................... 3 1.3 Motivations .................................................. 4 1.4 Goals of Responsible Disclosure .............................. 5 2 Phases of Responsible Disclosure ............................... 6 3 Responsibilities in the Phases of Vulnerability Disclosure ..... 7 3.1 Latent Flaw .................................................. 7 3.2 Discovery .................................................... 7 3.3 Notification Phase: Initial Notification ..................... 8 3.3.1 Vendor Responsibilities .................................... 8 3.3.2 Reporter Responsibilities .................................. 9 3.4 Notification Phase: Vendor Receipt .......................... 11 3.4.1 Vendor Responsibilities ................................... 11 3.5 Validation Phase ............................................ 11 3.5.1 Vendor Responsibilities ................................... 11 3.5.2 Reporter Responsibilities ................................. 13 3.5.3 Coordinator Responsibilities .............................. 14 3.6 Resolution Phase ............................................ 14 3.6.1 Vendor Responsibilities ................................... 14 3.6.2 Reporter Responsibilities ................................. 15 3.7 Release Phase ............................................... 16 3.7.1 Vendor Responsibilities ................................... 16 3.7.2 Reporter Responsibilities ................................. 18 3.7.3 Coordinator Responsibilities .............................. 18 3.7.4 Customer Responsibilities ................................. 19 3.7.5 Security Community Responsibilities ....................... 19 3.8 Follow-Up Phase ............................................. 20 4 Policy Publication ............................................ 20 4.1 Vendor Policy ............................................... 20 4.2 Reporter Policy ............................................. 20 4.3 Coordinator Policy .......................................... 21 5 References .................................................... 21 5.1 Disclosure Policies ......................................... 21 5.2 Commentary on Disclosure Details ............................ 21 5.3 Commentary on Disclosure Process ............................ 22 5.4 Commentary on Advisories .................................... 24 5.5 Commentary on Vendor Accessibility .......................... 24 5.6 Discovery of Issues in the Wild ............................. 25 5.7 Researcher Credibility and Vulnerability Reproduction ....... 26 5.8 Miscellaneous ............................................... 26 6 Acknowledgements .............................................. 26 7 Security Considerations ....................................... 26 8 Authors' Addresses ............................................ 27 9 Full Copyright Statement ...................................... 27 Christey & Wysopal Expires August 2002 [Page 2] Internet-Draft Responsible Vulnerability Disclosure February 2002 Document Conventions The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 1 Introduction and Purpose This document provides guidance and recommendations for the community of developers, vendors, end users, researchers and security professionals who wish to perform responsible vulnerability disclosure within the information technology arena. For purposes of this document, the term "responsible" refers to the recognition of a formal, repeatable process for the reporting, evaluation, resolution and publication of vulnerability information. "Vulnerability" refers to any bug, flaw, behavior, output, outcome or event within an application, system, device, or service that could lead to increased risk or security exploit. For purposes of this document, we have standardized on the term "product" to encompass the full suite of products that are addressed by this document. 1.1 Background Vulnerabilities are an inherent and unfortunate part of the design and development process. Vulnerability detection may occur during any phase of the product lifecycle, to include design, development, testing, implementation or operation. Ideally, vulnerabilities are largely prevented through a design process that considers security. However, due to a variety of reasons, many vulnerabilities are detected after a product is implemented in an operational environment and supporting customer objectives. A variety of legislative and social issues directly influences the process for vulnerability research, detection and response. Developers, customers and the security community all have divergent perspectives on the impact of vulnerabilities. Currently, vulnerability release is inconsistent and largely driven from the perspective of the party who has the greatest ability to control the process. In an effort to create a common framework by which objectives are met to the benefit of all parties, this document communicates a formal, repeatable process for addressing vulnerability disclosure in a responsible manner. This document provides a means to address the common goal of providing more secure products while reducing the risk to customers. 1.2 Major Roles in Disclosure Several types of individuals or organizations may play a role in the process of vulnerability disclosure. These roles may overlap. Christey & Wysopal Expires August 2002 [Page 3] Internet-Draft Responsible Vulnerability Disclosure February 2002 A Vendor is an individual or organization who provides, develops, or maintains software, hardware, or services, possibly for free. A Customer is the end user of the software, hardware, or service that may be affected by the vulnerability. A Reporter is the individual or organization that informs (or attempts to inform) the Vendor of the vulnerability. Note that the Reporter may not have been the initial discoverer of the problem. A Coordinator is an individual or organization who works with the Reporter and the Vendor to analyze and address the vulnerability. Coordinators are often well-known third parties. Coordinators may have resources, credibility, or working relationships that exceed those of the reporter or vendors. Coordinators may serve as proxies for reporters, help to verify the reporter's claims, resolve conflicts, and work with all parties to resolve the vulnerability in a satisfactory manner. Note: while Coordinators can facilitate the responsible disclosure process for a vulnerability, the use of Coordinators by other parties is not a requirement. The Security Community includes individuals or organizations whose primary goals include improving overall information technology security. The community includes security administrators and analysts, system administrators who are responsible for the security of their systems, commercial or non-profit organizations who provide security-related products or services, researchers and academics, informal groups, and individuals. 1.3 Motivations Individuals and organizations have a wide variety of motivations (some in direct conflict with each other) that make the disclosure process more complex. Vendors may have one or more of the following motivations. Some vendors believe that public notification may help their customers address vulnerabilities, at the possible cost of negative publicity. Some vendors may be unresponsive, or secretly fix vulnerabilities, for fear of negative publicity. Some vendors may not have the technical skills to understand the nature of the vulnerability and the risk that it poses. Customers often wish to have secure products, but security features can make it more difficult to use those products. Many customers do not care about the nature of the vulnerability. However, there is a small percentage of customers for whom vulnerability information plays a critical role in their usage of products. Some vendors may be customers of other vendors. Christey & Wysopal Expires August 2002 [Page 4] Internet-Draft Responsible Vulnerability Disclosure February 2002 Reporters have a variety of motivations. Because reporters are often the means through which vulnerability information is communicated, they have a major impact on how the disclosure process is followed. Reporters may be motivated by altruism ("to make computers more secure"), recognition or fame, marketing to highlight technical skills (for individuals as well as companies), forcing unresponsive vendors to address a vulnerability, curiosity or the challenge of vulnerability analysis, or malicious intent to damage the reputations of specific vendors, wreak havoc, or cause financial damage to customers. The vague goals of altruism are often open to different interpretations by different reporters. Reporters may be inexperienced, malicious, or have insufficient resources to follow the full process of disclosure. Reporters are seldom compensated for their important role in enhancing Internet security. The motivations for members of the security community may vary depending on the specific tasks that are being undertaken by the members. Community members may have motivations that include those of vendors, customers, and/or reporters. In addition, members of the security community may wish to track trends in vulnerabilities, identify new types of vulnerabilities, or design new products and processes to reduce the impact of vulnerabilities. Coordinators are often members of the security community, and as such may share the same motivations. Coordinators may also be required by their mission or contract to perform this role. 1.4 Goals of Responsible Disclosure The goals of responsible disclosure include: 1) Ensure that vulnerabilities can be identified and eliminated effectively and efficiently for all parties. 2) Minimize the risk to customers from vulnerabilities that could allow damage to their systems. 3) Provide customers with sufficient information for them to evaluate the level of security in vendors' products. 4) Provide the security community with the information necessary to develop tools and methods for identifying, managing, and reducing the risks of vulnerabilities in information technology. 5) Minimize the amount of time and resources required to manage vulnerability information. 6) Facilitate long-term research and development of techniques, products, and processes for avoiding or mitigating vulnerabilities. Christey & Wysopal Expires August 2002 [Page 5] Internet-Draft Responsible Vulnerability Disclosure February 2002 7) Minimize the amount of antagonism that often exists between parties as a result of different assumptions and expectations, due to the lack of consistent and explicit disclosure practices. 2 Phases of Responsible Disclosure Following are the basic phases of the responsible vulnerability disclosure process. Some of these phases may be bypassed in specific situations with agreement across all parties. In other cases, one or more parties may not be responsible, skipping some phases. 1) Latent Flaw. A flaw is introduced into a product during its design, specification, development, installation, or default configuration. 2) Discovery. One or more individuals or organizations discover the flaw through casual evaluation, by accident, or as a result of focused analysis and testing. In some cases, knowledge of the flaw may be kept within a particular group. A vulnerability report or an exploit program may be discovered "in the wild," i.e., in use by malicious attackers or made available for use and distribution. 3) Notification. A reporter or coordinator notifies the vendor of the vulnerability ("Initial Notification"). In turn, the vendor provides the reporter or coordinator with assurances that the notification was received ("Vendor Receipt"). 4) Validation. The vendor or other parties verify and validate the reporter's claims ("Reproduction"). 5) Resolution. The vendor and other parties also try to identify where the flaw resides ("Diagnosis"). The vendor develops a patch or workaround that eliminates or reduces the risk of the vulnerability ("Fix Development"). The patch is then tested by other parties (such as reporter or coordinator) to ensure that the flaw has been corrected ("Patch Testing"). 6) Release. The vendor, coordinator, and/or reporter release the information about the vulnerability, along with its resolution. The vendor may initially release this information to its customers and other organizations with which it may have special relationships ("Limited release"). The vendor or other parties may then release the information - possibly with additional details - to the security community. 7) Follow-up. The vendor, customer, coordinator, reporter, or security community may conduct additional analysis of the vulnerability or the quality of its resolution. Christey & Wysopal Expires August 2002 [Page 6] Internet-Draft Responsible Vulnerability Disclosure February 2002 3 Responsibilities in the Phases of Vulnerability Disclosure 3.1 Latent Flaw The following recommendations identify how most latent flaws can be avoided. 1) The Vendor SHOULD ensure that programmers, designers, and testers are knowledgeable about common flaws in the design and implementation of products. Rationale: Some classes of vulnerabilities are well-known and can be easily exploited using repeatable techniques. Educated programmers, designers, and testers can identify and eliminate vulnerabilities before the product is provided to customers, or prevent their introduction into the product in the first place. 2) Customers SHOULD configure their products and systems in ways that eliminate latent flaws or reduce the impact of latent flaws, including (1) removing default services that are not necessary for the operation of the affected systems, (2) limiting necessary services only to networks or systems that require access, (3) using the minimal amount of access and privileges necessary for proper functioning of the products, and (4) using security features of the product or operating system that reduce the chance that a flaw can be successfully exploited. Rationale: Many computer intrusions involve the exploitation of vulnerabilities in network services that are unnecessary for typical operating environments. In some cases, system configuration can reduce the overall risk of vulnerabilities (known and unknown). For example, the Code Red and Nimda worms of 2001 were largely successful because of these factors. 3) The Security Community SHOULD track all known vulnerabilities to identify new classes of vulnerabilities, educate the public about these types of vulnerabilities, and find ways to detect or prevent them in the development, testing, and deployment of products. 3.2 Discovery 1) The Reporter SHOULD make a reasonable effort to ensure that: - the vulnerability is real - the process of getting the product into a known exploitable state is repeatable - the vulnerability has not already been reported by the vendor or well-established vulnerability information sources Rationale: Some vulnerabilities are re-discovered after they have already been fixed, or the reporter has introduced the problem due to Christey & Wysopal Expires August 2002 [Page 7] Internet-Draft Responsible Vulnerability Disclosure February 2002 misconfiguration, or the reporter identifies the symptoms of the vulnerability without determining the cause. If the reporter ensures that the problem is new and real, then the reporter will will avoid unnecessarily consuming the time and resources spent by vendors and other parties in investigating the problem. Note: in some cases, a reporter may not be able to make a reasonable effort due to limitations of time, resources, access to the product, or expertise. In some cases, the problem may only appear intermittently, or the product is only temporarily accessible to the reporter (e.g., when the reporter is a consultant who discovers the problem in products that a customer uses). In other cases, the reporter may discover information about the vulnerability without having any access to the product. Note: in some cases, the reporter may be able to coerce the product into a state that is known to be exploitable, without creating a fully working exploit program (e.g., a buffer overflow with a long string of 'A' characters may produce a result that shows that the instruction pointer has been overwritten). This is considered a reasonable effort. 3.3 Notification Phase: Initial Notification To facilitate the disclosure process, Vendors need to be accessible to Reporters, and Reporters need to find and use the appropriate communication channels for notifying Vendors. 3.3.1 Vendor Responsibilities 1) The Vendor MUST make it as easy as possible for Reporters, Coordinators, Customers, and the Security Community to notify the Vendor of vulnerabilities. Rationale: It is often difficult for reporters or other parties to notify vendors of vulnerabilities, especially if the reporters are not customers. This may cause the parties to bypass other phases of the disclosure process, or adopt a policy that avoids vendor notification because of previous bad experiences with vendors. 2) The Vendor SHOULD establish a Security Response Capability (SRC) that consists of one or more individuals or groups that are responsible for responding to vulnerability reports, verifying vulnerabilities, releasing bulletins, etc. Christey & Wysopal Expires August 2002 [Page 8] Internet-Draft Responsible Vulnerability Disclosure February 2002 3) The Vendor SHOULD ensure that its staff knows how to recognize a reported security issue and direct it to the Security Response Capability. This recommendation applies to staff who provide support online, over the telephone, in person, or through some other means by which reporters may interact with the Vendor. 4) If the Vendor can control the e-mail addresses that it uses (e.g., it has its own domain name), then the Vendor SHOULD define and publish the "secalert" alias for use in vulnerability notification. Rationale: Currently, Vendors use a variety of aliases for notification, including "security-alert," "security," and "support." Some Vendors may use the "security" alias for physical security facilities. The "security" alias is also defined in RFC2142 for use in incident handling. The "security-alert" alias is longer than 8 characters and contains a dash, which could make it more difficult to use or locate in search engines. The "secalert" alias is not commonly used at this time, and as such it does not have the types of issues that some commonly-used aliases have. Note: smaller vendors may not be able to control which e-mail addresses they use. 5) If the Vendor operates a web site or other means of distributing information regarding its product, then the Vendor SHOULD create and publish a "security" page or folder that identifies how vulnerability reports should be made. The Vendor SHOULD make this page easy to find from other locations, such as a separate contact page or index. 6) The Vendor MUST provide a facility for individuals or organizations who are not Customers to report vulnerabilities. The Vendor SHOULD NOT require (1) an active technical support number, (2) telephone access that is not toll-free, or (3) user registration for a web site or other facility that would be used for reporting. Rationale: As described earlier, some reporters or coordinators are not necessarily customers of the Vendor. If the Vendor is not accessible to them, then they will be more likely to bypass other aspects of this process. 7) The Vendor SHOULD recognize that inexperienced or malicious reporters may not use proper notification, and define its own procedures for handling such cases. 3.3.2 Reporter Responsibilities 1) The Reporter SHOULD make reasonable efforts to use the appropriate channels for notifying the Vendor of the vulnerability: Christey & Wysopal Expires August 2002 [Page 9] Internet-Draft Responsible Vulnerability Disclosure February 2002 (a) The Reporter SHOULD attempt to notify the vendor through the channels described in this section. (b) If the Vendor is not accessible through those channels, then the Reporter MAY attempt to contact the vendor through technical support. Note: in some cases, a reporter may not be able to make a reasonable effort due to time limitations, lack of proper access to the vendor, inexperience, expense, prohibitions by the reporter's own organization, or the reporter does not meet some criteria for notification (e.g., a support contract number). 2) If the Reporter is unable to notify the Vendor, then the Reporter SHOULD ask a Coordinator to notify the Vendor. The Reporter SHOULD provide the Coordinator with a list of contacts or mechanisms that were used to attempt to notify the Vendor. Rationale: a Coordinator may appear more credible than the Reporter, or have a previously established relationship with the Vendor. The Reporter may be prohibited from disclosing the vulnerability directly to the Vendor. Note: the Coordinator will not necessarily have a different way of reaching the Vendor than the Reporter does. 3) The Reporter and/or Coordinator SHOULD record the date of notification. Rationale: This helps Customers, Reporters, Coordinators, and the Security Community track how long it takes for a Vendor to resolve a vulnerability after the initial notification. 4) The Reporter SHOULD provide the Vendor, and the Coordinator (if any), with all known details of the issue, including any programs, scripts, or pseudo-code that would allow the Vendor to reproduce and/or confirm the vulnerability. Rationale: such details make it easier for the Vendor and Coordinator to reproduce and diagnose the vulnerability, which then allows the Vendor to identify or develop a resolution more quickly. Note: some vulnerabilities may be theoretical or not well-understood in this phase of the disclosure process, and the Reporter may not have developed programs that exploit the problem. In other cases, the Reporter may be using proprietary programs to demonstrate the vulnerability. Christey & Wysopal Expires August 2002 [Page 10] Internet-Draft Responsible Vulnerability Disclosure February 2002 3.4 Notification Phase: Vendor Receipt 3.4.1 Vendor Responsibilities 1) The Vendor MUST notify the Reporter and involved Coordinators that the Vendor has received the notification. This Receipt does not necessarily imply that the Vendor has researched or reproduced the vulnerability, only that the Vendor is aware of the notification. Rationale: if the Vendor does not respond, then the Reporter or Coordinator may not be sure if the Vendor is truly aware of the reported vulnerability, and/or if the Vendor intends to resolve the vulnerability. This often causes Reporters or Coordinators to bypass later phases of the disclosure process in order to warn customers of the risks to their systems. 2) The Vendor MUST provide the Reporter and involved Coordinators with a Receipt within 7 days. Rationale: Other time frames (such as 5 business days) were considered but deemed unworkable due to international issues (e.g., "work weeks" may fall on different days in different countries, there are different national or religious holidays). Defining a time frame relative to the Vendor or Reporter could not work without some form of communication between both parties. Note: small but responsible Vendors or individuals may not be able to provide this degree of responsiveness, especially during vacation periods. Reporters and Coordinators SHOULD take this into account during the notification phase. Small, responsible Vendors SHOULD post some clear notification when it is known that such delays will occur. 3) If the Vendor's receipt message is automatically generated, then it SHOULD include a time period or date by which an individual (or the Security Response Capability) will provide follow-up on the reported vulnerability. The time period SHOULD NOT exceed 10 days. 4) Within 10 days of initial notification, the Vendor's Security Response Capability SHOULD provide a clear response to the Reporter and any involved Coordinators. 3.5 Validation Phase 3.5.1 Vendor Responsibilities 1) If the vulnerability is found in a supported product, the Vendor MUST either (1) reproduce the vulnerability, (2) determine if there is enough evidence for the existence of the vulnerability when it Christey & Wysopal Expires August 2002 [Page 11] Internet-Draft Responsible Vulnerability Disclosure February 2002 cannot be reproduced, (3) determine if the vulnerability is already known (and possibly resolved), or (4) work with the Reporter to determine if the vulnerability is related to the specific environment in which it was discovered (including configuration errors or interactions with other products). 2) If the vulnerability is found in an unsupported or discontinued product, the Vendor MAY refuse to validate the vulnerability. However, the Vendor MUST ensure that the reported vulnerability does not exist in supported product versions or other supported products based on the vulnerable product. 3) The Vendor SHOULD NOT assume that the risk or impact of the vulnerability is limited to what has been identified by the Reporter or involved Coordinator. Rationale: The Reporter or involved Coordinator may not have sufficient experience or time to identify the full scope of the problem. Sometimes, a theoretical vulnerability is later found to be more easily exploitable as a result of follow-on analysis or the creation of a tool. For example, it may be easy for a Reporter to find evidence of a buffer overflow vulnerability by sending a long argument that causes a product to crash. It is an indicator that a carefully crafted program could be used to execute arbitrary code. The Reporter and Vendor may not have the skills or resources to create such a program, but such a program could be created in the future. 4) The Vendor SHOULD examine its product to ensure that it is free of other problems that are similar to the reported vulnerability. Rationale: some Vendors reproduce and resolve the specific issue that is identified by the Reporter without extending their analysis to see if similar mistakes were made elsewhere in the product. The Reporter, others in the Security Community, or hackers may conduct follow-on research to find these other vulnerabilities. This can result in a cycle in which vulnerabilities are discovered and patched so often that it becomes difficult for customers to manage the volume of resolutions that they need to apply. 5) The Vendor MUST consult with the Reporter and involved Coordinators when more information or analysis is needed. 6) The Vendor SHOULD provide status updates to the Reporter and any involved Coordinators every 7 days. The Vendor MAY negotiate with the parties for less frequent updates. 7) The Vendor MUST notify the Reporter and any involved Coordinators when the Vendor is able to reproduce the vulnerability. Christey & Wysopal Expires August 2002 [Page 12] Internet-Draft Responsible Vulnerability Disclosure February 2002 8) The Vendor SHOULD attempt to resolve the vulnerability within 30 days of initial notification. 9) If the Vendor cannot resolve the vulnerability within 30 days, then the Vendor MUST provide the Reporter and involved Coordinators with specific reasons why the vulnerability cannot be resolved. 10) If the Vendor is aware of other vendors that share the same codebase as the affected product, then the Vendor MUST either (1) notify those vendors, or (2) notify a Coordinator that other Vendors may be affected by the reported vulnerability. 3.5.2 Reporter Responsibilities 1) The Reporter SHOULD work with the Vendor in a timely fashion to explain the vulnerability and conduct further analysis. Rationale: if a problem is sufficiently complex or only appears in a portion of deployed systems, then the Vendor may not be able to reproduce the issue. In other cases, the Vendor may not understand the problem. If the Reporter is slow to respond, then this can extend the time window during which Customers are at risk. 2) If the Vendor does not understand the nature, risk, or resolution of the vulnerability, then the Reporter or involved Coordinators SHOULD provide the Vendor with resources that help to explain the vulnerability. Note: Some Vendors may require - or insist - upon extensive consultation to identify the vulnerability. Reporters and Coordinators may not have the time or resources to provide such assistance. 3) If the Reporter does not have the time or resources to conduct such analysis, then the Reporter SHOULD notify the Vendor and suggest alternate contacts (such as Coordinators) who may be able to assist the Vendor. The Reporter SHOULD NOT attempt to bypass later phases. 4) If the Reporter finds that the Reporter is in error, then the Reporter SHOULD notify the Vendor and involved Coordinators. Rationale: if a Reporter does not perform this notification, then the Vendors or Coordinators may continue to spend unnecessary resources on further analysis of the issue. 5) The Reporter SHOULD grant time extensions to the Vendor if there is evidence that the Vendor is acting in good faith to resolve the vulnerability. Christey & Wysopal Expires August 2002 [Page 13] Internet-Draft Responsible Vulnerability Disclosure February 2002 6) If the Vendor is unresponsive or disagrees with the Reporter's findings, then the Reporter SHOULD involve a Coordinator. 3.5.3 Coordinator Responsibilities 1) The Coordinator MUST attempt to resolve any conflicts or technical disagreements that arise between the Reporter and the Vendor. 2) If a Vendor is unresponsive or does not appear to be acting in good faith to resolve the vulnerability, then the Coordinator SHOULD attempt to convince the Vendor to follow the proper process. 3) If a Reporter is unresponsive or does not appear to be acting in good faith to resolve the vulnerability, then the Coordinator SHOULD attempt to convince the Reporter to follow the proper process. 4) The Coordinator SHOULD work with the Vendor and Reporter to determine if other Vendors are affected by the same problem. 5) The Coordinator SHOULD work with the Vendor and Reporter to identify time extensions (if any) that are acceptable to all parties. 3.6 Resolution Phase The "Resolution" of a vulnerability involves action regarding one or more of the following: - patch creation - recommendation of configuration change - design change - workaround - no action If the Vendor does not participate or is unresponsive, then the Reporter and Coordinator might not be able to create a patch or change the design of the product. 3.6.1 Vendor Responsibilities 1) The Vendor MUST identify the fundamental nature of the flaw within the source code or in the design of the product ("Diagnosis"). 2) The Vendor MUST either (1) provide a patch, configuration change, or workaround that appropriately reduces or eliminates the risk of the vulnerability ("Fix Development"), or (2) provide the Reporter and involved Coordinators with specific reasons for its inaction. Christey & Wysopal Expires August 2002 [Page 14] Internet-Draft Responsible Vulnerability Disclosure February 2002 3) The Vendor SHOULD request time extensions from the Reporter and involved Coordinators when necessary. 4) The Vendor SHOULD test the patches, configuration changes, and workarounds sufficiently to ensure that either (1) they do not adversely affect the operation of the product, or (2) it is clear which conditions may adversely affect the operation of the product. Rationale: Vendors may be pressured to quickly resolve vulnerabilities without sufficient testing, especially when Reporters have bypassed the Notification or Validation phases. As a result, the resolution may adversely affect more systems than necessary. 5) The Vendor MUST provide the Reporter and involved Coordinators with all known configuration changes or workarounds that address the vulnerability ("Fix Development"). 6) The Vendor SHOULD provide the Reporter and involved Coordinators with any patches ("Patch Testing"). Rationale: this helps the Reporter and Coordinator to confirm that the vulnerability has been reduced or eliminated. Note: the Vendor's business model may require that only supported Customers can have access to a patch, which could exclude Reporters or Coordinators. Such Vendors should recognize that this practice may result in an incomplete patch that does not address the vulnerability in question. 7) If the Reporter is unresponsive or uncooperative, or a dispute arises, then the Vendor SHOULD work with a Coordinator to identify the best available resolution for the vulnerability. 3.6.2 Reporter Responsibilities 1) The Reporter SHOULD recognize that it may be difficult for a Vendor to resolve a vulnerability within 30 days if (1) the problem is related to insecure design, (2) the Vendor has a diverse set of hardware, operating systems, and/or product versions to support, or (3) the Vendor is not skilled in security. 2) The Reporter SHOULD grant time extensions to the Vendor if the Vendor is acting in good faith to resolve the vulnerability. 3) If the Vendor is unresponsive or uncooperative, or a dispute arises, then the Reporter SHOULD work with a Coordinator to identify the best available resolution for the vulnerability. Christey & Wysopal Expires August 2002 [Page 15] Internet-Draft Responsible Vulnerability Disclosure February 2002 3.7 Release Phase 3.7.1 Vendor Responsibilities 1) The Vendor SHOULD work with the Reporter and involved Coordinators to arrange a date after which the vulnerability information may be released. 2) The Vendor MAY ask the Reporter and Coordinator to allow a "Grace Period" up to 30 days, during which the Reporter and Coordinator do not release details of the vulnerability that could make it easier for hackers to create exploit programs. Rationale: a grace period provides Customers with a time period in which they can fix their systems. During this time, the lack of details may make it more difficult or resource-intensive for attackers to determine the nature of the vulnerability and craft an exploit. However, some security-aware Customers desire such details so that they can better decide whether the resolution of the vulnerability is appropriate for their environment. In addition, some members of the Security Community desire such details in order to (1) enhance tools or techniques to detect vulnerable systems on Customer networks (such as vulnerability scanners), (2) enhance tools or techniques to detect attempts to exploit vulnerabilities on Customer networks (such as intrusion detection systems), (3) provide databases or other information that Customers use to identify and prioritize vulnerabilities that may affect the Customer's enterprise, and (4) perform research and trend analysis. 3) If the Reporter has not properly followed the process and publicly announces the vulnerability, then the Vendor SHOULD post its awareness of the vulnerability, and the Vendor's progress in its resolution, to appropriate forums. Rationale: this allows Customers and the Security Community to know that the Vendor is aware of the problem and working to resolve it. Note: some Vendors may not wish to acknowledge such vulnerabilities until a patch is available. 4) If a Reporter has properly followed the process, then the Vendor MUST provide credit to that reporter. 5) If a Coordinator has properly followed the process, then the Vendor SHOULD provide credit to the Coordinator. 6) If a Reporter has not properly followed the process and publicly announces the vulnerability, then the Vendor MAY provide credit to the reporter. Christey & Wysopal Expires August 2002 [Page 16] Internet-Draft Responsible Vulnerability Disclosure February 2002 Rationale: Some people believe that even if a reporter has not followed the procedures properly, the reporter has still provided valuable information that is useful to the Vendor, Customers, Coordinators, and the Security Community, and academic integrity would dictate that reporters should be credited. However, since credit is a motivation for some reporters, others believe that irresponsible reporters should not be encouraged to bypass the process and still get credit. 7) The Vendor MUST NOT assume that the lack of vulnerability details will prevent the creation of an exploit. Rationale: If the Vendor provides source code for the product, then any entity who has access to the product could easily determine the specific locations of the vulnerability and identify possible attack vectors that reach the vulnerable code. If the Vendor does not provide source code, then any entity who has access to a patch could use reverse engineering techniques to determine how the code was changed, then infer the nature of the vulnerability. 8) The Vendor SHOULD cryptographically sign all patches using a method that is commonly accessible on the platforms for the Vendor's product. The Vendor should clearly advertise its cryptographic key and provide cryptographic checksums for its patches. Rationale: This increases the assurance that the patches from the Vendor are authentic. 9) The Vendor SHOULD provide an easily accessible mechanism for Customers and the Security Community to obtain all security advisories, such as a web page. The most recent advisory SHOULD be listed first. 10) The Vendor SHOULD provide a mechanism for notifying Customers and the Security Community when new advisories are published. 11) The Vendor SHOULD provide a means for the Security Community to identify which reported vulnerabilities are genuine, but are not regarded by the Vendor as important enough to merit a security advisory. Rationale: Vendors are often unwilling to release security advisories unless the security issue is critical for its Customers. This can reduce operating expenses for the Vendor and most Customers. However, some members of the Security Community, and some Customers, also prefer to protect themselves against less serious vulnerabilities. If a Vendor does not at least indicate to its security-aware Customers that a security-related resolution is available, then those Customers may remain at risk for Christey & Wysopal Expires August 2002 [Page 17] Internet-Draft Responsible Vulnerability Disclosure February 2002 vulnerabilities that they would otherwise wish to resolve. 12) The Vendor SHOULD provide an easily accessible indicator that allows a Customer to determine if the resolution has been applied to a system, e.g., by modifying the product's version number or providing the Customer with a tool that identifies the resolutions that have been applied to a product. 3.7.2 Reporter Responsibilities 1) The Reporter SHOULD work with the Vendor and involved Coordinators to arrange a date after which the vulnerability information may be released. 2) If the Vendor has not resolved the vulnerability within a time frame that is allowed by this process, then the Reporter SHOULD work with a Coordinator to announce the vulnerability to Customers and the Security Community. 3) If another reporter has not properly followed the process and publicly announced the vulnerability, then the Reporter MAY announce that the Reporter was responsibly following the disclosure process with the Vendor and involved Coordinators. 4) If a Vendor requests a Grace Period, then the Reporter SHOULD follow the Grace Period before releasing details of the vulnerability. 5) After the Grace Period, the Reporter MAY release additional details. The Reporter SHOULD carefully consider how much detail is needed by Customers and the Security Community. Note: in some cases, the nature of the vulnerability could make it difficult or impossible to release vulnerability details that do not allow someone to exploit the vulnerability. 6) The Reporter SHOULD provide credit to any Vendor and/or Coordinator who has followed the process. 3.7.3 Coordinator Responsibilities 1) The Coordinator SHOULD work with the Vendor and Reporter to arrange a date after which the vulnerability information may be released. 2) If the Vendor requests a Grace Period, the Coordinator SHOULD follow the Grace Period and encourage the Reporter to follow the Grace Period. Christey & Wysopal Expires August 2002 [Page 18] Internet-Draft Responsible Vulnerability Disclosure February 2002 3) The Coordinator SHOULD provide credit to any Vendor and/or Reporter who properly follows the process. 4) The Coordinator MAY provide credit to a reporter who has not properly followed the process. 3.7.4 Customer Responsibilities 1) The Customer MUST NOT assume that the lack of details will prevent the creation of an exploit. 2) If the Vendor has released information regarding the vulnerability, then the Customer SHOULD assume that the information is credible. The Customer SHOULD NOT require that the vulnerability be demonstrated before applying the resolution. 3) If the Vendor has not released such information, but a well-established Reporter or Coordinator has, then the Customer SHOULD assume that the information is credible. The Customer SHOULD NOT require that the vulnerability be demonstrated before applying the resolution. 4) If vulnerability information has been released and a Grace Period exists, then the Customer SHOULD apply the resolution to its systems during the Grace Period. 5) Where possible, the Customer SHOULD test any patches, configuration changes, or workarounds on test systems before making the changes in an operational environment. 6) The Customer SHOULD inform the Vendor and the Security Community if a patch, configuration change, or workaround does not appear to work properly. 7) The Customer SHOULD give preference to products whose Vendors follow responsible disclosure practices. 3.7.5 Security Community Responsibilities 1) The Security Community SHOULD publicly recognize all Vendors, Reporters, and Coordinators who follow responsible vulnerability disclosure. 2) The Security Community SHOULD adopt a set of terms that allows all parties to describe the inherent risk or impact of a vulnerability that can be interpreted in various environments, threat levels, and policies. Christey & Wysopal Expires August 2002 [Page 19] Internet-Draft Responsible Vulnerability Disclosure February 2002 Rationale: Customers have varying operational needs at different levels of security, which can make it difficult to define a "one size fits all" risk level for any vulnerability. Current terminology often uses a "High, Medium, Low" breakdown, but there are no formal definitions. As such, this terminology is used inconsistently, partially because it is based on the perspective of the entity who is using it. It is also insufficient to capture the complexity and tradeoffs of vulnerabilities in today's environment. 3.8 Follow-Up Phase 1) The Vendor SHOULD clearly notify Customers and the Security Community when a resolution is (a) faulty, or (b) revised. 2) The Vendor SHOULD NOT re-release the same advisory for newly discovered, closely related vulnerabilities. Rationale: The re-release of an advisory may not be noticed as well by Customers, which could cause the Customers to believe that their systems are secure because they applied the resolution that was identified in the original advisory. 4 Policy Publication 4.1 Vendor Policy A Vendor SHOULD publish a policy and procedures statement that includes the following information: 1) Where it complies (and does not comply) with the process outlined in this document. 2) The typical amount of time after notification that the Vendor requires to produce a resolution. 3) The Grace Period, if any, that the Vendor wishes to observe. 4) How the Vendor determines whether a reported problem is serious enough to merit a security advisory. 4.2 Reporter Policy If a Reporter is a member of the Security Community and the Reporter frequently finds new vulnerabilities, then the Reporter SHOULD publish a policy and procedures statement that includes the following information: 1) Where it complies (and does not comply) with the process outlined in this document. Christey & Wysopal Expires August 2002 [Page 20] Internet-Draft Responsible Vulnerability Disclosure February 2002 2) The maximum Grace Period that the Reporter is willing to follow. 4.3 Coordinator Policy A Coordinator SHOULD publish a policy and procedures statement that includes the following information: 1) Where the Coordinator complies (and does not comply) with the process outlined in this document. 2) The maximum Grace Period that the Coordinator is willing to follow. 5 References Note: many of these references identify posted messages to security-related mailing lists. These messages often resulted in long threads that explore the related issues in more depth. 5.1 Disclosure Policies RFPolicy 2.0 http://www.wiretrip.net/rfp/policy.html Bugtraq Frequently Asked Questions http://www.securityfocus.com/popups/forums/bugtraq/faq.shtml NTBugtraq Disclosure Policy http://ntbugtraq.ntadvice.com/default.asp?sid=1&pid=47&aid=48 CERT/CC Vulnerability Disclosure Policy http://www.kb.cert.org/vuls/html/disclosure/ ACROS ASPR Notification and Publishing Policy http://www.acros.si/aspr_policy.html NMRC policy http://www.nmrc.org/advise/policy.txt @stake Security Advisory Disclosure Policy http://www.atstake.com/research/policy/index.html 5.2 Commentary on Disclosure Details "Full Disclosure is a necessary evil" Elias Levy SecurityFocus web site August 16, 2001 http://www.securityfocus.com/news/238 Christey & Wysopal Expires August 2002 [Page 21] Internet-Draft Responsible Vulnerability Disclosure February 2002 "It's Time to End Information Anarchy" Scott Culp Microsoft web site October 2001 http://www.microsoft.com/technet/columns/security/noarch.asp "Security in an Open Electronic Society" Elias Levy SecurityFocus web site October 21, 2001. http://www.securityfocus.com/news/270 "Full Disclosure" Bruce Schneier Crypto-Gram Newsletter November 15, 2001 http://www.counterpane.com/crypto-gram-0111.html#1 "Script Kiddies Suck" Marcus Ranum Black Hat Briefings presentation July 2000 http://web.ranum.com/usenix/blackhat-2000-keynote.mp3 "The Network Police Blotter: The Slaughter of the Innocents" Marcus Ranum ;Login: magazine October 2000 http://web.ranum.com/usenix/ranum_5_temp.pdf 5.3 Commentary on Disclosure Process "Bugs in the Disclosure Process" Ivan Arce TISC Insight, Volume 3, Issue 3 February 9, 2001 http://tisc.corecom.com/newsletters/33.html "SUMMARY: Bug announcement rule of thumb." Bill Stout NTBugtraq mailing list August 13, 1998 http://marc.theaimsgroup.com/?l=ntbugtraq&m=90310164223252&w=2 Christey & Wysopal Expires August 2002 [Page 22] Internet-Draft Responsible Vulnerability Disclosure February 2002 "Microsoft admits IE security alert lapse" Wendy McAuliffe ZDNet November 19, 2001 http://www.zdnet.com/filters/printerfriendly/ 0,6061,2825716-2,00.html "RFP2K03: Contemplations on dvwssr.dll and its affects on life" Rain Forest Puppy Bugtraq mailing list April 20, 2000 http://www.securityfocus.com/archive/1/56394 "Xato Advisory: Win2k/XP Terminal Services IP Spoofing" Xato Bugtraq mailing list November 14, 2001 http://www.securityfocus.com/archive/1/240248 "Vulnerability Escrow (was: Extreme Hacking)" Crispin Cowan NFR Wizards mailing list July 7, 1999 http://archives.neohapsis.com/archives/nfr-wizards/1999_2/0416.html "Can we afford full disclosure of security holes?" Richard M. Smith Bugtraq mailing list August 10, 2001 http://www.securityfocus.com/archive/1/203499 "Anti-Web 'Vulnerability' is a false alarm" Doug Hoyte Vuln-Dev mailing list December 1, 2001 http://marc.theaimsgroup.com/?l=vuln-dev&m=100732828128718&w=2 "Windows of Vulnerability: A Case Study Analysis" William A. Arbaugh, William L. Fithen, John McHugh IEEE Computer December 2000 "Sun denies Unix flaw" John Geralds vnunet.com November 20, 2001 http://www.vnunet.com/News/1126973 Christey & Wysopal Expires August 2002 [Page 23] Internet-Draft Responsible Vulnerability Disclosure February 2002 "Open Response To Microsoft Security - RE: It's Time to End Information Anarchy" Steve Manzuik Vuln-Dev mailing list October 17, 2001 http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0195.html "A Step Towards Information Anarchy: A Call To Arms" hellNbak Nomad Mobile Research Center November 2, 2001 http://www.nmrc.org/InfoAnarchy/InfoAnarchy.htm "To Disclose or Not to Disclose, That Is the Question" Mark Joseph Edwards Windows 2000 Magazine June 27, 2001 http://www.windowsitsecurity.com/Articles/Index.cfm?ArticleID=21618 "Towards a responsible vulnerability process" David LeBlanc NTBugtraq mailing list November 3, 2001 http://archives.neohapsis.com/archives/ntbugtraq/2001-q4/0097.html 5.4 Commentary on Advisories "Writing security advisories" Kurt Seifried September 10, 2001 http://www.seifried.org/security/articles/ 20010910-writing-security-advisories.html "Xato commentary on MS security bulletins" Xato Bugtraq mailing list December 7, 2000 http://marc.theaimsgroup.com/?l=bugtraq&m=97626305317046&w=2 5.5 Commentary on Vendor Accessibility "Getting to the Third Wave of Security Responsiveness" Scott Culp January 2001 http://www.microsoft.com/technet/columns/security/thrdwave.asp Christey & Wysopal Expires August 2002 [Page 24] Internet-Draft Responsible Vulnerability Disclosure February 2002 "An informal analysis of vendor acknowledgement of vulnerabilities" Steve Christey, Barbara Pease Bugtraq mailing list March 11, 2001 http://marc.theaimsgroup.com/?l=bugtraq&m=98438570915835&w=2 "Shockwave Flash buffer overflow" Neal Krawetz Bugtraq mailing list December 29, 2000 http://marc.theaimsgroup.com/?l=bugtraq&m=97845942432045&w=2 "Re: Shockwave Flash buffer overflow" Peter Santangeli Bugtraq mailing list January 5, 2001 http://marc.theaimsgroup.com/?l=bugtraq&m=97897439808223&w=2 "Re: SafeWord Agent for SSH (secure shell) vulnerability" Leif Nixon Bugtraq mailing list November 29, 2001 http://marc.theaimsgroup.com/?l=bugtraq&m=100706579514862&w=2 5.6 Discovery of Issues in the Wild "sadmind" Nancy Lin SF-INCIDENTS mailing list December 9, 1999 http://marc.theaimsgroup.com/?l=incidents&m=94476722417209&w=2 "sadmind exploits (remote sparc/x86)" Marcy Abene Bugtraq mailing list December 10, 1999 http://marc.theaimsgroup.com/?l=bugtraq&m=94486731225359&w=2 "IIS %c1%1c remote command execution" Rain Forest Puppy Bugtraq mailing list October 17, 2000 http://marc.theaimsgroup.com/?l=bugtraq&m=97180137413891&w=2 Christey & Wysopal Expires August 2002 [Page 25] Internet-Draft Responsible Vulnerability Disclosure February 2002 5.7 Researcher Credibility and Vulnerability Reproduction "vCard DoS on Outlook 2000" Joel Moses Bugtraq mailing list August 31, 2000 http://marc.theaimsgroup.com/?l=bugtraq&m=96774764029236&w=2 "Microsoft Outlook 2000 vCard Buffer Overrun" @stake February 26, 2001 http://www.atstake.com/research/advisories/2001/a022301-1.txt "Re: Microsoft Security Bulletin MS01-012" Joel Moses Bugtraq mailing list February 23, 2001 http://marc.theaimsgroup.com/?l=bugtraq&m=98322714210100&w=2 5.8 Miscellaneous "Vulnerability disclosure publications and discussion tracking" University of Oulu November 20, 2001 http://www.ee.oulu.fi/research/ouspg/sage/disclosure-tracking/ "Devil in the details - why package signing matters" Kurt Seifried October 24, 2001 http://www.seifried.org/security/articles/ 20011023-devil-in-details.html 6 Acknowledgements We gratefully acknowledge the constructive comments received from several contributors. Any errors or inconsistencies in this document are solely the responsibility of the authors, and not of the reviewers. This document does not necessarily reflect the opinion of the reviewers or their parent organizations. We would like to thank Andy Balinsky, Mary Ann Davidson, Elias Levy, Russ Cooper, Scott Blake, Seth Arnold, Rain Forest Puppy, Marcus Ranum, Lori Woeler, Adam Shostack, Mark Loveless, Scott Culp, and Shawn Hernan for their valuable input. 7 Security Considerations This entire document discusses security issues. Christey & Wysopal Expires August 2002 [Page 26] Internet-Draft Responsible Vulnerability Disclosure February 2002 8 Authors' Addresses Steve Christey The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA E-Mail: coley@m... Chris Wysopal @stake, Inc. 196 Broadway Cambridge, MA 02139-1902 USA E-Mail: cwysopal@a... 9 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document expires August 12, 2002. Christey & Wysopal Expires August 2002 [Page 27] ======================================================== TSCM-L Technical Security Mailing List "In a multitude of counselors there is strength" To subscribe to the TSCM-L mailing list visit: http://www.yahoogroups.com/community/TSCM-L It is by caffeine alone I set my mind in motion. It is by the juice of Star Bucks that thoughts acquire speed, the hands acquire shaking, the shaking is a warning. It is by caffeine alone I set my mind in motion. =================================================== TSKS Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 5093 From: Richard Gray Date: Mon Mar 25, 2002 10:55pm Subject: Seeking:Texas/Mississippi/Louisiana Internship I am willing to volunteer time/travel to have the chance to work with an experienced professional in the Louisiana/Texas area. My future plans are to conduct low/medium level sweeps in south Louisiana only with a target market of Domestic Clients and Attorneys. I am willing to sign non-compete agreements in your target market area for the opportunity to learn from your experience. In exchange, I will provide you with a talented investigator to do any grunt work you need done at the site. Thanks in advance, Richard Gray _________________________________ Richard T. Gray Jr. Legal Investigator License No. 1914-050896-LA Gray & Associates, LLC PO Box 2368 Crowley, LA 70527 337-785-0046 Voice 800-394-8216 Fax www.la-pi.com ricky@l... "When you need to know!" _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 5094 From: gvp Date: Fri Mar 29, 2002 9:31pm Subject: black kettle > on the panel. That should say it all. Pathetic morons who need to see > their names in lights, and give each other awards. > > Steve > > > ******************************************************************* > Steve Uhrig, SWS Security, Maryland (USA) 5095 From: zack <10-33@c...> Date: Fri Mar 29, 2002 10:38pm Subject: Re: Spy Software Detection Help http://personal.atl.bellsouth.net/mia/k/r/kryp/ FREE !! At 03:37 AM 3/30/2002 +0000, you wrote: >Is there any software that will detect logging and spyware programs >installed on a computer? > >Ricky visit http://www.copscops.com Washington DC Police Department http://mpdc.dc.gov/main.shtm "Unity... Resolve... Freedom. These are the hallmarks of the American spirit." George W Bush President of the United States of America God Bless The USA .. NEVER forget 9-11-01 http://www.copscops.com/blessusa.htm [Non-text portions of this message have been removed] 5096 From: Gordon Mitchell Date: Sat Mar 30, 2002 7:16am Subject: Re: Contract for Low threat sweep I recommend something like the following. Everybody is likely to miss something so I wouldn't limit the scope of this sort of thing. "Future Focus services will be performed in compliance with applicable laws and regulations; eavesdropping device discovery will likely need to be reported to law enforcement. Client recognizes and affirms that inspections of this sort are an art even though highly technical in nature; no warranty whatsoever is expressed or implied." Richard Gray wrote: > > When I gain enough knowledge to begin offering low threat sweeps, is > there a contract that limits liability for high technology devices > missed by the sweep? > > Ricky > > _________________________________ > Richard T. Gray Jr. > Legal Investigator > License No. 1914-050896-LA > > Gray & Associates, LLC > PO Box 2368 > Crowley, LA 70527 > 337-785-0046 Voice > 800-394-8216 Fax > www.la-pi.com > ricky@l... > "When you need to know!" > > -----Original Message----- > From: Matthew Paulsen [mailto:mpaulsen6@a...] > Sent: Monday, March 25, 2002 10:20 AM > To: tscm-l@yahoogroups.com > Subject: [TSCM-L] Internet Draft - Responsible Vulnerability Disclosure > > Worth a read. May make companies legally liable for not fixing security > holes. > > http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosu > re-0 > 0.txt > > Internet Engineering Task Force Steve Christey > INTERNET-DRAFT MITRE > Valid for six months Chris Wysopal > Category: Best Current Practice @stake, Inc. > February 2002 > > Responsible Vulnerability Disclosure Process > draft-christey-wysopal-vuln-disclosure-00.txt > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. Internet Drafts are working > documents of the Internet Engineering Task Force (IETF), its Areas, > and its Working Groups. Note that other groups may also distribute > working documents as Internet Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Copyright Notice > > Copyright (C) The Internet Society (2002). All Rights Reserved. > > Abstract > > New vulnerabilities in software and hardware products are discovered > and publicized on a daily basis. The disclosure of vulnerability > information has been a divisive topic for years. During the process > of disclosure, many vendors, security researchers, and other parties > follow a variety of unwritten or informal guidelines for how they > interact and share information. Some parties may be unaware of these > guidelines, or they may intentionally ignore them. This state of > affairs can make it difficult to achieve a satisfactory outcome for > everyone who uses or is affected by vulnerability information. > > The purpose of this document is to describe best practices for a > responsible disclosure process that involves vulnerability reporters, > product vendors or maintainers, third parties, the security > community, and ultimately customers and users. > > Christey & Wysopal Expires August 2002 [Page 1] > > Internet-Draft Responsible Vulnerability Disclosure February 2002 > > Table of Contents > > 1 Introduction and Purpose ....................................... 3 > 1.1 Background ................................................... 3 > 1.2 Major Roles in Disclosure .................................... 3 > 1.3 Motivations .................................................. 4 > 1.4 Goals of Responsible Disclosure .............................. 5 > 2 Phases of Responsible Disclosure ............................... 6 > 3 Responsibilities in the Phases of Vulnerability Disclosure ..... 7 > 3.1 Latent Flaw .................................................. 7 > 3.2 Discovery .................................................... 7 > 3.3 Notification Phase: Initial Notification ..................... 8 > 3.3.1 Vendor Responsibilities .................................... 8 > 3.3.2 Reporter Responsibilities .................................. 9 > 3.4 Notification Phase: Vendor Receipt .......................... 11 > 3.4.1 Vendor Responsibilities ................................... 11 > 3.5 Validation Phase ............................................ 11 > 3.5.1 Vendor Responsibilities ................................... 11 > 3.5.2 Reporter Responsibilities ................................. 13 > 3.5.3 Coordinator Responsibilities .............................. 14 > 3.6 Resolution Phase ............................................ 14 > 3.6.1 Vendor Responsibilities ................................... 14 > 3.6.2 Reporter Responsibilities ................................. 15 > 3.7 Release Phase ............................................... 16 > 3.7.1 Vendor Responsibilities ................................... 16 > 3.7.2 Reporter Responsibilities ................................. 18 > 3.7.3 Coordinator Responsibilities .............................. 18 > 3.7.4 Customer Responsibilities ................................. 19 > 3.7.5 Security Community Responsibilities ....................... 19 > 3.8 Follow-Up Phase ............................................. 20 > 4 Policy Publication ............................................ 20 > 4.1 Vendor Policy ............................................... 20 > 4.2 Reporter Policy ............................................. 20 > 4.3 Coordinator Policy .......................................... 21 > 5 References .................................................... 21 > 5.1 Disclosure Policies ......................................... 21 > 5.2 Commentary on Disclosure Details ............................ 21 > 5.3 Commentary on Disclosure Process ............................ 22 > 5.4 Commentary on Advisories .................................... 24 > 5.5 Commentary on Vendor Accessibility .......................... 24 > 5.6 Discovery of Issues in the Wild ............................. 25 > 5.7 Researcher Credibility and Vulnerability Reproduction ....... 26 > 5.8 Miscellaneous ............................................... 26 > 6 Acknowledgements .............................................. 26 > 7 Security Considerations ....................................... 26 > 8 Authors' Addresses ............................................ 27 > 9 Full Copyright Statement ...................................... 27 > > Christey & Wysopal Expires August 2002 [Page 2] > > Internet-Draft Responsible Vulnerability Disclosure February 2002 > > Document Conventions > > The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", > and "MAY" in this document are to be interpreted as described in "Key > words for use in RFCs to Indicate Requirement Levels" [RFC2119]. > > 1 Introduction and Purpose > > This document provides guidance and recommendations for the community > of developers, vendors, end users, researchers and security > professionals who wish to perform responsible vulnerability > disclosure within the information technology arena. For purposes of > this document, the term "responsible" refers to the recognition of a > formal, repeatable process for the reporting, evaluation, resolution > and publication of vulnerability information. "Vulnerability" refers > to any bug, flaw, behavior, output, outcome or event within an > application, system, device, or service that could lead to increased > risk or security exploit. For purposes of this document, we have > standardized on the term "product" to encompass the full suite of > products that are addressed by this document. > > 1.1 Background > > Vulnerabilities are an inherent and unfortunate part of the design > and development process. Vulnerability detection may occur during > any phase of the product lifecycle, to include design, development, > testing, implementation or operation. Ideally, vulnerabilities are > largely prevented through a design process that considers security. > However, due to a variety of reasons, many vulnerabilities are > detected after a product is implemented in an operational environment > and supporting customer objectives. A variety of legislative and > social issues directly influences the process for vulnerability > research, detection and response. Developers, customers and the > security community all have divergent perspectives on the impact of > vulnerabilities. Currently, vulnerability release is inconsistent > and largely driven from the perspective of the party who has the > greatest ability to control the process. In an effort to create a > common framework by which objectives are met to the benefit of all > parties, this document communicates a formal, repeatable process for > addressing vulnerability disclosure in a responsible manner. This > document provides a means to address the common goal of providing > more secure products while reducing the risk to customers. > > 1.2 Major Roles in Disclosure > > Several types of individuals or organizations may play a role in the > process of vulnerability disclosure. These roles may overlap. > > Christey & Wysopal Expires August 2002 [Page 3] > > Internet-Draft Responsible Vulnerability Disclosure February 2002 > > A Vendor is an individual or organization who provides, develops, or > maintains so