รู้จักกับ 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 ครับ อย่าลืมติดตามกันนะครับ.....