Agentless Machine Scanning ใน Microsoft Defender for Cloud (MDC)

      สวัสดีครับทุกท่านสำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Agentless Machine Scanning ใน Microsoft Defender for Cloud กันครับ ซึ่งถือเป็นความสามารถหรือฟีเจอร์ที่สำคัญในการ Secure และ Protect Workloads (Servers หรือ VMs) ในองค์กรครับ ก่อนที่จะเข้าสู่เรื่องราวของ Agentless Machine Scanning ขออนุญาตอธิบายคร่าวๆ เกี่ยวกับ Microsoft Defender for Cloud (MDC) ซักหน่อยครับ เผื่อว่าผู้อ่านท่านใดอาจจะยังไม่คุ้นเคยกับ Microsoft Defender for Cloud หรือ MDC ครับ

เริ่มจาก Microsoft Defender for Cloud ถือว่าเป็นเซอร์วิสหนึ่งใน Microsoft Azure ครับ และอีกมุมหนึ่งถือว่า Microsoft Defender for Cloud เป็นสมาชิกอยู่ใน Microsoft Defender Family ครับ ซึ่งเป็น Family ที่ถูกออกแบบมาเพื่อทำ Threat Detection และ Protection ให้กับ IT Environments ขององค์กร โดยครอบคลุมท้้ง Hybrid และ Multi-Cloud ครับ โดย Microsoft Defender Family เป็นเพียงแค่ส่วนหนึ่งของ Microsoft Security Ecosystem ครับ เพราะทาง Microsoft ยังมี Security Solutions ต่างๆ อีกเยอะครับ รวมถึงยังมีการนำเอา AI เทคโนโลยีเข้ามาช่วยในเรื่องของ Cybersecurity อีกด้วยครับ รูปด้านล่างเป็น ภาพรวมที่แสดงถึง Microsoft Security Solutions ที่มี ณ ตอนนี้ครับ

สำหรับ Microsoft Defender for Cloud จะให้บริการ Security Services/Solutions หลักๆ ดังนี้:

- Cloud Security Posture Management (CSPM)

- Cloud Workload Protection Platform (CWPP)

- Cloud-Native Application Protection Platform (CNAPP)

และสำหรับบทความนี้เรื่องของ Agentless Machine Scanning ซึ่งเป็นความสามารถหนึ่งของ Microsoft Defender for Cloud จะอยู่ภายใน Security Services/Solutions ที่ชื่อว่า Cloud Workload Protection Platform หรือ CWPP ครับ โดย Agentless Machine Scanning จะเข้ามาช่วยในการ Secure และ Protect Workloads นั่นก็คือ Servers หรือ VMs นั่นเองครับ นั่นหมายความถ้าท่านผู้อ่านต้องการที่จะป้องกัน Servers หรือ VMs ที่อยู่ใน IT Environments ของท่าน สามารถพิจารณนำเอา Microsoft Defender for Cloud ไปประยุกต์ใช้งานได้ครับ

กลับมาที่เรื่องของการ Secure และ Protect Servers หรือ VMs ใน Microsoft Defender for Cloud นั้นจะเกี่ยวข้องกับ CWPP ดังนั้นจะต้องมีการวางแผน, ออกแบบ, เพื่อเตรียมความพร้อมในการ Secure และ Protect Servers หรือ VMs เหล่านั้น โดยการติดตั้ง Agents ไปยัง Servers หรือ VMs ที่ต้องการครับ ในยุคแรกๆ ของ Microsoft Defender for Cloud, ตัวของ Agent ที่ใช้คือ Azure Log Analytics Agent ซึ่งปัจจุบันไม่มีให้ใช้งานแล้วครับ โดยถูกแทนด้วย Agent ตัวต่อมา คือ Azure Monitor Agent หรือเรียกสั้้นๆ ว่า AMA ครับ จากนั้นก็มาถึง Agentless (นั่นก็คือ Agentless Machine Scanning ครับ) ครับ โดยการที่ Microsoft ทำการปรับปรุงและเปลี่ยนแปลงจาก Agent-Based มาเป็น Agentless (Agentless Machine Scanning) นั้นถือว่าเป็นการเปลี่ยนแปลงที่สำคัญในการ Secure และ Protect Workloads ในองค์กรเลยทีเดียวครับ เพราะอย่างที่เราทราบกันโดยปรกติ คือ หากองค์กรมีการนำเอา Security Solutions ใดๆ ก็ตามมาใช้งานในองค์กร ก็จะต้องมีการติดตั้งส่วนประกอบต่างๆ ของ Security Solutions ดังกล่าวรวมถึง Agent ด้วยครับ แต่สำหรับ Microsoft Defender for Cloud ตัวของมันเองไม่มีการติดตั้งใดๆ ที่ IT Environments ของลูกค้า หมายความว่า Microsoft Defender for Cloud ไม่ต้องการ Servers หรือ VMs ใดๆ เพื่อติดตั้งตัวมันเพื่อทำงานครับ เพราะ Microsoft Defender for Cloud รันอยู่ใน Data Centers ของ Microsoft หรือพูดง่ายๆ คือ รันและทำงานอยู่บน Cloud นั่นเองครับ

และในการที่เราต้องการ Secure และ Protect (Servers หรือ VMs) ที่ผมได้อธิบายไปก่อนหน้านี้ก็เช่นกันครับ ณ ตอนนี้เราไม่ต้องติดตั้ง Agent ใดๆ ของ Microsoft Defender for Cloud เหมือนกับแต่ก่อนครับ แต่ต้องบอกทุกท่านไว้ก่อนว่า Agentless เป็นเพียง Option หนึ่งที่เราสามารถนำไปพิจารณาครับ นอกเหนือจาก Agent-Based แบบก่อนหน้านี้ครับ ข้อดีของ Agentless คือ ไม่มีการติดตั้งสิ่งใดๆ ไปยัง Servers หรือ VMs ที่จะให้ Microsoft Defender for Cloud ไปทำการ Secure และ Protect ครับ ดังนั้นจะไม่มีการไปกระทบกับการทำงานของ Servers หรือ VMs นั้น ไม่ว่าจะเป็นเรื่องของ Performance และอื่นๆ ครับ เพราะเป็นสิ่งที่องค์กรกังวลครับ

หลังจากทำการเปิดใช้งานหรือ Activate ตัว Agentless Machine Scanning แล้ว มันจะเริ่มทำงานโดยทำการเก็บรวบรวมข้อมูลจาก Servers หรือ VMs มาทำการตรวจสอบและค้นหาเป็นระยะๆ ไม่ใช้แบบ Real-Time ครับ โดยการทำ Read-Only Snapshots ของ Servers หรือ VMs แล้วมาทำรวบรวมข้อมูลต่างๆ เช่น Installed Apps, Configurations, OS Versions, และอื่นๆ  ดังนี้:

- ทำการ Scans Endpoint Detection and Response (EDR) Settings เพื่อทำการประเมินค่า Settings ของ EDR ที่รันอยู่ใน Servers หรือ VMs ว่าถูกต้องหรือไม่ ถ้า Servers หรือ VMs ดังกล่าวทำงานร่วมกับหรือ Integrate กับ Microsoft Defender for Endpoint หรือ MDE

- ทำการ Scans Software Inventory และทำงานหรือ Integrate กับ Microsoft Defender Vulnerability Management หรือ MDVM

- ทำการ Scans Vulnerabilities เพื่อประเมินช่องโหว่ ด้วย Microsoft Defender Vulnerability Management หรือ MDVM

- ทำการ Scans Malware โดยทำงานร่วมกับ Microsoft Defender Antivirus

- อื่นๆ 

ข้อดีของ Agentless Machine Scanning 

- Zero Performance Impact เพราะไม่มีการติดต้ั้งใดๆ ไปยัง Servers หรือ VMs

- Simplified Deployment เพราะไม่มีการดาวน์โหลดและติดต้้งส่วนประกอบหรือสิ่งใดๆ ที่ Servers หรือ VMs ที่ต้องการ Secure และ Protect

- อื่นๆ

สำหรับการเรียกใช้งาน Agentless Machine Scanning นั้นจะขึ้นอยู่กับ Defender Plan ในส่วนของ Cloud Workload Protection Platform (CWPP) ในส่วนของ Workloads ที่เป็น Servers โดยจะมี 2 Plans ให้เลือกพิจารณา คือ Plan 1 และ Plan 2 ครับ ความแตกต่างของแต่ละ Plan ในการ Secure และ Protect Servers หรือ VMs คือ ฟีเจอร์และราคาครับ สำหรับ Agentless Machine Scanning เป็นฟีเอจร์หรือความสามารถที่อยู่ใน Plan 2 ครับ ดังรูปด้านล่างครับ

สำหรับการ Secure และ Protect Servers หรือ VMs ในองค์กรด้วย Microsoft Defender for Cloud นั้นในความเป็นจริงแล้วยังมีอีกหลายสิ่งที่จะต้องพิจารณาครับ นอกเหนือจาก Agentless Machine Scanning แล้ว ยังมี Microsoft Defender for Endpoint หรือ MDE ด้วยครับ เพราะ ณ ตอนนี้ Microsoft Defender for Cloud และ Microsoft Defender for Endpoint ทั้ง 2 Services นี้ Integrate ทำงานร่วมกันในการ Secure และ Protect Servers หรือ VMs ครับ และ Best Practices ในการดำเนินการ Secure และ Protect Servers หรือ VMs ควรพิจารณานำเอา Agentless Machine Scanning และ MDE Agent (MDE Sensor) ตลอดจน Services หรือส่วนประกอบอื่นๆ มาใช้งานร่วมกันครับ

รายละเอียเพิ่มเติมเกี่ยวกับ Agentless Machine Scanning สามารถไปที่ Link นี้ได้เลยครับ, Agentless machine scanning in Microsoft Defender for Cloud - Microsoft Defender for Cloud | Microsoft Learn

รายละเอียดเกี่ยวกับ Microsoft Defender for Cloud สามารถไปที่ Link นี้ได้เลยครับ, Microsoft Defender for Cloud Overview - Microsoft Defender for Cloud | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของ Agentless Machine Scanning ใน Microsoft Defender for Cloud ครับผม.....

Microsoft Cybersecurity ตอนที่ 6 (Security Adoption Framework)

      สวัสดีครับทุกท่าน กลับมาพบกันเช่นเคยครับ สำหรับบทความตอนนี้มีที่มาจากช่วงที่ผ่านมานั้น ผมมีโอกาสไปสอนและบรรยายเกี่ยวกับ Microsoft Cybersecurity Architect ให้กับลูกค้า ประกอบก่อนหน้านี้ผมเคยเขียนบทความเกี่ยวกับ Microsoft Cybersecurity ไปหลายตอน เพื่อแนะนำให้ทุกท่านได้รู้จักและทำความเข้าใจกับ Frameworks และ Models ต่างๆ ที่เกี่ยวข้องกับเรื่องของ Security เพื่อสามารถนำไปประยุกต์ใช้งานในการวางแผนออกแบบ Cybersecurity Architecture เพื่อทำการป้องกัน IT Environments (ครอบคลุมทั้ง Hybrid และ Multi-Cloud) ขององค์กร ไม่ว่าจะเป็น Cyber Kill Chain, Zero Trust, Defense In-Depth, และอื่นๆ ท่านใดที่ยังไม่รู้จักสามารถย้อนไปอ่านบทความของผมได้เลยครับ

สำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Framework หนึ่ง ซึ่งถูกออกแบบมาให้ใช้งานร่วมกับ Microsoft Zero Trust Model, Cloud Adoption Framework (CAF) ใน Secure Phase, Microsoft Cybersecurity Reference Architectures (MCRA) รวมถึง CIA Triad ครับ โดย Framework นี้มีชื่อว่า "Security Adoption Framework" หรือเรียกย่อๆ ว่า "SAF" ครับ

*Microsoft Zero Trust Model ถือว่าเป็นหัวใจและเป็นสิ่งสำคัญสำหรับการวางแผนและออกแบบ Cybersecurity Architecture และยังถือว่าเป็นหัวใจของ MCRA อีกด้วยครับ รายละเอียดเพิ่มเติมสามารถย้อนไปอ่านบทความของผมก่อนหน้านี้ได้ครับ

*CIA Triad คือ สิ่งสำคัญหรือเป็นพื้นฐานสำคัญสำหรับ Cybersecurity เมื่อ Security Architect จะทำการวางแผน, ออกแบบ, และทำการ Implement Security Solutions ต่างๆ เพื่อทำการ Secure & Protect IT Environments ขององค์กร โดย CIA Triad มีกฎหลัก 3 ข้อ คือ Confidentiality, Integrity, และ Availability ครับ

Security Adoption Framework (SAF) คืออะไร?

เป็น Framework ที่ถูกออกแบบมาเพื่อช่วยองค์กรในการนำเอา Security Best Practices ต่างๆ มาประยุกต์ใช้งานในองค์กรตามที่องค์กรต้องการ โดย SAF เตรียมแนวทางในการนำเอา Security Best Practices ดังกล่าวเข้ามาประยุกต์ใช้งานในองค์กร โดยมี Stages ดังนี้:

Stage 1: Assess คือ Stage ที่เริ่มด้วยการทำการประเมิน Security Posture ณ ปัจจุบันขององค์กรว่าเป็นอย่างไร เพื่อ Identify หรือกำหนด Gaps หรือ Risks ที่เกี่ยวข้องและทำการจัดลำดับ (Prioritize) ที่จำเป็นต่อการปรับปรุงเพื่อทำให้ Security Posture ขององค์กรมีความแข็งแรงและปลอดภัยมากขึ้น

*Security Posture คือ ภาพรวมของ Security Status ของ IT Assets/Services ที่อยู่ใน IT Environments ขององค์กร

Stage 2: Plan: คือ Stage ที่นำเอาผลลัพธ์ที่ได้จากวิเคราะห์และประเมิน Security Posture ณ ปัจจุบันขององค์กรจาก Stage 1 มาทำการพัฒนาหรือ Develop แผน (Plan) ในการปรับปรุง Security Posture ขององค์กร โดยแนวทางดังกล่าวจะประกอบไปด้วย Outline และ Actions ตามการจัดลำดับความสำคัญและมีการนำเอา Best Practices ต่างๆ มาช่วยในการพิจารณา

Stage 3: Implement คือ Stage ที่นำเอา Plan ใน Stage ก่อนหน้านี้มาทำการปรับปรุงเรื่องความปลอดภัยตามที่วางแผนและกำหนดไว้ โดยใน Stage นี้ คือ การนำเอา Microsoft Security Solutions ต่างๆ เข้าช่วยในการป้องกัน

Stage 4: Manage คือ Stage ที่จะต้องวางแผนเพื่อดำเนินการตรวจสอบค้นหาและจัดการ Security ใน IT Environments ขององค์กรอย่างต่อเนื่อง อีกทั้งยังสามารถปรับหรือเพิ่มเติมการค้นหาและป้องกันเมื่อมีภัยคุกคามใหม่เกิดขึ้น เพื่อช่วยลดความเสี่ยงที่องค์กรจะถูกโจมตีจากภัยคุกคาม (Threats) 

และทั้งหมดนี้คือเรื่องราวของ SAF คร่าวๆ ที่อยากให้ทุกท่านได้รู้จักครับผม.....

Protect AI Applications ด้วย Microsoft Defender for Cloud (MDC)

      สวัสดีครับทุกท่า่น กลับมาพบกันอีกเช่นเคยครับ และสำหรับบทความนี้ผมจะอัพเดทความสามารถใหม่ๆ ที่ถูกเพิ่มเติมเข้ามาใน Microsoft Defender for Cloud (MDC) ครับ โดยความสามารถดังกล่าวนี้จะเป็นการขยายการป้องกันครอบคลุมไปที่ AI Applications ครับ ที่มาที่ไปมาจากในช่วงที่ผ่านมาอย่างที่ทุกท่านทราบกันดีครับว่า AI และ ML เทคโนโลยีถูกนำเข้ามาประยุกตใช้งานในองค์กร โดยการนำเอาเทคโนโลยีดังกล่าวนี้มาประยุกต์ใช้งานก็มีหลากหลายมุมหรือหลาย Scenarios ครับ ทั้งนี้ขึ้นอยู่กับความต้องการของแต่ละองค์กรครับ และในบทความนี้ก็เป็น Scenario หนึ่งที่มีการนำเอา AI และ ML เทคโนโลยีเข้ามาทำงานร่วมกับ Applications ต่างๆ ที่องค์กรได้พัฒนาขึ้นมาใช้งาน เพื่อเพิ่มขีดความสามารถการทำงานของ Applications เหล่านั้นและแน่นอนว่าเพื่อรองรับกับความต้องการของธุรกิจครับ

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

ดังนั้นการที่องค์กรนำเอา AI เข้ามาทำงานร่วมกับ Applications ก็อาจจจะก่อให้เกิดความเสี่ยง เนื่องจาก Attackers จะอาศัยช่องโหว่และเทคนิคต่างๆ จากการที่องค์กรนำเอา AI เทคโนโลยีเข้ามาทำงานร่วมกับ Applications ครับ รูปด้านล่าง คือ Attack Surfaces หรือช่องทางใหม่ๆ ที่ก่อให้เกิดความเสี่ยงสำหรับการนำเอา AI เทคโนโลยีเข้ามาประยุกต์ใช้งานในองค์กร

ดังนั้นองค์กรจะต้องทำการวางแผนและเตรียมความพร้อมในการป้องกันภัยคุกคามตลอดจนความเสี่ยงต่างๆ ที่อาจจะเกิดขึ้นจากการที่องค์กรมีการนำเอา AI เทคโนโลยีเข้ามาประยุกต์ใช้งาน และจากประเด็นดังกล่าวนี้เอง ทำให้ Microsoft ได้เพิ่มหรือขยายความสามารถในการทำ Threat Detection และ Protection ของ Microsoft Defender for Cloud (MDC) ให้ครอบคลุมถึง AI Applications ครับ

สำหรับท่านที่ยังไม่รู้จัก Microsoft Defender for Cloud (MDC) ผมขออธิบายคร่าวๆ นะครับ ถ้าท่านใดสนใจและอยากรู้จัก MDC สามารถย้อนกลับไปอ่านบทความของผมได้ครับ สำหรับ Microsoft Defender for Cloud หรือ MDC นั้น เป็น Service นึงใน Microsoft Azure ครับ นอกจากนี้แล้ว MDC ยังเป็นสมาชิกของ Microsoft Defender Family (เป็น Family ที่ Microsoft เตรียมไว้สำหรับองค์กรที่ต้องการ Security Solutions เพื่อทำการ Secure และ Protect IT Environment ขององค์กร โดยครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments) 

ในความเป็นจริงแล้วทาง Microsoft ยังมี Security Solutions ต่างๆ เตรียมไว้สำหรับองค์กรที่ต้องการจะวางแผน, ออกแบบ, และดำเนินการในการ Secure และ Protect IT Environments (ครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments) รูปด้านล่างจะเป็น Microsoft Security Solutions ในการ Secure และ Protect AI Workloads ในองค์กรครับ

สำหรับ Microsoft Defender for Cloud ให้บริการ Security Solutions หลักๆ อยู่ 3 Solutions  คือ

1. Cloud Security Posture Management (CSPM)

2. Cloud Workload Protection Platform (CWPP)

3. Cloud-Native Application Protection Platform (CNAPP)

สำหรับความสามารถที่ถูกเพิ่มเติมตามที่เกริ่นไว้ข้างต้น คือ ในส่วนของ CSPM (Cloud Security Posture Management) จะเพิ่มการทำ Security Posture Management ที่เกี่ยวกับ AI  ซึ่งจะทำให้ SOC/Security Teams สามารถเห็นและจัดการ AI Infrastructure (SDKs, Plugins, ตลอดจน AI Services ที่เกี่ยวข้อง เช่น Azure OpenAI Service, Azure Machine Learning, Amazon Bedrock, เป็นต้น) ในการ Identify ความเสี่ยง, Potential Attack Vectors, รวมถึง Best Practices ที่เกี่ยวข้องกับ AI Infrastructure เพื่อช่วยในองค์กรในการค้นหาและป้องกัน

ต่อมาคือในส่วนของ CWPP (Cloud Workload Protection Platform), Microsoft Defender for Cloud จะทำหน้าที่เป็น "Prompt Guard" ระหว่าง Prompts ของผู้ใช้งาน กับ AI ในกรณีที่ผู้ใช้งานมีการส่ง Prompt ไปที่ AI Services (Azure OpenAI, Azure Foundry, และอื่นๆ) Microsoft Defender for Cloud จะทำการตรวจเช็ค Prompt ดังกล่าวนี้ว่ามีความเสี่ยงที่จะเป็น Attacks หรือไม่ ตัวอย่างของ Attacks ที่จะทำถูกตรวจเช็ค เช่น Jailbreak (Prompt Injection), Data Poisoning, Data Leakage, Credential Theft, เป็นต้น

รายละเอียดเพิ่มเติมเกี่ยวกับ Microsoft Defender for Cloud (MDC) ในการ Protect AI Workloads สามารถไปที่ Link นี้ได้เลยครับ, Enable threat protection for AI services - Microsoft Defender for Cloud | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของความสามารถใหม่ใน Microsoft Defender for Cloud ที่จะเข้ามาช่วยปัองกัน AI Workloads หรือ Applications ครับผม.....

รู้จักกับ Microsoft Sentinel Data Lake ตอนที่ 2

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะเป็นเรื่องราวต่อเนื่องจากบทความก่อนหน้านี้ที่ผมได้เกริ่นนำและอธิบายเกี่ยวกับ Microsoft Sentinel โดยเฉพาะเรื่องของการรวบรวมและการจัดเก็บ Logs ตลอดจนข้อมูลต่างๆ ของ Microsoft Sentinel ซึ่งจะมี Service หนึ่งใน Microsoft Azure เข้ามาเกี่ยวข้องและทำงานร่วมกับ Microsoft Sentinel โดย Service ดังกล่าวนั้นก็คือ Azure Log Analytics Workspace นั่นเองครับ (รายละเอียดลองย้อนกลับไปอ่านบทความตอนที่ 1 ตลอดจนบทความอื่นๆ ของผมที่เกี่ยวข้องกับ Microsoft Sentinel และ Azure Log Analytics Workspace กันดูครับ) และเพื่อไม่ให้เป็นการเสียเวลาเรามาทำความรู้จักกับพระเอกของบทความกันเลยครับ นั่นก็คือ "Microsoft Sentinel Data Lake" นั่นเองครับ

Microsoft Sentinel Data Lake (Preview) คืออะไร?

คือ Fully-Managed & Cloud-Native Data Lake ที่ถูุกออกแบบมาเพื่อช่วย SOC/Security Teams ในการบริหารจัดการสำหรับการจัดก็บข้อมูลต่างๆ (เช่น Logs) สำหรับการทำ Security Operations ผ่านทางสิ่งที่เรียกว่า "Microsoft Sentinel Data Lake Tier" 

*คำว่า "Tier" จะมีความเกี่ยวข้องกับ Azure Log Analytics Workspace ในการ Optimize การจัดเก็บข้อมูล (Data Retention) ที่ได้รวบรวมมารวมถึงค่าใช้จ่ายครับ ซึ่งก่อนหน้าจะมีอยู่ด้วยกัน 3 Tiers และมีอีก 1 Tier มาเพิ่ม คือ

1. Analytics Tier

2. Basic Tier

3. Auxiliary Tier 

4. Microsoft Sentinel Data Lake Tier (New) !!!!!

โดยข้อมูลดังกล่าวนี้จะถูกรวบรวมมาจาก IT Environments (ครอบคลุมทั้ง Hybrid และ Multi-Cloud) ขององค์กร จากนั้น SOC/Security Teams ก็จะทำการค้นหา (Detect) สิ่งปรกติ, เหตุการณ์ที่น่าสงสัย, และอื่นๆ (ผ่านทาง Microsoft Sentinel) และแน่นอนว่าข้อมูลที่ถูกรวบรวมมานี้จะต้องมีการวางแผน, ออกแบบ, และเตรียมการก่อนเพราะถ้าปราศจากสิ่งต่างๆ นี้จะส่งผลทำให้ข้อมูลที่รวบรวมมานั้นอาจจะไม่ตรงกับความต้องการสำหรับการทำ Security Operations รวมถึงส่งผลทำให้เกิดค่าใช้จ่ายที่สูงตามมาอีกด้วยครับ

และสำหรับท่านใดที่คุ้นเคยและใช้งาน Microsoft Sentinel อยู่ก็จะทราบว่าค่าใช้จ่ายหลักๆ ของ Microsoft Sentinel ส่วนหนึ่งเลยจะมาจากค่าใช้จ่ายในการรวบรวมข้อมูล (Data Collection) และเก็บรักษาข้อมูล (Data Retention) ที่ถูกรวบรวมมาจาก IT Assets ต่างๆ เช่น Identity, Endpoint, Network, และอื่นๆ (ซึ่งอยู่ภายใน IT Environments ขององค์กร) ซึ่งจะนำมาถูกเก็บเอาไว้ใน Azure Log Analytics Workspace ครับ และราคา (Pricing) ของ Azure Log Analytics Workspace นั้นโดยปรกติก็จะคิดจากปริมาณข้อมูลที่เก็บครับ โดยรูปแบบการคิดราคาก็มีให้เลือกหลายแบบ เช่น Pay-as-you-Go, Commitment, เป็นต้นครับ 

ดังนั้นสิ่งหนึ่งที่เป็น Best Practices คือ การวางแผนและออกแบบเรื่องของการรวบรวมและจัดเก็บข้อมูลต่างๆ ตามที่อธิบายข้างต้นมาที่จะนำมาเก็บไว้ใน Azure Log Analytics Workspace ว่าจะมีข้อมูลอะไรบ้าง เพราะส่งผลต่อเรื่องของค่าใช้จ่ายตามที่ได้อธิบายไปก่อนหน้านี้ครับ ซึ่งตรงจุดนี้เอง SOC/Security Teams จะต้องพิจารณาให้ดีว่าจะรวบรวมข้อมูลอะไรบ้าง และอาจจะมีความเป็นไปได้ว่าอาจจะต้อง Trade Off เรื่องของข้อมูลที่จะรวบรวมมาเก็บเพื่อดำเนินการเรื่องของ Security Operations กับค่าใช้จ่ายให้สมดุลย์กัน โดย SOC/Security Teams อาจจะต้องยอดปรับลดข้อมูลที่ต้องการเพื่อทำให้ค่าใช้จ่ายไม่สูงเกินไป แต่อาจจะส่งผลทำให้เกิดความเสี่ยงตามมา ซึ่งประเด็นดังกล่าวนี้จึงเป็นจุดที่ "Microsoft Sentinel Data Lake" เข้ามาช่วยครับ

โดย Microsoft Sentinel Data Lake จะมาพร้อมกับ Tier ใหม่ที่รองรับการจัดเก็บข้อมูลปริมาณมากๆ เยอะๆ (ภายใต้คอนเซปของ Data Lake Service) ได้อย่างง่ายดายอีกทั้งยังมีค่าใช้จ่ายที่ถูกกว่าครับ อีกทั้งยังสามารถทำการบริหารจัดการผ่านทาง Microsoft Defender XDR Portal (ซึ่งถือว่าเป็น Portal ที่มีความสามารถมากขึ้นเรื่อยๆ ในการบริหารจัดการและการทำ Security Operations โดยที่ผ่านมา Microsoft ได้มีการ Integrate นำเอา Microsoft Sentinel เข้ามาอยู่ใน Portal ดังกล่าวนี้ ภายใต้คอนเซปที่เรียกว่า "Unified Security Operations Platform") ครับ และในแง่ของการวิเคราะห์ (Analyst) ข้อมูลที่ได้ทำการรวบรวมมานั้น SOC/Security Teams สามารถทำการย้ายข้อมูลระหว่าง Analytics Tier กับ Microsoft Sentinel Data Lake Tier ได้เลย ส่งผลทำให้เกิดความยืดหยุ่นในการค้นหาข้อมูลเพื่อดำเนินการในกระบวนการต่างๆ ของ Security Operations เช่น Detection เป็นต้น

สำหรับการติดตั้งใช้งาน Microsoft Sentinel Data Lake นั้นไม่ได้ยุ่งยากหรือซับซ้อนเลยครับ เราเพียงแค่ทำการ Enable หรือ Onboard  (ใช้เวลาราวๆ 60 นาทีสำหรับการเตรียมตลอดจนเชื่อมต่อเข้ากับ Microsoft Entra Tenant) จากนั้นทำการบริหารจัดการผ่านทาง Portal (Microsoft Defender XDR Portal) โดยไม่ต้องมีการ Configure หรือ Migrate ข้อมูลใดๆ ครับ โดยเมื่อเราทำการ Enable หรือ Onboard Microsoft Sentinel Data Lake เรียบร้อยแล้ว Microsoft Sentinel Data Lake ก็พร้อมทำงานทันที ยกตัวอย่างเช่น ในกรณีที่องค์กรหรือเรามีการกำหนดและใช้งาน Auxiliary Tier (ใน Azure Log Analytics Workspace ที่ใช้งานกับ Microsoft Sentinel) ไว้ใช้งานก่อนหน้านี้ทุกอย่าง จะถูกโยกหรือ Switch มาที่ Microsoft Sentinel Data Lake (Microsoft Sentinel Data Lake Tier) แทนครับ นั่นหมายความว่า Microsoft Sentinel Data Lake Tier จะเข้ามาดำเนินการแทน Auxiliary Tier ครับ แต่ยังคงทำงานร่วมกับ Analytics Tier อยู่นะครับ เพราะเนื่องจาก Analytics Tier ถูกออกแบบมาสำหรับการทำ Analytics Rules, Workbooks, และอื่นๆ ใน Microsoft Sentinel โดยปรกติจะเก็บข้อมูลไว้นาน 30 วัน และเก็บได้นานสุด 2 ปี แต่ถ้าเราใช้ Azure Log Analytics Workspace ร่วมกับ Microsoft Sentinel จะทำให้เราสามารถเก็บข้อมูลได้นานถึง 90 วัน (Analytics Tier) ครับ ส่วน Microsoft Sentinel Data Lake จะเป็น Tier ที่ไม่ได้ถูกออกแบบมาเพื่อทำ Real-Time Analytics (เหมือนกับ Analytics Tier) แต่เน้นไปที่การเก็บข้อมูลที่เยอะๆและต้องการเก็บไว้นานๆ (Long-Term Storage) ครับ โดยเมื่อมีการรวบรวมข้อมูลต่างๆ ผ่านทาง Microsoft Sentinel Data Connectors ข้อมูลก็จะถูกส่งมาทั้ง Analytics Tier และ Microsoft Sentinel Data Lake Tier (พร้อมกับ Data Retention ของ Analytics Tier) โดยอัตโนมัติ และถ้าเราไม่ปรับ Data Retention ของ Microsoft Sentinel Data Lake ก็จะมีการคิดค่าใช้จ่าย รวมถึงการใช้ KOL Jobs เพื่อทำการย้ายข้อมูลที่ต้องการและทำการ Promote ผลลัพธ์ไปยัง Analytics Tier, และอื่นๆ  

รายละเอียดเพิ่มเติมเกี่ยวกับ Microsoft Sentinel Data Lake สามารถไปที่ Link นี้ได้เลยครับ, Microsoft Sentinel data lake overview (preview) - Microsoft Security | Microsoft Learn

มาถึงตรงนี้แล้วผมเชื่อว่าท่านผู้อ่านทุกท่านพอจะเห็นภาพและเข้าใจเบื้องต้นว่า Microsoft Sentinel Data Lake คืออะไรและเข้ามาช่วยในเรื่องอะไรนะครับ โดยส่วนตัวผมคิดว่า Microsoft Sentinel Data Lake จะเข้ามาช่วยได้แน่ๆ ในเรื่องของบริหารจัดการและจัดเก็บข้อมูล รวมถึงการค้นหาข้อมูล ที่มีความสะดวกและมีค่าใช้จ่ายที่ไม่แพงครับ แต่สิ่งที่ผมอยากจะเน้นย้ำทุกท่านสำหรับเรื่องของการรวบรวมและจัดเก็บข้อมูลที่จะนำเอามาใช้ใน Microsoft Sentinel เพื่อทำ Security Operations นั้น เรื่องสำคัญยังคงอยู่ที่การวางแผนและออกแบบครับ ถ้าปราศจากสิ่งนี้ต่อให้มี Microsoft Sentinel Data Lake ก็อาจจะไม่ได้เข้ามาช่วยหรือตอบโจทย์ตาม Requirements ของ SOC/Security Teams มาซักเท่าไหร่ครับ  และทั้งหมดนี้คือ เรื่องราวของ Microsoft Sentinel Data Lake ครับผม.....

รู้จักกับ Microsoft Sentinel Data Lake ตอนที่ 1

      สวัสดีครับทุกท่านสำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับความสามารถใหม่ใน Microsoft Sentinel ที่จะเข้ามาช่วยในการเรื่องของการบริหารจัดการข้อมูล (Logs และ Data อื่นๆ ที่เกี่ยวข้องกับ Security Operations) ที่ SOC หรือ Security Teams จะนำไปใช้ในการวิเคราะห์, ค้นหา, และอื่นๆ ได้อย่างมีประสิทธิภาพมากขึ้น ตลอดจนค่าใช้จ่ายลดลงครับ และสำหรับท่านผู้อ่านท่านใดที่คุ้นเคยกับเรื่องของ "Security Operations" ซึ่งถือว่าเป็น กระบวนหลักที่สำคัญในเรื่องของการบริหารจัดการในเรื่องของความปลอดภัยในระบบ IT ขององค์กรซึ่งครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments 

และในกระบวนของ Security Operations นั้นยังประกอบไปด้วย Processes หรือกระบวนการย่อยๆ ต่างๆ เช่น Protection, Detection, Investigation, และอื่นๆ ซึ่ง SOC หรือ Security Teams จะต้องทำการ Operates โดยอาศัยหรือใช้เครื่องมือตลอดจนโซลูชั่นต่างๆ เข้ามาทำการ Operate กระบวนดังกล่าวนี้ และแน่นอนว่าทาง Microsoft ได้เตรียมเครื่องมือตลอดจนโซลูชั่นต่างๆ (ดังรูปด้านล่าง) ที่จะเข้ามาช่วยในเรื่องดังกล่าวนี้ครับ ทั้งนี้ขึ้นอยู่กับความต้องการขององค์กรเป็นหลัก 

และหนึ่งในโซลูชั่นดังกล่าวนี้คือ "Microsoft Sentinel" ซึ่งถือว่าเป็น Service หนึ่งใน Microsoft Azure และอีกมุมหนึ่ง Microsoft Sentinel ถือว่าเป็นส่วนประกอบหนึ่งที่สำคัญของการทำ Security Operations ครับ

 

โดยตัวของ Microsoft Sentinel เป็น Cloud-Native Service ที่ให้บริการ 2 โซลูชั่นหลักๆ คือ:

1. Security Information Event Management (SIEM)

2. Security Orchestration, Automation, and Response (SOAR)

นอกจากนี้แล้วตัวของ Microsoft Sentinel ยังมี Phases การทำงานหลัก 4 Phases คือ:

1. Collect

2. Detect

3. Investigate

4. Response

และก่อนที่จะดำเนินการใช้งาน Microsoft Sentinel, สิ่งที่มีความสำคัญมากที่สุดคือ "การ Planning & Designing" ครับ เพราะเป็นสิ่งที่ทำให้เราได้ทำความเข้าใจ, เตรียมความพร้อม, ออกแบบ, และอื่นๆ ก่อนที่จะใช้งานครับ จากประสบการณ์ของผมที่เคยมีโอกาสทั้งสอน, ให้คำปรึกษา, ตลอดจน Implement นั้น พบว่าหลายๆ องค์กรยังขาดความรู้และความเข้าใจคอนเซปตลอดจนรายละเอียดที่สำคัญๆ ของ Microsoft Sentinel และเริ่มด้วยการ Implement ทันที โดยปราศจากการ Planning & Designing ที่ดีและพร้อม จะก่อให้เกิดปัญหาหลายอย่างๆ เช่น เรื่องของค่าใช้จ่าย, ความคาดหวังว่า Microsoft Sentinel จะเข้ามาช่วยป้องกันระบบ IT Environment ขององค์กรจากภัยคุกคาม, และอื่นๆ โดยปัญหาที่ผมยกตัวอย่างนี้ต้นตอมาจากขาดความเข้าใจตลอดจนการวางแผนและออกแบบที่ดีและพร้อมกับ สำหรับท่านใดที่เพิ่งศึกษาเรื่องราวของ Microsoft Sentinel สามารถไปค้นบทความเก่าๆ ของผมได้ครับ ผมเคยเขียนบทความหลายบทความที่เกี่ยวข้องกับ Microsoft Sentinel หรือไปศึกษาจาก Microsoft Documentations ครับ

สำหรับท่านใดที่รู้จักตลอดจนเคยใช้งาน Microsoft Sentinel ก็จะทราบว่าตัวของ Microsoft Sentinel นั้นจะต้องอาศัยการทำงานร่วมกับ Services อื่นๆ ใน Microsoft Azure หลายตัว และหนึ่งในนั้น คือ "Azure Log Analytics Workspace" ครับ 

ซึ่งถือมีความสำคัญกับ Microsoft Sentinel มากครับ เพราะ Azure Log Analytics Workspace จะเป็น Service ที่ให้บริการ "Data Repository" หรือที่ที่สำหรับให้เราทำการเก็บข้อมูลต่างๆ (Collected Data) โดยข้อมูลที่ว่านี้จะเป็นข้อมูลที่เกี่ยวข้องและนำมาใช้กับเรื่องของ Security Operations เท่านั้นนะครับ ตัวอย่างเช่น Log, Metric Data เป็นต้นครับ โดยข้อมูลที่ว่านี้จะต้องนำการรวบรวม (Collect) มาจาก IT Assets ต่างๆ ที่อยู่ในองค์กร เช่น Identity, Endpoint, Network, เป็นต้น โดยจะรวบรวมข้อมูลอะไรมาบ้างนั้นขึ้นอยู่กับการ Planning & Designing ตามที่ได้เกริ่นไว้ข้างต้นครับ โดยข้อมูลที่รวบรวมก็จะถูกเก็บเข้าไปยัง Azure Log Analytics Workspace ครับ โดยข้อมูลที่เก็บอยู่ในนั้นจะถูกจัดเก็บในรูปแบบของ Table ครับ และเราสามารถทำการค้นหาข้อมูลดังกล่าวที่ถูกเก็บอยู่ Azure Log Analytics Workspace ได้โดยใช้ Query Language ที่ชื่อว่า "Kusto Query Language" หรือเรียกสั้นๆ ว่า "KQL" ครับ และต้องบอกว่าปัญหาหนึ่งที่ผมได้เกริ่นไว้ข้างต้นว่า ถ้าเราไม่ได้มีการ Planning & Designing สำหรับการนำเอา Microsoft Sentinel เป็นอย่างดี ส่งผลทำให้ค่าใช้จ่ายของ Microsoft Sentinel สูง เพราะต้นตอหรือสาเหตุหลักมาจาก ค่าใช้จ่ายของ Azure Log Analytics Workspace ที่แหละครับ ดังนั้นสิ่งที่พิจารณาหลักๆ ก่อนที่เราจะดำเนินการ Implement Microsoft Sentinel คือ:

- ทำการวางแผนและออกแบบ ตลอดจนจำนวนของ Azure Log Analytics Workspaces ว่าจะออกแบบอย่างไรและจะมีกี่ Workspaces

- ระยะเวลาที่ต้องการจัดเก็บข้อมูลใน Azure Log Analytics Workspace คือเท่าไร  (Data Retention)

- ข้อมูลที่จะถูกรวบรวมมาจาก IT Environment ครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments มีอะไรบ้าง

- อื่นๆ

และจากสิ่งต่างๆ ที่จะต้องพิจารณาข้างต้นนั้นจะมีผลโดยตรงกับค่าใช้จ่ายของ Microsoft Sentinel (จริงๆ คือ ค่าใช้จ่ายของ Azure Log Analytics Workspace) เพราะเราจะต้องทำความเข้าใจและเตรียมความพร้อม ตลอดจนการ Planning & Designing ให้ดีและครอบคลุม ตลอดจนรองรับกับความต้องการครับ และจากสิ่งต่างๆ ที่จะต้องพิจารณาหลักที่ผมได้อธิบายไว้ก่อนหน้านี้ จึงเป็นที่มาของความสามารถใหม่ใน Microsoft Sentinel ครับ นั่นก็คือ "Microsoft Sentinel Data Lake" นั่นเองครับ และจากสิ่งที่ผมได้อธิบายเรื่องราวและรายละเอียดข้างต้นเพื่อให้ทุกท่านได้ทำความเข้าใจก่อนว่า Microsoft Sentinel Data Lake จะเข้ามาช่วย Microsoft Sentinel ตรงไหนและอย่างไรครับ หรือจะบอกว่าบทความนี้เป็นบทความที่เกริ่นนำและเล่าเรื่องราวที่มาที่ไปก่อนครับ จากนั้นเราจะมาทำความรู้จักกับ Microsoft Sentinel Data Lake กันในบทความต่อไปซึ่งเป็นตอนที่ 2 ครับ อย่าลืมติดตามกันนะครับ.....

ทำความรู้จักกับ Microsoft Entra Agent ID

      สวัสดีครับทุกท่าน เรากลับมาพบกันเหมือนเช่นเคยครับและสำหรับในบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับฟีเจอร์ใหม่ใน Microsoft Entra ID ที่มีชื่อว่า "Microsoft Entra Agent ID" ครับ และก่อนจะพาทุกท่านไปทำความรู้จักกับ Micrsoft Entra Agent ID ขออนุญาตเล่าที่มาที่ผ่านไปก่อนนะครับ โดยขอเริ่มจากตัวของ Microsoft Entra ID ก่อนสำหรับ Microsoft Entra ID ถือว่าเป็น Service และส่วนประกอบที่สำคัญสำหรับสำหรับเรื่องของความปลอดภัยโดยเฉพาะบน Cloud โดยตัวของ Microsoft Entra ID นั้นให้บริการในเรื่องของการบริหารจัดการ Identity หรือที่เรียกกันว่า "Identity and Access Management" หรือ "IAM" ครับ โดย Microsoft ได้ใส่ Microsoft Entra ID เข้าไปใน Cloud Services ต่างๆ ของ Microsoft เช่น Microsoft Azure, Microsoft 365, เป็นต้น โดยเริ่มจากความสามารถพื้นฐานก่อนเลยนั่นก็คือ

1. Authentication

2. Authorization

3. Auditing

4. Administration *ข้อนี้ถูกเพิ่มเติมเข้ามาในกรณีที่เป็น IAM ของ Microsoft (Microsoft Entra ID)

นอกจากความสามารถพื้นฐานข้างต้นแล้ว  Microsoft Entra ID ยังมีความสามารถมากมายครับ เช่น สามารถไป Integrate หรือทำงานร่วมกับ Directory Service (Active Directory Domain Service) สำหรับการทำ Hybrid Identity Scenario, สามารถไป Integrate หรือทำงานร่วมกับ Cloud/SaaS Apps, สามารถ Integrate ทำงานร่วมกับ Unified Endpoint Management, และอื่นๆ ครับ  ยิ่งไปกว่านั้น Microsoft Entra ID ยังถูกออกแบบมาให้ Align กับ "Microsoft Zero Trust Model" อีกด้วยครับ เพื่อช่วยองค์กรในวางแผน, ออกแบบ, ดำเนินกาสร้างความปลอดภัยให้กับ IT Environment ขององค์กรโดยครอบคลุมทั้ง Hybrid และ Multi-Cloud ครับ และอีกมุมหนึ่ง Microsoft Entra ID ยังเป็นสมาชิกที่อยู่ภายใต้ Microsoft Entra Family ด้วยครับ โดย Family ดังกล่าวนี้ ทาง Microsoft ได้ออกแบบไว้สำหรับการบริหารจัดการ Identity ซึ่งปัจจุบันประกอบไปด้วยสมาชิกหลายตัว เช่น Microsoft Entra ID Governance, Microsoft Entra Permission Management, Microsoft Entra Verified ID, และอื่นๆ ครับ

และกลับมาที่เรื่องของการบริหารจัดการ Identity ด้วย Microsoft Entra ID เพื่อพาทุกท่านเข้าสู่เรื่องราวของฟีเจอร์ใหม่ (Microsoft Entra Agent ID) ครับ  ถ้าเราพูดถึง Identity แล้ว สิ่งที่เราจะต้องทราบก่อนเลยคือ Identity แบ่งได้ 2 แบบหลักๆ ครับ คือ:

1. Human Identity คือ คน (People) นั่นก็คือ ตัวเรานั่นเองครับ และอย่างที่เราทราบกันว่า เราจะต้องมี Identity ก่อน ถึงจะเข้าถึงหรือ Access Resources ต่างๆ ในองค์กรได้ ตัวอย่างของ Human Identity เช่น User Account นั่นเองครับ โดยใน Microsoft Entra ID รองรับ Identity  อยู่ 3 ชนิด คือ:

- User Account

- Group Account

- External Account (Guest Account)

2. Non-Human Identity คือ สิ่งที่ต้องการเข้าถึงหรือ Access Resources แต่ไม่ใช่คนหรือผู้ใช้งานครับ โดยเรียกอีกชื่อหนึ่งว่า "Workload Identities" เช่น Apps, Services, และอื่นๆ รวมถึง AI ครับ

นั่นหมายความว่า Microsoft Entra ID จะต้องทำการบริหารจัดการ Identity ทั้ง 2 แบบหลักๆ ข้างต้น (Human และ Non-Human Identity) ในการเข้าถึง Resources ต่างๆ ในองค์กรของเราครับ และในบทความนี้จะเกี่ยวข้องกับการที่ Microsoft Entra ID จะเข้าไปบริหารจัดการ Non-Human Identity ซึ่งไม่ใช่ Apps หรือ Services ครับ แต่เป็น AI ครับ เพราะเนื่องจากที่ผ่านมาจนถึงทุกวันนี้มีหลายๆ องค์กรได้นำเอา AI เทคโนโลยีเข้ามาประยุกต์ใช้งานในองค์กร  ตัวอย่างเช่น การนำเอา AI Agent เข้ามาประยุกต์ใช้งาน (ปัจจุบัน Microsoft เองมี AI Agent มากกว่า 20,000 AI Agent และมีมากขึ้นเรื่อยๆ) และแน่นอนครับว่า AI เทคโนโลยีและความสามารถต่างๆ เหล่านี้เมื่อนำเข้ามาใช้งานในองค์กรของเรา ก็จะต้องการเข้าถึง Resources ต่างๆ ในองค์กรของเรา ประเด็นนึงในแง่ของความปลอดภัยก็คือ องค์กรจะรับมือและจัดการอย่างไรกับ AI (เช่น AI Agent) จากเรื่องดังกล่าวนี้ครับ และจากจุดนี้เองจึงเป็นที่มาที่ทาง Microsoft ได้ทำการพัฒนาฟีเจอร์ใหม่ให้กับ Microsoft Entra ID เพื่อใช้ในการบริหารจัดการ AI จากเรื่องดังกล่าวนี้ครับ เล่าที่มาที่ไปให้ทุกท่านได้ทราบพอสมควร ก็ถึงเวลาที่จะพาทุกท่านไปทำความรู้จักกับ "Microsoft Entra Agent ID" กันครับ

Microsoft Entra Agent ID คืออะไร?

คือ ฟีเจอร์หนึ่งของ Microsoft Entra ID ที่จะเข้ามาช่วยในการบริหารจัดการ AI Agent ที่องค์กรได้นำเอาเข้ามาประยุกต์ใช้งานในองค์กร และอย่างที่ได้เกริ่นไว้ก่อนหน้าว่า AI Agent มีความต้องการที่จะเข้าถึง Resources ต่างๆ ในองค์กร ซึ่งทำให้หลายๆ องค์กรจะต้องวางแผนและรับมือกับเรื่องของความปลอดภัยในกรณีที่มีการนำเอา AI เทคโนโลยี (เช่น AI Agent) เข้ามาประยุกต์ใช้งานครับ

โดยทาง Microsoft ได้ทำการเปิดตัว Microsoft Entra Agent ID ครั้งแรกใน Microsoft Build ที่ผ่านมาโดยทาง Microsoft บอกว่า Microsoft Entra Agent ID คือ Unified Directory ของ Identities ทั้งหมดที่สร้างขึ้นมาจากการใช้งาน Microsoft Copilot Studio กับ Azure AI Foundry นั่นหมายความว่า Identities เหล่านี้ถูกสร้างมาจาก Developer หรือ Information Worker นั่นเอง  ต่อจากนั้นทาง Microsoft ได้เพิ่มความสามารถในการจัดการ, Security, และ Governance กับ Identities ดังกล่าวนี้อีกด้วย โดยสามารถเข้าไปจัดการผ่านทาง Microsoft Entra Admin Center (Portal ที่เอาไว้ใช้ในการบริหารจัดการ Microsoft Entra Family)

ขออนุญาตสรุปให้ทุกท่านเข้าใจว่า Microsoft Entra Agent ID (ฟีเจอรหนึ่งของ Microsoft Entra ID) จะเข้ามาช่วยในการจัดการและควบคุม Non-Human Identity (ต้วอย่างเช่น AI Agent) โดย Microsoft Entra ID Agent จะทำให้ AI Agent มี ID เป็นของตัวเอง (เหมือนกับ Identity ปรกติ) เพื่อทำให้ Microsoft Entra ID สามารถจัดและควบคุม AI Agent โดยมีรายละเอียดดังนี้:

1. ติดตาม (Track) และตรวจสอบ (Monitor) Activity ต่างๆ ของ AI Agent ใน IT Environment

2. บริหารจัดการ Agent Lifecycle (Create, Approve, Use, และ Retire)

3. Enforce หรือบังคับให้ใช้ Microsoft Entra Conditional Access (เหมือนกับ Human Identity)

4. Align เข้ากับ Zero Trust Principles *Microsoft มีการอัพเดท Zero Trust Model ให้ครอบคลุมเรื่องของ AI เรียบร้อยก่อนหน้านี้  รายละเอียดเพิ่มเติมไปที่ Link ครับ, Microsoft extends Zero Trust to secure the agentic workforce | Microsoft Security Blog

5. อื่นๆ 

และทั้งหมดนี้คือเรื่องราวของฟีเจอร์ใหม่ของ Microsoft Entra ID ครับผม.....

Security Operations & XDR

      สวัสดีครับทุกท่าน สำหรับบทความนี้มีที่มาจากการที่ผมได้มีโอกาสสอนและบรรยายเรื่องของการวางแผนออกแบบ Cybersecurity Architecture โดยใช้ Security Solutions ต่างๆ ของทาง Microsoft ครับ โดยเรื่องดังกล่าวจะเกี่ยวข้องกับหลายปัจจัยที่จะต้องนำเอามาใช้ในการวางแผนออกแบบตลอดจนผู้ที่ออกแบบหรือที่เราเรียกว่า "Cybersecurity Architect" จะต้องมีความรู้ความเข้าใจคอนเซปตลอดจนรายละเอียดต่างๆ ที่เกี่ยวข้องกับเรื่องดังกล่าวนี้ทั้งหมด ยกตัวอย่างเช่น เรื่องของ Security Models (Shared Responsibilities, Zero Trust Model, MCRA, และอื่นๆ)

ถัดมาคือ เรื่องของ Cyber Kill Chain กับ Standard Security Models เช่น  NIST, MITRE ATT&CK, เป็นต้น, 

และตามด้วยเรื่องของ Microsoft Security Ecosystem (เช่น Microsoft Entra Family, Microsoft Defender Family, และอื่นๆ) ครับ

ซึ่งจะมาพร้อมกับเทคโนโลยีต่างๆ ที่จะมาช่วยในเรื่องของการสร้างความปลอดภัยให้กับ IT Environments ขององค์กร ไม่ว่าจะอยู่ในรูปแบบที่เป็น Hybrid หรือ Multi-Cloud Environments ก็ตาม

และสำหรับบทความนี้ผมจะนำเสนอเทคโนโลยีหนึ่งที่เกี่ยวข้องกับ Security โซลูชั่น ที่หลายๆ บริษัทชั้นนำที่มีโซลูชั่นด้านความปลอดภัยให้บริการอยู่มากมายในตลาด และหนึ่งในนั้นคือ Microsoft ครับ โดยเทคโนโลยีที่ผมกำลังพูดถึงหรืออยากจะพาท่านผู้อ่านทุกท่านไปทำความรู้จักนั่นก็คือ "Extended Detection and Response" หรือเรียกกันสั้นๆ ว่า "XDR" ครับ โดยเทคโนโลยีนี้ผมเชื่อว่าทุกท่านจะน่าเคยได้ยินและคุ้นเคยกันอยู่แล้วใช่มั๊ยครับ !!!!! แต่ถ้ามีใครมาถามหรืออยากจะปรึกษาทุกท่าน โดยเริ่มจาก XDR คืออะไร? และเทคโนโลยีดังกล่าวนี้จะเค้ามาช่วยองค์กรในเรื่องของความปลอดภัยอย่างไร? ทุกท่านจะอธิบายหรือตอบคำถามเมื่อซักครู่นี้ว่าอย่างไรครับ? 

ก่อนที่จะพาทุกท่านเข้าสู่เรื่องราวของ XDR ผมอยากจะขอเกริ่นหรือท้าวความก่อนว่า XDR จะเป็นเทคโนโลยีหนึ่งที่จะเข้ามาเกี่ยวข้องกับกระบวนการที่เรียกว่า "Security Operations" ตามชื่อของบทความนี้เลยครับ โดยกระบวนการดังกล่าวนี้จะเป็นกระบวนที่สำคัญในการที่จะช่วย Secure & Protect IT Environments (ครอบคลุม Hybrid และ Multi-Cloud) ขององค์กร โดยจุดเริ่มต้นจะมาจากการที่องค์กรมีความต้องการที่จะทำการวางแผนตลอดจนเตรียมความพร้อมในการที่จะดำเนินการในเรื่องของความปลอดภัยให้กับองค์กร แต่องค์กรนั้นๆ ไม่ทราบว่าจะต้องเริ่มต้นอย่างไร?, ต้องทำอย่างไร? และอื่นๆ 

และจากจุดนี้เองครับท่านที่ทำหน้าที่หรือมีบทบาทเป็น Cybersecurity Architect จะเข้ามาช่วยองค์กร โดยเริ่มจากเก็บรวบรวมความต้องการ, ศึกษาเรื่องราวตลอดจนข้อมูลต่างๆ ของ Existing Environments ขององค์กร, ตามด้วยการนำเอา Frameworks, Best Practices, Models, และอื่นๆ มาประยุกต์ใช้ในการวางแผนและออกแบบ, จากนั้น Cybersecurity Architect ก็จะทำการออกแบบซึ่งการออกแบบดังกล่าวนี้จะเกี่ยวข้องกับ Security Operations ด้วยครับ เพราะฉะนั้นท่านใดที่ยังไม่รู้จักหรือยังไม่ทราบว่า Security Operations คืออะไร? ลองย้อนกลับไปอ่านบทความของผมก่อนหน้านี้ได้ครับ สำหรับ Security Operations จะประกอบไปด้วย Processes ย่อยๆ และมี Cycle ดังรูปด้านล่างครับ

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

ผมจะเริ่มเข้าสู่เรื่องของ XDR โดยผมจะพาท่านไปทำความรู้จักกับเทคโนโลยีนึงก่อน ซึ่งเทคโนโลยีดังกล่าวนี้คือ เทคโนโลยีที่เป็นต้นทางก่อนที่มาถึง XDR ครับ เทคโนโลยีที่ว่านี้ คือ "Endpoint Detection and Response" หรือ "EDR" ครับ 

Endpoint Detection and Response (EDR) คืออะไร?

คือ Security โซลูชั่นที่ทำการตรวจสอบ (Monitor) Endpoints (ครอบคลุมถึง Servers และ Devices) อย่างต่อเนื่องเพื่อทำการค้นหา (Detect), ป้องกัน (Prevent), และแก้ไข (Remediate) ภัยคุกคามหรือ Threats ที่โจมตี Endpoints  ณ ปัจจุบัน Endpoint Security โซลูชั่นมักจะมาพร้อมกับ Agent เพื่อทำการติดตั้ง Agent ดังกล่าวนี้ไปยัง Endpoints ที่องค์กรต้องการป้องกัน โดยเมื่อทำการติดตั้ง Agent ไปยัง Endpoints เรียบร้อยแล้วตัว Agent จะทำการรวบรวม, วิเคราะห์, ตรวจสอบ, และส่งรายงานไปยัง Endpoint Security โซลูชั่นที่อยู่บน Cloud เพื่อดำเนินการต่อไป เช่น Triage, Investigation, เป็นต้น นอกจากนี้แล้วตัวของ EDR ยังสามารถทำงานร่วมกัน Security โซลูชั่นอื่นๆ ได้อีก เช่น SIEM เป็นต้นครับ

สำหรับ EDR เทคโนโลยีนี้ทาง Microsoft ได้นำเอามาใช้ใน Endpoint Security โซลูชั่นที่ชื่อว่า "Microsoft Defender for Endpoint" หรือเรียกสั้นๆ ว่า "MDE" ครับ

Extended Detection and Response (XDR) คืออะไร?

คือ Security โซลูชั่น ที่พัฒนาต่อยอดมาจาก EDR ครับ โดย XDR จะทำการรวบรวมข้อมูลจากหลายๆ ส่วนใน IT Environments นอกเหนือจาก Endpoints เช่น Email, Apps, Network, เป็นต้น เพื่อทำการค้นหา, ตรวจสอบ, และทำการป้องกัน นั่นหมายความว่า XDR ไม่ได้ทำการตรวจสอบค้นหาโดยดูจาก Endpoints อย่างเดียวเหมือนกับ EDR แต่ยังทำการค้นหาส่วนอื่นๆ ที่เกี่ยวข้องเพื่อจะทำให้การค้นหา, ตรวจสอบ, และป้องกันภัยคุกคามมีประสิทธิภาพมากยิ่งขึ้น  สำหรับ XDR เทคโนโลยีดังกล่าวนี้ทาง Microsoft ได้นำเอามาใช้ใน Security โซลูชั่นที่ชื่อว่า "Microsoft Defender XDR" หรือชื่อเดิมคือ Microsoft 365 Defender ครับ โดย Microsoft Defender XDR จะอยู่ใน Microsoft Defender Family ครับ

และ MDE หรือ Microsoft Defender for Endpoint จะเป็น Product/Service นึงที่อยู่ใน Microsoft Defender XDR ครับ นั่นหมายความว่าเราสามารถพิจารณานำเอา Microsoft Defender XDR มาใช้ในการป้องกัน Endpoints, Microsoft 365 (Exchange Online และอื่นๆ), Identity, และอื่นๆ ครับ รายละเอียดเพิ่มเติมสามารถไปย้อนอ่านบทความของผมก่อนหน้านี้ได้ครับ รวมถึงไปที่ Link นี้ครับ, Microsoft Defender XDR | Microsoft Security

สำหรับเรื่องราวของ Security เทคโนโลยียังมีอีกเยอะมากครับ สำหรับบทความนี้ผมนำเสนอแค่ 2 Security โซลูชั่น คือ EDR และ XDR ครับ ถ้าโฟกัสเฉพาะ Security โซลูชั่นที่ลงท้าย xxxDR ยังมีอีกเยอะนะครับนอกเหนือจาก EDR และ XDR ครับ ตัวอย่างเช่น

1. Network Detection and Response (NDR), Security โซลูชั่นนี้จะทำการรวบรวมข้อมูลที่เกี่ยวข้องกับ Network ไปทำการตรวจสอบและวิเคราะห์เพื่อค้นหาภัยคุกคามครับ และจะทำงานร่วมกับ Security โซลูชั่นอื่นๆ เช่น UEBA, SIEM เป็นต้น

2. Identity Detection and Response (ITDR), Security โซลูชั่นนี้จะทำการค้นหาแ่ละจัดการกับภัยคุกคามที่โจมตีระบบ Identity-Based System 

3. Managed Detection and Response (MDR), เป็นการบริการเกี่ยวกับ EDR ให้กับองค์กรที่ไม่มีทีมงานทางด้านความปลอดภัยครับ โดยรายละเอียดและขอบเขตงานของการให้บริการดังกล่าวนี้ขึ้นอยู่กับการตกลงกันระหว่างผู้ให้บริการ MDR กับผู้ใช้บริการครับ

และทั้งหมดนี้คือเรื่องราวของเทคโนโลยี EDR และ XDR ที่ถูกนำมาใช้ใน Security โซลูชั่นต่างๆ โดย Cybersecurity Architect สามารถนำเอามาพิจารณาร่วมกับ Cybersecurity Architecture รวมถึง Security Operations ที่ออกแบบไว้ได้ครับผม.....