ทำความเข้าใจผลลัพธ์ที่ต้องการ: เราคัดเลือกชุดฟีเจอร์ของ Cloud Defense Free อย่างไร

เมื่อเราตัดสินใจเปิดตัวFireMon Cloud Defense เวอร์ชันฟรี เรารู้ดีว่าต้องสร้างสมดุลระหว่างความท้าทายสำคัญสองข้อ:

• เรารู้อยู่แล้วว่าแพลตฟอร์มของเราขยายขนาดได้ แต่เราจะปรับให้ขยายขนาดอย่างคุ้มค่าเชิงเศรษฐกิจเพื่อรองรับองค์กรขนาดใหญ่ในระยะยาวได้หรือไม่ ไม่ต้องบอกก็รู้ว่าเราไม่สามารถปล่อยออกไปเฉย ๆ แล้วหวังว่าค่าใช้จ่าย AWS จะไม่ทำให้เราล้มละลาย
• ภายใต้ข้อจำกัดด้านต้นทุน เราจะมอบชุดฟีเจอร์ที่สร้างคุณค่าอย่างแท้จริงให้ผู้ใช้ได้หรือไม่ คุณค่านั้นคืออะไร และจะแก้ปัญหาใดได้บ้าง

ความจริงคือ “ฟรี” ไม่เคยฟรีอย่างแท้จริง เพราะการใช้งานสิ่งใดก็ตามย่อมต้องใช้เวลาและความพยายาม เราไม่ได้มอง Cloud Defense รุ่นฟรีเป็นเศษเล็กเศษน้อยที่โยนทิ้งให้ เพราะเรารู้ว่าหากเราขอให้ผู้ใช้สมัคร ติดตั้ง และใช้งานแพลตฟอร์ม พวกเขาจะทำเช่นนั้นก็ต่อเมื่อเราช่วยให้พวกเขาทำงานได้สำเร็จจริง

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

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

การกำหนดผลลัพธ์ที่ต้องการ

ที่ FireMon เราชื่นชอบเฟรมเวิร์ก Jobs to be Done สำหรับกลยุทธ์ผลิตภัณฑ์เป็นอย่างมาก ชื่อของมันบอกใบ้อยู่แล้ว แต่เฟรมเวิร์กนี้ชี้นำการตัดสินใจด้านผลิตภัณฑ์โดยมุ่งไปที่งานที่ลูกค้าพยายามทำให้สำเร็จ และผลลัพธ์เฉพาะที่ลูกค้าคาดหวัง นี่เป็นการสรุปเฟรมเวิร์ก JTBD แบบหยาบมาก แต่น่าจะพอเห็นภาพ แทนที่จะโฟกัสที่ฟีเจอร์ คุณจะโฟกัสที่ผลลัพธ์ที่ลูกค้าคาดหวังจากการใช้ผลิตภัณฑ์ แล้วใช้สิ่งนั้นออกแบบฟีเจอร์

หลังผ่านกระบวนการเชิงลึกที่ประกอบด้วยการวิจัย ประสบการณ์ และการสัมภาษณ์ เราได้กลั่นกรองออกมาเป็นร่างชุดผลลัพธ์ที่ผู้เชี่ยวชาญด้านความปลอดภัยบนคลาวด์ต้องการ ดังนี้:

• เพิ่มความรู้และความเข้าใจเกี่ยวกับสถานะความปลอดภัยบนคลาวด์ทั่วทั้งขอบเขตการใช้งานคลาวด์ของเรา (visibility)
• ลดโอกาสเกิดการตั้งค่าคลาวด์ที่ผิดพลาดทั่วทั้งขอบเขตการใช้งานคลาวด์ของเรา (prevention)
• ลดความเสี่ยงด้านความปลอดภัยและ compliance บนคลาวด์ (ทั้งปริมาณและระยะเวลา) ทั่วทั้งขอบเขตการใช้งานคลาวด์ในสภาพแวดล้อมแบบกระจายศูนย์ (remediation)
• เพิ่มความสามารถในการสื่อสารประเด็นความปลอดภัยบนคลาวด์ต่อผู้บริหารและหน่วยงานกำกับดูแล
• ลดโอกาสการสูญเสียและการใช้สิทธิ์ IAM ในทางที่ผิดต่อการใช้งานคลาวด์ของเรา
• เพิ่มความสามารถในการป้องกัน ตรวจจับ และตอบสนองต่อการโจมตีบนคลาวด์
• รักษาความปลอดภัยให้ทันกับการเปลี่ยนแปลงของบริการและแพลตฟอร์มคลาวด์จากผู้ให้บริการหลายราย
• ลดแรงเสียดทานและภาระด้านความปลอดภัยที่ตกอยู่กับทีมพัฒนาและทีมคลาวด์ โดยไม่เพิ่มความเสี่ยงด้านความปลอดภัย
• ลดความเสี่ยงของการละเมิดความปลอดภัยเมื่อเราใช้งานผ่านคอนเทนเนอร์
• ลดเวลาที่ใช้ในการผสานความปลอดภัยบนคลาวด์เข้ากับโปรแกรมของเรา ด้วย API และโครงสร้างข้อมูลมาตรฐาน

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

การแปลงผลลัพธ์ให้เป็นฟีเจอร์

เมื่อได้รายการดังกล่าว ก็ถึงเวลาพิจารณาว่าเราจะปรับหรือสร้างสิ่งใดได้บ้าง:

• เพิ่มความรู้และความเข้าใจเกี่ยวกับสถานะความปลอดภัยบนคลาวด์ทั่วทั้งขอบเขตการใช้งานคลาวด์ของเรา (visibility)

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

เราสรุปว่าเราสามารถสร้างสมดุลด้านต้นทุนและยังมอบคุณค่าได้ด้วยการสแกนวันละครั้งและเก็บประวัติ inventory ย้อนหลัง 30 วันพร้อมการติดตามการเปลี่ยนแปลง จะเห็นว่าเรายังไม่ได้พูดถึงการตั้งค่าความปลอดภัยที่ผิดพลาด แต่เดี๋ยวจะไปถึงจุดนั้น หลังจากทำแบบจำลองต้นทุน เราพบว่าสามารถรันสิ่งนี้ในระดับองค์กร (บัญชีที่เฝ้าติดตามหลายพันบัญชี) ได้ภายในงบประมาณ จึงตอบโจทย์ทั้งการมอบคุณค่าและการควบคุมต้นทุน

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

• ลดโอกาสเกิดการตั้งค่าคลาวด์ที่ผิดพลาดทั่วทั้งขอบเขตการใช้งานคลาวด์ของเรา (prevention)

การป้องกันการตั้งค่าคลาวด์ที่ผิดพลาดเป็นโจทย์ที่ยากกว่าการตรวจจับมาก จะบล็อกใน CI/CD pipeline หรือไม่หากผู้ใช้ทำงานแบบ Infrastructure as Code แล้วการเปลี่ยนแปลงด้วยมือล่ะ จะจัดการ workflow อย่างไรโดยไม่สร้างแรงเสียดทานมากเกินไปหรือทำให้ระบบพัง

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

• ลดความเสี่ยงด้านความปลอดภัยและ compliance บนคลาวด์ (ทั้งปริมาณและระยะเวลา) ทั่วทั้งขอบเขตการใช้งานคลาวด์ในสภาพแวดล้อมแบบกระจายศูนย์ (remediation)

นี่คือหัวใจหลักของ Cloud Defense มาตั้งแต่ผลิตภัณฑ์เวอร์ชันแรก แม้ remediation แบบอัตโนมัติจะไม่เหมาะกับรุ่นฟรี (อีกครั้ง เพื่อสร้างสมดุลระหว่างต้นทุนและความซับซ้อน) แต่ก็ไม่มีเหตุผลใดที่จะไม่เปิดใช้ชุดการตรวจสอบความปลอดภัยทั้งหมดของเรา

แต่การได้รายการประเด็นความปลอดภัยที่ยาวเหยียดไม่ได้ช่วยให้แก้ไขได้เสมอไป อีกหนึ่งความสามารถหลักของผลิตภัณฑ์เราคือการผสานรวมกับ ChatOps อย่างลึกซึ้ง โดยพื้นฐานเรารองรับทั้ง Slack และ Teams แต่ Teams ต้องใช้การสนับสนุนมากกว่าเพราะ... ก็ Teams นั่นแหละ เราจึงตัดสินใจเปิดใช้งานการแจ้งเตือนผ่าน Slack แบบละเอียด (ราย account หรือ project) อย่างเต็มรูปแบบ เพราะแทบไม่มีต้นทุนเพิ่มสำหรับเรา แต่มีคุณค่ามหาศาลสำหรับผู้ใช้

• เพิ่มความสามารถในการสื่อสารประเด็นความปลอดภัยบนคลาวด์ต่อผู้บริหารและหน่วยงานกำกับดูแล

ต้นทุนภายในของเราในการสร้างรายงาน compliance แทบไม่มีนัยสำคัญ แม้ในสภาพแวดล้อมขนาดใหญ่ สำหรับ compliance การประเมินวันละครั้งมักตอบโจทย์ผลลัพธ์ที่ต้องการได้มากกว่าพอ เราต้องลงแรงพัฒนาเพิ่มเติมเพื่อรองรับรายงาน PDF ที่ดีขึ้นสำหรับการใช้งานขนาดใหญ่ (เช่น หลายร้อยบัญชี) แต่เราก็จำเป็นต้องทำสิ่งนี้ให้ลูกค้าเชิงพาณิชย์อยู่แล้ว

• รักษาความปลอดภัยให้ทันกับการเปลี่ยนแปลงของบริการและแพลตฟอร์มคลาวด์จากผู้ให้บริการหลายราย

เนื่องจากผลิตภัณฑ์ฟรีและเชิงพาณิชย์ของเราใช้คลังการตรวจสอบชุดเดียวกันที่เราอัปเดตอย่างต่อเนื่อง ความสามารถนี้จึงเปิดใช้งานได้ทันที ความพยายามด้านวิศวกรรมในช่วงแรกของเรามุ่งไปที่การปรับต้นทุนสำหรับ AWS เราจึงตัดสินใจเปิดตัวโดยยังไม่รองรับ Azure หรือ GCP ในตอนเริ่มต้น ขณะนี้ Azure ใกล้พร้อมแล้ว ผู้ใช้จึงจะได้รับการรองรับ multi-cloud เต็มรูปแบบแบบฟรีในที่สุด

• ลดโอกาสการสูญเสียและการใช้สิทธิ์ IAM ในทางที่ผิดต่อการใช้งานคลาวด์ของเรา

เรามีฟีเจอร์ที่ยอดเยี่ยมชื่อว่า Authorization Control ซึ่งยกระดับความปลอดภัยของ IAM ได้อย่างมีนัยสำคัญ แต่เชิงเศรษฐกิจแล้วยังไม่คุ้มที่จะใส่ไว้ในผลิตภัณฑ์ฟรี

• เพิ่มความสามารถในการป้องกัน ตรวจจับ และตอบสนองต่อการโจมตีบนคลาวด์

ผลิตภัณฑ์เชิงพาณิชย์ของเรารองรับการตรวจจับภัยคุกคามแบบเรียลไทม์ แต่นี่เป็นอีกฟีเจอร์ที่เชิงเศรษฐกิจไม่เอื้อให้รองรับในแพลตฟอร์มฟรี เนื่องจากปริมาณกิจกรรมที่ต้องเฝ้าติดตามแบบเรียลไทม์นั้นสูงมาก

• ลดแรงเสียดทานและภาระด้านความปลอดภัยที่ตกอยู่กับทีมพัฒนาและทีมคลาวด์ โดยไม่เพิ่มความเสี่ยงด้านความปลอดภัย
• ลดความเสี่ยงของการละเมิดความปลอดภัยเมื่อเราใช้งานผ่านคอนเทนเนอร์
• ลดเวลาที่ใช้ในการผสานความปลอดภัยบนคลาวด์เข้ากับโปรแกรมของเรา ด้วย API และโครงสร้างข้อมูลมาตรฐาน

ผลลัพธ์เหล่านี้ล้วนเพิ่มต้นทุนและ/หรือความซับซ้อนที่เรารู้สึกว่ายังไม่สามารถรองรับได้อย่างเหมาะสมในผลิตภัณฑ์ฟรี ไม่ว่าจะด้วยต้นทุนโครงสร้างพื้นฐาน การสนับสนุน หรือการพัฒนา

การจัดชุดฟีเจอร์

ผลลัพธ์ที่ต้องการเมื่อผนวกกับการวิเคราะห์ต้นทุน ช่วยให้เราตัดสินใจได้ว่าจะจัดฟีเจอร์ใดไว้ในชุดนี้:

• การสแกนวันละครั้ง
• Resource inventory พร้อมประวัติย้อนหลัง 30 วัน
• ชุดการตรวจสอบความปลอดภัยแบบครบถ้วน
• รายงาน compliance พื้นฐาน
• การผสานรวมกับ Slack
• AWS ในตอนนี้ ส่วน Azure และ GCP จะตามมาเมื่อเราอัปเดตแพลตฟอร์ม

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

ชุดนี้ตอบโจทย์ผลลัพธ์ที่ต้องการหลักด้านvisibilityด้านความปลอดภัย และผลลัพธ์ด้านการสื่อสาร เพื่อยกระดับการรายงานและลดระยะเวลาการ remediation ไปพร้อมกัน และเรารู้ว่าสิ่งเหล่านี้มีคุณค่า เพราะเป็นผลลัพธ์ที่ผู้คนสร้างเครื่องมือ OSS ด้านความปลอดภัยบนคลาวด์ขึ้นมาเพื่อแก้ไขเป็นอันดับแรก และเป็นจุดกำเนิดของตลาด Cloud Security Posture Management ทั้งหมด

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

ลองใช้งานและบอกความคิดเห็นของท่านกับเรา FireMon Cloud Defense ยังคงพัฒนาอย่างต่อเนื่อง และเป็นแนวทางสำคัญที่ช่วยให้เราสนับสนุนผู้เชี่ยวชาญด้าน cloud security ให้ทำงานได้สำเร็จยิ่งขึ้น