Cyber Security Academy · บทเรียน

หลักการตรวจจับในรูปแบบโค้ด

ปฏิบัติต่อการตรวจจับเช่นเดียวกับซอฟต์แวร์

หลักการตรวจจับในรูปแบบโค้ด เป็นบทเรียน Cyber Security Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cyber Security Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

เหตุผลของการตรวจจับในรูปแบบโค้ด

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

ประโยชน์ที่เห็นได้ชัดมีดังนี้:

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

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

การตรวจจับในรูปแบบไฟล์ที่มีการจัดการเวอร์ชัน

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

โครงสร้างทั่วไปจะแยกกฎตามแพลตฟอร์มและยุทธวิธี:

detections/
  windows/
    credential_access/
      lsass_memory_dump.yml
    execution/
      suspicious_powershell.yml
  cloud/
    aws/
      root_account_usage.yml
tests/
  windows/
    lsass_memory_dump_test.yml

การตรวจทานคำขอผสาน

การตรวจจับรายการใหม่หรือรายการที่แก้ไขทุกครั้งจะต้องผ่าน คำขอผสาน วิศวกรอีกคนจะตรวจทานตรรกะ ความเสี่ยงต่อผลบวกลวง และการจับคู่ ATT&CK ก่อนผสาน

ผู้ตรวจทานจะถามว่า:

ตรรกะตรงกับภัยคุกคามที่อธิบายไว้หรือไม่
กิจกรรมที่ถูกต้องตามปกติใดบ้างที่อาจทำให้กฎนี้ทำงาน
ระดับความรุนแรงและข้อมูลอ้างอิง ATT&CK ถูกต้องหรือไม่
มีการทดสอบที่ครอบคลุมทั้งผลบวกจริงและผลบวกลวงหรือไม่

กระบวนการนี้ช่วยตรวจพบข้อผิดพลาดที่นักวิเคราะห์ซึ่งแก้ไข SIEM ตอนตีสองเพียงลำพังอาจมองข้าม

การตรวจสอบการผสานรวมอย่างต่อเนื่อง

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

ขั้นตอนทั่วไปของการผสานรวมอย่างต่อเนื่องสำหรับคลังที่ใช้ซิกมา:

# .github/workflows/validate.yml (excerpt)
steps:
  - name: Lint Sigma syntax
    run: sigma check ./detections
  - name: Validate against schema
    run: sigma check --validators all ./detections
  - name: Run unit tests
    run: pytest tests/

การนำไปใช้งานโดยอัตโนมัติ

เมื่อผสานแล้ว งานนำไปใช้งานจะแปลงกฎที่ใช้งานข้ามแพลตฟอร์มได้เป็นภาษาสำหรับสร้างคำค้นหาเป้าหมาย และส่งกฎเหล่านั้นไปยัง SIEM หรือ EDR ผ่านส่วนติดต่อโปรแกรมประยุกต์

สำหรับ Sigma โดยทั่วไปคุณจะเรียกใช้ตัวแปลง เช่น sigma convert พร้อมระบบส่วนหลังที่ตรงกับแพลตฟอร์มของคุณ (สปลังก์, อีลาสติก, ไมโครซอฟท์ เซนทิเนล) จากนั้นกระบวนการทำงานจะอัปโหลดการค้นหาที่บันทึกไว้หรือกฎการวิเคราะห์ที่สร้างขึ้น

ไม่มีบุคคลใดต้องคัดลอกคำค้นหาไปวางในคอนโซล สถานะที่นำไปใช้งานจะตรงกับสิ่งที่อยู่ใน main เสมอ

sigma convert -t splunk -p splunk_windows \
  detections/windows/execution/suspicious_powershell.yml

การทดสอบการตรวจจับ

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

การทดสอบทำงานในกระบวนการผสานรวมอย่างต่อเนื่อง ดังนั้นการเปลี่ยนแปลงที่ทำให้ความครอบคลุมลดลงหรือนำสัญญาณรบกวนกลับมา จะทำให้การสร้างไม่ผ่านก่อนผสาน นี่คือแหล่งความมั่นใจที่สำคัญที่สุดเมื่อปรับโครงสร้างกฎในวงกว้าง

test:
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 javascript:...' }
    expected: match
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 shell32.dll,Control_RunDLL' }
    expected: no_match

ข้อมูลเมตาของกฎและวงจรชีวิต

ให้ความสำคัญกับข้อมูลเมตาในระดับเดียวกับองค์ประกอบหลัก การตรวจจับแต่ละรายการจะบันทึก สถานะของตนเองเมื่อพัฒนาผ่านวงจรชีวิต:

experimental — เพิ่งเขียนขึ้นใหม่และต้องเฝ้าติดตามอย่างใกล้ชิด
test — ทำงานอยู่แต่ยังไม่น่าเชื่อถือพอสำหรับการแจ้งเตือน
stable — ผ่านการพิสูจน์แล้วและมีอัตราผลบวกลวงต่ำ
deprecated — มีกฎอื่นมาแทนที่หรือเลิกใช้งานแล้ว

การติดตามสถานะไว้ในไฟล์ช่วยให้คุณเลื่อนระดับ ลดระดับ และเลิกใช้กฎได้อย่างมีเจตนา แทนที่จะปล่อยให้ตรรกะที่ล้าสมัยค้างอยู่ในระบบจริง

การใช้งานข้ามระบบส่วนหลัง

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

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

sigma convert -t elasticsearch rule.yml
sigma convert -t microsoft365defender rule.yml
sigma convert -t splunk rule.yml

กระบวนการจับคู่ฟิลด์

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

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

sigma convert -t splunk -p sysmon rule.yml

สภาพแวดล้อมและการเลื่อนระดับ

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

พัฒนา — เขียนและเรียกใช้การทดสอบหน่วยในกระบวนการผสานรวมอย่างต่อเนื่อง
เตรียมใช้งาน — นำไปใช้กับสำเนาข้อมูลเทเลเมทรีจริงในโหมดตรวจสอบ
ระบบจริง — เลื่อนระดับเมื่ออัตราผลบวกลวงอยู่ในระดับยอมรับได้

การเลื่อนระดับเป็นขั้นตอนที่ตั้งใจและผ่านการตรวจทาน โดยเชื่อมโยงกับสถานะวงจรชีวิตของกฎ ไม่ใช่ผลโดยบังเอิญจากการผสาน การนำไปใช้แบบเป็นขั้นตอนนี้สะท้อนแนวทาง “แจ้งเตือนแล้วจึงบล็อก” ที่ใช้กับการตรวจจับแบบแทรกในสายงาน

ความครอบคลุมและตัวชี้วัด

เนื่องจากการตรวจจับเป็นโค้ด คุณจึงสามารถวัดความครอบคลุมด้วยโปรแกรมได้ เชื่อมโยงกฎแต่ละข้อกับเทคนิคของ MITRE ATT&CK และสร้างแผนที่ความร้อนเพื่อดูว่าส่วนใดที่ครอบคลุมและไม่ครอบคลุม

ตัวชี้วัดที่ควรติดตามเมื่อเวลาผ่านไป:

เทคนิคที่ครอบคลุมเทียบกับจำนวนเทคนิคทั้งหมดในแบบจำลองภัยคุกคาม
อัตราผลบวกลวงต่อกฎ
เวลาเฉลี่ยตั้งแต่เกิดแนวคิดกฎจนถึงการใช้งานจริง
จำนวนกฎในแต่ละสถานะของวงจรชีวิต

ตัวเลขเหล่านี้เปลี่ยนวิศวกรรมการตรวจจับจากเรื่องเล่าหรือความเห็นส่วนตัวให้เป็นโครงการที่มีการบริหารจัดการ

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจพื้นฐานของการตรวจจับในรูปแบบโค้ด

ทบทวน

การตรวจจับในรูปแบบโค้ดนำความเคร่งครัดของวิศวกรรมซอฟต์แวร์มาใช้กับการตรวจจับ:

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

ถัดไป คุณจะเขียนกฎที่ใช้งานข้ามระบบด้วยซิกมา

คำถามที่พบบ่อย

บทเรียน “หลักการตรวจจับในรูปแบบโค้ด” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “หลักการตรวจจับในรูปแบบโค้ด” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cyber Security Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “หลักการตรวจจับในรูปแบบโค้ด”

ปฏิบัติต่อการตรวจจับเช่นเดียวกับซอฟต์แวร์ คุณปฏิบัติ Cyber Security Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cyber Security Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cyber Security Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “หลักการตรวจจับในรูปแบบโค้ด” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cyber Security Academy นี้ได้ไหม

ได้ บทเรียน Cyber Security Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Cyber Security Academy