Cyberm8 | למה ספקי SOAR Cloud-Native נכשלים בתשתית היברידית

הנוף

ארבעת הספקים ש-CISOs ישראלים בוחנים — ואיפה כל אחד נשבר

כשארגון ישראלי בוחן אוטומציית אבטחה, ארבעה שמות עולים שוב ושוב. לכל אחד יש חוזקות אמיתיות. לכל אחד יש גם מגבלות ארכיטקטוניות ספציפיות שהופכות אותו ללא מתאים לסביבות היברידיות או עתירות תשתית. אלה לא דעות שיווקיות. אלה מגבלות הנדסיות שמתועדות בתיעוד המוצר שלהם עצמם.

Torq

Hyperautomation Cloud-Native

הקמה ישראלית. אורקסטרציית API בענן מצוינת. בונה workflows מהיר. מגבלה קריטית: מודל הרצה 100% SaaS. כל workflow רץ בענן של Torq. כל קריאת API עוברת דרך התשתית שלהם. לא יכול לפעול באזורי isolated network. לא ניתן לפריסת on-prem. גישה ל-firewall vendors רק דרך API יוצא — בלי מודל agent מקומי לרשתות מבודדות.

נכשל ב-on-prem / isolated network

Tines

אוטומציית אבטחה No-Code

הקמה אירית. ממשק story builder נקי. טוב ל-workflows של triage התראות SOC. מגבלה קריטית: הרצה מתארחת בענן עם agent "tunnel" אופציונלי למשאבי on-prem. ה-tunnel דורש קישוריות יוצאת קבועה לענן Tines — מה שאומר שהוא לא יכול לפעול בסביבות חד-כיווניות או data diode. אין הבנה מובנית של primitives רשת (IPs, subnets, ACLs הם סתם "שדות טקסט").

נכשל בחד-כיווני / OT

Swimlane

פלטפורמת SOAR Low-Code

הקמה אמריקאית. מציעה אפשרות פריסת on-prem. מגבלה מרכזית: פריסת on-prem היא התקנת VM כבדה שדורשת תשתית משמעותית (מסד נתונים, תור הודעות, שרת web). לא מקונטיינרת לפריסת edge. בלי תבנית hot-folder או נתונים חד-כיווניים. primitives רשת מובנים מוגבלים — עדיין דורשת "אינטגרציות" Python מותאמות לפעולות ספציפיות ל-vendor.

on-prem חלקי, footprint כבד

Cortex XSOAR

SOAR של Palo Alto Networks

רכשה את Demisto. marketplace אינטגרציות ענק. מגבלות מרכזיות: מתומחרת כחלק מהאקו-סיסטם של Cortex — רכישת XSOAR לעתים קרובות מחייבת רכישת Cortex XDR, XSIAM, ורישיונות data lake נוספים. אפשרות on-prem קיימת אבל מקבלת פחות דגש לטובת ענן. עומס תפעולי כבד לפריסה ותחזוקה. נעילת vendor לאקו-סיסטם של Palo Alto.

נעילת אקו-סיסטם יקרה

ההשוואה

מטריצת יכולות: מה כל פלטפורמה יכולה ולא יכולה לעשות

הטבלה הזו מעריכה כל פלטפורמה מול הדרישות הספציפיות של סביבות ארגוניות ותשתיות קריטיות ישראליות. כל טענה ניתנת לאימות מול התיעוד ומדריכי הפריסה העדכניים של כל vendor.

יכולת	Torq	Tines	Swimlane	XSOAR	Cyberm8
פריסת on-prem מלאה	לא	לא	VM כבד	מקבל פחות דגש	Container
Isolated / חד-כיווני	לא	לא	לא	לא	Hot Folder
Primitives רשת מובנים IP, subnet, VLAN, ACL כאובייקטים typed	JSON בלבד	שדות טקסט	קוד מותאם	מוגבל	מובנה
Push טרנזקציוני רב-vendor הכל-או-כלום על מערך firewalls	סדרתי	סדרתי	סדרתי	סדרתי	אטומי
Rollback אוטומטי בכשל חלקי	לא	לא	לא	ידני	אוטומטי
אפס קוד מותאם לסנכרון firewall	דורש JS	actions מותאמים	אינטגרציות Python	Marketplace	No code
ריבונות נתונים (IL) כל הנתונים נשארים בתשתית ישראלית	ענן US/EU	ענן EU	אם on-prem	אם on-prem	On-prem
פריסת edge קלילה container בודד, 2GB RAM	לא רלוונטי	לא רלוונטי	VM כבד	VM כבד	Docker/Podman
עמידה ב-IEC 62443 / מערך הסייבר	לא תואם	לא תואם	לא תואם	לא תואם	תוכנן לזה

ההבדל המהותי

Torq, Tines, ו-Swimlane הן פלטפורמות אוטומציית workflows שיכולות לקרוא ל-API-ים של אבטחה. Cyberm8 היא מנוע אוטומציית תשתית רשת שמבין טופולוגיית אבטחה. ההבדל הוא לא סמנטי. הוא קובע האם הפלטפורמה יכולה להתמודד עם העומס האמיתי של ניהול מעטפת hybrid-cloud בלי קוד מותאם, סיכוני split-brain, או נעילת vendor.

השאלה האמיתית

מה ה-SOAR הקיים שלכם לא יכול לעשות — גם עם תקציב בלתי מוגבל

זה החלק בשיחה שצוותי מכירות של vendors נמנעים ממנו. המגבלות שלהלן הן לא פערי פיצ'רים שייסגרו ב-roadmap עתידי. הן מגבלות ארכיטקטוניות שמוטמעות באופן שבו הפלטפורמות האלה תוכננו.

1. הן לא יכולות לפעול ללא קישוריות אינטרנט

פלטפורמות SOAR cloud דורשות קישוריות קבועה לענן האורקסטרציה שלהן. אם קו האינטרנט שלכם נופל, האוטומציה נעצרת. אם מדיניות האבטחה שלכם אוסרת הרצה בענן ל-workflows מסוימים, ה-workflows האלה לא יכולים להתקיים בפלטפורמות האלה. Cyberm8 רצה מקומית. היא מריצה מה-container ברשת שלכם. קישוריות אינטרנט היא אופציונלית — משמשת רק לעדכונים ולאימות רישיון, אף פעם לא להרצה.

2. הן לא יכולות להבטיח מצב עקבי בין vendors

כש-Torq דוחפת כלל ל-5 firewalls, היא קוראת ל-5 API-ים באופן סדרתי. אם API מספר 3 עושה timeout, ל-API-ים 1 ו-2 יש את הכלל החדש ול-4 ו-5 אין. הפלטפורמה מתעדת את הכשל ופותחת ticket. הרשת שלכם עכשיו במצב split-brain. המודל הטרנזקציוני של Cyberm8 מתייחס לכל ה-push כפעולה אטומית. הכל מצליח או הכל עושה rollback. בלי tickets. בלי שחזור ידני. בלי split-brain.

3. הן לא יכולות לנרמל סכימות ספציפיות ל-vendor ללא קוד

ב-Tines, כדי לסנכרן כלל AWS Security Group למדיניות Check Point, צריך לכתוב "action" מותאם שמפרסר את ה-JSON response של AWS, מחלץ את השדות הרלוונטיים, ממיר אותם לפורמט ה-API של Check Point, מטפל ב-edge cases (prefix lists, הפניות security group, IPv6 dual-stack), ושולח POST של התוצאה. ב-Cyberm8, אתם גוררים connector מ-"AWS Security Groups" ל-"Check Point Policy" והמנוע מטפל בתרגום באופן מובנה. כי הוא מבין מה זה CIDR block.

לוועדת ההערכה

שאלו כל vendor את השאלה הזו במהלך ה-POC: "הראו לי סנכרון כלל firewall על פני 3 vendors שונים. אחר כך תנתקו את החיבור ל-vendor מספר 2 באמצע ה-push. הראו לי את ה-rollback האוטומטי." אם הם לא יכולים להדגים את זה חי, אין להם את זה. ואתם תבנו את זה בעצמכם ב-Python.

מסגרת החלטה

מתי להשתמש במה: הערכה כנה

אנחנו לא טוענים ש-Cyberm8 מחליפה כל פלטפורמת אוטומציה. אנחנו טוענים שהיא ממלאת פער ספציפי שאף פלטפורמה אחרת לא נותנת לו מענה. הנה מסגרת כנה לאיזה כלי מתאים לאיזה use case:

Triage התראות SOC בענן טהור (ניתוח פישינג, העשרת איומים, פתיחת tickets) → Torq או Tines מצוינות. תשתמשו בהן.
Workflows חקירת אירועים מורכבים (פורנזיקה רב-שלבית, בלימה, חיסול) → Cortex XSOAR או Splunk SOAR. נבנו בדיוק לזה.
סנכרון מעטפת hybrid-cloud (AWS SGs ל-firewalls on-prem, AD ל-ACLs, ניהול מדיניות cross-vendor) → Cyberm8. הפלטפורמה היחידה עם primitives מובנים, עקביות טרנזקציונית, והרצה on-prem.
אוטומציה באזורי isolated network / OT (זרימת נתונים חד-כיוונית, טופולוגיית data diode, עמידה ב-IEC 62443) → Cyberm8. הפלטפורמה היחידה שפועלת ללא קישוריות נכנסת.

הארכיטקטורה הטובה ביותר משתמשת בכלי הנכון לכל עומס. תשתמשו ב-SOAR שלכם לאיומים. תשתמשו ב-Cyberm8 לתשתית. תנו לכל מנוע לעשות את מה שהוא נבנה בשבילו.

ראו את ההבדל בשידור חי

תביאו את רשימת ההערכה שלכם. נריץ את תרחישי הבדיקה שלכם מול יעדי firewall אמיתיים ונראה לכם איך עקביות טרנזקציונית נראית בפועל.

בקשו POC תחרותי ← info@cyberm8.com | ראש העין, ישראל