แก้ช่องโหว่และทำ Security Hardening

รายงาน vulnerability assessment หรือ penetration test จบลงตรงที่รายการช่องโหว่ แต่ปัญหาขององค์กรส่วนใหญ่เพิ่งเริ่มตรงนี้ ใครจะเป็นคนแก้ ผู้ดูแลระบบมีทั้ง Windows, Linux, database, firewall และ cloud อยู่ในมือพร้อมกัน ไม่มีใครเชี่ยวชาญครบทุก platform แล้ว finding ที่เขียนว่า "ตั้งค่าไม่ปลอดภัย" ก็ไม่ได้บอกว่าค่าที่ปลอดภัยควรเป็นเท่าไหร่ใน environment ของคุณ เพราะรายงานไม่ได้เขียนมาเพื่อตอบคำถามนั้นตั้งแต่แรก

บริการนี้ทำสองอย่าง อย่างแรกคือ แก้ช่องโหว่ที่คุณมีอยู่แล้ว ทำงานจากรายงาน pentest หรือ vulnerability assessment ทั้งของเราและของผู้ให้บริการรายอื่น อย่างที่สองคือ ทำ hardening ทั้ง baseline ปรับตั้งค่า system component ให้เป็นไปตาม security best practice ตั้งแต่ต้น เพื่อให้ attack surface ลดลงทั้งระบบ ไม่ใช่แค่จุดที่ scanner บังเอิญตรวจเจอ เราอ้างอิง CIS Benchmarks เป็นหลัก ถ้าไม่มี benchmark ของ component นั้นก็ใช้ vendor recommendation และถ้าไม่มีจริง ๆ เราใช้ CIS Critical Security Controls เป็น framework บวกกับประสบการณ์ของทีม ร่างเป็น baseline ให้ ทุกกรณีคุณจะรู้ว่าค่าที่เราตั้งมาจากไหน ไม่ใช่ตั้งเพราะเคยชิน อยากอ่านพื้นฐานก่อน ทีมของเราเขียนไว้แล้วทั้ง บทความแนะนำเรื่อง hardening และ ฉบับเริ่มต้นลงมือทำ

แก้ช่องโหว่กับทำ hardening ต่างกันอย่างไร

สองอย่างนี้มักถูกเรียกรวมกัน แต่ตอบคนละโจทย์ ขอบเขตคนละแบบ และคิดค่าใช้จ่ายคนละแบบ

การแก้ช่องโหว่ (remediation) เป็นงานตั้งรับ มี finding อยู่ในมือแล้ว ต้องปิดให้ได้ก่อน deadline ของ audit หรือก่อนรอบ retest ขอบเขตชัดเพราะผูกกับรายการ finding และวัดผลได้ตรง ๆ ว่าปิดไปกี่ข้อ

การทำ hardening เป็นงานเชิงรุก คือทำให้ระบบเป็นไปตาม security baseline ที่ควรจะเป็นมาตั้งแต่แรก มาตรฐานและ compliance บอกให้ทำ แต่มักไม่มีคนทำ โดยเฉพาะกับระบบที่อยู่บน production ผลลัพธ์คือ attack surface ที่ลดลงทั้งระบบ ไม่ใช่แค่จุดที่ scanner ตรวจพบ

ในทางปฏิบัติ ช่องโหว่จำนวนมากที่เจอในรายงาน pentest ไม่ใช่ CVE ที่ต้องรอ patch จาก vendor แต่เป็นการตั้งค่าที่หลวม แบบที่ hardening baseline ดี ๆ ปิดไปตั้งแต่ต้นแล้ว องค์กรที่แก้เป็นราย finding ทุกรอบก็เลยมักเจอปัญหาเดิมซ้ำในรอบถัดไป เพราะแก้ที่อาการ ไม่ได้แก้ที่ baseline

ขอบเขตที่เรา harden

ขอบเขตกำหนดด้วยจำนวนเครื่องและชนิดของ component ที่จะทำ ตกลงกันก่อนเริ่มงานเสมอ ถ้ายังไม่รู้จะเริ่มจากตรงไหน เราแนะนำให้เริ่มที่ชั้น OS ก่อน แล้วค่อยไล่ขึ้นไปชั้นบน

• ระบบปฏิบัติการ — Windows Server, Windows client, Linux distribution หลัก ๆ และ Unix ปกติเราแนะนำให้เริ่มจากชั้นนี้ เพราะกระทบ application ที่รันอยู่ข้างบนน้อยกว่าชั้นอื่น
• Server software — web server, application server และ middleware
• Database — ทั้งการตั้งค่า engine สิทธิ์ของ account และการเข้ารหัสระหว่างทาง
• Network device และ firewall — rule base, management plane และ protocol ที่เลิกใช้แล้วแต่ยังเปิดค้างอยู่
• Cloud — การตั้งค่าระดับ account และระดับ service บน cloud provider หลัก ตรงนี้คือการ harden component บน cloud ให้ถึง baseline ถ้าโจทย์ของคุณคือการตรวจทั้ง environment เทียบกับ shared responsibility model นั่นเป็นคนละงานกัน ดูที่ การประเมินความมั่นคงปลอดภัยของ cloud
• Container และ orchestration — image, runtime และการตั้งค่า cluster
• Active Directory — โครงสร้างสิทธิ์ นโยบาย และการตั้งค่าที่มักกลายเป็นเส้นทาง lateral movement

ถ้ามี component ที่ไม่อยู่ในรายการนี้ เอาโจทย์มาคุยกันก่อนได้

ขั้นตอนการทำงาน

การ harden ที่ทำให้ระบบล่มคือการ harden ที่ล้มเหลว กระบวนการของเราออกแบบมาให้งานลงจอดได้จริง

1. Scoping และ asset inventory — ตกลงว่ามี component อะไรอยู่ในระบบบ้าง จะทำกี่เครื่อง ชนิดไหน เทียบ guideline ไหน และอะไรที่จะไม่แตะ ตกลงกันตรงนี้ ไม่ใช่ไปเจอเอาตอนจบ
2. Baseline audit — ตรวจสถานะปัจจุบันเทียบกับ benchmark ที่เลือกไว้ ให้เห็นช่องว่างเป็นตัวเลขก่อนเริ่มแก้ ทั้งคุณและเราก็จะมีจุดอ้างอิงร่วมกันว่าเริ่มจากตรงไหน
3. ประเมินผลกระทบและตกลง exception — ทำครบทุกข้อในเอกสารอาจเป็นไปไม่ได้ ความเสี่ยงเป็นสิ่งที่ต้องคำนึง แต่ business operation ก็สำคัญ ข้อไหนที่ทำแล้วกระทบระบบงานจริงหรือขัดกับนโยบายที่คุณมีอยู่ จะถูกบันทึกเป็น exception พร้อมเหตุผลแทนการฝืนทำ บันทึกพวกนี้ก็เป็นเอกสารที่ auditor ขอดูอยู่แล้ว
4. Backup แล้วทยอยทำเป็นรอบ — สำรองการตั้งค่าเดิมก่อนทุกครั้ง ทำทีละกลุ่ม เริ่มจาก non-production ก่อนเสมอ ถ้ามีปัญหาหลังปรับ เรา restore กลับได้ทันที
5. Verify — audit ซ้ำหลังปรับ ยืนยันว่าค่าที่ตั้งไปมีผลจริง และระบบยังทำงานปกติ
6. ส่งมอบรายงานและเอกสาร baseline — คุณได้ทั้งผลของงานรอบนี้ และเอกสาร baseline ที่ทีมคุณเอาไปใช้กับเครื่องใหม่ต่อได้เอง
7. ตรวจซ้ำตามรอบ — เลือกได้ configuration drift เกิดขึ้นทันทีที่มีคนเข้าไปแก้ระบบ เราตรวจซ้ำตามรอบที่ตกลงกัน เพื่อให้เห็นว่าอะไรหลุดออกจาก baseline ไปแล้วบ้าง

ทำอัตโนมัติด้วย Confix

harden สิบเครื่องทำด้วยมือได้ แต่ harden สามร้อยเครื่องแล้วตรวจซ้ำทุกไตรมาส ทำด้วยมือไม่ไหว

เราใช้ Confix เป็นตัวช่วยทำ system hardening และ audit บนเซิร์ฟเวอร์ Windows และ Unix แบบอัตโนมัติ ด้วย template ที่ปรับแต่งได้ ตัว template ทำให้ baseline ขององค์กรถูกเขียนออกมาเป็นสิ่งที่จับต้องได้ พอ audit รอบใหม่ก็เห็นทันทีว่าเครื่องไหนหลุดไปจากมาตรฐาน

ใช้ได้สองแบบ ให้เราเข้าไปทำเป็นบริการด้วยเครื่องมือนี้ หรือรับ license ไปให้ทีมคุณใช้เองต่อ ตอนเริ่มเราช่วยวาง template และสอนใช้งานให้ แบบหลังเหมาะกับองค์กรที่มีทีม infrastructure ของตัวเองและอยากทำเรื่องนี้เป็นงานประจำ

สิ่งที่คุณได้รับ

• รายงาน baseline audit ก่อนและหลัง — เห็นเป็นตัวเลขว่าผ่านกี่ข้อจากทั้งหมดกี่ข้อ ทั้งตอนเริ่มและตอนจบงาน
• เอกสาร hardening baseline ขององค์กรคุณ — ระบุทุกข้อว่าตั้งค่าอะไร อ้างอิงจากแหล่งไหน ทั้ง CIS, vendor หรือทีมเรา และเพราะอะไร ทีมคุณเอาไปใช้กับเครื่องที่ติดตั้งใหม่ต่อได้เลย
• บันทึก exception พร้อมเหตุผล — ข้อที่ไม่ได้ทำและเหตุผลทางธุรกิจหรือทางเทคนิคที่ทำให้ไม่ได้ทำ เขียนมาให้ใช้ตอบ auditor ได้โดยตรง
• การตั้งค่าเดิมที่สำรองไว้ — พร้อม restore ถ้าพบปัญหาภายหลัง
• ผลการยืนยันหลังแก้ไข — audit รอบสองที่ยืนยันว่าค่าที่ตั้งมีผลจริง
• สรุปสำหรับผู้บริหาร — ภาพความเสี่ยงที่ลดลง ในระดับที่ผู้บริหารและ auditor อ่านรู้เรื่อง

ทีมและใบรับรอง

งานนี้ทีมภายในของเราลงมือเอง ถือใบรับรองในวงการอย่าง OSCP, OSCE, CREST CRT, CREST CPSA และ GIAC GREM ที่ได้มาจากการสอบภาคปฏิบัติอย่างเข้มข้น พื้นฐานสาย offensive security ชุดเดียวกันนี้แหละที่ทำให้การตัดสินใจเรื่อง hardening มีน้ำหนัก เรารู้ว่าการตั้งค่าแบบไหนที่ผู้โจมตีเอาไปใช้ได้จริง เหตุผลของการปรับแต่ละข้อจึงไม่ใช่แค่ว่าเอกสารเขียนไว้ ดูใบรับรองทั้งหมดที่ทีมถือ

มาตรฐานที่ใช้

1. CIS Benchmarks — เป็นตัวเลือกแรกเสมอ เอกสารจาก Center for Internet Security ครอบคลุม component ส่วนใหญ่ที่องค์กรใช้งานจริง มีการ update สม่ำเสมอ แต่ละข้อมีทั้งเหตุผล ผลกระทบ วิธีตรวจสอบ และวิธีแก้ไขกำกับไว้ คุยกับ auditor ได้ตรงไปตรงมา
2. Vendor recommendation — ถ้า CIS ไม่มี benchmark ของ component นั้น เราใช้เอกสาร hardening guide จากผู้ผลิตโดยตรง เอกสารพวกนี้มักเป็นแหล่งที่แม่นที่สุดสำหรับ product เฉพาะทาง
3. ประสบการณ์ของทีม บน framework ที่อ้างอิงได้ — เมื่อไม่มีทั้งสองอย่าง เราใช้ CIS Critical Security Controls เป็นโครง แล้ว map ว่า feature หรือ function ไหนของ component นั้นตรงกับ control ข้อใด บวกกับ guideline จาก community ที่เชื่อถือได้ ผลลัพธ์คือ baseline ที่ร่างขึ้นเฉพาะสำหรับคุณ พร้อมเหตุผลกำกับทุกข้อ ไม่ใช่ความเห็นลอย ๆ

การ harden คือการปิดสิ่งที่การตรวจประเมินหาเจอ งานนี้เลยอยู่ถัดจากงานที่ผลิต finding ออกมา ทั้ง vulnerability assessment ที่ให้ความครอบคลุมทั่วทั้งระบบ penetration test ที่ให้หลักฐานว่าผู้โจมตีไปถึงไหนได้ และ การทดสอบ infrastructure สำหรับเครือข่ายกับเซิร์ฟเวอร์ที่อยู่ข้างล่าง ส่วนโจทย์ที่ไม่ใช่ว่าจะปรับค่าไหน แต่เป็นว่าองค์กรต้องมี control อะไรบ้างและจะทำหลักฐานให้ auditor อย่างไร นั่นเป็นฝั่ง governance ทีม consulting ของเราดูแลส่วนนั้น