From: John Savage Date: Thu Mar 21, 2002 7:50am Subject: MLPIA Banner Good Morning! Here is the link to the MLPIA banner ad: http://mlpia.org/images/anim_mlpia.gif Go to "File" and "Save As" to your own computer, >src="http://mlpia.org/images/anim_mlpia.gif" width="600" height="80" >border="0" alt=Maine Licensed Private Investigators Association"> Please also keep in mind that this group is now by referrals and invitation only, so if you know of someone that would like to be a part of this rapidly growing "networking machine," send them this way. Respectfully, The MLPIA Network http://groups.yahoo.com/group/MLPIA-Network/ John Lee Savage (LPIA) P.O. Box 634 Old Orchard Beach, ME 04064 TEL: 207-286-3945 FAX: 781-723-2551 ******************************************* Licensed by the Maine Department of Public Safety (Lic #373) ******************************************* Maine Notary Public ******************************************* National Association of Investigative Specialists (NAIS) ******************************************* Maine Licensed Private Investigators Association (MLPIA) www.mlpia.org ******************************************* --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.338 / Virus Database: 189 - Release Date: 3/14/02 5044 From: Joseph Date: Thu Mar 21, 2002 0:51pm Subject: RE: MLPIA Banner Well, for one thing I would change your banner to the accepted standard for web pages which is 468 * 60. This will help those who wish to use your banner that already have a system in place. Joseph -----Original Message----- From: John Savage [mailto:iseeu@m...] Sent: Thursday, March 21, 2002 5:51 AM To: TSCM-L@yahoogroups.com Subject: [TSCM-L] MLPIA Banner Good Morning! Here is the link to the MLPIA banner ad: http://mlpia.org/images/anim_mlpia.gif Go to "File" and "Save As" to your own computer, >src="http://mlpia.org/images/anim_mlpia.gif" width="600" height="80" >border="0" alt=Maine Licensed Private Investigators Association"> Please also keep in mind that this group is now by referrals and invitation only, so if you know of someone that would like to be a part of this rapidly growing "networking machine," send them this way. Respectfully, The MLPIA Network http://groups.yahoo.com/group/MLPIA-Network/ John Lee Savage (LPIA) P.O. Box 634 Old Orchard Beach, ME 04064 TEL: 207-286-3945 FAX: 781-723-2551 ******************************************* Licensed by the Maine Department of Public Safety (Lic #373) ******************************************* Maine Notary Public ******************************************* National Association of Investigative Specialists (NAIS) ******************************************* Maine Licensed Private Investigators Association (MLPIA) www.mlpia.org ******************************************* --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.338 / Virus Database: 189 - Release Date: 3/14/02 ======================================================== 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/ 5045 From: Matthew Paulsen Date: Thu Mar 21, 2002 6:57pm Subject: New Interception Bill in New Zealand http://www.newsbytes.com/news/02/175371.html New Zealand telecommunications network operators and Internet service providers will be legally obligated to install a system that will allow police or the secret service to eavesdrop on phone calls or e-mail messages, the New Zealand government has confirmed. Many will also have to pay for the capability, Associate Minister of Justice Paul Swain said today. The changes to New Zealand's telecommunications laws were tabled last year. The legislation - the Telecommunications (Interception Capability) Bill - is being drafted right now, the minister said. The bill would require all telecom and Internet service providers to be "interception-capable." Customer e-mail and voice messages may be intercepted by carriers when the police, the New Zealand Security Intelligence Service or the Government Communications Security Bureau present a warrant ordering the carriers to do so. "The government will pay for the provision of interception capability for existing fixed and mobile voice networks to be implemented within 18 months from the date the legislation is enacted," Swain said, in a government media release today. Network operators will have to meet the cost of allowing snooping on Internet and e-mail communications within five years of the legislation enactment. Swain confirmed that any interception will require a warrant issued by the High Court - which is the current case for traditional wiretapping. "This law on interception capability will bring us into line with legal requirements already in place in a number of different countries including the United States, Australia, Germany, Netherlands and the U.K .," Swain said. "New Zealand has to make these changes to be certain our law enforcement and national security are not eroded by changes in technology," he added. Reported By Newsbytes.com, http://www.newsbytes.com . 5046 From: James M. Atkinson Date: Thu Mar 21, 2002 8:20pm Subject: FOREGONE CONCLUSION FOREGONE CONCLUSION: (A) The Japanese eat very little fat and suffer fewer heart attacks than the British or Americans. (B) On the other hand, the French eat a lot of fat and also suffer fewer heart attacks than the British or Americans. (C) The Chinese drink very little red wine and suffer fewer heart attacks than the British or Americans. (D) The Italians drink excessive amounts of red wine and also suffer fewer heart attacks than the British or Americans. (E) Conclusion: Eat & drink what you like. It's speaking English that kills you. -- -------------------------------------------------------------------------------------------------- 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 -------------------------------------------------------------------------------------------------- 5047 From: Marko Radovic Date: Fri Mar 22, 2002 2:12am Subject: 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 5048 From: James M. Atkinson Date: Fri Mar 22, 2002 0:49pm Subject: Blind Man's Dilemma Blind Man's Dilemma A blind man enters a Ladies Bar by mistake. He finds his way to a barstool and orders a drink. After sitting there for a while, he yells to the bartender, "Hey, you wanna hear a blonde joke?" The bar immediately falls absolutely quiet. In a very deep, husky voice, the woman next to him says, "Before you tell that joke, sir, you should know five things: 1 - The bartender is a blonde. 2 - The bouncer is a blonde. 3 - I'm a 6 feet tall, 200 pound blonde with a black belt in karate. 4 - The woman sitting next to me is blonde and is a professional weightlifter. 5 - The lady to your right is a blonde and is a professional wrestler. Now think about it seriously, Mister. Do you still wanna tell that joke?" The blind man thinks for a second, shakes his head, and declares, "Nah...Not if I'm gonna have to explain it five times." -- -------------------------------------------------------------------------------------------------- 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 -------------------------------------------------------------------------------------------------- 5049 From: zack <10-33@c...> Date: Fri Mar 22, 2002 7:22am Subject: From Russia with love I did not think that they could sell this stuff............do you pay in rubbles ?? <<< Date: Fri Mar 22, 2002 1:46pm Subject: Re: From Russia with love WELL, , , , LOOK AT THE EMAIL ADDY, , , ," info@t... " {oops,sry abt the caps}, , , , , It's in Russia! ======================================== zack wrote: > I did not think that they could sell this stuff............do you pay in > rubbles ?? > > <<< (DVR) Edic-mini > http://www.telesys.ru/english/edic-mini.shtml > with extraordinary characteristics: > Edic-mini model A - the smallest size over the world (17x57x10 mm), up to > 1120 min of > record time. > Edic-mini model ÷ - the longest battery life (up to 70 hours in record > mode, metal case > 27È54È7 mm), up to 1120 min of recording time. > Edic-mini model B1 - the roundest DVR in the world :-) (metal case d=30 mm, > h=14 mm), up to 1120 min of recording time. > Edic-mini model C - the longest recording time (up to 8960 min =149 hours), > metal case 27È54È10 mm > Coming soon: > Edic-mini model S - stereo digital voice recorder. > EdiÓ-mini BW1 - round wood (cade) case (for lovers of cade fragrance :-), > the most stylish DVR in the world. > > All digital voice recorders have extremely high voice sensitivity, digital PC > interface, telephone line interface to record phone > conversations, programmable user's interface, ability of using it for data > storage and > transfer (capacity from 16Mbyte to 1Gbyte). > > Also we produce voice modules (assembled PCB only) EMM > http://www.telesys.ru/english/modules.shtml , > which are Edic-mini compatible and allow you to create your own solution > of high technology DVR. > > We are looking for dealers for selling our product, but pls note, that we > don't offer cheap product, we offer unique one - it has no > competitors in the word market now. > We are ready to design and produce any kind of DVR upon your request. Low > volume order (100+) is acceptable too. > > Welcome to our website http://www.telesys.ru/english to get more > information. > > 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] > > > ======================================================== > 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/ 5051 From: DrPepper Date: Fri Mar 22, 2002 1:52pm Subject: Re: From Russia with love Sure, , , pay in rubles, and get squat in return for your money, , , , And if you use a credit card, it'll be maxed out in a flash, , , , DrPepper wrote: > WELL, , , , LOOK AT THE EMAIL ADDY, , , ," info@t... " > {oops,sry abt the caps}, , , , , It's in Russia! > > ======================================== > > zack wrote: > > > I did not think that they could sell this stuff............do you pay in > > rubbles ?? > > > > <<< > (DVR) Edic-mini > > http://www.telesys.ru/english/edic-mini.shtml > > with extraordinary characteristics: > > Edic-mini model A - the smallest size over the world (17x57x10 mm), up to > > 1120 min of > > record time. > > Edic-mini model ÷ - the longest battery life (up to 70 hours in record > > mode, metal case > > 27È54È7 mm), up to 1120 min of recording time. > > Edic-mini model B1 - the roundest DVR in the world :-) (metal case d=30 mm, > > h=14 mm), up to 1120 min of recording time. > > Edic-mini model C - the longest recording time (up to 8960 min =149 hours), > > metal case 27È54È10 mm > > Coming soon: > > Edic-mini model S - stereo digital voice recorder. > > EdiÓ-mini BW1 - round wood (cade) case (for lovers of cade fragrance :-), > > the most stylish DVR in the world. > > > > All digital voice recorders have extremely high voice sensitivity, digital PC > > interface, telephone line interface to record phone > > conversations, programmable user's interface, ability of using it for data > > storage and > > transfer (capacity from 16Mbyte to 1Gbyte). > > > > Also we produce voice modules (assembled PCB only) EMM > > http://www.telesys.ru/english/modules.shtml , > > which are Edic-mini compatible and allow you to create your own solution > > of high technology DVR. > > > > We are looking for dealers for selling our product, but pls note, that we > > don't offer cheap product, we offer unique one - it has no > > competitors in the word market now. > > We are ready to design and produce any kind of DVR upon your request. Low > > volume order (100+) is acceptable too. > > > > Welcome to our website http://www.telesys.ru/english to get more > > information. > > > > 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] > > > > > > ======================================================== > > 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/ > > > ======================================================== > 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 5052 From: John Savage Date: Sun Mar 24, 2002 7:35am Subject: MLPIA Proudly Presents: Forensic Polygraph Assessments Seminar !!!! Doug Calderbank & Cory Emmons Announce.......... "MAINE LICENSED PRIVATE INVESTIGATORS ASSOCIATION (MLPIA)" Proudly Presents: FORENSIC POLYGRAPH ASSESSMENTS FOR THE LEGAL PROFESSION, CORPORATE SECURITY DEPARTMENTS, AND THE PRIVATE SECTOR! WHEN: Wednesday April 17, 2002 (2002-2003 MEMBERSHIP KICKOFF) TIME: 4:30 PM Presentation · 6 PM Social & Buffet · 7 PM Meeting WHERE: Augusta Country Club in Manchester, Maine (only 3.4 miles West from Exit 30) When are polygraphs used? Who uses polygraph services? What happens in a polygraph examination? Why are polygraph services valuable to your client? Learn and see for yourself! Some of the valuable aspects of the investigative use of polygraph testing are to help exonerate the innocent person who is surrounded by circumstantial evidence. It is also particularly valuable in those investigations that rely only on testimonial evidence and in marital and family counselors to alleviate fears and prove innocence to spouse and family members. Polygraph testing can be utilized for law enforcement applicant screening, victims of sex crimes, child abuse cases, and civil litigation to name a few. This presentation is a learning experience for Defense Attorneys, Public Defenders, Civil Litigation Attorneys, Private Investigators, Companies and Corporations under the limits of the Employee Polygraph Protection Act of 1988 (EPPA), and Law Enforcement Agencies. The presenters of this event will be Portland Police Detective Mark Teceno and Retired State Police Polygraph Examiner Donald Lizotte. The Presentation includes a delicious FULL DINNER BUFFET and materials for: $20.00 MEMBERS or $30.00 NON-members R.S.V.P. as soon as possible and then make out your check by April 5th payable to: MLPIA, ATTN: Polygraph Presentation, PO Box 1645, Portland, Me 04104 Questions? E-mail the association at: MLPIA@a... or hit reply on the yahoo groups You can also contact (Seminar Chairpersons) Investigators Douglas Calderbank @ 207-671-3868 or Corey Emmons @ 207-756-2684. PLEASE SUPPORT THE ASSOCIATION BY ATTENDING A MLPIA GENERAL MEMBERSHIP MEETING WILL ALSO BE HELD AFTER THE BUFFET INVITE ALL NON-MEMBERS, CLIENTS, LAWYERS, AND ASSOCIATES TO ATTEND AND LEARN MORE ABOUT MLPIA Visit our redesigned website at: www.MLPIA.org John Lee Savage (LPIA) P.O. Box 634 Old Orchard Beach, ME 04064 TEL: 207-286-3945 FAX: 781-723-2551 ******************************************* Licensed by the Maine Department of Public Safety (Lic #373) ******************************************* Maine Notary Public ******************************************* National Association of Investigative Specialists (NAIS) ******************************************* Maine Licensed Private Investigators Association (MLPIA) www.mlpia.org ******************************************* --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.342 / Virus Database: 189 - Release Date: 3/14/02 5053 From: D.A.Linsky Date: Sun Mar 24, 2002 1:41pm Subject: Re: Digest Number 891 SSC, Inc. - Phone = 203-333-1707 - Location = Connecticut - Experience = greater than 15 years INVESTIGATIVE ADVISOR - Connecticut: SSC, Inc. an innovative and progressive Security and Investigations company is searching for a Professional Investigative Advisor for its Investigations division. This position requires heavy interface with media, law enforcement and professional organizations as a public representative of SSC, Inc. We are searching for a seasoned Law Enforcement or Military Investigative Official with previous command experience. Position will support sales, management and the development of our consulting business. We are open to discussion of employment either as a subcontractor or as a full time employee. This position requires periodic travel within the northeast corridor and superb written and verbal communication skills. Public appearances are an important part of this job. For additional information or to schedule an interview, apply by email or forward your resume with salary history to David Linsky President, SSC, Inc. You can also visit our website at http://www.securesvc.com ----- Original Message ----- From: To: Sent: Sunday, March 24, 2002 2:16 PM Subject: [TSCM-L] Digest Number 891 ======================================================== 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 ------------------------------------------------------------------------ There is 1 message in this issue. Topics in this digest: 1. MLPIA Proudly Presents: Forensic Polygraph Assessments Seminar !!!! From: "John Savage" ________________________________________________________________________ ________________________________________________________________________ Message: 1 Date: Sun, 24 Mar 2002 08:35:34 -0500 From: "John Savage" Subject: MLPIA Proudly Presents: Forensic Polygraph Assessments Seminar !!!! Doug Calderbank & Cory Emmons Announce.......... "MAINE LICENSED PRIVATE INVESTIGATORS ASSOCIATION (MLPIA)" Proudly Presents: FORENSIC POLYGRAPH ASSESSMENTS FOR THE LEGAL PROFESSION, CORPORATE SECURITY DEPARTMENTS, AND THE PRIVATE SECTOR! WHEN: Wednesday April 17, 2002 (2002-2003 MEMBERSHIP KICKOFF) TIME: 4:30 PM Presentation · 6 PM Social & Buffet · 7 PM Meeting WHERE: Augusta Country Club in Manchester, Maine (only 3.4 miles West from Exit 30) When are polygraphs used? Who uses polygraph services? What happens in a polygraph examination? Why are polygraph services valuable to your client? Learn and see for yourself! Some of the valuable aspects of the investigative use of polygraph testing are to help exonerate the innocent person who is surrounded by circumstantial evidence. It is also particularly valuable in those investigations that rely only on testimonial evidence and in marital and family counselors to alleviate fears and prove innocence to spouse and family members. Polygraph testing can be utilized for law enforcement applicant screening, victims of sex crimes, child abuse cases, and civil litigation to name a few. This presentation is a learning experience for Defense Attorneys, Public Defenders, Civil Litigation Attorneys, Private Investigators, Companies and Corporations under the limits of the Employee Polygraph Protection Act of 1988 (EPPA), and Law Enforcement Agencies. The presenters of this event will be Portland Police Detective Mark Teceno and Retired State Police Polygraph Examiner Donald Lizotte. The Presentation includes a delicious FULL DINNER BUFFET and materials for: $20.00 MEMBERS or $30.00 NON-members R.S.V.P. as soon as possible and then make out your check by April 5th payable to: MLPIA, ATTN: Polygraph Presentation, PO Box 1645, Portland, Me 04104 Questions? E-mail the association at: MLPIA@a... or hit reply on the yahoo groups You can also contact (Seminar Chairpersons) Investigators Douglas Calderbank @ 207-671-3868 or Corey Emmons @ 207-756-2684. PLEASE SUPPORT THE ASSOCIATION BY ATTENDING A MLPIA GENERAL MEMBERSHIP MEETING WILL ALSO BE HELD AFTER THE BUFFET INVITE ALL NON-MEMBERS, CLIENTS, LAWYERS, AND ASSOCIATES TO ATTEND AND LEARN MORE ABOUT MLPIA Visit our redesigned website at: www.MLPIA.org John Lee Savage (LPIA) P.O. Box 634 Old Orchard Beach, ME 04064 TEL: 207-286-3945 FAX: 781-723-2551 ******************************************* Licensed by the Maine Department of Public Safety (Lic #373) ******************************************* Maine Notary Public ******************************************* National Association of Investigative Specialists (NAIS) ******************************************* Maine Licensed Private Investigators Association (MLPIA) www.mlpia.org ******************************************* --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.342 / Virus Database: 189 - Release Date: 3/14/02 ________________________________________________________________________ ________________________________________________________________________ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 5054 From: Steve Uhrig Date: Sun Mar 24, 2002 9:15pm Subject: Educating v. Marketing? This message is one posted following a thread from another TSCM list (a closed list, so don't inquire about joining). Others on that list thought the info was of general interest, so I am posting it here in case anyone could benefit. Feel free to reprint it anywhere, WITH PRIOR PERMISSION FROM ME. ================== > Has anyone in the business, that you all know of that is, ever tried a > series of dog and pony road shows that have been targeted at the right > general-mix and large slate of invitees for the pure and honest purpose > of 'education', and not simply to 'sell' their own services? Sir Bob, You will probably find many of us regularly do presentations before various groups, exposing them to the technology, explaining the need for the service, how to select a legitimate practitioner, and a very few words said about the presenter being a local legitimate provider of the service who happened to take the time to speak before this group where others haven't. Several times a year I do a presentation and mini dog and pony show before Chamber of Commerce meetings, various county monthly Bar Association meetings, various security and management groups, etc. The meetings help me keep my public speaking skills up, keep me familiar with explaining things in the language of the common layman (very important; eliminate or define any buzzwords) and keep my name before the types of people who may buy my service. I generally try to tag my presentation on with a PIs. Even though a PI license is not required to sweep in MD, if any hostile device were found it almost always will involve subsequent investigation, and I am more comfortable having a license associated with the job from the beginning. The PIs I work with, of course, are ones who have referred me a lot of work and are in my camp, and their enthusiasm comes across. I give some simple handouts to each attendee, at the conclusion of my presentation. I have learned if you give them out early, people will read them instead of listening to me. They can read anytime; they can listen to me once. The handouts have my letterhead on them only, no advertising or marketing. I do have business cards and Rolodex cards up front and I invite attendees to take one, but I do not hand them out. There are no other competent sweepers in my immediate area, so I don't get into mentioning anyone else. If I did, they'd darn well have to pay me referrals to cover my expenses and hassle in generating work for them. The presentations always are well received, enough intelligent questions asked to where I know they absorbed my material and I wasn't over their head (very important to perfect your presentation that way, or they will be sleeping while you are talking), and I watch after the group leaves how many of my handouts are left behind. A few are normal, and I collect them to use again. A lot means I was over their head or the group was not the proper people to listen to this sort of presentation. BUT (and there is always a but) -- Selling sweeps most of the time is like selling wedding dresses. If you knock on a door peddling wedding dresses and someone in the household is getting ready to get married, you may have a sale. If someone in the business is not getting married, it doesn't matter what quality your wedding dresses are, how well you know wedding dresses, how cheap they are, and how many of their friends you have fitted with wedding dresses. You don't sell a dress or a sweep. It is hard to generate business for sweeps. The best you can do, and it is a long, slow, ongoing process, is to let them know of the threat and who to call if they ever should have a concern in the future. And all the worn out cautions apply: people buy from people. They much prefer to buy from people they have met. But it doesn't happen overnight. You have to be patient, and keep chipping away even when you don't see results. The market has no loyalty. Just because you did a dynamite presentation for the Bar Association, they will not call you a year later when one of their clients asks about a sweep. They will call the last guy who contacted them, whether it be you or a schlock PI with a Ralph Thomas box. You need to keep pouding away. I have found it to be very true that the average sale is made on the 5th attempt. This can be the 5th exposure through 5 meetings, or you could count direct mail, trade shows, word of mouth, etc. That number 5 is the average. Sometimes it will be one. Sometimes it will be ten. Give up before 5 and you've wasted your time on the first 1, 2, 3 or 4. Appearances are critical. Dress BETTER than them. Have your wife clean all the dust off your sweep gear. Yeah, we all know we don't use the stuff enough to keep it from getting dusty. Charge all batteries. Bring plenty of extension cords. Arrange for enough tables to set everything up. Remember the old adage: "What I hear, I forget. What I see I remember. What I do, I understand." Pass around deactivated or dummy bugs. Have anyone interested X-ray your phony bugged telephone handset. Borrow a pager or small recorder from someone in the audience, and show how your nonlin can find it buried underneath something. Do not, however, let them back you into a phony sweep where they hide something and challenge you to find it. I tell them, "I WILL find it, but I go through a procedural list, and if you are willing to sit here and be absolutely still and quiet, no talking, for potentially several hours, I WILL find anything you have concealed. However, I work from checklists and I do not violate that as the chances of overlooking a critical step would be too high." That's all it takes. Then show them how the nonlin will find something under a newspaper on a table, or some such. If you don't have a telephone handset, use an FRS radio with the PTT switch held down with a rubber band and show how the equipment responds. Don't concentrate too much on equipment, though. You will find many of these folks, especially older ones, are technologically challenged and will not have much patience. Limit playing with your toys to 10 minutes max in a one hour presentation. Discuss liability if a company hired to find something misses it. Do that without overtly implying any competition is incompetent. Merely make the statement of fact and let them make the connection in their own mind. Every few minutes, atop and ask if there are any questions. Try to learn the participant's name, and repeat his name and question for the others in the group who may not have heard the questions. Treat every question, no matter how stupid, seriously. And feed people back their names and titles, if any, They eat that up. Repeat the questioner's name to the group, as he may be a big wheel or officer the rest will respect, and pay more attention to a question from the big shot. If they try to trip you up, don't get flustered. My answer is "a proper answer to your question would take more time than I have right now. I'll be glad to get with you after the meeting and answer your question in the detail it requires." Or, never be afraid to say you don't know but will be glad to research the answer and get back to them. I try to get a business card from everyone as well as pass around a roster for everyone to sign with full contact info including email. If they ask the reason, I will say this is so I know I have spoken with you already and won't bother to mail you literature in the future that we already have covered in this presentation, or some such. Like with the media (especially with the media), MAKE SURE you control the interview. If they get into all these dragged out lunatic stories, tell them you will be glad to get with them after the presentation and give their question the attention it deserves (which may be nothing). Pay special attention to quiet guys who hang around looking at your gear but don't approach you. Be aggressive. He may be on the edge of buying some spy shop crap and is beginning to have some doubt. Since I go with a PI, I have the PI introduce me. Seems more humble. Have the PI hand lit out near the end of your presentation. Have the PI leave his cards on the table too. Treat everyone with respect, even when you find out they have contracted your incompetent competition for $50K a quarter. Don't speak down about anyone or anything. State the facts, and let them draw their own conclusion. I could go on forever, but these are the basics. Good question Bob. If there was any interest, I'd teach a TSCM marketing course. But since only 8 people will see this message, this is not the place to announce it. I may copy this message, edited, to the main list. Some good info for newbies. Anyone sweeping actively or full time has developed their marketing to a high level of efficiency. Learn from them. Copyright (C) March 2001 by Steve Uhrig, SWS Security =============== ******************************************************************* 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" ******************************************************************* 5055 From: Matthew Paulsen Date: Mon Mar 25, 2002 10:19am Subject: 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-disclosure-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] 5056 From: James Goldston Date: Mon Mar 25, 2002 0:34pm Subject: RE: Internet Draft - Responsible Vulnerability Disclosure The RFC has been withdrawn by its authors. See below. James =-=-=-=-=-=-= ISN message -=-=-=-=-=-=-= http://www.newsbytes.com/news/02/175273.html By Brian McWilliams, Newsbytes BURLINGTON, MASSACHUSETTS, U.S.A., 18 Mar 2002, 2:26 PM CST Proponents of an effort to standardize the handling of computer security vulnerabilities today aborted the effort after receiving critical comments from reviewers. In a message today to members of the Internet Engineering Task Force's Security Area Advisory Group, the authors announced they were withdrawing the draft in response to feedback from members who felt the document was not appropriate for the IETF "since it does not deal with technical protocols." The proposed standard, laid out in a document called "Responsible Vulnerability Disclosure Process," was submitted last month to the IETF, an Internet standards body, by Steve Christey and Chris Wysopal, security researchers from Mitre Corp. and AtStake, respectively. The document proposed a set of "best practices" to be used by product vendors, security researchers and others involved in the disclosure of computer security flaws. "There does not appear to be any way to achieve consensus on that issue, regardless of the merits of the current draft or any future document that may attempt to describe disclosure recommendations," said Christey in the message today. Christey and Wysopal were not immediately available for comment. The announcement of the proposed standard's demise stated that the authors are "currently identifying other forums that may be more suitable for discussion of the current document and future revisions. If we can't find such a forum, we will create one." Under the proposed standard, discoverers of security bugs will honor a 30-day grace period after reporting a security flaw to a vendor before disclosing details of the vulnerability. Vendors in turn are to acknowledge reports of bugs within seven days, and to set up a special e-mail address for receiving reports. The draft follows an October 2001 call for responsible disclosure from Scott Culp, head of Microsoft's security response center. In a much-discussed document at the Microsoft site, Culp decried what he called the state of "information anarchy" surrounding the current security reporting process. While many security researchers and vendors already follow the practices detailed in the proposed IETF standard, others expressed concerns that codifying a reporting standard could have negative consequences. In a posting to the SAAG mailing list last month titled "Thanks, I am not buying this RFC," Georgi Guninski, a Bulgarian security consultant, stated that the proposed standard could allow vendors to label bug finders as "irresponsible while shifting the focus from their buggyware." According to an acknowledgments section, the draft document reflected input from several key security industry figures, including the leaders of security at Microsoft and Oracle, as well as representatives from top security consulting firms and the Computer Emergency Response Team. The draft IETF vulnerability disclosure document is at http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure- 00.txt - ISN is currently hosted by Attrition.org To unsubscribe email majordomo@a... with 'unsubscribe isn' in the BODY of the mail. =-=-=-=-=-=-= End of ISN message -=-=-=-=-=-=-= > -----Original Message----- > From: Matthew Paulsen [mailto:mpaulsen6@a...] > Sent: Monday, March 25, 2002 11: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-d > isclosure-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 [snip] 5057 From: Richard Gray Date: Sun Mar 24, 2002 3:32pm Subject: Introduction Hello: I am a private investigator in Louisiana. I currently do not offer TSCM service because I don't have an adequate base knowledge, but plan to offer it in the future after receiving training. It amazes me how many of my local colleagues purchase a $1,000.00 RF Sweeper and offer countermeasures sweeps, but have absolutely no idea about what they are doing. I guess this is prevalent in any industry. Anyhow, what organizations provide training for countermeasures work? I would prefer online learning with minimal travel. Thanks in advance for any assistance, 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!" TSKS Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service . [Non-text portions of this message have been removed] 5058 From: greendots . Date: Sun Mar 24, 2002 2:27pm Subject: blonde joke Q: Why are blonde jokes only "one liners"? A: So brunettes can understand them. --- _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx 5059 From: James M. Atkinson Date: Mon Mar 25, 2002 9:16pm Subject: Mini spy cameras record brisk sales in China after Taiwan sex scandal http://www.hindustantimes.com/nonfram/210302/dLFOR21.asp Mini spy cameras record brisk sales in China after Taiwan sex scandal AFP Beijing, March 21 Sales of miniature spy cameras have boomed in China after a hidden device was used to record the sexual exploits of a Taiwanese politician, state media said on Thursday. Many of the cameras, which sell for as little as 100 yuan (12 dollars), are bought by people who wish to supervise their spouse's activities, the China Daily reported. Sales of the devices began to rocket after Taiwanese politician Chu Mei-feng's romp with a married lover was secretly filmed, with the salacious escapade then watched by an eager public via pirate VCDs and the Internet. News of the liaison was also heavily featured on mainland Chinese Internet sites. "I wholesaled more than 400 micro-cameras last month," a dealer at an electrical appliance shop in the southern city of Guangzhou told the paper. 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. -- -------------------------------------------------------------------------------------------------- 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 -------------------------------------------------------------------------------------------------- 5060 From: Date: Mon Mar 25, 2002 5:34am Subject: Body Scanner Photos Websites of interest: 1. www.aclu.org/issues/privacy/bodyscanner.html (New airport scanner photos.) 2. Philadelphia Inquirer front page of Sunday issue (3-24-02) "Drive-by hackers hunt free, easy Web access". WWW. philly.com and www.phillynews.com 5061 From: ed Date: Mon Mar 25, 2002 5:00pm Subject: bill allows investigators to plant a listening device indefinitely http://www.latimes.com/news/nationworld/nation/la-000021670mar25.story?coll=la%2Dheadlines%2Dnation Maryland's proposal would expand the ability of police to tap phones by allowing investigators to plant a listening device indefinitely, not just for 30 days. It would, for the first time, permit use of a "roving wiretap" to record a suspect's conversations on multiple phones with a single warrant.... 5062 From: Steve Uhrig Date: Tue Mar 26, 2002 10:44am Subject: Re: bill allows investigators to plant a listening device indefinitely Once upon a midnight dreary, ed pondered, weak and weary: > Maryland's proposal would expand the ability of police to tap phones by > allowing investigators to plant a listening device indefinitely, not just > for 30 days. It would, for the first time, permit use of a "roving > wiretap" to record a suspect's conversations on multiple phones with a > single warrant.... This pretty much is basic CALEA. MD will try to claim they invented it, and the feds ran with it. Maryland has been toughening up on wiretap laws, not relaxing them. I live in MD. 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" ******************************************************************* 5063 From: James M. Atkinson Date: Tue Mar 26, 2002 3:50pm Subject: Threat from Foreign Economic Collection and Industrial Espionage http://www.ncix.gov/pubs/reports/fy01.htm http://www.ncix.gov/docs/fecie_fy01.pdf 2001 This report was prepared by the Office of the National Counterintelligence Executive and is not available in hard copy. However, it is in PDF format and can be downloaded by using the link at the bottom of this page. Scope Note This annual report reviews the threat from foreign economic collection and industrial espionage and is conducted in compliance with a Congressional mandate. Reporting throughout calendar year 2000 showed continued efforts by foreign governments, corporations, and individuals to acquire US proprietary economic information. The Intelligence Authorization Act for Fiscal Year 1995, Section 809(b), Public Law 103-359 requires that the President annually submit to Congress updated information on the threat to US industry from foreign economic collection and industrial espionage. This report updates the sixth Annual Report to Congress on Foreign Economic Collection and Industrial Espionage, disseminated in September 2000 and covers intelligence reporting and other information from calendar year 2000. The Authorization Act specifies that the annual report is to examine three aspects of the threat to US industry: the number and identity of the foreign governments believed to be conducting industrial espionage, the industrial sectors and types of information and technology targeted by such espionage, and the methods used to conduct espionage. To prepare this assessment, the Office of the National Counterintelligence Executive (NCIX) requested the assistance of the Intelligence Community (IC). The following government agencies provided individual assessments for this report: *Air Force Office of Special Investigations (AFOSI). *Central Intelligence Agency (CIA). *Defense Intelligence Agency (DIA). *Defense Security Service (DSS). *Department of Energy (DOE). *Department of State, including the Bureau of Intelligence and Research and the Bureau of Diplomatic Security. *Federal Bureau of Investigation (FBI). *Army Counterintelligence Center (ACIC). *Naval Criminal Investigative Service (NCIS). *National Reconnaissance Office (NRO). *National Security Agency (NSA). *US Customs Service. Key Findings As the world's leading industrial power and leader in technology development, the United States continues to be a prime target of foreign economic collection and industrial espionage. The United States pays a high financial price for economic espionage. The business community estimates that, in calendar year 2000, economic espionage cost from $100-250 billion in lost sales. The greatest losses to US companies involve information concerning manufacturing processes and research and development. Increasing competition for limited global resources will intensify economic collection against the United States, including the theft of trade secrets and competitive business information. Definitions Economic Espionage. There is no consensus within the US Government on the definition of economic espionage. For the purposes of this report, NCIX will use the US Attorney General's definition of economic espionage as "the unlawful or clandestine targeting or acquisition of sensitive financial, trade, or economic policy information; proprietary economic information; or critical technologies." This definition excludes the collection of public domain and legally available information that constitutes a significant majority of economic collection. Aggressive intelligence collection that is entirely in the public domain and is legal may harm US industry, but it is not espionage. It, however, may help foreign intelligence services identify and fill information gaps that could be a precursor to economic espionage.a Industrial Espionage. According to the Justice Department, industrial espionage is defined "as activity conducted by a foreign . . . government or by a foreign company with the direct assistance of a foreign government against a private US company for the sole purpose of acquiring commercial secrets." This definition does not extend to the activity of private entities conducted without foreign government involvement, nor does it pertain to lawful efforts to obtain commercially useful information, such as information available on the Internet. Although some open-collection efforts may be a precursor to clandestine collection, they do not constitute industrial espionage. Some countries have a long history of ties between government and industry; however, it is often difficult to ascertain whether espionage has been committed under foreign government sponsorship, a necessary requirement under the Economic Espionage Act, Title 18 U.S.C., Section 1831. Proprietary Information. Another term used in this report is proprietary information, the definition of which is information not within the public domain and that which the owner has taken some measures to protect. Generally, such information concerns US business and economic resources, activities, research and development, policies, and critical technologies. Although it may be unclassified, the loss of this information could impede the ability of the United States to compete in the world marketplace and could have an adverse effect on the US economy, eventually weakening national security. Commonly referred to as "trade secrets," this information typically is protected under both state and federal laws. For a conviction under the Economic Espionage Act (EEA) of 1996 (Title 18 U.S.C., Chapter 90), a person must convert a trade secret to an economic benefit in interstate or foreign commerce. Overview of the Threat to US National Security The United States continues to be threatened by the theft of proprietary economic information and information on critical technologies. The risks to sensitive business information and advanced technologies continue to increase significantly as foreign governments--both former adversaries and allies--focus their espionage resources in ever-greater numbers on the private sector. They are seeking not only technological data but also financial and commercial information that will provide their companies with a competitive edge in the global economy. Targeted US Defense Information and Technology According to US defense industry reporting, targeting conducted by commercial and individual foreign collectors accounted for 60 percent of the total suspicious activities. Government-sponsored targeting--including military and other official government activity--accounted for 21 percent of suspicious activities. Targeting activities by government-affiliated entities--including institutes, laboratories, and universities--accounted for another 19 percent. Foreign companies whose work exclusively or predominantly supports government agencies were assessed as being government affiliated. Collection Methods There has been no visible change in foreign collection methods over the past year. Economic and industrial information collectors seldom use one method of collection. They combine collection techniques into a concerted effort that includes legal and illegal methods, and they continue to become more innovative in their tactics. Consistent with traditional espionage operations, significant foreign intelligence collection efforts are often conducted legally and openly. These collection efforts often serve as precursors to economic espionage: *Open-source collection activities: *Requests for information. *Solicitation and marketing of services. *Acquisition of technology and companies. *Visits by foreign nationals to US facilities. *Conferences. *Internet activity (cyber attack and exploitation). *Exploitation of joint ventures. Requests for Information Activities reported in this category include unsolicited requests received from known or unknown sources--usually foreign--for classified, sensitive but unclassified, export?controlled, or company proprietary information. According to the Defense Security Service (DSS), in 2000 these kinds of suspicious activities accounted for 41 percent of total reported collection efforts. Not surprisingly, there has been a dramatic rise in the use of the Internet for these kinds of collection activities. DSS reported that the use of the Internet by foreign entities collecting US technology and technical information accounted for 27 percent of all suspicious contacts. The Internet provides a simple, low-cost, nonthreatening, risk-free means of worldwide access to US technology. E-mail and Web-chat exchanges are inconspicuous and can bypass traditional security safeguards, directly reaching the targeted individual. Solicitation and Marketing of Foreign Services One of the most popular tactics used to gain access to US research and development facilities is to have foreign scientists submit unsolicited employment applications. In 2000, facilities that were the targets of this kind of solicitation were working on such technologies as electro-optics, ballistics, and astrophysics. Other approaches included offers of software support, internships, and proposals to act as sales or purchasing agents. In addition, of growing importance is the greater use of foreign research facilities and software development companies located outside the United States to work on commercial projects related to protected programs. Any time direct control of a process or a product is relinquished, the technology associated with it is susceptible to possible exploitation. Acquisition of Technology and Companies Acquisitions were greatly on the rise in 2000. This is the latest manifestation of an increased trend to acquire sensitive technologies through purchase. According to DSS reporting, 88 percent of all reported suspicious acquisition activities involved third parties. Third parties are not the actual entities acquiring the technology but are the ultimate end users. Third-party acquisitions are often an indicator of a possible technology transfer or diversion because when the ultimate recipients are determined, they are often countries that are on embargoed lists for the acquired items. One method that is commonly used involves setting up a freight forwarder, that is, a cooperating US-based company that will provide the ultimate foreign recipient with a US address to subvert US export-control laws. Exploitation of Visits to US Companies During the past year, efforts continued by foreigners to exploit their visits to US facilities. Some examples of exploitation techniques include: *Wandering around facilities unescorted, bringing unauthorized cameras and/or recording devices into cleared facilities, or pressing their hosts for additional accesses or information. *Adding last minute and/or unannounced persons as part of the visit. *Arriving unannounced and seeking access by asking to see an employee belonging to the same organization as the visitor. *Hiding true agendas, for example, by trying to shift conversations to topics not agreed upon in advance. *Misrepresenting a visitor's importance or technical competency to secure visit approval. Conferences International seminar audiences often include leading scientists and technical experts, who pose more of a threat than intelligence officers due to their level of technical understanding and ability to exploit immediately the intelligence they collect. The counterintelligence community reporting indicates that, during seminars, foreign entities attempt subtle approaches such as sitting next to a potential target and initiating casual conversation. This activity often serves as a starting point for later exploitation. Membership lists of international business and/or technical societies are increasingly used to identify potential US targets. One of the most common targeting techniques is to use collectors who have common cultural backgrounds with the target such as origin of birth, religion, or language. Internet Activity (Cyber Attack and Exploitation) This category addresses cyber attack and exploitation vice Internet?based requests for information. The majority of Internet endeavors are foreign probes searching for potential weaknesses in systems for exploitation. One example was a network attack that, over the period of a day, involved several hundred attempts to use multiple passwords to illegally obtain access to a cleared defense facility's network. Fortunately, the facility had an appropriate level of protection in place to repel this attack. This example reflects the extent to which intelligence collectors are attempting to use the Internet to gain access to sensitive or proprietary information. Given the considerable effort that is under way in the cyber attack and exploitation arenas, substantial resources will need to be allocated in the future to ensure adequate security countermeasures. Exploitation of Joint Ventures/Research Joint ventures place foreign personnel in close proximity to US personnel and technology and can thereby facilitate access to protected programs. This is of special concern when foreign employees are in place for long periods of time. In this scenario, there is always a danger that foreign employees will be more readily accepted as full partners, and the security vigilance of US colleagues may wane. Some examples of suspicious activity in joint ventures/research include: foreign workers seeking access to areas or information outside the purview of their work agreement, enticing US companies to provide large quantities of technical data as part of the bidding process, and foreign organizations sending more representatives than reasonably necessary for particular projects. Illegal Collection Activities Foreigners seeking to acquire US proprietary economic and industrial information often engage in the following types of illegal activities: *Acquisition of export-controlled technologies. The unlawful acquisition of export-controlled technologies by foreign collectors remains a considerable concern. Methods of operation employed to circumvent the export-control process include: using front companies within the United States and overseas, illegally transporting products to an undisclosed end user by utilizing false end-user certificates, and purchasing products that have been modified during the manufacturing process to meet export-controlled specifications. *Theft of trade secrets and critical technologies. US businessmen traveling overseas are increasingly becoming targets of foreign collection activities. There are numerous examples of briefcases or laptop computers showing evidence of unauthorized access after being left unattended in hotel rooms. In addition, there is evidence of travelers being photographed during business meetings in foreign countries for future targeting. *Agent recruitment, US volunteers, and co-optees. Foreign intelligence services and government-sponsored entities continue to utilize traditional clandestine espionage methods to collect US trade secrets and critical technologies. These methods include agent recruitment, US volunteers, and co-optees. ------------------------------------------------------------------------ Appendix Key Economic Espionage Cases Published in the Press People's Republic of China Case One Two businessmen, one a Chinese national, who is the president of a Beijing-based firm, and the other a naturalized Canadian citizen, pleaded guilty to charges of illegally exporting fiber-optic gyroscopes to the PRC without the required State Department permits. Export of these gyroscopes to the PRC is prohibited. The two men bought the gyroscopes from a Massachusetts company and planned to export them to the PRC via a Canadian subsidiary of the Beijing-based firm. The gyroscopes can be used in missile and aircraft guidance systems, as well as smart bombs. Case Two Two naturalized US citizens were convicted of conspiring to illegally export weapons parts to their native China. They used their exporting company to purchase surplus US missile, aircraft, radar, and tank parts from the Defense Reutilization and Marketing Service and then ship them to the PRC. The exported items were on the US Munitions List that prohibited them from being shipped without a license from the State Department. Case Three Two Chinese scientists and a naturalized US citizen who was born in China were arrested for stealing product designs from a major US telecommunications firm and passing them to a Chinese Government-owned company in Beijing. Both Chinese scientists had received technical degrees from US universities before being employed by the US firm. Case Four A Chinese company based in Orlando, Florida, was charged with illegally exporting radiation-hardened integrated circuits to Chinese missile and satellite manufacturers in the PRC without the required Department of Commerce licenses. The affidavit prepared by the Department of Commerce described three illegal diversions of the missile microchips. According to weapons proliferation specialists, the microchips have military applications and could be used by the Chinese military to improve their long-range missile-targeting capabilities. Case Five A naturalized Chinese national was arrested for attempting to smuggle a defense-grade Radiance high-speed (HS) infrared camera to the PRC. Since the Radiance HS camera is on the US Munitions List, companies must file with the Department of State to legally export such items. The camera was destined for the Chinese State Ship Building Corporation, a state-owned conglomerate of 58 companies that is based in Beijing and Shanghai. Pakistan Case One US Customs Service agents arrested two Pakistani brothers and charged them with conspiring to smuggle sophisticated cameras for military intelligence gathering to a Pakistani Government laboratory. One of the brothers was a naturalized US citizen, while the other, a Pakistani citizen, had recently completed requirements for a master's degree in engineering at a US university. A US aerospace company alerted the US Customs Service to the suspicious activities of the brothers after they attempted to purchase the cameras despite being denied an export license by the State Department. Case Two A British citizen pleaded guilty to violating the Arms Export Control Act by trying to ship night-vision goggles and blueprints for C-130 aircraft to Pakistan. He was acting on behalf of a firm located in Islamabad. The C-130 aircraft is used for a variety of military purposes, including troop transport, surveillance, and gunships. Iran A 20-month federal investigation culminated in the arrest by the US Customs Service of a naturalized Canadian from Iran and a Malaysian citizen for conspiring to illegally export aircraft parts for the F-14 Tomcat, F-5 Tiger, and F-4 Phantom to the Iranian air force. In addition, a naturalized US citizen from Iran pleaded guilty to violating the Arms Export Control Act by trying to smuggle F-14 parts into Iran. -- -------------------------------------------------------------------------------------------------- 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 -------------------------------------------------------------------------------------------------- 5064 From: James M. Atkinson Date: Tue Mar 26, 2002 3:55pm Subject: Dennis Miller on Airport Security It seems like every week you read about another airport that had to be evacuated because some clueless Pillar of Dim forgot he had his 20-piece commemorative Civil War surgeon's kit in his carry-on bag. Ultimately who's to blame for all the security problems that led up to September 11? We could point the finger at the airlines, but it isn't really fair. They've got enough to worry about, delaying our flights, making sure the planes have barely enough Sprite so I can't get a full can, and editing the next middling issue of their inflight magazine to make sure their puff piece on Alicia Keys doesn't actually cross the line into the informative. Before September 11th, the average airport security checkpoint had holes that Joey Chitwood could barrel-roll a flaming Camaro through. The name on your boarding pass could've been "Mr. Hey Ivgottabomb," but as long as you put your ankle-holstered Derringer and 10-inch Bowie knife into that plastic bucket with approximately the same muted, rhythmic din as others did car keys and coins, the only thing likely to raise the screener's eyebrow would be your Superman logo bikini briefs slowly parading across the X-Ray monitor. Prior to September 11th, the two firms providing security to most of the airports in America were named "Argenbright" and "Wackenhut." In retrospect, it probably wasn't such a good idea putting our lives in the hands of what sounds like a couple of Scandinavian lube jellies. Some congressmen didn't want to federalize airport security screeners because they said private enterprise could handle it more efficiently. Yeah, right. That's why, when somebody starting mailing anthrax to the Capital dome, the first thing you guys did was tell the FBI, "No, don't bother with your well-trained high-tech expertise, we low-bid-contracted the job out to a couple of minimum wage slugs who are killing time until a second-assistant fry-cook position opens up at Wendy's." You really want airline safety? Make the airport screeners fly on a plane once a week. And if you think the rent-a-guards manning the scanners at your airport appear unfocused or distracted, you've never been to LAX. I've seen security personnel turn down the volume on the metal detectors so they can debate whether or not Yasmine Bleeth is hotter in person. But there are also instances where these security people should lighten up a little bit. Not every errant piece of metal has the potential to kill. You ever try taking a guy out with a nail clipper or a tweezers? Believe me, it takes hours. And we have to do our