นโยบายโปรแกรมเป็นสิ่งสําคัญสําหรับ VDP และต้องมีการสร้างอย่างละเอียดรอบคอบ นโยบายโปรแกรมเป็นสิ่งแรกที่นักวิจัยด้านความปลอดภัยจะเห็นเมื่อเข้าร่วมใน VDP โดยจะกำหนดแนวทางสำหรับโปรแกรม กำหนดความคาดหวัง และกำหนดคำมั่นสัญญาที่มีต่อนักวิจัยที่เลือกเข้าร่วม
วิธีสร้างและโฮสต์นโยบายโปรแกรม
ใช้หลักเกณฑ์ด้านล่างเพื่อร่างนโยบายโปรแกรมสำหรับ VDP ของคุณ นโยบายโปรแกรมมักจะยาวเพียง 1-3 หน้า และมักจะมีหัวข้อต่อไปนี้ด้วย
- นักวิจัยสัญญา
- หลักเกณฑ์การตรวจหาเชื้อไวรัส
- ขอบเขตของโปรแกรม
นโยบายโปรแกรมต้องพร้อมใช้งานสำหรับผู้มีโอกาสเป็นนักวิจัยทุกคน หากคุณมีแผนที่จะเปิดตัว VDP แบบส่วนตัวให้กับนักวิจัยที่ได้รับเชิญเพียงไม่กี่คน นโยบายโปรแกรมจะต้องมีการควบคุมสิทธิ์เข้าถึงบางอย่างเพื่อให้นักวิจัยที่คุณเชิญพร้อมใช้งาน แต่จำกัดไว้สำหรับผู้เข้าร่วมคนอื่นๆ นักวิจัยยังต้องการวิธีส่งรายงาน เช่น เว็บฟอร์มหรืออีเมลแทนที่เชื่อมต่อกับระบบคำขอแจ้งปัญหาเพื่อการติดตามรายงานด้วย โปรดพิจารณาเรื่องนี้ขณะตั้งค่า แหล่งข้อมูลออนไลน์ของ VDP
แพลตฟอร์มการเปิดเผยข้อมูลช่องโหว่ของบุคคลที่สามและรางวัลบั๊กโดยทั่วไปมีความสามารถต่างๆ เช่น
- วิธีสร้าง แก้ไข และเผยแพร่นโยบาย
- การควบคุมการเข้าถึงเพื่อสร้างโปรแกรมส่วนตัว
- เชิญแฮ็กเกอร์ได้โดยอัตโนมัติด้วยความเร็วที่เหมาะสม
- ฟังก์ชันกล่องจดหมายเพื่ออำนวยความสะดวกในการประมวลผลรายงานขาเข้า
แพลตฟอร์มของบุคคลที่สามยังมีบริการให้คำปรึกษาที่หลากหลายเพื่อช่วยทำให้กระบวนการสร้างและเปิดตัว VDP เป็นไปอย่างง่ายดาย โดยทั่วไปแล้ว แพลตฟอร์มของบุคคลที่สามและบริการให้คำปรึกษาจะมีค่าใช้จ่าย พิจารณาต้นทุนและประโยชน์ของการใช้บุคคลที่สามเทียบกับการสร้างและการจัดการโปรแกรมภายในองค์กรเพื่อหาเส้นทางที่ดีที่สุดสำหรับองค์กร
หากต้องการแรงบันดาลใจเพิ่มเติมเกี่ยวกับสิ่งที่ควรใส่ไว้ในนโยบายโปรแกรม โปรดอ่าน "กรอบการทำงานสำหรับโปรแกรมการเปิดเผยข้อมูลช่องโหว่สำหรับระบบออนไลน์" ของกระทรวงยุติธรรมสหรัฐอเมริกา
ผู้มีส่วนเกี่ยวข้องกับนโยบายโปรแกรม
ขณะที่คุณร่างนโยบายโปรแกรม ให้พิจารณาทำงานร่วมกับผู้ถือผลประโยชน์ร่วม หลายๆ ทีมอาจให้ข้อมูลเกี่ยวกับข้อควรพิจารณาเพื่อนำไปประกอบนโยบาย
| ผู้มีส่วนเกี่ยวข้อง | ข้อควรพิจารณา |
|---|---|
| กฎหมาย |
|
| ไอที |
|
| วิศวกรรมศาสตร์ |
|
| PR |
|
| ความปลอดภัย |
|
คำมั่นสัญญาจากนักวิจัย
คำมั่นสัญญาของผู้วิจัยจะอธิบายถึงความมุ่งมั่นขององค์กรที่มีต่อนักวิจัยที่เข้าร่วมโดยมีเจตนาดีโดยปฏิบัติตามหลักเกณฑ์การทดสอบที่ระบุไว้ในนโยบาย ตัวอย่างเช่น ความมุ่งมั่นในการตอบสนองต่อรายงานความปลอดภัยทั้งหมดที่เข้ามาใหม่ภายในระยะเวลาที่กำหนด รวมถึงการตัดสินใจว่าจะยอมรับและแก้ไขรายงานช่องโหว่ใด
ตัวอย่าง
<ชื่อองค์กรของคุณ> มุ่งมั่นที่จะทำงานร่วมกับนักวิจัยด้านความปลอดภัยเพื่อช่วยระบุและแก้ไขช่องโหว่ในระบบและบริการ ตราบใดที่คุณกระทำการโดยมีเจตนาดีและปฏิบัติตามหลักเกณฑ์ที่ระบุไว้ในนโยบายนี้ เราจะพยายามอย่างเต็มที่ที่จะดำเนินการตาม สิ่งต่อไปนี้- ตอบกลับเบื้องต้นสำหรับรายงานช่องโหว่ภายใน 3 วันทำการ
- ตัดสินใจว่าจะยอมรับ (ตั้งใจแก้ไข) หรือปฏิเสธ (ระบุว่ารายงานเป็นความเสี่ยงที่เป็นผลบวกลวงหรือความเสี่ยงที่ยอมรับได้) รายงานช่องโหว่ของคุณภายใน 10 วันทำการ
- แจ้งให้คุณทราบเกี่ยวกับความคืบหน้าล่าสุดในการแก้ไขรายงานที่เรายอมรับจากคุณ
การใช้ภาษาที่ปลอดภัยในนโยบายโปรแกรมจะช่วยให้นักวิจัยมั่นใจได้ว่าจะไม่มีการดำเนินคดีตามกฎหมายเพื่อการทดสอบระบบของคุณ ตราบใดที่หน่วยงานดังกล่าวปฏิบัติโดยมีเจตนาดีและปฏิบัติตามหลักเกณฑ์ทั้งหมดที่อธิบายไว้ในนโยบาย
หลักเกณฑ์การตรวจหาเชื้อไวรัส
หลักเกณฑ์การทดสอบจะอธิบายถึงการทดสอบความปลอดภัยที่อยู่ในขอบเขตของ VDP รวมถึงการทดสอบที่ไม่ได้อยู่ในขอบเขตและควรหลีกเลี่ยงโดยนักวิจัย หากมีประเภทช่องโหว่ที่เฉพาะเจาะจงที่คุณต้องการให้นักวิจัยเน้น ส่วนนี้ก็เหมาะที่จะไฮไลต์ช่องโหว่เหล่านั้น
ตัวอย่าง:
เมื่อทำการทดสอบความปลอดภัย โปรดปฏิบัติตามหลักเกณฑ์ต่อไปนี้
- ทดสอบกับบัญชีและข้อมูลของคุณเองเท่านั้น (เช่น สร้างบัญชีทดสอบ) หากคุณพบช่องโหว่ที่อาจส่งผลให้มีการเข้าถึงข้อมูลของผู้ใช้รายอื่น โปรดตรวจสอบกับเราก่อนทำการทดสอบเพิ่มเติม
- หากคุณเข้าถึงข้อมูลของผู้ใช้รายอื่นในการทดสอบโดยไม่ได้ตั้งใจ โปรดแจ้งให้เราทราบและอย่าจัดเก็บข้อมูลผู้ใช้ดังกล่าวไว้
- อย่าดำเนินการทดสอบที่ส่งผลให้เกิดการปฏิเสธเงื่อนไขการให้บริการหรือทำให้บริการเวอร์ชันที่ใช้งานจริงของเรามีประสิทธิภาพลดลง
- วิศวกรรมสังคมอยู่นอกเหนือขอบเขตของโปรแกรมนี้ อย่าพยายามออกแบบองค์กรหรือผู้ใช้เพื่อสังคม
เราให้ความสนใจเป็นพิเศษเกี่ยวกับช่องโหว่และผลกระทบประเภทต่อไปนี้
- การเรียกใช้โค้ดจากระยะไกล
- XSS ที่ทำให้เกิดการเข้าถึงข้อมูลที่ละเอียดอ่อน (เช่น ข้อมูลเซสชัน)
- การแทรก SQL ที่ทำให้เกิดการเข้าถึงข้อมูลหรือฟังก์ชันการทำงานที่ละเอียดอ่อน
- ข้อบกพร่องตามตรรกะทางธุรกิจที่ส่งผลให้มีการเข้าถึงข้อมูลหรือฟังก์ชันการทำงานที่ละเอียดอ่อน
เราไม่ค่อยสนใจช่องโหว่ประเภทต่อไปนี้ ซึ่งมีแนวโน้มที่จะ
ถูกปฏิเสธว่าเป็นผลบวกลวงหรือความเสี่ยงที่ยอมรับได้
- ไม่มีส่วนหัว X-Frame-Options ในหน้าที่ไม่มีฟังก์ชันการทำงานเปลี่ยนแปลงสถานะ
- ผลลัพธ์ของเครื่องสแกนอัตโนมัติที่ไม่ได้รับการยืนยัน
- ปัญหาที่ไม่น่าจะหาประโยชน์ไม่ได้และ/หรือไม่มีผลกระทบด้านความปลอดภัยที่แท้จริง
ขอบเขต
ขอบเขตนี้จะกำหนดเนื้อหาที่นักวิจัยสามารถทดสอบเทียบกับ เนื้อหาที่ไม่ถือว่าเป็นส่วนหนึ่งของ VDP คุณจะต้องพิจารณาขอบเขตนี้อย่างรอบคอบและขยายขอบเขตให้มากที่สุดเท่าที่จะเป็นไปได้โดยไม่ทำให้ทีมของคุณทำงานหนักเกินไป ยิ่งคุณยินดีที่จะกำหนดขอบเขตมากเท่าไหร่ ก็จะยิ่งมีโอกาสได้รับการมีส่วนร่วมจากนักวิจัยด้านความปลอดภัยมากขึ้นเท่านั้น แต่อย่าขยายขอบเขตให้กว้างจนทีมจะตามรายงานเข้ามาไม่ได้ เริ่มต้นด้วยเนื้อหาไม่กี่อย่างในขอบเขต ขยายขอบเขตเมื่อคุณเห็นภาพมากขึ้นเกี่ยวกับปริมาณรายงานที่คุณจะได้รับ ก่อนที่จะเปิด VDP ต่อสาธารณะเมื่อเวลาผ่านไป ให้ตั้งเป้าไว้ว่าจะต้องครอบคลุมทุกอย่าง
ในแง่ของวิธีการกำหนดขอบเขตของคุณภายในนโยบายโปรแกรม การเพิ่มรายละเอียดเกี่ยวกับเนื้อหาหรือด้านต่างๆ จะช่วยให้นักวิจัยด้านความปลอดภัยทราบว่าอะไรคือสิ่งสำคัญสำหรับคุณและควรจะมุ่งเน้นความพยายามไปที่ใด และคุณยังใส่เคล็ดลับเกี่ยวกับวิธี ทดสอบเนื้อหาอย่างปลอดภัยได้ด้วย ตัวอย่าง
| ชิ้นงาน | mail.example.com |
|---|---|
| คำอธิบาย | โดเมนหลักสำหรับผู้ใช้ในการเข้าถึงอีเมล |
| ช่องโหว่และผลกระทบที่น่าสนใจ |
|
| ปัญหาที่มีแนวโน้มจะถูกปฏิเสธ |
|
| คำแนะนำในการทดสอบ | ทดสอบกับบัญชีที่คุณเป็นเจ้าของหรือได้รับความยินยอมที่ชัดเจนให้ทดสอบเท่านั้น เมื่อสร้างบัญชีทดสอบ โปรดใส่ "vdptest" ไว้ที่ใดที่หนึ่งในชื่อผู้ใช้ คุณสามารถสร้างบัญชีทดสอบได้ที่ mail.example.com/new |
ตัวอย่างนี้เป็นการแจกแจงที่มีรายละเอียดพอสมควร หรือจะระบุรายการแบบง่ายๆ ของเนื้อหาที่อยู่ในขอบเขตและนอกขอบเขตก็ได้ ดังนี้
ขอบเขต
- mail.example.com
- example.com
อยู่นอกขอบเขต
- blog.example.com
การระบุแหล่งที่มา VDP
คุณจะต้องมีทรัพยากรบางอย่างให้พร้อมก่อนเปิดตัว VDP คุณจะต้องมีแหล่งข้อมูลสำหรับ
- กำลังตรวจสอบรายงานช่องโหว่ขาเข้า
- การสื่อสารกับแฮ็กเกอร์
- การค้นหาเจ้าของเนื้อหาและการส่งข้อบกพร่อง
- การแก้ไขข้อบกพร่อง
- การจัดการช่องโหว่ / ติดตามผลการแก้ไข
กลับไปเยือนผู้มีส่วนเกี่ยวข้องคนสำคัญ
หากยังไม่เคย ให้ทบทวนการสนทนากับผู้มีส่วนเกี่ยวข้องหลักที่คุณหารือกับ VDP ด้วยก่อนหน้านี้เพื่อให้แน่ใจว่ามีความสอดคล้องกันในไทม์ไลน์ของการเปิดตัว VDP รวมถึงการจัดคิวทรัพยากรที่จำเป็นสำหรับการเปิดตัว เช่น คุณอาจต้องทำงานกับผู้นำด้านวิศวกรรมเพื่อให้แน่ใจว่าทีมต่างๆ เตรียมพร้อมสำหรับข้อบกพร่องด้านความปลอดภัยที่อาจเข้ามาจัดการในช่วง 2-3 สัปดาห์แรกหลังการเปิดตัว ภายในทีมรักษาความปลอดภัย ให้ตรวจสอบว่าผู้ที่คัดกรองการแจ้งเตือนในระบบตรวจจับและตอบสนองของคุณทราบวันที่เปิดตัว VDP และพิจารณาจัดสรรเวลาและทรัพยากรเพิ่มเติมเมื่อเริ่มการทดสอบ นอกจากนี้ คุณยังต้องสร้างทีมเพื่อช่วยสนับสนุนการดำเนินงานประจำวันของ VDP ด้วย
สร้างทีมของคุณ
การใช้งาน VDP ต้องอาศัยการดำเนินงานในระดับที่เหมาะสมและต้องอาศัยการทำงานที่ต้องหยุดชะงัก หากพยายามตรวจสอบ ตรวจสอบทางเทคนิค และตอบสนองต่อรายงานช่องโหว่ทั้งหมดที่ส่งเข้ามา รวมทั้งรายงานข้อบกพร่อง ติดตามสถานะ และแจ้งข้อมูลอัปเดตให้แก่นักวิจัยด้วยตนเอง อาจทำให้คุณหมดไฟได้ แม้คุณจะไม่มีทีมรักษาความปลอดภัยขนาดใหญ่ ให้หาอาสาสมัครที่ดูแลเรื่องความปลอดภัยมาช่วยสร้างทีมเพื่อช่วยดำเนินงานและเรียกใช้ VDP ของคุณ คุณยังต้องมี "เจ้าของ" หรือ "ผู้นำ" ที่ชัดเจนของ VDP ที่เป็นผู้รับผิดชอบต่อความสำเร็จของ VDP ในท้ายที่สุด แต่คุณก็ต้องมีทีมที่จะสนับสนุนผู้นำรายดังกล่าวด้วย
สร้างกำหนดเวลาที่ทำงาน
เมื่อคุณมีทรัพยากรอยู่ในระบบและพร้อมช่วยเหลือเกี่ยวกับ VDP แล้ว ก็ให้กำหนดโครงสร้างการทำงานโดยการกำหนดตารางเวลาในหน้าที่ คุณสร้าง URL นี้ได้ตามต้องการ แต่การหมุนเวียนรายสัปดาห์เป็นเรื่องปกติ เมื่อคุณปฏิบัติหน้าที่ทั้งสัปดาห์ คุณมีหน้าที่ดำเนินการต่อไปนี้
- Triage - ตรวจสอบรายงานช่องโหว่ที่เข้ามาใหม่
- ตรวจสอบรายงานทางเทคนิค แล้วเลือก "ยอมรับ" หรือ "ปฏิเสธ"
- แจ้งการตัดสินใจของคุณให้แฮ็กเกอร์ที่รายงานปัญหาทราบ
- หากจำเป็น ให้ขอข้อมูลเพิ่มเติมจากแฮกเกอร์หากคุณไม่สามารถ ทำให้ปัญหาเกิดซ้ำได้
- หากช่องโหว่นี้ถูกต้อง ให้ยื่นข้อบกพร่องที่มีการปรับแต่งกับเจ้าของที่ถูกต้อง
- การจัดการช่องโหว่ - ส่งต่อช่องโหว่ที่มีอยู่
- ตรวจสอบข้อบกพร่องที่ยื่นในช่วงสัปดาห์ที่ผ่านมาที่ทําหน้าที่เพื่อให้แน่ใจว่าการแก้ไขมีความคืบหน้าตามมาตรฐานความรุนแรงและลำดับเวลาการแก้ไข
- ใช้เคล็ดลับจากการค้นหาเจ้าของเพื่อช่วยโน้มน้าวเจ้าของให้จัดการข้อบกพร่องเหล่านี้
- สื่อสาร - แจ้งข้อมูลอัปเดตเกี่ยวกับรายงานที่มีอยู่แก่นักวิจัยด้านความปลอดภัย
- นักวิจัยอาจขอให้อัปเดตรายงานที่มีอยู่ ตรวจสอบเรื่องนี้และตอบกลับตามความจำเป็น
- หากช่องโหว่ได้รับการแก้ไขแล้ว ให้แจ้งเรื่องนี้กลับไปให้นักวิจัยทราบว่าความพยายามอย่างหนักของพวกเขาทำให้เกิดการเปลี่ยนแปลงในทางที่ดีกับองค์กรของคุณ คุณยังสามารถใส่ภาษาเทมเพลตเพื่อขอให้ผู้วิจัยแจ้งให้ทราบว่าคุณพลาดการแก้ไขใดๆ ไปหรือไม่ หรือระบบอาจข้ามการแก้ไขของคุณไปในทางใดทางหนึ่ง
ขึ้นอยู่กับจำนวนรายงานที่คุณได้รับ ความซับซ้อนของรายงานเหล่านี้ รวมทั้งทักษะและความรู้ของบุคคลที่ปฏิบัติงาน การเข้าเวรอาจใช้เวลานานตั้งแต่ 2-3 ชั่วโมงไปจนถึงทั้งสัปดาห์ เคล็ดลับสำหรับการหมุนเวียนหน้าที่ ให้ประสบความสำเร็จมีดังนี้
- ตรวจสอบว่าทีมของคุณพร้อมที่จะเข้ามาช่วยสนับสนุนงานในช่วงสัปดาห์ที่หนักๆ โดยเฉพาะ
- เตรียมขั้นตอนการส่งมอบที่ดี หากมีปัญหาที่อาจต้องให้เจ้าหน้าที่รับหน้าที่ดูแลทราบทันที ให้เขียนบันทึกการโอนงานหรือสนทนาสดในช่วงปลายสัปดาห์
- สร้างการกำหนดเวลาอัตโนมัติเพื่อให้ทุกคนรู้เวลาที่ต้องปฏิบัติหน้าที่ ซึ่งอาจเป็นการสร้างรายการปฏิทินที่เกิดซ้ำสำหรับแต่ละคน
- โดยเฉพาะอย่างยิ่งในช่วงเริ่มต้น VDP ให้ตรวจสอบกับบุคคลที่ปฏิบัติหน้าที่ว่าจำได้ว่าเป็นสัปดาห์ของตน และดูว่าพวกเขา ต้องการความช่วยเหลือหรือไม่ หากคุณมีทรัพยากรระดับต้นในการหมุนเวียนมากกว่านี้ ให้เรียกใช้ทรัพยากรระดับอาวุโสเพื่อดูแลให้พนักงานรู้สึกสบายใจและถามคำถามได้เมื่อมีปริมาณมากขึ้น
- มีกระบวนการที่ยืดหยุ่นสำหรับการสลับสัปดาห์ แน่นอนว่าอาจมีบางคนที่มีเหตุฉุกเฉินและจำเป็นต้องหยุดพักระหว่างสัปดาห์ หรือมีบางคนจะลาพักร้อน ฯลฯ ในกรณีนี้ โปรดกระตุ้นให้ทีมสลับสัปดาห์กันตามที่จำเป็นเพื่อจัดตารางเวลาของทุกคนให้พร้อม
- สร้าง "ข้อมูลสรุป" เกี่ยวกับหน้าที่ซึ่งสรุปงานที่ต้องครอบคลุม รวมถึงเอกสารเกี่ยวกับวิธีทำงาน
ตัดสินใจเกี่ยวกับภายในองค์กรเทียบกับบุคคลที่สาม
คำแนะนำส่วนใหญ่ที่ผ่านมาจะอิงตามการสร้างและการเรียกใช้ VDP ภายในองค์กร มีบริการและแพลตฟอร์มให้คำปรึกษาที่หลากหลาย ที่จะช่วยคุณสร้างและเรียกใช้ VDP บุคคลที่สามเหล่านี้มักมีค่าใช้จ่าย แต่อาจเป็นประโยชน์ในการช่วยแนะนำวิธีสร้าง เปิดตัว และเรียกใช้ VDP นอกจากนี้บางแห่งยังให้บริการคัดแยกเพื่อช่วยตรวจสอบรายงานช่องโหว่ขาเข้า ช่วยจัดการการสื่อสารกับแฮ็กเกอร์ และส่งต่อรายงานที่ถูกต้องไปยังทีมของคุณเท่านั้น การตัดสินใจว่าคุณจะสร้างกระบวนการนี้ด้วยตนเองหรือใช้แพลตฟอร์มของบุคคลที่สามจะขึ้นอยู่กับข้อกำหนดและทรัพยากรที่มี หากคุณมีงบประมาณจำนวนมาก แต่มีพนักงานจำนวนไม่มาก การใช้ประโยชน์จากบุคคลที่สามเพื่อช่วยดูแลโปรแกรมของคุณน่าจะมีประโยชน์ แต่ถ้าหากเป็นอีกแบบหนึ่ง การใช้เวลาสร้างโปรแกรมด้วยตัวเองอาจเป็นสิ่งที่คุ้มค่า
การรับรายงาน
หากคุณเลือกใช้แพลตฟอร์มของบุคคลที่สาม แฮกเกอร์ควรมีช่องทางให้แฮ็กเกอร์ส่งรายงานถึงคุณโดยตรง หากคุณสร้างโปรแกรมภายในองค์กร คุณจะต้องสร้างโปรแกรมด้วยตนเอง ซึ่งอาจเป็นอีเมลที่สร้างคำขอแจ้งปัญหาหรือข้อบกพร่องโดยอัตโนมัติในตัวติดตามปัญหา (เช่น security@example.com) หรืออาจเป็นเว็บฟอร์มซึ่งมีช่องแบบฟอร์มที่จำเป็น ลิงก์จากหน้าเดียวกับนโยบายโปรแกรมก็ได้ ไม่ว่าจะเป็นรูปแบบใด นี่เป็นโอกาสที่ดีที่สุดในการ แจ้งให้แฮ็กเกอร์ทราบรูปแบบที่คุณต้องการรับรายงาน โปรดทราบว่าการขอให้แฮ็กเกอร์ส่งรายงานในรูปแบบใดรูปแบบหนึ่งไม่ได้รับประกันเสมอไปว่าจะทำได้จริง แต่ก็ไม่มีอะไรเสียหายที่จะถาม นี่คือตัวอย่างของสิ่งที่คุณอาจขอในแบบฟอร์มการส่งรายงาน
เรื่อง: [โปรดเพิ่มรายละเอียดเกี่ยวกับปัญหา 1 บรรทัด เช่น "XSS ใน mail.example.com
ทำให้เกิดการขโมยเซสชัน"]
1.
2.
3.
สถานการณ์การโจมตีและผลกระทบ: [สิ่งนี้จะแสวงหาประโยชน์ได้อย่างไร ปัญหา
นี้ส่งผลกระทบด้านความปลอดภัยอะไรบ้าง]
คำแนะนำด้านการแก้ไข: [ไม่บังคับ หากคุณมีคำแนะนำว่าจะแก้ไขหรือแก้ไขปัญหานี้ได้อย่างไร ให้เพิ่มไว้ที่นี่]