Microsoft Defender for Cloud กับ Azure Arc-enabled Servers

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมจะมานำเสนอเรื่องราวของ Cloud Security โดยจะเข้าไปเกี่ยวข้องกับ Microsoft Defender for Cloud หรือ MDC ครับ และอย่างที่หลายๆ ท่านรู้จักและคุ้นเคยกับ MDC อยู่แล้ว ก็พอจะทราบว่า MDC เป็น Service หนึ่งที่อยู่ใน Microsoft Azure ที่ให้บริการ Security Solutions เช่น Cloud Security Posture Management (CSPM), Cloud Workload Protection (CWP), และ Cloud-Native Application Protection Platform (CNAPP) สำหรับท่านใดที่ยังไม่คุ้นเคยหรือยังไม่รู้จัก Microsoft Defender for Cloud สามารถไปหาอ่านบทความของผมก่อนหน้าได้เลยครับ

กลับมาที่ตัวของ MDC กันต่อครับ ด้วยความสามารถที่เพิ่มได้เกริ่นไว้เมื่อซักครู่นั้น ทำให้เราสามารถพิจารณานำเอา MDC เข้ามาช่วยในการ Secure & Protect Workloads ต่างๆ ยกตัวอย่างเช่น Virtual Machines โดย Workloads (Virtual Machines) เหล่านั้นจะอยู่ใน On-Premise หรือ On Cloud ก็ได้ครับ เพราะ MDC สามารถทำการ Secure & Protect ครอบคลุม IT Environments ทั้ง Hybrid และ Multi-Cloud อยู่แล้วครับ จากตัวอย่างของ Workloads ที่ผมได้เกริ่นไว้ นั่นก็คือ Virtual Machines นั้นในกรณีที่องค์กรใดก็ตามที่ต้องการบริหารจัดการตลอดจนการ Secure & Protect Virtual Machines ที่อยู่ใน Hybrid หรือ Multi-Cloud Environment อย่างในกรณีของตัวอย่างที่ผมกำลังอธิบายอยู่นี้ คือ ผมต้องการที่จะทำการ Secure & Protect Virtual Machines ของผมโดยใช้ MDC ครับ และจากความต้องการนี้ส่งผลทำให้ผมจะต้องนำเอาอีกหนึ่ง Service ที่อยู่ใน Microsoft Azure ที่มีชื่อว่า "Azure Arc" เข้ามาทำงานร่วมกับ MDC ครับ เพราะตัวอย่างของผมนี้ Virtual Machines ของผมไม่ได้อยู่ใน Microsoft Azure ครับ อาจจะอยู่ใน On-Premise หรือ On Cloud (Cloud Service Providers อื่นๆ เช่น AWS, GCP, เป็นต้น) โดย Azure Arc จะเป็น Service ที่เข้ามาทำให้การบริหารจัดการ Resources ต่างๆ ที่อยู่ใน Hybrid และ Multi-Cloud Environments ได้สะดวกและง่ายมากขึ้นครับ และในความเป็นจริงแล้วตัวของ Azure Arc นั้นมีความสามารถเยอะครับ ดังรูป

แต่สำหรับบทความนี้ผมจะหยิบเอาความสามารถของ Azure Arc ที่เกี่ยวข้องกับการทำงานร่วมกับ MDC เพื่อทำการ Secure & Protect Virtual Machines ครับ และความสามารถของ Azure Arc นี้มีชื่อว่า "Azure Arc-enabled Servers" ครับ

Azure Arc-enabled Servers คืออะไร?

ตามที่ผมไว้อธิบายไว้ก่อนหน้านี้ว่า Azure Arc-enabled Servers นั้นจะเข้ามาช่วยในเรื่องของการบริหารจัดการตลอดจนการทำงานร่วมกันกับ MDC เพื่อทำการ Secure & Protect Virtual Machines (ที่ไม่ได้อยู่ใน Microsoft Azure) ครับ

สำหรับ Azure Arc (Azure Arc-enables Servers) นั้นจะมีส่วนประกอบที่สำคัญคือ Agent ครับ โดย Agent ของ Azure Arc จะมีชื่อว่า "Connected Machine Agent" โดย Agent ดังกล่าวนี้จะนำไปติดตั้งที่ Virtual Machines ที่ต้องการ และตัวของ Agent จะตัวเองเสมือนกับเป็นสะพานในการเชื่อมต่อกันระหว่างตัวของ Virtual Machines (Resources) กับ Microsoft Azure ครับ นอกจากนี้แล้วในตัวของ Connected Machine Agent ยังประกอบไปด้วย Logical Components ต่างๆ ดังนี้:

- Hybrid Instance Metadata Service (HIMDS) มีหน้าที่จัดการ Connection ระหว่าง Microsoft Azure กับ Azure Identity ของ Connected Machine

- Guest Configuration Agent ทำหน้าที่ในการประเมินว่า Machines ดังกล่าว Comply กับ Policies หรือ Compliances ต่างๆ ที่ได้มีการบังคับใช้หรือไม่

- Extension Agent ทำหน้าที่ในการจัดการ VM Extensions รวมถึง การ Install, Uninstall, และ Upgrade

เมื่อมีการสร้างการเชื่อมต่อระหว่าง Azure Arc กับ Resources นั้น (Virtual Machines ที่อยู่ใน On-Premise หรืออยู่ใน Cloud Service Providers อื่นๆ) ผ่านทาง Connected Machine Agent เรียบร้อยแล้ว ส่งผลทำให้เกิดสิ่งที่เรียกว่า "Arc-enabled" กับ Resouces นั้นๆ 

ทำให้ Resources ที่ว่านี้เปรียบเสมือนกับว่ามันเป็น Resources ที่ถูกสร้างหรือเกิดขึ้นใน Microsoft Azure อย่างที่เราคุ้นเคยครับ ส่งผลทำให้เราสามารถบริหารจัดการ Resources (ผ่าน Arc-enabled) นั้นๆ ได้ (สามารถทำ Access Control, Policy, เป็นต้น) นอกจากนี้แล้วเรายังสามารถนำเอา Services ต่างๆ ใน Microsoft Azure เข้ามาทำงานร่วมกัน ตัวอย่างของ Services ที่ผมนำมาทำงานร่วมกันนั่นก็คือ Microsoft Defender for Cloud หรือ MDC นั่นเองครับ

ความสามารถของ Azure Arc-enables Servers

- สามารถจัดการ Resources (ผ่าน Arc-enabled ที่อธิบายไปก่อนหน้านี้) โดยสามารถจัดเรียงเพื่อทำ Inventory ของ Resources ดังกล่าวนี้เข้ามาอยู่ใน Resource Group และบริหารจัดการผ่านทาง Tools ต่างๆ ของ Microsoft Azure เช่น Azure Portal, Azure Command Line Interface (CLI), Azure PowerShell, และอื่นๆ

- สามารถทำงานร่วมกับ Microsoft Defender for Cloud

- สามารถทำงานร่วมกับ Microsoft Sentinel

- สามารถทำงานร่วมกับ Azure Policy

- อื่นๆ

รายละเอียดเพิ่มเติมสำหรับ MDC ที่จะทำงานร่วมกับ Azure Arc สามารถไปที่ Link ดังกล่าวนี้ได้เลยครับ, Connect on-premises machines - Microsoft Defender for Cloud | Microsoft Learn

และทั้งหมดคือเรื่องราวของตัวอย่างการนำเอา 2 Services ใน Microsoft Azure ซึ่งก็คือ Microsoft Defender for Cloud (MDC) กับ Azure Arc (Azure Arc-enabled Servers) มาทำงานร่วมกันเพื่อดำเนินการ Secure & Protect Virtual Machines ที่อยู่ที่ไหนก็ได้ครับผม.....

มาทำความรู้จักกับ Kusto Query Language (KQL) เพื่อทำ Threat Hunting

      สวัสดีปีใหม่ 2567 ครับทุกท่าน สำหรับบทความนี้ถือว่าเป็นบทความแรกของปี 2567 ครับ โดยจะเป็นบทความที่จะนำเสนอเรื่องราวเกี่ยวกับ Microsoft Sentinel ครับ แต่จะโฟกัสที่เรื่องของการทำ Threat Hunting ใน Microsoft Sentinel และ Azure Log Analytics Workspace ครับ เพราะโดยคอนเซปการทำงานของ Microsoft Sentinel นั้นจะต้องอาศัยการทำงานร่วมกับหลายๆ Services (ใน Microsoft Azure) ตัวอย่างเช่น Azure Log Analytics Workspace ซึ่งถือว่าเป็นมีบทบาทสำคัญกับ Microsoft Sentinel เนื่องจากตัวของ Azure Log Analytics Workspace จะทำหน้าที่ในการเก็บข้อมูลต่างๆ ของ IT Environment นั้น (รายละเอียดเพิ่มเติมเกี่ยวกับ Azure Log Analytics Workspace สามารถย้อนกลับไปอ่านบทความก่อนหน้านี้ของผมได้เลยครับ) เมื่อข้อมูลที่ได้ทำการรวบรวมมาถูกเก็บไว้ใน Azure Log Analytics Workspace เรียบร้อยแล้ว ท่านที่เป็นเกี่ยวข้องกับ Security เช่น Security Operations Analyst หรือ SOC Teams เป็นต้น ก็สามารถทำการค้นหาข้อมูลที่เก็บอยู่ใน Azure Log Analytics Workspace ได้โดยใช้วิธีการเขียน Query ซึ่งใช้ภาษาที่เรียกว่า "Kusto Query Language" หรือ "KQL" ครับ 

โดยการ Query ข้อมูลดังกล่าวนี้มีวัตถุประสงค์คือ ต้องการที่ทำการค้นหาจากข้อมูลที่ได้เก็บรวบรวมมานั้น เพื่อมาวิเคราะห์และตรวจสอบดูว่ามีสิ่งผิดปรกติ,  เหตุการณ์ที่น่าสงสัย, หรือมี Activities ใดๆ ที่ผิดปรกติเกิดขึ้นใน IT Environment นั้นๆ หรือไม่ โดยการดำเนินการดังกล่าวนี้ในมุมของ Cybersecurity จะเรียกว่า "Threat Hunting" ครับ ซึ่งถือว่าเป็น การตรวจสอบและป้องกันแบบเชิงรุก (Proactive) ครับ ลำดับถัดไปผมจะพาทุกท่านมาทำความรู้จักกับ KQL ที่เกี่ยวข้องกับ Microsoft Sentinel เท่านั้นนะครับ เพื่อดำเนินการในเรื่องของการทำ Threat Hunting อย่างที่อธิบายไว้เมื่อซักครู่ครับ

Kusto Query Language (KQL) คืออะไร ?

อย่างที่อธิบายไปก่อนหน้านี้เกี่ยวกับ KQL คือ ภาษาที่เราสามารถเขียนเพื่อทำการดึงและวิเคราะห์ข้อมูล (รองรับข้อมูลขนาดใหญ่)ที่เก็บอยู่ใน Azure Log Analytics Workspace (ที่ได้มีการ Integrate หรือทำงานร่วมกับ Microsoft Sentinel) มาทำการค้นหาหรือวิเคราะห์สำหรับการทำ Threat Hunting  โดย KQL เป็นการเขียน Query แบบที่เรียกว่า "Read-Only Request" คือ เป็นการเขียน Query เพื่อทำการ Explore, Filter, Correlate, และ Summarize ข้อมูลครับ และรูปด้านล่างเป็นการแสดงถึงความสามารถหรือฟีเจอร์หนึ่งใน Azure Log Analytics Workspace ที่ชื่อว่า "Log Analytics Explorer" ดังรูปด้านล่างครับ

เราสามารถใช้ Log Analytics Explorer ในการเขียน KQL Query ได้ครับ สิ่งที่ผมอยากจะอธิบายเพิ่มเติมเกี่ยวกับ Azure Log Analytics Workspace เพิ่มเติม คือ เมื่อทำการรวบรวมข้อมูลต่างๆ มาเก็บไว้ใน Azure Log Analytics Workspace  ตัวของ Azure Log Analytics Workspace จะทำการจัดเก็บข้อมูลที่ได้รวบรวมมานั้นในรูปแบบของ Table ครับ เพราะฉะนั้นมีความเป็นไปได้ที่แต่ละองค์กรที่มีการใช้งาน Microsoft Sentinel และ Azure Log Analytics Workspace จะมี Tables ที่เหมือนแลแตกต่างกันครับ เพราะฉะนั้นเมื่อข้อมูลถูกเก็บมาไว้ที่ Azure Log Analytics Workspace เรียบร้อย หมายความว่าจัดเก็บอยู่ใน Tables ต่างๆ เรียบร้อยแล้ว จากนั้นเราสามารถที่จะเขียน KQL Query เพื่อดึงข้อมูลที่เก็บไว้ใน Tables ต่างๆ ตามความต้องการได้ครับ 

ส่วนประกอบของ KQL Query

จากรูปด้านบนส่วนประกอบของ KQL Query ประกอบไปด้วยส่วนประกอบต่างๆ ดังนี้:

1. Data หรือ Dataset คือ ข้อมูลที่มาจาก Table เดียว (Single Table), จากหลายๆ Tables (Multiple Tables), จาก User Defined Tables (Tables ที่เราสร้างเอง), เป็นต้น

2. Condition คือ การกำหนดเงื่อนไขในการดึงและวิเคราะห์ข้อมูล

3. Evidence หรือ Project คือ การกำหนดข้อมูลใดบ้างที่จะถูกแสดงผล ถ้าไม่กำหนดก็จะแสดงผลทั้งหมด

จาก 3 ส่วนประกอบของ KQL Query ก็จะถูกเชื่อมกันด้วย " | "  เรียกว่า "Pipeline Operators" หมายความว่า Output ที่ได้จากส่วนประกอบหนึ่งจะกลายเป็น Input ของส่วนประกอบถัดไปครับ  

ตัวอย่าง KQL Query แบบง่ายๆ ดังรูปด้านล่าง

SecurityEvent

| where EventID == 4624

SecurityEvent คือ ชื่อของ Table โดยผมต้องการค้นหาข้อมูลคือ EventID หมายเลข 4624 ครับ

หรืออีกหนึ่งตัวอย่าง

SigninLogs | where ResultType == "Failure" 

SigninLogs คือ ชื่อของ Table โดยผมต้องการค้นหาข้อมูลคือ การ Sign-In ที่มีผลลัพธ์เป็น Failure ครับ

โดย KQL Query ข้างต้น เราสามารถเขียนและรัน (Run) ได้ผ่านทาง Log Analytics Explorer โดยตัวของ Log Analytics Explorer เป็นฟีเจอร์หนึ่งที่อยู่ใน Azure Log Analytics Workspace อย่างที่เกริ่นไว้ข้างต้นครับ คราวนี้มาสำรวจดู Log Analytics Explorer กันครับ

1. Action Bar คือ ส่วนที่เราสามารถกำหนด Scope, Run, Save, และอื่นๆ กับ KQL Query 

2. Metadata คือ Tables, Queries (Microsoft Defined Queries and Saved Queries), และอื่นๆ ดังรูปด้านล่าง

3. Query Windows คือ ส่วนที่เราเขียน KQL Queries ดังรูปด้านล่างครับ

4. Result Windows คือ ส่วนที่แสดงผลลัพธ์หรือ Result ของ KQL Query

สิ่งที่เราจะต้องดำเนินการก่อนที่จะทำ Threat Hunting หรือการเขียน KQL Query เพื่อทำการค้นหาและวิเคราะห์ข้อมูลต่างๆ ตามที่ได้อธิบายไว้ในข้างต้น คือ การวางแผนเพื่อดำเนินการ Hunting ครับ ยกตัวอย่างเช่น เราจะต้องมีการวางแผนกำหนดวัตถุประสงค์ของการทำ Threating Hunting ก่อนว่าเราต้องการค้นหาและวิเคราะห์ข้อมูลเพื่ออะไร?, การค้นหาดังกล่าวนี้เกี่ยวข้องกับข้อมูลใดบ้างๆ, และอื่นๆ หลังจากนั้นค่อยมาทำการเขียน KQL Query ครับ โดย Microsoft ได้มีเตรียมข้อมูลและ Resources ต่างๆ ตลอดจนตัวอย่างของ KQL Queries เอาไว้ให้เราพิจารณาเพื่อนำไปประยุกต์ใช้งานครับ ผมขอแนะนำ Link นี้ (Kusto Query in Microsoft Sentinel) ครับ, Kusto Query Language in Microsoft Sentinel | Microsoft Learn

และนี่คือเรื่องราวเบื้องต้นเกี่ยวกับการทำ Threat Hunting ใน Microsoft Sentinel โดยใช้ KQL ครับผม.....