สรุปบางประเด็นที่น่าสนใจจาก NIST SP 800-61 Rev.3

เอกสาร NIST SP 800-61 Rev. 3 (https://csrc.nist.gov/pubs/sp/800/61/r3/final) แบ่งขั้นตอนการทำงานออกเป็น 2 phases ใหญ่ๆ คือ Preparation and Lessons Learned กับ Incident Response

สมัย rev.2 นั้นขั้นตอนสุดท้ายที่เป็นเรื่อง Post-Incident Activity มักจะเป็นขั้นตอนที่ถูกมองข้าม เพราะเวลาเกิดปัญหาก็ไม่ค่อยอยากยอมรับความผิดพลาดหรือไม่อยากเอามาคุยกันตรงๆ ว่าปัญหามันเกิดเพราะอะไร และจะป้องกันยังไงไม่ให้เกิดซ้ำอีก ปล่อยให้ incident มันถูกปิดไปแบบงงๆ ไม่สนใจแก้ไขปัญหาที่ root cause รอบนี้ทาง NIST เลยใส่หัวข้อ Lessons Learned มาเป็นตัวบังคับเลยว่าต้องทำเสมอ การทำ IR ตาม rev.3 ต้องเปลี่ยนทั้งแนวคิดในการเตรียมตัววางแผน การดำเนินการ การแชร์ข้อมูล และการเอาข้อผิดพลาดมาคุยกันแบบตรงๆ เพื่อไม่ให้ผิดเรื่องเดิมจากสาเหตุเดิม

แนวทางการแจ้งและการประสานงานเรื่อง incident ควรมีกลไกเพื่อช่วยให้สามารถทำแบบ automated ได้มากที่สุด เพราะฉะนั้นอะไรต่างๆ ที่เคยเป็นอุปสรรค เช่น ข้อกำหนดหรือ template ที่ต้องให้กรอกแบบฟอร์มเยอะๆ เพิ่มงาน paperwork โดยไม่จำเป็น ควรถูกปรับปรุงให้รองรับการทำงานแบบ automated ได้

ข้อควรพิจารณาในการอ้างอิงข้อมูล CVSS

หนึ่งในเรื่องที่คนมักจะเข้าใจผิดกันคือการอ้างอิง CVSS เพราะตัว value นั้นไม่ใช่ static แต่เป็น dynamic เนื่องจากจุดประสงค์ของ CVSS คือการพยายามทำ risk assessment เพื่อประเมินว่าช่องโหว่นี้มี priority มากน้อยแค่ไหน โดยตัว score นั้นสามารถเปลี่ยนแปลงได้เมื่อเวลาผ่านไปหรือเมื่อมีข้อมูลอื่นมาหักล้าง metrics ที่ตั้งไว้ในตอนแรก

โดยหลักการคือเมื่อมีคนเจอช่องโหว่ใหม่ แล้วแจ้งไปยังทีมพัฒนาหรือทางทีม CERT ก็จะมีการประเมิน impact และ severity ของช่องโหว่นั้น โดยข้อมูลหลักๆ ที่ใช้ในการประเมิน metric ก็จะอ้างอิงจาก exploitability, impact, และ threat บางช่องโหว่นั้นตอนที่ประเมินรอบแรกอาจจะได้คะแนนสูงมาก เพราะตอนใส่ข้อมูล attack complexity นั้นยังไม่มีความชัดเจนว่า service นั้นถูกติดตั้งและเปิดใช้งานมาแต่แรกหรือต้องมาเปิดเพิ่มทีหลัง หรือต้องมีการ chain อะไรมาก่อนหน้านี้บ้างถึงจะโจมตีสำเร็จ อีกทั้งเมื่อมีการรายงานช่องโหว่พร้อมมี PoC แต่ว่ายังไม่มี fix/mitigation ก็แน่นอนว่ายิ่งจะทำให้ได้คะแนนสูง แต่เมื่อเวลาผ่านไป เช่น เมื่อมีเครื่องที่ติดตั้ง official patch ไปเป็นจำนวนมากแล้ว ตัวคะแนนที่ได้ก็อาจจะถูกปรับลดลง

ทางทีมที่ทำเรื่อง CVSS เองก็ยอมรับว่ามันยังไม่ใช่ perfect solution แต่ก็พยายามจะปรับปรุงให้ดีขึ้นเพื่อให้สามารถใช้เป็นแนวทางในการทำ vulnerability management ได้ มีคนพยายามเสนอทางเลือกอื่นเพื่อใช้อ้างอิงแทน CVSS แต่ก็ยังไม่ค่อยแพร่หลายเท่าไหร่นัก เพราะฉะนั้นเวลาอ่านข่าวช่องโหว่แล้วเจอว่าตอนแรกประกาศมาเป็น critical แต่ภายหลังถูกปรับเป็น high หรือ medium ก็เป็นเรื่องปกติ

References

• https://www.softwaresecured.com/post/why-common-vulnerability-scoring-systems-suck
• https://www.redhat.com/en/blog/why-cvss-does-not-equal-risk-how-think-about-risk-your-environment

สรุปเนื้อหาเอกสาร SOC of the future : Blueprint of a Security Operations Center in 2030

เอกสาร SOC of the future : Blueprint of a Security Operations Center in 2030 เป็นการรวบรวมข้อมูลจากงานวิจัย แบบสำรวจ แนวโน้มภัยคุกคาม รวมถึงมาตรฐานและข้อกำหนดต่างๆ ที่เกี่ยวข้องกับงาน SOC เพื่อประเมินว่าในอีก 5 ปีข้างหน้า รูปแบบการทำงานของ SOC จะเป็นลักษณะไหน โดยข้อมูลในเอกสารนี้จะครอบคลุมการให้บริการของ SOC ในฝั่งยุโรปเป็นหลัก กลุ่มเป้าหมายคือคนทำงาน SOC, MSSP รวมถึงหน่วยงานภาครัฐ​ด้วย

Ransomware Incident Handling

Ransomware guidelines ในช่วงหลังๆ จะมีการอัปเดตให้ครอบคลุมเหตุการณ์ประเภท data extortion และ ransomware-as-a-service เพราะจุดประสงค์ของการโจมตีจะไม่ได้มีแค่การ encrypt ข้อมูล แต่จะมีทั้งการวาง backdoor, ทำ lateral movement, และทำ data exfiltration ร่วมด้วย ต่อให้มีการจ่ายค่าไถ่ หรือหา free decryption tool มาใช้งานได้ ก็ยังไม่ใช้การแก้ไขปัญหาตามหลักที่ควรจะเป็น มีโอกาสโดนซ้ำได้ อีกทั้งข้อมูลที่หลุดออกไปก็จำเป็นต้องหาวิธีรับมือเพิ่มเติมด้วย

สิ่งหนึ่งที่ควรระวังเวลาโดน ransomware โจมตี คือการมาโพสต์สอบถามในอินเทอร์เน็ตว่าโดนตัวนี้จะแก้ยังไง ซึ่งก็มักจะมีคนที่ไม่เข้าใจแล้วมาแนะนำให้ไปหา free decryption tool มาลอง โดยไม่ได้พิจารณาความเป็นไปได้ในการกู้ข้อมูลกลับคืน หรือความเสี่ยงที่อาจจะถูกหลอกให้เข้าไปยังเว็บไซต์ปลอมที่ attacker สร้างมาเพื่อหลอกว่าเป็น tool ที่สามารถ decrypt ไฟล์ได้โดยไม่ต้องจ่ายเงิน แต่จริงๆ แล้วเป็นมัลแวร์ที่จะเข้าไปฝังตัวอยู่ในระบบของเหยื่อเพื่อรอโจมตีซ้ำอีกที

การเอา random program มารันบนเครื่องที่โดน compromise เป็นสิ่งที่ไม่ควรทำมากๆ เพราะนอกจากจะเพิ่มความเสี่ยงแล้ว ยังอาจส่งผลเสียต่อการทำ incident response หรือ investigation ด้วย เพราะฉะนั้นเวลาเจอคำแนะนำอะไรแบบนี้ต้องลองพิจารณาดีๆ ว่าเชื่อถือได้มากน้อยแค่ไหน บางทีการเอาเวลาไปทำในส่วน improvement กับ recovery อาจจะมีประโยชน์กว่า

การออกข้อสอบอัตนัย ในยุคที่สามารถใช้ AI มาช่วยเขียนคำตอบได้

ถ้าออกข้อสอบแบบอัตนัย แล้วมีคนใช้ ChatGPT หรือเครื่องมืออื่นในลักษณะเดียวกันมาช่วยเขียนคำตอบ จะพิจารณายังไง

1. วัตถุประสงค์ของข้อสอบแบบอัตนัย ควรเป็นการวัดความเข้าใจและความสามารถในการอธิบาย โดยสิ่งที่เรียกว่า “ความเข้าใจ” นั้นอาจจะเป็นได้ทั้งความรู้เดิมที่มีอยู่แล้ว หรือเป็นความรู้ใหม่ที่พึ่งจะไปค้นหาและเรียบเรียงมาตอบก็ได้ ซึ่งถ้าตัวคำถามนั้นเป็นสิ่งที่สามารถหาคำตอบได้ทั่วไป หรือใช้เวลาไม่นานในการหาคำตอบ ก็ไม่ผิดที่คนจะใช้เครื่องมือช่วยหาแล้วเอาคำตอบนั้นมาส่ง อีกอย่างถ้าออกโจทย์มาไม่ดี คนตรวจก็น่าจะแยกแยะได้ยากด้วยว่าอะไรที่เป็นการตอบเอง อะไรที่เป็นการค้นข้อมูลมาตอบ ซึ่งวิธีการให้คะแนนก็อาจจะต้องประเมินว่าสิ่งที่เอามาตอบนั้นมีความถูกต้องครบถ้วนมากน้อยแค่ไหน หรือเลือกแหล่งอ้างอิงที่น่าเชื่อถือแค่ไหน

2. หากเป็นการให้เขียนเล่าประสบการณ์หรือยกตัวอย่างกรณีศึกษามาอธิบาย อันนี้น่าจะเริ่มยากขึ้น เพราะส่วนที่เป็นคำตอบพื้นฐานอาจจะพอใช้เครื่องมือช่วยเขียนได้ แต่ประสบการณ์กับตัวอย่างกรณีศึกษานั้นมีความเป็นไปได้สูงที่จะเกิดจาก hallucination ถ้าไม่ใช่เคสที่เคยลงมือทำจริง หรือไม่ใช่กรณีศึกษาที่เคยเกิดขึ้นจริง ก็อาจจะได้คำตอบที่ระบบแต่งเรื่องขึ้นมาเอง ซึ่งเรื่องนั้นอาจจะไม่สมเหตุสมผลหรือไม่มีแหล่งอ้างอิงที่แน่ชัด ถ้าเจอกรณีแบบนี้ก็อาจจะไม่ให้คะแนนในส่วนที่เป็นการอธิบาย แต่ถ้าเป็นเรื่องแต่งที่เนียนมาก หรือมีการยกตัวอย่างเคสที่เกิดขึ้นจริงมาตอบ ก็น่าจะพอให้คะแนนได้

3. การให้ความเห็นโดยผู้เชี่ยวชาญ หรือการวิเคราะห์เชิงลึก อันนี้จากที่ลองดู เหมือนระบบน่าจะยังช่วยเขียนได้แค่เนื้อหาแนวทั่วๆ ไป แต่ยังไม่สามารถเขียนเนื้อหาวิเคราะห์ในเชิงลึกได้ รวมถึงถ้าให้เขียนคำแนะนำก็อาจจะได้คำแนะนำที่ไม่ถูกต้องหรือเป็นคำแนะนำที่ไม่สามารถบอกได้ว่าจะทำจริงได้ยังไง (อันนี้ based on ว่าถ้าเป็นผู้เชี่ยวชาญจริงๆ ควรบอกได้ว่าสิ่งที่แนะนำมานั้นมันสามารถทำจริงได้ยังไง) ถ้าลองให้ ChatGPT ตอบในสิ่งที่เป็นเรื่องเฉพาะเจาะจง ส่วนใหญ่จะได้คำตอบแบบทั่วๆ ไป หรือแย่สุดคือพยายามจะตอบในเชิงลึกแต่เนื้อหาผิด ซึ่งถ้าใครเอาคำตอบมาแปะเลยโดยไม่ได้ตรวจสอบก่อนว่าถูกหรือเปล่า ก็คงไม่ให้คะแนนในส่วนนี้

สรุปคือยังไงทุกวันนี้ก็คงเลี่ยงไม่ได้ที่ข้อสอบแบบอัตนัยจะถูกโยนเข้า ChatGPT แล้วเอาสิ่งที่ได้มาเป็นคำตอบ และเอาจริงๆ ก็ควรสนับสนุนให้คนใช้เครื่องมือพวกนี้ รวมถึงฝึกวิเคราะห์คำตอบที่ได้จากการใช้งานระบบด้วย ไม่ใช่ทำแค่โยนคำถามไปแล้วเอาคำตอบมาใช้ดื้อๆ แนวทางการให้คะแนนคงไม่ใช่การมองว่าใครใช้ ChatGPT มาตอบคือปัดตก แต่ควรเปลี่ยนเป็นการประเมินว่าคนที่เอาคำตอบมาตอบนั้นได้มีการตรวจสอบหรือวิเคราะห์คำตอบก่อนส่งแล้วหรือยัง โดยเฉพาะอย่างยิ่งในกรณีที่เป็นคำถามที่ต้องใช้ความเชี่ยวชาญหรือประสบการณ์ในการตอบ

DFIR Case Study: วิเคราะห์การใช้มัลแวร์ RAT ขโมยเงินคริปโต

เมื่อช่วงเดือนกุมภาพันธ์ 2024 ที่ผ่านมา หลายคนน่าจะเคยได้ยินเคสของผู้เสียหายที่ถูกคนร้าย remote เข้ามาควบคุมเครื่องคอมพิวเตอร์แล้วโอนเงินคริปโตออกจากบัญชี ซึ่งหลังจากที่คุณอ้ำ (ผู้เสียหาย) ได้เขียนบล็อกเพื่อแชร์ประสบการณ์เรื่องนี้ไป ก็มีผู้เสียหายรายที่ 2 ติดต่อเข้ามา แจ้งว่าโดนเคสแบบเดียวกัน โดยเครื่องคอมพิวเตอร์ของผู้เสียหายรายที่ 2 นั้นยังไม่ได้ถูก format จึงน่าจะพอมีร่องรอยอะไรบางอย่างเพื่อให้พอวิเคราะห์ได้ว่าถูกโจมตีได้ยังไง

ผมได้รับการประสานจากคุณอ้ำ เพื่อขอให้ช่วยวิเคราะห์เคสของผู้เสียหายรายที่ 2 เนื่องจากสอบถามข้อมูลเบื้องต้นแล้วพบว่าทั้ง 2 เหตุการณ์นี้มีลักษณะร่วมกันคือทั้งวันเวลาที่เกิดเหตุ รูปแบบการโจมตี รวมถึงไฟล์ที่ผู้โจมตีทิ้งไว้ในเครื่อง ก็มีลักษณะคล้ายๆ กัน จึงอาจเป็นไปได้ว่าผู้โจมตีน่าจะเป็นกลุ่มเดียวกันหรือมีความเกี่ยวข้องกัน ซึ่งถ้าสามารถวิเคราะห์สาเหตุที่ทั้ง 2 เคสนี้ถูกโจมตีได้ ก็น่าจะมีประโยชน์กับคนอื่นๆ ด้วย

สรุปผลการวิเคราะห์ (ทั้งสิ่งที่พอจะมีหลักฐานให้ยืนยันได้ และสิ่งที่ยังไม่มีข้อมูลเพียงพอให้ตอบ) ทางคุณอ้ำได้เขียนเล่าไว้ในบล็อกตอนที่ 2 แล้ว ซึ่งใครที่สนใจเกี่ยวกับการทำ digital forensics ก็สามารถตามไปอ่านจากบล็อกนั้นได้เลย โดยในโพสต์นี้ผมจะขอแยกเฉพาะประเด็นทางเทคนิคบางส่วนออกมาขยายต่อ ซึ่งเนื้อหาหลักๆ จะมี 3 หัวข้อ คือ การทำ disk imaging, การทำ investigation, และ lessons learned

การกำหนด password policy และการเลือกใช้งาน password manager ในองค์กร

ปัจจุบันทุกองค์กรจำเป็นต้องกำหนด password policy ซึ่งโดยหลักๆ น่าจะครอบคลุมเรื่องรูปแบบการตั้ง password, การเปิดใช้งาน MFA, รวมถึงการแนะนำให้ใช้งานโปรแกรม password manager ที่ผ่านมามีหลายหน่วยงานที่ออกคำแนะนำเรื่องแนวทางการกำหนดหรือการบริหารจัดการ password ซึ่งบางคำแนะนำก็ล้าสมัย ไม่สอดคล้องกับเทคโนโลยีและรูปแบบการใช้งานในปัจจุบัน

หน่วยงาน NCSC ซึ่งดูแลด้าน cyber security ของประเทศสหราชอาณาจักร ได้มีคำแนะนำเรื่องการกำหนด password policy และการเลือกใช้งาน password manager ในองค์กร ซึ่งเป็นคำแนะนำที่อ้างอิงกับข้อกำหนดและมาตรฐานในปัจจุบัน รวมถึงมีคำอธิบายที่มาที่ไป ข้อจำกัด และประเด็นที่ควรพิจารณาในคำแนะนำแต่ละข้อ เพื่อให้ผู้ดูแลระบบสามารถเลือกแนวทางที่เหมาะสมกับบริบทหรือสภาพแวดล้อมขององค์กรได้ ในบทความนี้จะเป็นการสรุปภาพรวมของเอกสารดังกล่าว โดยจะแบ่งเนื้อหาออกเป็น 2 ส่วน คือ การกำหนด password policy และการเลือกใช้งาน password manager ในองค์กร

หลักการทำงาน ข้อจำกัด และข้อควรระวัง ในการทำ memory acquisition

ในการทำ digital forensics and incident response หนึ่งในขั้นตอนที่อาจส่งผลกระทบต่อความยากง่ายในการวิเคราะห์อย่างมีนัยสำคัญ คือการทำ volatile memory acquisition ซึ่งเป็นการเก็บข้อมูลจาก RAM เนื่องจากมีโอกาสสูงที่จะได้ข้อมูลที่เกี่ยวข้องกับการโจมตี ไม่ว่าจะเป็น มัลแวร์, รหัสผ่าน, ข้อมูลที่ถูก decrypt แล้ว, ข้อมูลที่ยังไม่ได้ถูกบันทึกลงใน disk, ข้อมูล network connection, หรือข้อมูล process creation command line ซึ่งหากได้ข้อมูลเหล่านี้มาประกอบการวิเคราะห์ ก็อาจช่วยประหยัดเวลาได้หลายชั่วโมงหรือหลายวัน (หรือบางเคส เช่น full disk encryption ก็อาจจะไม่สามารถวิเคราะห์ต่อได้เลยถ้าไม่มีข้อมูลจาก RAM มาใช้ในการ decrypt)

อย่างไรก็ตาม เนื่องจากข้อมูลใน RAM นั้นมีการเปลี่ยนแปลงอยู่ตลอดเวลา ปริมาณความจุ RAM ที่เพิ่มขึ้นกว่าสมัย 10 ปีที่แล้ว อีกทั้งในระบบปฏิบัติการรุ่นใหม่ๆ เริ่มมี security feature ที่เกี่ยวข้องกับ memory protection เพิ่มเข้ามา ทำให้ tool หรือ process เดิมที่เคยใช้ในการทำ memory acquisition ได้ อาจไม่สามารถใช้งานได้ หรืออาจจะยังพอใช้งานได้แต่ไม่เสถียร ส่งผลให้โปรแกรม crash หรืออาจจะทำให้ระบบ crash ได้เลย ซึ่งจะทำให้ evidence อื่นๆ เสียหายไปด้วย เพราะฉะนั้นการทำความเข้าใจหลักการทำงาน ข้อจำกัด และข้อควรระวัง ในการทำ memory acquisition จะช่วยให้สามารถประเมินความเสี่ยงและพิจารณาเลือกขั้นตอนและวิธีการที่เหมาะสมกับสถานการณ์นั้นๆ ได้

ความแตกต่างและแนวทางการใช้งาน IOCs, IOAs, และ TTPs

IOCs

• ย่อมาจาก Indicators of Compromise โดยคำว่า indicator หมายถึง “ตัวบ่งชี้” ส่วน compromise หมายถึง “การทำให้เสียหาย หรือทำให้อ่อนแอ” (ไม่ได้แปลว่า “การประนีประนอม”)
• เมื่อผู้โจมตีสามารถเจาะระบบได้สำเร็จ อาจจะมีการทิ้ง “ร่องรอย” หรือ “หลักฐาน” บางอย่างไว้ในระบบที่ถูกโจมตีสำเร็จแล้ว ซึ่งในระบบที่ทำงานตามปกติไม่ควรจะปรากฎข้อมูลในลักษณะนี้
• ตัวอย่างข้อมูลเหล่านั้น เช่น IP ที่ผู้โจมตีใช้ในการเชื่อมต่อเข้ามา, account ที่ถูกสร้างขึ้นมาใหม่หลังจากที่เจาะระบบสำเร็จ, ไฟล์หรือเครื่องมือที่ผู้โจมตี upload เข้ามา (ซึ่งตามปกติไม่ควรมีไฟล์นี้อยู่บนเครื่อง), หรือ IP/domain ของเซิร์ฟเวอร์ที่ใช้สำหรับควบคุมเครื่องที่ตกเป็นเหยื่อ (ซึ่งตามปกติไม่ควรมีการเชื่อมต่อออกไปยัง IP/domain เหล่านี้)
• IOC จะถูกสร้างขึ้นมาก็ต่อเมื่อมีเหยื่อรู้ตัวว่าถูกโจมตี และได้มีการวิเคราะห์ระบบหรือข้อมูลที่เกี่ยวข้องจนทราบช่องทางหรือผลลัพธ์ที่เกิดขึ้นบนระบบที่ถูกโจมตีสำเร็จ (แต่รู้แล้วจะแชร์ข้อมูลให้กับคนอื่นหรือไม่ แชร์มากน้อยแค่ไหน ก็เป็นอีกเรื่องนึง)
• เนื่องจาก IOCs ส่วนใหญ่จะเป็นสิ่งที่เกิดขึ้นหลังจากที่ระบบถูกโจมตีสำเร็จ เพราะฉะนั้นแนวทางการนำ IOCs มาใช้งานจึงมักจะเป็นการเอา IP, domain, hash มาเช็คกับ log หรือ scan บนระบบที่สงสัยว่าอาจถูกโจมตี (เป็นลักษณะ reactive)
• ในบางกรณีอาจจะเอา IOCs มาใช้เพื่อป้องกันก่อนที่จะถูกโจมตีได้ เช่น เอา IP กับ domain ที่ถูกระบุว่าเกี่ยวข้องกับการโจมตี มา block ที่ firewall หรือเอาค่า hash มาใส่ใน antimalware signature เพื่อให้ block ทันทีที่เจอไฟล์ malware ปรากฎในเครื่อง
• IOCs มีได้หลายรูปแบบ ความยากง่ายในการใช้งาน และความแม่นยำ อาจแตกต่างกันไป เช่น file hash จะตรงไปตรงมา แต่ผู้โจมตีสามารถเปลี่ยนค่า hash เพื่อหลบเลี่ยงการตรวจจับได้ง่าย ในขณะที่ IP/domain อาจจะเป็นได้ทั้งของที่ผู้โจมตีสร้างและใช้งานเอง หรือเป็นการเจาะระบบอื่นแล้วใช้ระบบนั้นในการโจมตีต่ออีกทีก็ได้ ซึ่งถ้าเป็นกรณีหลัง หากผู้ดูแลระบบสามารถแก้ไขปัญหาได้ และระบบไม่ได้ถูกโจมตีแล้ว ข้อมูล IOCs นั้นก็จะไม่ valid
• แนวทางการใช้งาน IOCs มีระบุไว้ใน RFC 9424 (ออกเมื่อเดือนสิงหาคม 2023) ส่วนที่น่าสนใจ เช่น ควรมีการระบุ context เพิ่มเติมให้กับ IOCs เพื่อคนที่เอาไปใช้งานจะได้ประเมินความเกี่ยวข้องหรือความน่าเชื่อถือของข้อมูลนั้นๆ ได้ หรือหากเป็น IOC ที่ข้อมูลอาจไม่ valid เมื่อเวลาผ่านไประยะหนึ่ง (เช่น IP/domain) ก็ควรมีการระบุ timestamp ของ IOCs นั้นด้วย
• ข้อควรระวังคือการนำ IOCs มา block นั้นอาจไม่ใช่การแก้ปัญหาที่ถูกวิธี เป็นเพียงแค่การซื้อเวลา (เช่น รอติดตั้ง patch หรือรอแก้ไข config) รวมถึงควรรีวิวความถูกต้อง ความเกี่ยวข้อง ความน่าเชื่อถือ และอายุการใช้งานของ IOCs อย่างสม่ำเสมอ เพื่อลด false positive

แชร์ประสบการณ์การรับมือกับ beg bounty

Bug bounty คือการให้เงินรางวัลกับคนที่แจ้งช่องโหว่ ซึ่งโดยปกติองค์กรที่มีนโยบายในลักษณะนี้มักจะมีการประกาศให้ทราบอย่างชัดเจนในหน้าเว็บไซต์หรือประกาศไว้บนแพลตฟอร์มสำหรับ bug hunter แต่ปัจจุบันหลายๆ องค์กรที่ไม่ได้มีนโยบาย bug bounty มักจะพบพฤติกรรมในลักษณะที่เป็นการพยายามแจ้งช่องโหว่เข้ามาแล้วเรียกร้องขอให้จ่ายเงิน ซึ่งเรียกเหตุการณ์แบบนี้ว่า beg bounty (อ่านรายละเอียดเพิ่มเติมได้จากบทความของ Computer Weekly)

ในฐานะที่เคยได้รับผิดชอบเรื่องการรับมือกับเคส beg bounty เลยขอแชร์ประสบการณ์บางส่วนจากเคสที่เคยเกิดขึ้นจริง

1. ตรวจสอบว่าองค์กรมีนโยบายจ่ายค่าตอบแทนให้กับการค้นพบช่องโหว่หรือไม่ ถ้ามี เงื่อนไขการจ่ายคืออะไร เช่น ประเภทของช่องโหว่ ระดับความรุนแรง หรือแนวทางการโจมตีที่เป็นไปได้ (ต้องตรวจสอบด้วยว่าใน report มี information เพียงพอให้ประเมินข้อมูลเหล่านี้หรือเปล่า) ถ้าไม่มีนโยบายจ่ายค่าตอบแทน ก็คงต้องตอบว่าขอบคุณที่ช่วยแจ้งและอธิบายไปตามจริง ถ้าเป็นไปได้ควรประกาศเรื่องนี้ไว้ใน security.txt เลย

2. ส่วนใหญ่ช่องโหว่ที่ถูกแจ้งมาในลักษณะ beg bounty มักจะไม่ค่อยมีผลกระทบเท่าไหร่ หรืออาจจะยังไม่ใช่ช่องโหว่ที่สามารถใช้โจมตีได้จริงๆ ออกแนวใช้ tool สแกนแล้วเจออะไรเล็กๆ น้อยๆ เช่น misconfig ก็เอามาแจ้งเพื่อหวังเงินเฉยๆ

3. องค์กรควรกำหนดทีมที่ทำหน้าที่ vulnerability response เพื่อช่วยติดต่อกับผู้ดูแลระบบ รวมถึงประเมิน impact และแนวทางการตอบกลับคนที่แจ้ง เพราะบางทีทีมที่ได้รับแจ้งช่องโหว่ (เช่น IT หรือ SOC) อาจจะไม่สามารถ verify รายละเอียดในส่วนนี้ได้ หรือไม่สามารถประเมินได้ว่าการโจมตีนั้นจะทำได้จริงตามที่กล่าวอ้าง