www.cioworldmagazine.com

 Breaking News

ICT Trend Watch (ตอนที่ 27) การรับมือเหตุการณ์ความมั่นคงปลอดภัยคอมพิวเตอร์

ICT Trend Watch (ตอนที่ 27) การรับมือเหตุการณ์ความมั่นคงปลอดภัยคอมพิวเตอร์
February 15
11:01 2016
ดร.ไพโรจน์ ธรรมศีลสุวรร
ดร.ไพโรจน์ ธรรมศีลสุวรร

NEC Corporation (Thailand) &Technology Coordinator of TTC, JAPAN ผู้เชี่ยวชาญด้านไอทีและการสื่อสาร ผ่านประสบการณ์มากกว่า 10 ปี ดำรงตำแหน่งคณะอนุกรรมการวิจัยวิจัยโทรคมนาคม TRIDI และอาจารย์มหาวิทยาลัยชั้นนำของประเทศ

“เป็นเนื้อหาต่อเนื่องจากฉบับที่ผ่านมาที่ให้ความสำคัญกับการตั้งทีมแก้ไขปัญหาความปลอดภัยข้อมูลที่เรียกว่า CSIRT ฉบับนี้ขอตัวอย่างกรณีศึกษาของญี่ปุ่นสำหรับกระบวนการในการรับมือเหตุการณ์ในลักษณะดังกล่าวขึ้น ที่สามารถนำแนวคิดมาประยุกต์ใช้ได้”

HPE1 662x190

ฉบับที่ผ่านมาได้เปิดประเด็นเรื่อง มาตรการรับมือเกี่ยวกับความปลอดภัยทางข้อมูลซึ่งไม่ใช่ภาระของผู้ดูแลระบบไอซีทีเพียงฝ่ายเดียวอีกต่อไป แต่ระดับผู้บริหารขององค์กรก็ต้องรับผิดชอบแบบเต็มๆ กับความเสียหายที่เกิดขึ้น โดยเสนอแนวทางการตั้งทีมขึ้นเพื่อรับมือกับปัญหาดังกล่าวที่เรียกว่า CSIRTซึ่งย่อมาจาก Computer Security Incident Response Team ภายใต้การดูแลของผู้บริหารที่เกี่ยวข้องอย่าง CIO

องค์กรในยุคปัจจุบันนั้น ผู้บริหารจำเป็นต้องมีการวางมาตรการรับมือเกี่ยวกับความมั่นคงปลอดภัยคอมพิวเตอร์หรือที่เรียกกันว่า incident (ไม่ว่าจะเป็นการติดมัลแวร์ การถูกโจมตีแบบDDoSมีunauthorized accessเกิดขึ้น มีการตั้ง Phishingsite ต่างๆ เป็นต้น)โดยควรจะมีทีม CSIRT ที่มีภารกิจอยู่หลากหลายตั้งแต่การวางแผนและดำเนินการเพื่อ “ป้องกันเหตุการณ์ความมั่นคงปลอดภัยไว้ล่วงหน้า”ไปถึง “รับมือขณะเกิดเหตุการณ์ความมั่นคงปลอดภัย”ตลอดจน“บริหารจัดการหลังเกิดเหตุการณ์ความมั่นคงปลอดภัย”เป็นต้น

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

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

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

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

ขั้นที่หนึ่ง (Incident Detection/Contact Receipt)ในการตรวจสอบให้รู้ถึงหรือรับแจ้งการเกิดของเหตุการณ์
ขั้นที่สอง (Triage)ในการให้ลำดับความสำคัญของเหตุการณ์ที่เกิดขึ้นตลอดจนทำการวินิจฉัยว่าเป็นเหตุการณ์ที่ทางองค์กรสมควรดำเนินการจัดการรับมือหรือไม่
ขั้นที่สาม(Incident Response)ในการวางแผนและดำเนินการจัดการรับมือ (สำหรับเหตุการณ์ที่ได้ผ่านการวินิจฉัยให้จัดการรับมือในขั้นที่สองมาแล้ว) ตลอดจนตรวจสอบว่าปัญหาได้ถูกแก้ไขแล้ว
ขั้นที่สี่ (Report/Information Disclosure)ในการรายงานหรือเปิดเผยข้อมูล(ในกรณีที่จำเป็น) ต่อภายนอกหรือหน่วยงานที่มีหน้าที่กำกับดูแล ซึ่งอาจจะทำไปพร้อมๆ กับขั้นตอนการวางแผนหรือดำเนินการจัดการรับมือ

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

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

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

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

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

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

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

Related Articles

0 Comments

No Comments Yet!

There are no comments at the moment, do you want to add one?

Write a comment

Write a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

BannerWeb_CIOworld_2

Like Us On Facebook

Facebook Pagelike Widget

Categories

Newsletters

ลงทะเบียนรับข่าวสารจาก CIOWorldMagazine.com