00:45 על עומר ו-Pentera
- (עומר) אז נעים מאוד - עומר. הצטרפתי ל-Pentera - השם הקודם היה בכלל Pcysys, אבל אנחנו מנסים לשכוח את זה . . . - בתחילת 2018.
- כחלק מה-Batch הראשון של המפתחים שהצטרפו לחברה.
- החברה קמה כבר ב-2015.
- התחלתי כמפתח, עשיתי מגוון תפקדים - והיום אני VP Engineering בחברה.
- ו-Pentera היא בעצם חברת-מוצר, שמפתחת פלטפורמה לביצוע מבדקי-חדירות אוטומטיים.
- מה שנקרא Automated Pen-Testing.
- כדי להבין את הבעיה ש-Pentera פותרת, אני חושב שצריך לחזור רגע לאיזושהי הנחת-יסוד - שבעולמות ה-IT, ה-Best Practice הוא בעצם לבצע Pen-Testing כדי לבדוק את הרשת הארגונית.
- תחת ההנחה שאתה לא יודע איפה אתה פגיע עד שלא בדקת.
- רק שיש איזושהי בעיה קטנה עם כל העולם הזה - שהוא ידני . . .
- והקצב שבו הרשת משתנה, שהוא שעתי, לא מאפשר לתהליך כזה להיות ידני.
- [למיטבי-שמע - 422 Pentesting with Erez Metula]
- אז בעצם, הפלטפורמה שאנחנו מפתחים עושה את המבדקי-חדירות - ממש “שמה לך את התוקף בכף- היד”, שאתה יכול, On-Demand, להריץ אותו.
- למה זה טוב, בנוסף? כי אתה רוצה לבדוק את עצמך לא בשעות-העבודה, לא על ידי בנאדם שצריך לאכול, להפסיק, ללכת לישון . . .
- ואתה רוצה לבדוק את עצמך גם במקרי-קצה.
- מה גם שניקח רגע את התהליך הידני וננסה לדמיין אותו - נגיד שהגיעו בודקים, עשו את מה שעשו, עבדו שבועיים בארגון . . .
- נגיד שהמבדק היה מעולה - ואחרי זה הם נותנים לך איזשהו דוח.
- הלכת ותיקנת, אוקיי, מה עכשיו? נחכה עכשיו עוד שנה כדי לראות שמה שתיקנתי בכלל עבד, או איזה אפקטי-פרפר הוא עשה?
- הרעיון פה הוא להריץ עוד פעם בדיקה On-Demand - וככה אתה יכול לוולדץ (To Validate) את זה שעשית עבודה טובה.
(אורי) זה בעצם לקחת את הרעיון של Automatic Testing - ה-Unit Tests, System Tests, שאנחנו מכירים מאיכות של תוכנה - “ולהלביש אותו" על Penetration Testing?
- (עומר) עם אפילו עוד קצת יותר אבסטרקציה, אפשר לאטמט (Automate) הכל.
- אז גם פה, במקום לעשות בדיקה ידנית ל-Feature שעשית - אז כן, זה בדיוק אותו קונספט.
(רן) בוא ניתן לזה קצת צבע . . . ודרך אגב, לא הרבה יודעים - תמיד רציתי להגיד את זה - “לא הרבה יודעים”, אבל אני התחלתי את הקריירה שלי בתור Pen-Tester.
אז פעם, דברים שהייתי עושה לפני די הרבה זמן, זה סריקות Port-ים, סריקה של כל מיני Resource-ים עם ACL-ים לא נכונים, ניסיון להריץ כל מיני “סקריפטולוגיה” (Script) של דברים שמוכרים, שיודעים שיכולים לפרוץ, כמו SQL-Injection ומיליון דברים אחרים, שאני בטוח שמאז נולדו הרבה כאלה. [שאל את יוסף - The Dark Side of AI: The Hidden Risks in Open-Source AI Models / Jossef Harush Kadouri]
זאת אומרת, זה סוג ה-Pen-Testing שאנחנו מדברים עליו?
- (עומר) ממש כך.
- מה שהמערכת עושה - היא מחקה את פעולות-התקיפה שתוקף אמיתי היה עושה, ולא נותנת לסימולציה או ל-Playbook-ים להיכנס.
- כלומר, אפשר לדמין איזושהי מכונת-מצבים סופר-מורכבת, עם איזשהו Exponent של מצבים
- שכל פעם, המכונה צריכה לקבל את ההחלטה הטובה ביותר, כדי לחלחל את ההתקפה ולהתפרץ לארגון -
- עד שמגיעה ל-Crown-Jewel בתוך הארגון.
- אז בעצם, זה מידול של תהליך התקיפה.
(רן) שאלה תם - איך אתה יודע שאתה לא מזיק בזמן שאתה בודק?
- (עומר) אנחנו נורא אוהבים את השאלה הזו . . . יש המון אנרגיה והשקעה במחקר.
- יש לנו, אני חושב, באחוזים, את קבוצת המחקר מהגדולות שיש בחברות מהסוג שלנו.
- כל ה-Payload-ים וכל ה-Cyber וכל התקיפות וכל המנגנון שמשנע את התקיפה - מפותח על ידינו.
- אנחנו חיים במרחבים שהם בטוחים - אנחנו לעולם לא נעשה משהו שמתעסק עם Kernel-ים או התקפות מסוג Denial of Service וכדומה.
- ואנחנו ממש חרטנו את זה על דגלנו - ש-Safety by Design.
- אנחנו יודעים לזהות את הצורה שבה המערכת נמצאת כרגע - ואנחנו יודעים לעדכן מה קרה במקרה שמשהו השתבש.
- וכשאני אומר “משהו השתבש” - זה פיזיקה, שלא הצליחה לקרות.
- אז אפשר לדווח על זה.
- ויש כל מיני Safe-Guard-ים כאלה.
(רן) אוקיי, מה גודל החברה? פחות או יותר ש...
- (עומר) גודל החברה? אנחנו היום כמעט 350 עובדים בכל העולם.
(רן) ופיתוח?
- (עומר) HQ ופיתוח בארץ; הפיתוח - סדר-גודל של פלוס/מינוס 50 מפתחים.
(רן) אוקיי.
(אורי) תגיד, יכול להיות שבאחת השנים האחרונות, חברה מאוד בולטת בתחום שלכם נפרצה בעצמה - ואז חלק מהמתודולוגיות שלה זלגו לעולם ההאקרים, ל-Dark Net? יכול להיות שהיה דבר כזה?
- (עומר) אם יכול להיות?
(אורי) לא, כאילו אני חושב זה פורסם . . . [הכוונה לכיף הזה - The Leaked NSA Spy Tool That Hacked the World או אולי לקרקס בין Cellebrite ל-Signal?]
- (עומר) אני לא מצליח לשלוף . . . . אבל אני חושב שבאופן כללי, זה יהיה יחסית קשה לפרק, לעשות Reverse לדבר הזה.
- כלומר, אתם מדבר על המתודולוגיות של איך מנהלים תקיפה בצורה אוטומטית, לאו דווקא על המידע שיש בו . . .
(אורי) לא, גם כאילו - ברגע שיודעים איזה תקיפות חקרתם, או איזה תקיפות אתם מסמלצים (Simulate), אז כאילו,
פתאום יש המון מידע על איך לתקוף.
(רן) זה כמו שלמי שמפתח וירוס, יותר קל לו אם יש לו את ה-Antivirus, אז זה יודע . . .
- (עומר) אז נכון. אנחנו לא מסמלצים תקיפות - אנחנו תוקפים, הלכה למעשה.
- אבל התשובה היא “כן” - אם הקוד שלנו לנו יגיע לידיים לא נכונות, יהיה נורא ברור איך אנחנו יכולים ועושים את מה שאנחנו עושים.
07:06 מי תוקף ואיך לחשוב SaaS-ית
(רן) אוקיי, אז הבנו בגדול מה החברה עושה. עכשיו בואו נדבר על המורכבות.
אז למעשה, המוצר שלכם התחיל בתור מוצר On-premises, נכון? זאת אומרת, אנחנו נותנים ללקוח, הוא מריץ, או אולי אנשים מטעמכם מריצים, אבל על חומרה שלו, בתוך Data Center שלו. והנה הגיע הענן . . .
- (עומר) נכון.
(רן) והחלטתם אתם שגם אתם רוצים לעננים . . .
- (עומר) נכון. אז אני אנסה לעשות סדר, בצורה יחסית תכליתית.
- קודם כל - יש מגוון מרחבי-תקיפה.
- כשהחברה קמה, החלטה אסטרטגית - לתקוף מתוך הארגון, Pen-Test ל-Infrastructure.
- יש המון מרחבים - יש מרחב מחוץ לארגון, בתוך הארגון, יש Cloud, יש IoT, יש OT, יש המון עולמות . . . [הרבה על זה כאן - גיקונומי פרק #881 – יבגני דיברוב וארמיס].
- תחת ההנחה של Assume Breach - תניח שהתוקף בתוך הארגון שלך - אמרנו, המוצר שלנו צריך להיות מוצר On-premises.
- יש יתרונות, יש חסרונות - לא כל כך משנה עכשיו.
- אז זה המוצר הראשי שלנו.
- כשהחברה עברה את סבב-הגיוס השני שלה - באזור 2021 - החלטנו להרחיב את סט-היכולות, כדי להגדיל את ה-Business, לעשות Cross-Selling, Up-Selling וכו’.
- והחלטנו להנגיש את היכולות שלנו - פשוט מבחוץ.
- כלומר, ה-Use Case השתנה: במקום תקיפה מתוך הארגון, תקיפה מחוץ לארגון.
- כלומר, התוקף יושב בחוץ - ומנסה להתפרץ פנימה.
(רן) ואלו אותן תקיפות, בגדול?
- (עומר) אז יש חפיפה גדולה מאוד בין התקיפות - אבל חלק מהעסק היה להמציא יכולות Cyber שלא קיימות, אני אוכל לתת קצת דוגמאות . . .
- למשל, כשאתה בתוך הארגון - אז אתה כבר בתוך הארגון. כל מה שאתה צריך זה Port בקיר.
- יש לך כתובת IP, נגיד, אתה עושה איזושהי שאילת את Broadcast, עונות לך מלא מכונות - ואתה אומר “אוקיי, זה ה-Context שלי”.
- זה שלב ראשון בתקיפה - אני רוצה להבין מי במשחק.
- מבחוץ, בואו ננסה לחשוב על זה - אני לא יכול לעשות Broadcast ל-0.0.0.0.0.0, אני אקבל את כל העולם . . . .
- אני צריך מודל אחר של להבין מה ה-Context שלי.
- אז פה, אני מחשיב את זה תקיפה, נכון? כי זה חלק מ”מעגל התקיפה”. היינו צריכים לבנות בכלל מודל Cyber חדש, של לנסות להבין, “אוקיי, מה ה-Asset-ים של הארגון?”
- אנחנו עובדים ב-Mode של Black Box, וכל מה שאני רוצה לדעת עליך כארגון זה את ה-Domain שלך, שזה Reversim.io [נגיד… reversim.com].
- מכאן אני מתחיל לשאול שאלות - מי כתב את ה-Domain? על שמי הוא רשום? . . .
- (אורי) יש לנו את Reversim.io?
- (רן) אולי כדאי שיהיה לנו . . .
- (עומר) אז יש גם Use Case כזה . . .
- (רן) אנחנו עוד מבועת ה-Dotcom - אבל שלא יגנבו לנו ויכניסו לנו סוס טרויאני, אולי כדאי . . .
- (עומר) אז זה רגע השוני - ויש גם הרבה חפיפה.
- בסוף אם ננסה לתת פה איזשהו דימוי - “קליע Cyber”, כלומר Payload או איזושהי יכולת - לא משנה לה כל כך מי יורה אותה, אוקיי? העיקר שהיא פוגשת את המטרה שלה.
- אממה? כל “מכונת-הירייה” הזאת צריכה רגע להשתנות.
- אז (1) - שהחלטנו, עסקית, להציע עוד מוצר לתקיפה מבחוץ - זה מיד גוזר SaaS . . .
- אין דבר כזה - “תקיפה מבחוץ, ב-On-premises”.
- אז ההחלטה הייתה להקים מוצר Pentera - שה-Use Case הוא תקיפה מבחוץ.
(רן) אתה עדיין יכול להריץ את זה על איזושהי חומרה שלך. זה לא בהכרח חייב לרוץ בענן, אבל אני מסכים - זה יותר הגיוני, זה יותר קל . . .
(אורי) לא משנה, SaaS זה SaaS . . .
- (עומר) אנחנו סטארטאפ, כאילו זה...
(רן) לא, ברור - פרקטית, זה יותר קל.
- (עומר) בדיוק. אוקיי, אז עכשיו, יש שני אתגרים גדולים שקורים בחברה.
- 1 - פוקוס. בסדר? כלומר, הדבר הכי חשוב ל...
(אורי) מה שקורה תמיד, שאתה נהיה Multi-Product, נכון?
- (עומר) בול. וזה גוזר עוד המון דברים. אפשר, אם יהיה זמן, להגיע אליהם - מבנה ארגוני, איך ה-Sales מקבלים את זה? מה האסטרטגיית Go-to-Market? עולם ומלואו.
- אבל בואו נסתכל ונתמקד רגע ב-R&D - אז פוקוס של ה-R&D.
- והדבר השני - שיש פה גישה בכלל חדשה - “לחשוב saaS-ית”.
- וננסה רגע לפרק את זה.
- אז הקמנו צוות - ממש קרענו את ה . . . בין שניים לשלושה מפתחים, בין שניים לשלושה חוקרים - ולי הייתה את הזכות להוביל את זה.
- ואמרנו יעד, תאריך - ושם המוצר עולה ל-Production,
- ומכאן התחיל המסע.
(רן) אז אנחנו מדברים על צוות של חמישה?
- (עומר) בסדר גודל . . . תוך כדי הצטרפו אחד-שניים,
- היינו אפילו בלי DevOps, QA . . .
(רן) מה הקבועי-זמן, פחות או יותר?
- (עומר) היעד היה כשלושה רבעונים - ולרוץ.
11:42 נצלול לטכנולוגיה - עולם אחר
(רן) והבנתם איזה מוצר אתם רוצים לבנות? איזה Sub-Set של המוצר?
- (עומר) לגמרי כן, לגמרי כן.
- ועכשיו, בואו נצלול רגע לטכנולוגיה.
(אורי) אז זה גם עולם . . . זה כאילו מוצר חדש - שפותר עולם בעיה חדש. זה לא, כאילו, תקיפה מבחוץ, זה שונה לגמרי מתקיפה מבפנים.
(רן) כן, אבל רגע, אני חושב ששווה להדגיש כמה דברים לפני שאתה ממשיך. אחד, בעולם ה-Security, יכול להיות שיש אילוצים קצת שונים, כשאתה מפתח איזה שהוא SaaS. זאת אומרת, אתה לא רוצה “לתת לדרקון להשתולל בחוץ“, באינטרנט, בזמן שאולי On-premises זה קצת יותר קל להגביל אותו בחוץ. אז אתה צריך קצת יותר שליטה על זה.
ושתיים, יכול להיות שיש טכנולוגיות, או יש Stack טכנולוגי, שפיתחתם - שעבד מעולה On-premises. לצורך העניין, לא יודע - Database-ים קטנים כאלה, שעכשיו פתאום צריך לשבור את הראש איך עושים לזה Scale רוחבי או whatever. כלומר, בונים איזה משהו “SaaS-י”.
זה היה גם Scale אחר לגמרי של הבעיה?
- (עומר) עולם אחר. עולם אחר . . . ב-On-premises, אמנם אתה “בתוך קופסא”, אבל ה-Scale שלך הוא ה-N לקוחות שיש לך. אז יש N קופסאות, N לקוחות . . . .
(רן) זאת אומרת, בתוך הארגון - יש לך אלף Node-ים אז יש לך אלף Node-ים, זה העולם שלך. באינטרנט . . .
- (עומר) יש עולם של Scale בתוך הארגון . . . אנחנו ממש עכשיו בתהליכים מאוד יפים.
- זה גם קורה - אבל זה שונה.
- למה? אם אנחנו מסתכלים רגע על המערכת שלנו, אז בואו נחלק, שבור אותה לשני Domain-ים מרכזיים.
- אחד - ה-Domain של מערכת-התקיפה - “מכונות הירייה”, כמו שקראתי להן, מה שמשנע את ה-Cyber.
- שזה קצת פחות אינטואיטיבי למי שלא בתוך החברה.
- והחלק היותר אינטואיטיבי, שזה ה-Domain השני - זה בעצם האפליקציה: המסך Login, ה-Inventory, ה-Report-ים, הנוטיפיקציות (Notifications), איך אני מנהל . . .
- בעצם, “מה שהלקוח נוגע בו”.
(רן) אתה בעצם הופך מ-Single - ל-Multi-Tenant.
- (עומר) בול. וזה אחד האתגרים הראשונים.
- עכשיו, בואו ננסה לעשות חיבור בין סטארטאפ צעיר, שרץ מהר ו-On-premises - מה הסיכוי שהקוד שכתוב שם, יצליח...
(אורי) יהיה רלוונטי בכלל . . .
- (עומר) ופה התחילו...
(רן) זה מריח כמו Refactor גדול . . .
- (עומר) נכון, אז אוקיי . . .
(אורי) או... לא יודע - זה נשמע לי כמו פשוט בנייה מחדש, כי זה עולם בעיה אחר.
(רן) יפה, זה עוד דילמה, נכון? זה עוד דילמה - אם לבנות מחדש או להשתמש במה שקיים?
- (עומר) מדויק.
- אז בכוונה עשיתי את החלוקה הזאת לשני האזורים - כי אני אעבור ביניהם, וננסה להבין מה היה קצת יותר קל לעשות לו Adjustments, ומה היה הרבה יותר מאתגר.
- אז אם רגע נלך למרחב האפליקטיבי (Applicative), אז דברים כמו - רן, שאתה ציינת
- נגיד Single-Tenant לעומת Multi-Tenant: מעולם לא נכתב קוד שאמור לטפל ב-Multi-Tenancy של User-ים . . .
- זה נשמע כאילו פשוט, אבל רגע - לא. צריך לכתוב את זה From Scratch.
(רן) זה משהו שקל לטעות בו, מניסיון . . . אתה כותב, אתה מניח שרק אתה בחי ב-Database - ופתאום יש לך עוד לקוחות בתוך אותו Database, ואתה מתחיל לאבד רשומות . . .
- (עומר) נכון, אז זה משהו שהיינו ערים אליו, ועשינו מ-Day One.
- הדבר הבא זה שאתה צריך להחליף את כל ה-Infrastructure . . .
- עכשיו יש לך Ansible, שעושה לך Deployment למוצר On-premises . . .
(אורי) אגב, זה לא מחויב המציאות שיהיה לך Multi-Tenancy. מה זה משנה אם אתה SaaS או לא SaaS? בסוף יש לקוח. כאילו, יש לפעמים שיטת Scaling שאומרת “בואו, לכל לקוח אני בונה Swimlane, אף אחד לא מפריע לאף אחד, ושוחים בנפרד”. זה לא בהכרח . . . כאילו, לא מחייב להיות Multi-Tenant על כמה לקוחות, או על...
- (עומר) נכון, אז אני חושב ש...
(אורי) זה לפעמים יותר יעיל במשאבים, אבל זה לא מחייב.
- (עומר) נכון, אני מסכים. זה ה-Mode פעולה שבחרנו פה, הוא עשה לנו שכל.
- ומעבר לאתגר הזה, היה לנו את האתגר של לשמור על “הלינגו” של המוצר.
- כלומר, בואו נחשוב על דברים מאוד טריוויאליים ללקוח - הממשק, איך נראים ה-Logo-ים, הצבעים, מפת התקיפה, הטבלאות . . .
- כל הדברים שלקוחות שלנו כבר ציפו לראות אותו דבר.
- אז מה עושים? שכפלים את הקוד? ברור שלא, נכון? אנחנו החלטנו ש...
- הייתה פה הזדמנות טובה לקחת איזשהו Monolith, שחי ב-On-premises - החלטנו לא לגעת בו, ופשוט לכתוב אותו מחדש.
(רן) כן, כמו שאומרים אנשי המכירות ואנשי המוצר - “מה הבעיה? את הדבר הזה - פשוט תעשה שם”.
- (עומר) אני מת על זה, כן . . .
(רן) . . . “ זה כבר עובד! אז רק נשאר לך לפרוש את זה שם, וזהו”. [Tony Stark Was Able To Build This! In A Cave! With A Box Of Scraps…]
- (עומר) “מה הבעיה? תגיעו לירח, ואז . . .”. כן.
- אז גם היינו צריכים לשמור על רכיבים גרפיים, על קומפוננטות (Components), על כל מיני דברים לוגיים שהיינו חייבים לשמור עליהם לטובת הלקוחות.
- אז פה יצאנו לאיזשהו מסע של Shared Components.
- החל מכמו שאמרתי, רכיבים גרפיים ועד ספריות בקוד.
- כלומר, איזושהי לוגיקה שצריכה לחיות גם ב-On-prem וגם פה.
- אוקיי, צריך להתחיל לעשות אבסטרקציה, ו”להוציא דברים למעלה”.
16:55 ה-Stack הטכנולוגי
- (עומר) כן, אז Ansible, אני רק אגיד, כבודו במקומו מונח.
- אנחנו בדיוק בתהליכים - בגלל ה-Scale שלנו, המערכת היא כבר גדולה - אנחנו עושים פרויקט מדהים של לשכתב הכל מחדש, ולכתוב ולהיפטר מ-Ansible, עוברים ל-Python.
- אז יש Python, יש Java, יש DocumentDB.
- יש לנו המון שפות Low Level שקשורות ל-Cyber, ו-Stack-ניטור . . . כל מיני דברים נחמדים כאלו.
- (עומר) אז React, כן.
- אחלה, אז עכשיו - אנחנו לא יכולנו לקחת את כל האופן שבו דיפלטנו (Deployed) את המערכת ב-On-Premises.
- יש פה עכשיו Infrastructure-as-Code From Scratch - עוד איזשהו אתגר.
- אני חושב ששם, הדבר שראינו זה שהיה לנו נכון לדפלט (Deploy) את כל ה-Service-ים החדשים שבנינו כמה שיותר מהר.
- במקום להתחיל לעשות איזושהי Over-הנדסה, ואז לראות איפה צווארי-הבקבוק.
- מדברים על זה הרבה, אני חושב שידענו להפריד מה מראש צריך Scale - כמו נגיד Stack-ים של תקיפה, שצריכים לקום פר-דרישה של לקוח (On-demand), או חישובים כבדים, כמו Reports וחישובי Inventory למיניהם.
- אז אלה הדברים שידענו מראש שאנחנו רוצים להתחיל מההתחלה כסוג של Service-ים בפני עצמם.
- אבל רצנו מהר קדימה עם איזשהו Monolith
- מתוך ידיעה שאנחנו נשקיע מאוד באיך שה-Monolith בנוי - DAL-ים, DAO Services, DTOs . . .
- ממש הכל מאוד מאוד Decoupled בקוד.
- זה היה מאוד מאתגר, אבל נכנסנו לזה בידיעה - כדי שכשיגיע היום, יהיה לנו ונוכל לבנות ולדפלט (Deploy) מחדש את ה-Service-ים כמו שצריך, ו . . .
(אורי) “ונשבור את ה-Monolith!”
- (עומר) בדיוק. אנחנו שלוש שנים לתוך התהליך הזה, ואני יכול להגיד - לא נשברו הרבה Service-ים.
- זה לא מפתיע אותי, אבל יש שניים-שלושה Service-ים שהוצאנו מה-Monolith.
- אז אנחנו מתנהלים ב-Mono-Repo החדש הזה, שהחלטנו ללכת עליו . . .
(אורי) מה גודל הצוות היום, שעובד?
- (עומר) כמעט שישה מפתחים . . .
(אורי) אני חייב להגיד לך משהו - לפעמים, השבירה ל-Service-ים היא פונקציה של גודל הצוות, ולא של גודל העומס או דברים כאלה. אתה במקום סביר לגמרי . . .
- (עומר) כן, שמח לשמוע.
- כן, היה חשוב לנו מאוד לא לבוא עם איזשהו פתרון - ואז להתחיל לחפש לו בעיה
- אלא ממש רגע להתקל בבעיה, ו . . .
- יש אתגר אחר, שאומר “אוקיי, אתה אמנם רוצה לצאת עם MVP - אבל . . .”
- זו בעיה שוב מעולם ה-Business של “האם הארגון יכול לקבל MVP בכלל?”
- כי הארגון באיזשהו מקום אחר: יש איזשהו מוצר ראשי, קדימה - מצפים ממך להרבה
- אבל זה לא כזה משנה, אתה יכול לסמלץ (Simulate) - עליתי לProduction, יש לקוחות, עכשיו אני מתחיל ללכת על זה.
(רן) כלומר, יש לך מוצר קיים, אתה רוצה לעשות ללקוח Up-Sell ל-Feature נוסף - הוא יצפה לאותה איכות. אתה לא יכול לתת לו משהו . . .
- (עומר) בדיוק. הוא לא סלחן, זה לא מעניין אותו שיש קונספטים של פיתוח שקוראים להם “MVP” . . .
(אורי) אבל מן הסתם התחלתם עם סט פיצ'רים מסוים, ואחר כך היו הרבה פיצ'רים שאמרתם “את זה נשאיר לאחר כך”, נכון? לאחרי העלייה.
- (עומר) חד משמעית, חד משמעית. את הדברים הממש . . . ה-Flow-ים “הרגילים”, של User Login וניהול של ה-Inventory, ו-Dashboard-ים, ו-Report-ים.
- עכשיו אנחנו כל פעם מוסיפים קצת, חותכים מה שצריך.
- אבל כן, זה הסיפור.
20:42 אספקטים של Pen-Testing במעבר לענן / “ברוך הבא לעולם ה-SaaS”
(רן) בהקשר הזה - של לייצר פיצ'רים חדשים, אבל גם להיות רזה - אז אולי שווה להזכיר מתודולוגיה, שאני חושב שקיימת ב-AWS, יתקנו אותי אנשים שמכירים, של אחד, קודם כל, מוציאים PR או כותבים את ה-PR בסוג של PRD. כלומר, אנחנו יודעים מה אנחנו רוצים לשחרר, ואז דואגים לשני פיצ'רים חשובים: אחד - Security ושתיים - Scale. כל השאר יבוא אחר כך.
זאת אומרת, מבחינת פיצ'רים מוצריים, מתחילים בחסר, אוקיי? זה ברור. ישנם דברים שכן צריך לדאוג להם - שזה יכולת לעשות Scaling ויכולת לעשות שהדברים האלה יהיו Secure.
ובהקשר הזה, רציתי לשאול, זאת אומרת - יש לא מעט אתגרים, בעולם תוכנה גנרי, של לעבור מ-On-premises לענן.
אבל איזה אתגרים מיוחדים מצאתם בעולם של ה-Cyber Security, וספציפית בעולם של Pen-Testing? כלומר, מדובר פה על אחריות כבדה, אוקיי? אתם נותנים “מכונות ירייה” לאנשים, אתם רוצים לדעת שאתם נותנים את זה לאנשים הנכונים, ושהם עושים בהם שימוש נכון. שאם הם פוגעים במישהו, אז הם יפגעו בעצמם, שהם לא יפגעו באחרים. לצורך העניין, מה מונע מחברה מסוימת לבוא ולתקוף - אפילו בטעות - אבל לבוא ולתקוף חברה אחרת?
וזהו, איזה אספקטים מעניינים מבחינת Pen-Testing, גיליתם במעבר לענן?
- (עומר) מעניין מאוד . . . אני חושב שקודם כל, זה מדויק מה שאמרת - ברגע שאתה נותן כלי תקיפה, ושם אותו בידיים לא נכונות, זה פשוט לא לוקח.
- המגבלות בענן הן קצת . . . By-Design, האינטרנט הוא קצת יותר מגביל במה שאתה יכול לעשות.
- לדוגמה, אין לך גישת Layer-2, בסדר? אז זו שכבה שתוקפים “אוהבים לשרוץ בה”, אז צריך לוותר על זה.
- אז עכשיו אתה נגיד צריך לעבוד בשכבת ה-TCP - ה-Cloud Vendors לא מאפשרים לך לעשות את דברים שהם לא שם.
- זה אתגר ראשון. כלומר, אתה צריך לוותר על הרבה מהתקיפות שלך.
- אתגר שני, שלטעמי היה המשמעותי ביותר, זה איך לבנות את המודל שאותו אתה תוקף.
- כשאני אומר “מודל”, זה בעצם “את הלקוח”.
- אמרנו, אם זו רשת ארגונית - אתה רק פותח עיניים: “אוקיי, אני מתוך הרשת, הכל במשחק”.
- פה אני בחוץ - ועכשיו אני צריך להבין מה שייך ללקוח שלי.
- הלקוח לא יכול לכוון את הכלי לאן שהוא רוצה - הוא לא יכול להגיד “רוץ לכתובת IP כזו” או “רוץ לכתובת או ל-Domain ספציפי”.
- היינו צריכים לבנות איזשהו אלגוריתם שבונה את המודל.
(רן) “הוא לא יכול” - כי זה לא נכון לכם מוצרית, או כי אתם רוצים בכוונה להגיד . . . ?
- (עומר) הוא לא יכול כי אין לו שליטה, אין לו שליטה על זה.
- המודל נבנה בצורה אוטומטית על ידינו, סוג של איטרציות (Iterations) של שאלות כאלה.
(רן) אז אמרת נגיד קודם - הולכים נגיד ל-DNS, בודקים על שם מי זה רשום, מחפשים עוד כאלה . . .
- (עומר) נכון, אז בואו נפתח את זה קצת - אז נגיד על שם מי זה רשום? אולי הוא רשם עוד Domain-ים? מצוין.
- עכשיו, נתחיל לעשות אינומרציות (Enumerations )של ה-Sub-Domains - אני אגלה שיש לך את App [.app] נקודה, את Dev נקודה, את Staging נקודה, את Prod נקודה, whatever . . . מעולה.
- אז עכשיו העשרתי את ה-Database שלי.
- אחרי שיש לי Sub-Domains, השלב הבא - אני מתקדם לריזלוב (Resolve) של כתובות IP.
- יפה, אז עכשיו יש לי כתובות IP, מעולה.
(רן) אז אתה מחפש מה הבלוקים . . .
- (עומר) ועכשיו רואה אם הוא רשם את זה - ועכשיו אני יכול להצליב את השם שלך, ואת הכתובות IP של ה-Sub-Domain-ים שלך.
- אני יכול רגע לראות איזה Network Blocks רשמת - ועכשיו אני יכול לסרוק את ה-Network Blocks.
- אז עכשיו, על כל כתובת IP, אני יכול גם לעשות סריקת Service-ים - איזה VPN-ים רצים, איזה Website-ים יש לך . . . מעולה.
- יש עוד מימד שלם של Identities - אנחנו יודעים גם, בחלק מהמודולים שאנחנו מציעים, זה להבין האם הייתה לך איזושהי דליפה בארגון.
- ואנחנו יודעים להביא אולי סיסמאות או מידע רגיש שהגיע.
- מה שעשיתי עכשיו - יריתי פה המון Atrifact-ים, המון Asset-ים שיש בארגון.
- אבל עכשיו צריך להבין . . . אוקיי, אז רזלבתי (Resolve) כתובת IP - אבל אולי היא של AWS? מאיפה אני יודע אם זה Owned by You או לא?
- אז פה נכנס כל האלגוריתם של להבין מה שייך לך ומה לא.
- קראנו לזה Confidence - אני נותן ציון לכל Asset, ולפי איזשהו Threshold מסוים אני יודע להגיד האם הוא שייך לך או לא.
- כלומר, אוי ואבוי אם אני אתקוף כתובת IP, שהיא לא שייכת לך . . . . או ה-Website שהוא לא שייך לך.
- אגב, ה-Cloud Providers מגבילים אותך
- אתה יכול לעשות Pen-Testing - אבל בהסכמה, וב-TCP, בסדר?
- כלומר, מאוד קל לעשות שטויות . . .
- איפה שהמנגנון לא בטוח . . .
(רן) דרך אגב, מה הם נותנים לך? לתקוף את מי שהם מארחים ב-TCP? או שכשאתה כשאתה נמצא אצלהם, מותר לך לתקוף אחרים, רק ב-TCP?
- (עומר) אופציה ראשונה . . .
(רן) אוקיי.
- (עומר) אתה יכול לתקוף את עצמך.
(רן) כלומר, לצורך העניין, הלקוח יכול להיות בכל מקום - על ענן כלשהו או לא. אבל אתה כנראה Deployed, נניח ב-AWS, אז זה כבר שם עליך איזה שהם מגבלות.
- (עומר) נכון.
(אורי) רגע, הרמת לי ל...
(רן) אורי אוהב את זה . . .
(אורי) לא, לא, לא . . . מן הסתם, ה-Cloud Providers - אחד הדברים שהם לא אוהבים זה שתוקפים משתמשים בתשתית שלהם כדי לתקוף. זה לא אתי, זה לא טוב, לא יפה וכו’. אבל אתה מתחזה לתוקף . . .
- (עומר) נכון, אני תוקף. זה ה-Business שלי. אני...
(אורי) לא, אבל השאלה היא האם הייתם צריכים לדבר - אני לא יודע על איזה ענן אתם מתארחים, So-called *AWS - לדבר איתם ישירות, ולהגיד “זה ה-Business שלנו, שתדעו. זה מה שאנחנו עושים”.
- (עומר) נכון, אז זו בדיוק הנקודה. יש Pen-Testing Policy לכל אחד מה-Vendor-ים האלה, ואתה חייב לעשות את זה בשיתוף פעולה. זה לגיטימי.
- תחשוב, עזוב - בוא נוציא אותי מהמשוואה ואת הסיפור פה מהמשוואה. תחשוב . . .
(אורי) אתה כנראה לא ה-Pen-Tester היחיד . . .
- (עומר) בדיוק. אתה רוצה לעשות Pen-Test לעצמך - פשוט תפעל לפי ה-Policy.
- זה האירוע הפחות מאתגר, בסדר?
- האירוע יותר מאתגר זה איך אתה לא מבדר את התקיפה לאזורים שהם לא של הלקוח.
- אז גם פה, עכשיו, היינו צריכים לקחת את כל הרכיבים האלה - ולא הגיוני להגיד ללקוח “חכה, מתישהו המערכת תגיע לשם”.
- היא לא נכתבה ככה בכלל, היא ל-On-prem - זה שלך, תשתמש בזה כמה שאתה רוצה ב-On-premises.
- פה, עכשיו, אנחנו צריכים לחשוב על Scale-up.
(אורי) לא, אבל זה לא אותו מוצר בכלל . . .
- (עומר) אז אני חוזר לשני ה-Domain-ים - כל מערכת התקיפה היא בדיוק אותה מוצר.
- לא משנה לה איזה לוגיקה היא מריצה בפנים - אבל היא צריכה עכשיו לדעת לעשות Scale.
- ופה, זה היה החלק שהיה יותר קל לנו - לקחת Container-ים, לארוז אותם לסוג של Cluster כזה.
- ולפי דרישת הלקוח - סוג התקיפה שהוא רוצה, יש מגוון סוגים של תקיפות שאנחנו מציעים - אנחנו יודעים להעלות לו את ה-Cluster הרלוונטי, לשם תכלית ספציפית.
- מתבצעת עבודה, יורד - הולך הביתה. בסדר?
- כאן בעצם ה-Scale-Out הוא . . . תיאורטית הוא אינסופי.
- כמובן שאתה נתקל בכל מיני מגבלות, של Service Quota והרבה דברים.
- זה גם לוקח אותי לנקודה, שבה אני חושב...
(אורי) . . . סליחה, זה גם Load מאוד מאוד משתנה, נכון?
- (עומר) Load מאוד משתנה. יש הרבה Compute והרבה Memory בתקיפה, אין ספק. משמעותי מאוד.
(אורי) לא, אבל זה עולה, זה יורד, אין לזה שעות קבועות, אין לזה זמנים קבועים . . .
- (עומר) נכון, ובהגדרה - אני לא יכול להחזיק את כל ה-Stack הזה באוויר כל הזמן.
- ואז זה לימד אותנו עוד מימד, שאני ממליץ לכל מי שעושה את המעבר הזה, שרגע צריך לחשוב על זה - עלויות.
- זה נשמע גם טריוויאלי, אבל אתה צריך איזשהו Cost Strategy, שאין לך ב-On-prem - כי אתה לא משלם על “הברזלים”.
- פה זה כבר אירוע אחר.
- (עומר) חשמל, Memory, CPU . . . . פה זה עלויות שלך.
- זה משהו גדול, בסדר?
(אורי) ספר לנו על זה . . .
- (עומר) כן, אז אני אומר אתם מודעים לזה. מהחוויה של רגע לחשוב על הדבר הזה . . . .
(רן) כן, בחברה שבה אף אחד לא הבין Cost, פתאום יש חמישה מפתחים שכבר צריכים להבין Cost - ומחרתיים זהו עשרים מפתחים שצריכים להבין Cost . . .
- (עומר) זה המקרה הטוב . . .
- המקרה הרע הזה שיש לך טעות Cost, שיש “תאונת Cost” - וזה משהו שהוא קריטי בסטארטאפ צעיר, שלא יכול להרשות לעצמו תאונה כזו.
- אז בעולם שאין בו מגבלות תקציביות וכסף, פתאום זה משהו לחשוב עליו.
- עולם נוסף שנפתח כשאתה עושה את המעבר הזה, זה כל העולם של Monitoring ו-Security באופן כללי.
- פתאום אתה רואה, זה נהדר - אתה יכול לראות את ה-Service-ים שלך, אתה יכול לנטר אותם.
- זה כמובן משפיע מאוד על הפיתוח.
- עכשיו אוקיי ברור - זה היתרונות של SaaS - אבל זה עוד Effort שצריך לשים, כחלק מהזמן.
- אתה לא יכול להיות “עיוור” - אתה יודע, אתה מעלה איזושהי מערכת ו”טוב, מה קורה איתה?”.
- זה לא עובד.
- (עומר) אין גישה, נכון, אין גישה . . .
(אורי) זה פשוט אצל הלקוח . . .
(רן) כן, אני מבין - אבל עדיין, אין לך “כניסת שירות”? זאת אומרת . . .
- (עומר) אז תראה, יש דברים מאוד, שהם תחת Legal מאוד נוקשה . . .
- ואין לך Log . . . אין לך Log-ים נגישים - אתה לא יכול לזהות אנומליות, אתה לא רואה, אין לך ניטורים . . .
- אין לך EPM על המערכת.
- והדבר הכי טוב שאתה יכול לעשות זה לסמלץ (Simulate) אצלך את הלקוח.
- אבל זה לא באמת מספיק, כי כמות הסביבות שאתה נפגש בהן ב-On-prem, היא אינסופית, ממש אין סופית . . .
(רן) “זה עבד אצלי על המחשב” . ..
- (עומר) בדיוק.
(רן) כן, זאת אומרת - זה למעשה גם נותן לכם הזדמנויות, של ניטור לצורך העניין, ויכולת לעשות, אולי, Cost Saving - כשלפני זה אולי לא היה Cost, אבל פה אתם פתאום צריכים לחשוב על זה.
אז באמת, ה-Traffic שלכם הוא כזה Spikey? זאת אומרת, נגיד, פעם 12 בלילה - עולים אלף, עושים את העבודה שלהם ויורדים?
- (עומר) כן. זה ממש ככה.
(רן) אז זה דורש לבנות אורקסטרציה (Orchestration).
(אורי) ויותר מזה - יכול להיות שגם הרבה מזה הוא לא חזוי מראש, נכון?
- (עומר) נכון. אז כמו כל דבר שכותבים - צריך איזושהי מגבלה, אתה לא יכול לתת למשהו להיות לא מוגבל.
- לשמחתנו, אנחנו - כמובן שהתחככנו במגבלות, אבל אלו היו מגבלות “מטופשות”, של דברים שאתה לא חושב עליהם.
- כי גם אחת החוויות שאני באופן אישי ממש שמחתי עליה, זו איזושהי חווייה של שחרור צווארי-בקבוק.
- אתה פתאום עולה לעולם, כשאתה לא בתוך קופסא - אתה פשוט משחרר פה איזה מערכת.
- עכשיו, זה מדהים לראות באיזה צווארי-בקבוק אתה נתקל.
- אתה אומר “טוב, מה אחד? מאה!” . . . אין לי בעיה שלם על זה.
- אבל זה לא כזה פשוט - כי אז אתה רואה שיש לך איזו פונקציה, שהיא פשוט לא כתובה לזה.
- ואז אתה חייב לעשות Profiling, ולנסות לזהות את צווארי-הבקבוק.
- ואתה מגיע למגבלות שהן לא פיזיות בכלל - הן פשוט שהקוד כתוב בצורה, שמעולם לא “התחכחה עם Scale כזה”.
(אורי) זה פשוט “ברוך הבא לעולם ה-SaaS” . . . .
- (עומר) ממש ככה, זה... אני אומר - זו חוויה מאוד מאוד נעימה וטובה.
- וצריך לקחת את הדברים האלה בחשבון - כי זה לוקח זמן.
- פתאום יש לך איזשהו תהליך מרכזי, בתוך המערכת, אבל אתה אומר “טוב, עכשיו אני נתקע עליו?”
- וזה גוזר, מהר מאוד, השפעה על ה-Roadmap קדימה, ואיזה דברים חייבים להתעסק בהם.
(רן) כן. כמו שנאמר - “יש במדעי-המחשב רק שלושה גדלים: אפס, אחת, והמון”. [חשבתם לגייס Gully Dwarves ?]
- (עומר) בדיוק.
32:15 יש עוד מימדים
(רן) כן, אז אנחנו ככה ממש לקראת הסוף. אנחנו נגענו בכמה נושאים, אנחנו לא נגענו בהכל. אבל אנחנו דיברנו בעיקר על איך לוקחים מוצר שהוא On-premises בתחום של Pen-Testing - והופכים אותו, או חלקו, או אולי בונים מוצר דומה, במעבר לענן.
חלק מהדברים שתיארת הם גנריים, במעבר לענן - או דרך, אגב, גם מעבר הפוך, גם את זה עושים - והלקחים הם רלוונטיים: אם זה שיתוף קוד, אם זה לקחת צוות ואמרת “לקרוע” אותו, לשלוף משם אנשים באמצע ולבנות צוותים חדשים. אבל חלק כן רלוונטיים גם ספציפית בתחום של Pen-Test. אבל . . .
(אורי) אני - רק לרפרר (Reference) לפרק אחר שעשינו עם נתי, על “ה-Trillion Dollar Paradox” [זה - 421 The Cost of Cloud, a Trillion Dollar Paradox with Martin Casado], שגם מדבר - המאמר הזה מדבר על המעבר של חברות מ-On-premises אצל הלקוח ל-SaaS: מה זה אומר בכלל על זה, אבל גם מה זה אומר על עולם העלויות, שנגעת בו.
- (עומר) כן, אני חושב שיש עוד מימדים באמת מאוד מורכבים, כמו שנגענו בהם - מה זה אומר על החברה? מה זה אומר על מבנה ארגוני בכלל? האם המבנה ארגוני הוא תוצר של הארכיטקטורה, או להפך? . . .
- אז אני אומר . . .
(אורי) אה, זה תמיד יקרה ככה . . . תמיד תיהיה הלימה - זה חוק Conway.
- (עומר) אז אנחנו היינו מודעים לחוק Conway.
- אז קודם כל אמרנו “טוב, צוותים פר-מוצר”, אבל אז אמרנו “טוב, זה צריך להיות צוותים פר-Domain” . . .
- מכונת התקיפה יכולה לרוץ או ב-On-premises, או ב-SaaS - זה לא משנה לה.
- אז כן, אז זה.
- עלויות - דיברנו. על פיתוח . . .
- (עומר) לא, אז כיום כולם משויכים למערכת שלהם.
- המערכת יכולה להיות או ב-On-premises, או ב-SaaS - ואז זה גם, תחשבו על ה...
- (עומר) לא - גם וגם.
- כולם יודעים הכל, וזה גם מאוד מפתח אנשים לחשוב בצורות חשיבה שונות.
34:25 הסוף / אני לא מאמין שאני גר בפתח-תקווה
(רן) אוקיי. בסדר. אז כמו שרפררנו (Reference), אנחנו לקראת הסוף.
עוד כמה מילים אולי על החברה - אמרת שאתם שאתם סדר-גודל של כ-50 מפתחים?
- (עומר) יש כ-50 מפתחים - מפתחים, מפתחות, DevOps, QA . . .
- אנחנו כמובן מגייסים . . .
(רן) איפה אתם?
- (עומר) יושבים בפתח תקווה, מעל תחנת רכבת קלה.
- בתור תל אביבי, אני אגיד שזה לא כזה נורא . . .
- אז בהחלט החברה גדלה, האתגרים...
(אורי) זה לא נורא להיות תל אביבי, או לא נורא ל...
(רן) לא לא - זה אחלה לוגו . . .
- (עומר) נשאיר את זה כסימן שאלה - שכל אחד ייקח את זה למקום שיעבוד לו . . .
(רן) אני חשבתי על סלוגן לפתח-תקווה - “פתח-תקווה: זה לא כל כך נורא” . . . סליחה.
- (עומר) יצאו דברים יפים מפתח תקווה, נגיד את זה רגע לדיסקליימר. [חוץ מבר-זיק?]
- אז כן - החברה מגייסת לצוותי פיתוח: Backend, Frontend, DevOps, QA.
- יש גם תפקידים אחרים, כמובן.
- וגדלים.
- המון אתגרים, כי יש יותר משני מוצרים בחברה - ומעל אלף לקוחות כבר.
(רן) צריך ניסיון כ-Pen-Tester? כאיש Security?
- (עומר) אז תלוי לאן אתה מגיע - לצוות המחקר, שגם אליו מגייסים, אתה צריך להיות Top-Notch ב-Cyber.
- כי אנחנו עושים הכל From Scratch.
- צריך גם לחקור-לאחור, גם לפתח לקדימה.
- ובעולמות של הפיתוח - אז נתנו פה קצת טעימה: ה-Stack מגוון, עם אתגרי On-prem, אתגרי SaaS, ועוד הרבה דברים טובים לשנה הקרובה, שאמורים להגיע.
שיהיה המון בהצלחה, עם כל ה-SaaS הזה!
בהצלחה. ותודה רבה שבאת.
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
