Microsoft Cybersecurity ตอนที่ 4 (Microsoft Cybersecurity Reference Architectures)

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะเข้าสู่ตอนที่ 4 สำหรับเรื่องราวที่เกี่ยวข้องกับ Microsoft Cybersecurity ครับ โดยบทความนี้ผมจะพาทุกท่านไปรู้จักกับ "Microsoft Cybersecurity Reference Architectures" หรือเรียกสั้นๆ ว่า MCRA ครับ และเพื่อไม่ให้เป็นการเสียเวลา เรามาทำความรู้จักกับ MCAR กันเลยครับผม

Microsoft Cybersecurity Reference Architectures (MCRA) คืออะไร?

MCRA เป็น Model ที่อธิบายถึงความสามารถต่างๆ ของ Microsoft Cybersecurity ครับ โดย MCRA จะมาพร้อมกับเอกสาร, คำแนะนำ, Templates, และอื่นๆ ที่ท่านผู้อ่านหรือท่านที่ทำหน้าเป็น Cybersecurity Architect จะนำไปพิจารณาเพื่อทำการวางแผนและออกแบบ Cybersecurity Architecture ให้ครอบคลุม IT Environments ขององค์กร เช่น On-Premise, Hybrid, และ Multi-Cloud Environments

MCRA ถูกออกแบบมาเพื่อช่วยองค์กรทุกขนาหรือทุก Sizes ครับ ไม่ว่าจะขนาดเล็กหรือขนาดใหญ่ ที่กำลังวางแผน, ออกแบบ, และดำเนินการติดตั้งหรือ Implement Microsoft Cybersecurity หรือ Security Solutions  เพื่อทำการป้องกันและสร้างความปลอดภัยให้กับ IT Environments ตามความต้องการขององค์กร

นอกจากเอกสารและคำแนะนำต่างๆ ที่อยู่ใน MCRA แล้ว ตัวของ MCRA  ยังอธิบายถึงความสามารถต่างๆ ของ Microsoft Cybersecurity หรือ Security Solutions ในการ Integrate หรือทำงานร่วมกับ Cloud Services ต่างๆ ของ Microsoft เช่น Microsoft 365, Microsoft Azure, Cloud Service Providers อื่นๆ เช่น AWS และ GCP, และอื่นๆ 

รูปด้านล่างเป็นรูปที่แสดงถึง Reference Architectures ของ MCRA ที่เราหรือท่านที่เป็น Cybersecurity Architect จะต้องนำมาพิจารณาเพื่อใช้ในการวางแผนและออกแบบ Cybersecurity Architecture ตามที่ได้เกริ่นไว้ในตอนต้นครับ 

โดยใน Reference Architectures ดังกล่าวนี้ประกอบไปด้วย ส่วนประกอบต่างๆ ดังนี้:

1. Capabilities เป็นส่วนประกอบที่เกี่ยวข้องกับความสามารถของ MCRA ในด้านต่างๆ เช่น Security, Compliance, Identity, และอื่นๆ 

2. People เป็นส่วนประกอบที่เกี่ยวข้องกับคนหรือบุคคลากรซึ่งถือว่าเป็น Asset หนึ่งที่มีความสำคัญที่เราจะต้องดำเนินการวางแผนและออกแบบในการป้องกันและสร้างความปลอดภัย นอกจากนี้แล้วยังรวมถึงเรื่องของการทำ Access Control ในองค์กรอีกด้วย

3. Zero Trust User Access เป็นส่วนประกอบที่เกี่ยวข้องกับการนำเอา Zero Trust Model เข้ามาประยุกต์ใช้งาน โดยเฉพาะการบังคับใช้กับคน (People) ในการเข้าถึง Resources ต่างๆ 

4. Attack Chain Coverage เป็นส่วนประกอบที่เกี่ยวข้องกับการนำเอา Models ต่างๆ เช่น Defense-In-Depth มาช่วยในการวางแผนและออกแบบ

5. Security Operations เป็นส่วนประกอบที่เกี่ยวข้องกับการวางแผนและออกแบบกระบวนการของการดำเนินการ Security Operations ตั้งแต่ การรวบรวมข้อมูล (Data Collection), การค้นหา (Detection), และอื่นๆ 

6. Operational Technology เป็นส่วนประกอบที่เกี่ยวข้องกับการป้องกันและสร้างความปลอดภัยให้กับ Endpoints ในองค์กร

7. Azure Native Controls เป็นส่วนประกอบที่เกี่ยวข้องกับการพิจารณานำเอาฟีเจอร์ทางด้าน Security ของ Microsoft 365 และ Microsoft Azure เข้ามาประยุกต์ใช้งานในองค์กร

8. Multi-Cloud & Cross-Platform เป็นส่วนประกอบที่เกี่ยวข้องกับการวางแผนและออกแบบการป้องกันและสร้างความปลอดภัยให้ครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments 

9. Secure Access Service Edge (SASE) เป็นส่วนประกอบที่เกี่ยวข้องกับ Security Framework ที่ถูกออกแบบให้ครอบคลุมในส่วนของ Networking และใช้งานร่วมกับ Zero Trust โดยใน SASE ยังประกอบไปด้วยส่วนประกอบย่อยๆ อีก เช่น SD-WAN, SWG, CASB, และอื่นๆ 

รูปด้านล่างเป็นรูปที่แสดงถึงความสามารถหลักๆ ของ MCRA โดยการนำเอา Microsoft Cybersecurity หรือ Security Solutions มาใช้งานครับ

สำหรับเรื่องราวของ Microsoft Cybersecurity Reference Architecture (MCRA) ยังมีรายละเอียดอีกเยอะมากครับ สามารถไปศึกษาเพิ่มเติมจาก Link นี้ครับ, Microsoft Cybersecurity Reference Architectures - Security documentation | Microsoft Learn

มาถึงตรงนี้ท่านผู้อ่านจะเห็นว่า บทบาทหน้าที่หรือ Roles ของ Cybersecurity Architect นั้น จะต้องอาศัยความรู้ความเข้าใจคอนเซปตลอดจนเรื่องต่างๆ มากมายครับ เช่น Models (Defense-In-Depth, Zero Trust, และอื่นๆ), รวมถึงเรื่องราวของ MCRA, และอื่นๆ มาใช้ในการวางแผนและออกแบบ Cybersecurity Architecture ให้กับองค์กรครับ และทั้งหมดนี้คือเรื่องราวของ MCRA ครับผม.....

Microsoft Defender for Cloud New Feature - Direct Onboarding

      สวัสดีครับทุกท่านสำหรับบทความนี้ ผมขออนุญาตอัพเดทฟีเจอร์ใหม่ใน Microsoft Defender for Cloud ที่เพิ่ง GA หรือ General Available ไม่กี่วันที่ผ่านมาครับ โดยฟีเจอร์ดังกล่าวนี้มีชื่อว่า "Direct Onboarding" ครับ โดยฟีเจอร์ดังกล่าวถือว่าเป็นการทำงานร่วมกันระหว่าง Microsoft Defender for Cloud (MDC) กับ Microsoft Defender for Endpoint (MDE) ที่มันดีขึ้นหรือ Seamless มากกว่าเดิมครับ ขออนุญาตเล่าให้ฟังคร่าวๆ เกี่ยวกับ Microsoft Defender for Cloud หรือ MDC เผื่อท่านผู้อ่านท่านใดที่เพิ่งเข้ามาอ่านบทความนี้ จะได้ไม่งงครับ แต่ถ้าต้องการทราบเรื่องราวของ Microsoft Defender for Cloud สามารถย้อนไปอ่านบทความก่อนหน้านี้ของผมได้เลยครับ ผมเคยเขียนบทความที่อธิบายถึงเรื่องราวและความสามารถของ MDC เอาไว้ครับ 

กลับมาที่เรื่องราวเกี่ยวกับ Microsoft Defender for Cloud กันต่อครับ โดย MDC เป็น Service หนึ่งใน Microsoft Azure ครับ โดยทำหน้าที่หลัก ๆ อยู่ 2 อย่าง คือ CSPM (Cloud Security Posture Management) และอีกหน้าที่หนึ่งคือ CWPP (Cloud Workload Protection Platform) หรือบางครั้งเรียก CWP ก็ได้ครับ Microsoft ได้ทำการวางแผนและออกแบบให้ Microsoft Defender for Cloud เป็นส่วนประกอบส่วนหนึ่งที่สำคัญของ Microsoft Cybersecurity Solutions ในการที่จะเข้ามาช่วยองค์กรในการป้องกันและสร้างความปลอดภัยให้กับ IT Environment ขององค์กรโดยครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments ครับ ประมาณนี้สำหรับที่มาที่ไปของ MDC ครับ 

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

แต่ ณ ตอนนี้เรามีทางเลือกเพิ่มเติมสำหรับการ Secure และ Protect Non-Azure VM นอกเหนือจากการใช้ Azure Arc คือ การใช้ฟีเจอร์ใหม่ที่ชื่อว่า Direct Onboarding ครับ ด้วยความสามารถของฟีเจอร์ดังกล่าวนี้ทำให้เราสามารถทำการ Deploy MDE (โดยใช้ Scripting, Package, และอื่นๆ) ผ่านทาง Microsoft 365 Defender Portal โดยที่ไม่ต้องมีการติดตั้ง Agent หรือ Extensions ใด และสุดท้าย Microsoft Defender for Cloud ก็จะเข้ามาทำหน้าที่ของเค้าคือ การ Secure และ Protect VMs เหล่านั้นครับ เพราะฉะนั้นในแง่ของการบริหารจัดการสำหรับ Microsoft Defender for Cloud มีความยืดหยุ่นมากขึ้นครับ โดยเฉพาะเรื่องของ Endpoint Security ครับ รูปด้านล่างเป็นภาพของฟีเจอร์ Direct Onboarding ของ Microsoft Defender for Cloud ครับ

*เมื่อมีการ Enable เรียบร้อย จะใช้เวลาราวๆ หรือประมาณ 24 ชั่วโมงเพื่อทำการ Sync ข้อมูลเกี่ยวกับ VMs ใน Designated Subscription และส่วนของ Devices จาก Microsoft Defender for Endpoint (MDE) เป็นระยะๆ ในส่วนของ Licenses จะใช้จาก Microsoft Defender for Cloud (Defender Plan) ที่กำหนดไว้ครับ

สำหรับ Direct Onboarding ฟีเจอร์ดังกล่าวนี้ จะเกี่ยวข้องกับ  Defender Plan ใน Microsoft Defender for Cloud (Defender for Servers) ซึ่งเป็นหน้าที่นึง (CWPP) ของ MDC ตามที่ผมได้อธิบายไว้ข้างต้นครับ ดังรูปด้านล่างครับ

ในการทำงานจริงจะต้องมีการวางแผนและเตรียมความพร้อมกันก่อนนะครับ และจากประสบการณ์โดยส่วนตัวรวมถึง Best Practices ของ Microsoft ไม่แนะนำให้ท่านผู้อ่านไปทำการ Enable และกำหนดค่า Settings ต่างๆ ของ Microsoft Defender for Cloud เพื่อใช้งานทันทีนะครับ เช่นเดียวกับฟีเจอร์ Direct Onboarding ครับ รายละเอียดเพิ่มเติมเกี่ยวกับ Direct Onboarding สามารถไปที่ Link นี้ได้เลยครับ, Onboard non-Azure machines with Defender for Endpoint | Microsoft Learn

และท้้งหมดนี้คือเรื่องราวของฟีเจอร์ใหม่ใน Microsoft Defender for Cloud ที่ชื่อว่า Direct Onboarding ที่ผมอยากจะนำเสนอหรือแนะนำให้ทุกท่านได้รู้จักครับผม.....

แนะนำฟีเจอร์ใหม่ใน Microsoft Sentinel (Workspace Manager)

      สวัสดีครับทุกท่านกลับมาพบกันเหมือนเช่นเคยครับ สำหรับบทความนี้ของผมจะเป็นเรื่องราวของฟีเจอร์ใหม่ใน Microsoft Sentinel ที่มีชื่อว่า "Workspace Manager" ซึ่ง ณ วันที่ผมเขียนบทความนี้ยังเป็น Preview อยู่นะครับ  สำหรับท่านใดที่คุ้นเคยหรือใช้งาน Microsoft Sentinel กันอยู่แล้ว น่าจะทราบว่า Microsoft Sentinel เองนั้นต้องการอีกหนึ่ง Service ใน Microsoft Azure มาช่วยทำงานและ Service ที่ว่านี้ถือว่าเป็น Service ที่สำคัญมาก Service หนึ่ง สำหรับเรื่องของการทำ Security Operations โดยใช้ Solutions ของทาง Microsoft ครับ Service ที่ผมกำลังพูดถึงนี้มีชื่อว่า "Azure Log Analytics Workspace" ครับ

โดยตัวของ Azure Log Analytics Workspace เองมีความสามารถในการเก็บข้อมูล (Ingested Data) ที่ทำการรวบรวมมาจาก IT Environment ขององค์กร ข้อมูลดังกล่าวจะถูกเก็บไว้ที่นี่ครับ และนอกจากนี้แล้ว SOC หรือ Security Teams ยังสามารถทำการค้นหาหรือ Query ข้อมูลที่เก็บอยู่ใน Azure Log Analytics ได้อีกด้วย โดยใช้ Query Language ที่ชื่อว่า "Kusto Query Language" หรือเรียกสั้นๆ ว่า KQL ครับ เพราะฉะนั้นถ้าเราต้องการที่จะใช้งาน Microsoft Sentinel ทำหน้าทีเป็น SIEM และ SOAR เรื่องนึงที่ควรจะต้องนำมาพิจารณาในขั้นตอนของการวางแผนและออกแบบ คือ การเรื่องของ Azure Log Analytics Workspace ที่จะนำมาใช้งานร่วมกับ Microsoft Sentinel นั้นจะมี Azure Log Analytics จำนวนกี่ Workspaces ? ทั้งนี้ขึ้นอยู่กับความต้องการของแต่ละองค์กร แต่ที่แน่ๆ คือ เราจะต้องมีอย่างน้อย 1 Azure Log Analytics Workspace ใช้งานกับ Microsoft Sentinel แน่นอนครับ

ทำความรู้จักกับ Workspace Manager (Preview)

อย่างที่ผมเกริ่นไว้ตอนต้นของบทความนี้ว่า ผมจะพาทุกท่านมารู้จักกับฟีเจอร์ใหม่ฟีเจอร์หนึ่งใน Microsoft Sentinel ครับ นั่นก็คือฟีเจอร์นี้นั่นเองครับ โดย Workspace Manager ฟีเจอร์ดังกล่าวนี้ ถือว่าเป็นฟีเจอร์ที่น่าสนใจอย่างมากครับ โดยเฉพาะในกรณีที่องค์กรนั้นๆ มีหลายๆ Workspaces หรือหลายๆ Azure Log Analytics Workspaces ครับ 

ด้วยความสามารถของ Workspace Manager จะเข้ามาช่วย SOC หรือ Security Teams ตลอดจนผู้ที่เกี่ยวข้องในการบริหารจัดการใน Environment ที่มีหลาย Workspaces ให้มีความยืดหยุ่นและมีประสิทธิภาพมากขึ้นครับ ยกตัวอย่างเช่น สมมติว่ามีออฟฟิศของท่านผู้อ่านมีการใช้งาน Microsoft Sentinel อยู่แล้ว และมี 2 Azure Log Analytics Workspaces (สมมติชื่อว่า LAW1 กับ LAW2) เราสามารถใช้ Workspace Manager ในการเอา Content จาก LAW1 ไปใส่ที่อีก Azure Log Analytics Workspace หนึ่งซึ่งจากตัวอย่างนี้คือ LAW2 ครับ โดยมีวัตถุประสงค์คือ ต้องการบังคับหรือควบคุมให้ทุกๆ Azure Log Analytics มี Baselines เดียวกัน หรืออาจจะใช้ในอีกวัตถุประสงค์หนึ่งคือ สำหรับใน Environment ที่มีการออกแบบ Microsoft Sentinel ในรูปแบบที่เรียกว่า "MSSP" (ย่อมาจาก Managed Security Service Provider) SOC หรือ Security Teams ต้องการที่จะเอา Content บางส่วน (เช่น Analytic Rules และอื่นๆ) จาก Azure Log Analytics Workspace ของ MSSP หรือของผู้ให้บริการ (LAW1) ไปยัง Azure Log Analytics Workspace ของลูกค้า (LAW2) ครับ

โดยคอนเซปของ Workspace Manager เราจะต้องทำการกำหนดว่า Azure Log Analytics Workspace ใดจะเป็น "Central" หรือ Master จากนั้นท่านผู้อ่านสามารถทำการ Add หรือเพิ่ม Azure Log Analytics อื่นๆ เข้าไปโดยจะอยู่ใน Azure AD Tenant เดียวกันหรืออยู่คนละ Azure AD Tenants ก็ได้ครับ 

จากนั้นทำการพิจารณาและสร้าง "Workspace Manager Group" ขึ้นมา จากนั้นทำการกำหนดว่า Azure Log Analytics Workspaces ใดบ้าง จะอยู่ใน Workspace Manager Group ดังกล่าวนี้ หลังจากนั้น SOC หรือ Security Teams สามารถกำหนดว่าจะทำการส่งหรือ Push Contents (Analytic Rules, Workbooks, และอื่นๆ) ใดจาก Central Workspace ไปยัง Group (Azure Log Analytics Workspace อื่นๆ) และจากคอนเซปดังกล่าวนี้ ถ้าเรามองในแง่หรือประเด็นของประโยชน์หรือ Benefits ที่ได้จากฟีเจอร์ดังกล่าวนี้ คือ Workspace Manager ทำให้การบริหารจัดการใน Environment ที่มีหลายๆ Workspaces มีความยืดหยุ่นและจัดการได้สะดวกและง่ายมากขึ้น

รายละเอียดเพิ่มเติมเกี่ยวกับ Workspace Manager สามารถไปที่ Link นี้ได้เลยครับ, Manage multiple Microsoft Sentinel workspaces with workspace manager | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของฟีเจอร์ใหม่ใน Microsoft Sentinel ที่มีชื่อว่า Workspace Manager ที่ผมอยากแนะนำให้ทุกท่านรู้จักครับผม.....