יום רביעי, 6 באוקטובר 2021

422 Pentesting with Erez Metula

בפרק מספר 422 של רברס עם פלטרפורמה - אני מתכבד לארח באולפן הוירטואלי שלי את ארז מטולה
(רן) אז אם אתם מזהים את הקול הזה, זה בגלל שאתם מאזינים ממש-ממש-ממש אדוקים - עם ארז נפגשנו לפני 10 שנים - או יותר, אולי אפילו 11 שנים [מפה לשם כמעט 12…] - והקלטנו פרק, אז, על נושא של Penetration Testing [058 אבטחת מידע בתכנה software security, כולל הפתיח ההיסטורי למטיבי שמע], והנה אנחנו נפגשים שוב אחרי 10 או 11 שנים, כדי לראות מה התעדכן. רמז - הרבה . . . 

אז לפני שנכנס לעולם ה-Pen-Testing, ארז - ספר לנו, ככה בכמה מילים, עליך - 


  • (ארז) בשמחה - אני נמצא בתחום הזה של ה-Security בערך מאז שאני זוכר את עצמי . . . עוד בתור ילד, התעסקתי עם כל מיני שפות פיתוח ועם לפרוץ למשחקים ולעשות כל מיני דברים [לכאורה].
    • היה לי ברור שזה הכיוון שלי, עוד בתור ילד היה לי ברור שאני איכשהו אשלב בין עולם המחשבים ועולם האבטחה - “הפריצות” אז קראנו לזה, עוד לא הייתה הגדרה לכזה דבר.
    • ובאמת, בשביל לעשות את זה בצורה רצינית, היה לי ברור שגם צריך לעשות את זה בצורה “נכונה” ו”אקדמאית”, נקרא לזה.
  • אז לאחר שלמדתי תואר ראשון ותואר שני בתחום, אמרתי “רגע, מה אני עוד יכול לעשות?”
    • אולי אני אלך לעבוד בחברת פיתוח, כי בסך הכל אני מפתח תוכנה - אבל מצד שני, אני מאוד אוהב את ה-Security . . .
  • אז אמרתי - רגע, בדיוק נולד תחום חדש שנקרא Application Security - אני מדבר איתך על לפני 20 שנה, כן? כשנכנסתי לעניינים - ואמרתי “איזה  מגניב!”
    • זה תחום שמשלב בין Security לפיתוח - בדיוק החיתוך הזה - ווואלה, נשמע לי מאוד מגניב, משהו שאני מאוד מתחבר אליו.
  •  ומאז גם התחלתי להתעסק עם כל מיני דברים שקשורים לכלים שפיתחתי, למחקרים שביצעתי, הרצאות שעשיתי במקומות כמו Black Hat ו-DevCon
    • אפילו יצא לי לכתוב ספר בנושא, שנקרא Managed Code Rootkits
    • ומאז מאוד פיתחתי את התחום והשתדלתי לקחת סביבי הרבה מאוד אנשים שיטפלו בנושא הזה
  • ולפני משהו כמו 10 שנים הקמתי חברה בשם AppSec Labs - זו חברה שמתמחה בתחום ה-Application Security, ומה שאנחנו עושים בעצם זה בדיוק זה: אנחנו 15 איש, עושים Penetration Testing, עושים Code Review, מייעצים איך לכתוב אפליקציות בצורה בטוחה . . . 

(רן) מצויין, באמת הסטוריה ארוכה ומכובדת - לא הרבה יודעים, אבל גם אני התחלתי את הקריירה שלי כ-Pen-Tester, באיזשהו שלב . . . אחרי שסיימתי את הלימודים, זה היה אחד הדברים הראשונים שעשיתי, ואח”כ עברתי לכיוונים אחרים של Frontend ו-Backend ותשתיות - והיום Data Science, אבל כן, יש לי עדיין פינה חמה בלב לעולם ה-Pen-Testing וגם אני הייתי ב-Black Hat וכאלה, מכיר את החבורה . . .
אבל בכל אופן, למי שאולי לא מכיר - הזכרנו את המילה הזו מספר פעמים: Pen-Testing: מה המשמעות? מה זה Pen-Testing? מה המשמעות של להיות Pen-Tester?
  • (ארז) Pen-Testing זה, בצורה הכי נקרא-לזה-ככה-“מסונתזת”-שלו, זו מערכת, שיכולה להיות מערכת We-App או Mobile-App . . .
    • ויכול להיות Pen-Test תשתיתי בכלל - Pen-Test לשרת קבצים, ל-IAS, ל-Apache . . . לא משנה מה, תמיד יש Target.
    • בשורה התחתונה - המטרה היא להפיק דוח, להפיק רשימת Vulnerabilities, בעיות שנמצאו במערכת - על מנת שהצד השני - בדרך כלל בעל המערכת - יוכל להבין בפני מה הוא עומד.
  • אם בעל המערכת יודע שיש לו איזושהי מערכת, ואין לו כל כך מושג אילו בעיות יש שם - אז הדבר הכי קרוב לפורץ אמיתי, שיפרוץ לו למערכת וינצל את זה - זה לקחת מישהו, נקרא לזה “מהטובים” - Penetration Tester, שבצורה מסודרת ומבוקרת ובתיאום עם אותו גורם, יבצע לו [עבורו] סוג של סימולציה של האיש הרע
    • רק שבמקום שהוא באמת ינצל את הפרצות האלה ויעשה עם זה משהו, הוא פשוט בא ואחרי זה אומר לו “הנה, תראה - אלו הן הבעיות שמצאתי והנה, מההבנה שלי את הבעיות, אני גם יכול להגיד לך איך כדאי לך לטפל ולתקן אותן”.

(רן) בסדר גמור, מעולה - אז אפשר לחשוב על Pen-Tester כעל שודד טוב”: מישהו שמדמה פריצה אבל בסופו של דבר נותן לך דוח ולא גונב לך את הכסף, או את שאר הדברים . . .
אז המקצוע הזה, כמו שאמרת, התחיל כבר לפני 20 שנה או יותר - אבל בוא נדבר על מה שקורה היום, זאת אומרת - מה התחדש, לפחות נאמר ב 5-10 שנים האחרונות, מבחינה טכנולוגית, מבחינה מתודולוגית . . . מה חדש בזמן האחרון?
  • (ארז) אז קודם כל המון השתנה . . . אם אני אקביל את זה למה שהיה אז, בפגישה הקודמת שלנו לפני ~15 שנה, אז העולם היה מאוד פשוט . . .
    • אז היתה לך טכנולוגיה אחת, בדרך כלל, שרת Web אחד . . . הכל היה מאוד הומוגני.
    • הרוב היה רץ על IAS-ים, בדרך כלל מה שכתבו היו Web-Apps עם ASP . . . בהמשך התחיל NET.
    • אם כבר היו אפקליציות Web-יות אז הן היו רק Java . . . היה מאוד מצוצמם.
  • בדרך כלל, מי שעשה Penetration Testing בתקופה ההיא היו סוג של לקוחות מאוד-מאוד ממוקד - 
    • זה יכול להיות  . . . בדרך כלל בנקים או תעשיות בטחוניות וכאלה.
  • היום,Literally, כולם עושים Penetration Testing - כי כולם מבינים שזה צורך מאוד חשוב
    • וזה איזשהו שינוי מאוד מהותי שאנחנו רואים היום - שכולם עושים כל הזמן, כולם עושים להכל, לא רק לאותן אפליקציות שהן, ככה חשופות.
  • ואם נסתכל רגע על ההבדל המשמעותי - אני אגיד את זה במשפט אחד ואני אפתח את זה: בשורה התחתונה, היום הרבה יותר מורכב לבצע Penetration Testing ממה שבוצע בעבר.
    • היום, למשל, כשאנחנו מסתכלים על Target - אני, ברשותך, אתמקד בעולם שאני מכיר ושוחה ומומחה בו, תחום ה - Applications . . . אם אני מסתכל על Applications - 
      • ואגב Applications זה מושג מאוד רחב: זה יכול להיות Web-Apps, זה יכול להיות Mobile-Apps, זה יכול להיות IOTs, זה יכול להיות  REST APIs, ו . . . You-name-it . . . כל עולם ה-Software
    • בקיצור, הום הרבה יותר מורכב לבצע Penetration Testing, כי הפרופיל של ה-Penetration Tester הוא כזה שהוא צריך להיות הרבה יותר ורסטילי
      • הוא לא יכול להכיר רק טכנולוגיה אחת, הוא לא יכול לבוא ולהגיד “אני יודע רק טכנולגויה אחת - אני יודע רק לבדוק Web-App מסוג Java!”
      • הוא צריך להכיר טכנולוגיות שונות, הוא צריך לדעת את ההבדלים . . . מה ההבדל בין אפליקציה שנגיד מותקנת On-Prem - שזה, אגב, היה בעבר בעיקר On-Prem - לבין, פתאום, אפליקציות שהן  . . . היום כמעט שאין On-Prem, רק בסביבות מיוחדות אתה תראה On-Prem.
      • היום הרוב זה SaaS - אם ניקח את זה עוד שלב קדימה, היום הכל כמעט בנוי מעל תשתיות Cloud
      • ו-SaaS לא בהכרח אומר Cloud, יכול להיות שיש מישהו שיש לו SaaS שלא בהכרח משתמש בכל ה-Advanced Features שיש ל-Cloud Providers, כמו Storage של Encryption Keys וכמו שירותים שאתה “זורק את הקוד שלך” ויש לך איזה Lambda Function . . . אתה זורק את הקוד ואתה לא צריך בכלל תשתיות . . .
      • אלו דברים שמאוד השתנו - ולכל סוג של מערכת, לפי ה-Deployment שלה ולפי הטכנולוגיה שלה, יש ממש סט של בעיות שאותו Pen-Tester צריך להכיר.
    • בשורה התחתונה - ב-Pen-Testing, יש לך זמן קבוע - זה לא, ככה, “תבדוק כמה שאתה רוצה”, תמיד יש זמן קבוע - בסופו של דבר, Pen-Testing זו פעילות מסחרית, שיש לה זמן מוקצב, 
      • ואחד מהאתגרים הכי גדולים שיש ל-Pen-Tester, מעבר לטכנולוגיה, זה לדעת איך הוא “משחק נכון” עם השעות - איך הוא עושה פיזור נכון, אופטימלי, של השעות שלו
      • איפה הוא שם את השעות אל מול ההסתברות הגבוהה למציאת Vulnerabilities - הייתי אומר שזה שם המשחק היום.

(רן) אז אני מנסה, ככה, לדמיין איך נראה היום שלך, או של אחד העובדים בחברה שלך . . . אז נגיד, יש לקוח עם חוזה חדש ועכשיו יש לך, לצורך העניין, איזשהו “בנק-שעות” שאותו אתה הולך להשקיע ב-Pen-Testing - מה, זה מתחיל באנליזה? ארכיטקטורה של המערכת? שיחה עם מהנדסים, או שאתה מתייחס לזה כמו אל קופסא שחורה? זו השאלה ראשונה - עד כמה המערכת צריכה להיות “שקופה” אליך?
שאלה שנייה היא האם יש איזשהו סט-כלים, Tools-of-Trade, שאיתם אתה תמיד מתחיל ראשון - ואז משם ממשיך הלאה, לפי הממצאים?
  • (ארז) שאלה מצויינת, שאלות מצויינות . . . יש כמה שאלות שמתחבאות במה שהעלת . . .
  • אני אתחיל, קודם כל, מאיזושהי הצהרה - בשורה התחתונה, כשעושים Penetration Testing, אפשר להגיד שהעולם מתחלק לשלושה סוגים - סוג אחד זה Black-Box, סוג שני זה White-Box, בצד השני של הסקאלה; ובאמצע נמצא Gray-Box.
    • אני מאוד מאמין ב-Gray-Box . . . ואני אתחיל רגע בהסבר של מה כל אחד אומר . . .
  • אז Black-Box אומר “קח את המערכת, עזוב’תי באמ’שלך ותחזור אלי עם דוח” - זה ממש, בשפה פשוטה . . .
    • במקרה הטוב אתה מקבל Username ו-Password, יש לך נגיד את ה-URL של המערכת ו-User ו-Password וזהו, לא משתפים איתך פעולה.
    • זו גישה אנכרוניסטית, לדעתי . . . היא מתאימה מאוד למצב שבו אתה יודע לחלוטין שבדקת את המערכת ואין שום דבר ויש סבירות מאוד נמוכה שימצאו [משהו] ועוד הרבה מאוד סיבות למה שתעשה Black-Box, יש עוד כמה . . .
    • בשורה התחתונה, היא לא אופטימלית - אתה יכול לבזבז כמות שעות אדירה על דברים שאתה יכול לחלץ, את אותו Vulnerability, בשיחה של חמש דקות עם מתכנת, בסדר? . . . .
      • או בלהסתכל בדיוק, לעשות Pin-point, ללכת ל-Class המתאים בקוד, כשאתה יודע איפה כנראה מסתתרת הלוגיקה שאתה רוצה לבחון - ופשוט להסתכל על הקוד ולהבין מה קורה שם.
  • מהצד השני נמצא White-Box, שזה בעצם אומר “תן לי את הקוד, בוא נעשה White-Box Testing - תן לי את הקוד, אני בעיקר אסתכל עליו, אשאל שאלות, אסתכל על ה-Sequence Data וכו’” . . . 
    • ונמצא בעיות - נסתכל על ה-Design ונמצא בעיות.
  • ויש את האמצע - האמצע זה ה-Gray-Box, שבעצם אומר “בוא נעשה את שניהם - בוא נשתמש בשני המכשירים, גם במכשיר ה-Pen-Testing ‘ה-Black-box-י’ וגם במכשיר ‘ה-White-box-י’, על מנת לאתר Vulnerabilities”
    • שם המשחק הוא שבהינתן זמן נתון - קבוע, Fixed - אני רוצה למצוא את מקסימום ה=Vulnerabilities
    • אני, כ-Pen-Tester, מאוד ארצה-  כמו רופא שיכול לנתח ויש לו סט של מכשירים, שיכול להרים פעם את האיזמל הזה ופעם את ההוא וכו’
      • אני רוצה לבוא ולהגיד שהייתי מאוד שמח, בהינתן בעיה נתונה שאני רוצה לבחון, לחשוב ולהגיד רגע, האם אני ניגש אליה במסלול . . .עם המכשיר של ה-Black, כי זה יותר נכון לבדוק אותה עם Black?
      • אולי יותר נכון להסתכל עליה ב-White?
      • או אולי נכון להתחיל Black, לעבור ל-White, לחזור ל-Black, לחזור ל-White . . . וככה בעצם, בצורה מאוד יעילה, לאתר את הבעיות
  • וזה מוביל אותי לשאלה ששאלת - מהי המתודולוגיה של צורת הבדיקה? הPipline הוא כזה:
    • עוד לפני שמתחיל Penetration Testing, נהוג לעשות משהו שנקרא Scoping - 
      • ו-Scoping זה תהליך שהוא חצי-עסקי וחצי-טכנולוגי - תהליך שבו מדברים עם הלקוח, עוד לפני שיש הצעת מחיר, לפני שיודעים מה בכלל הולכים לבדוק וכו’ - ושואלים אותו “תגיד, מה מעניין אותך? מה היית רוצה לבדוק? בוא - שרטט לי גבולות גזרה, שרטט לי את הרכיבים שלך . . . האם ה-Web-App כן ב-Scope או לא ב-Scope? ה-REST API, שמדבר עם השירות-צד-שלישי שלך - כן להכניס אותו או לא להכניס אותו?”
      • קודם כל, מחליטים איתו מה בכלל רוצים, מהם הגבולות גזרה, מבינים מה המורכבות של המערכת, כמה דפים יש לכל מערכת . . . כי הרי מערכת - לא מודדים אותה לפי משקלה בק”ג . . . מודדים אותה לפי כמות הדפים, כמות ה-APIs, עד כמה הם מורכבים  . . .
      • יכולות להיות שתי מערכות, לשתיהן עשר End-Points - אבל אחת היא סופר-מורכבת והשנייה היא כזאת פשוטה כזאת, כמה GET-ים פשוטים שמחזירים אינפורמציה . . . .
    • אחרי שקובעים עם הלקוח את היקף הפעילות, מקבלים הצעת מחיר, הוא מאשר אותה, כל הצד הביזנסי . . . עברנו אותו.
    • קובעים Kick-off - זה שלב סופר-חשוב ב-Pen-Test, זה שלב שבו, ביחד עם הלקוח, קובעים, בשלב הראשון של המערכת - 
      • מזמנים את כל הגורמים הרלוונטיים, בין עם זה ה-Pen-Testers וה-Product וה-Project Managers - זה מהצד שלנו, למשל
      • ומהצד של הלקוח - בדרך כלל את מי שמכיר את המוצר הכי טוב - מנהלת הפיתוח, לפעמים ה-CISO, מנהל מערכות מידע . . . גורמים מצד הלקוח.
      • ורואים שקודם כל יש לנו את כל המידע שאנחנו צריכים - URL-ים ו-Password-ים וכל מה שצריך למערכות - רואים שהכל עובד, סופר-חשוב . . . 
      • בשלב הזה, של ה-Kick-off, זה השלב שבו נרצה גם לאושש את הנחות הייסוד שלנו, לגבי גבולות הגזרה - אני יכול לתת . . . לא חסרות דוגמאות, שפתאום מישהו מתעורר, מהצד של הלקוח, ואומר “רגע! המערכת הזו, שאמרתם שהיא ב-Scope - היא לא מוכנה, או שלא אמורים לבדוק אותה” - ויכול להיות גם מקרה הפוך, שמישהו יבוא ויגיד “רגע! מה עם השירות ההוא-וההוא? מה עם השירות שעכשיו עושה את Event-rule הזה? הוספנו את זה לפני כמה ימים וכן צריך להכניס אותו ל-Scope . . . .”
      • אז זה בדיוק המקום שבו כל מיני דברים צפים.
    • אחרי שעברנו את השלב הזה, מה שנהוג לעשות - ואני אחבר את זה רגע ל-Gray-Box - זה לקבוע שיחה עם אחד המתכנתים, מישהו שמכיר טוב את המערכת, וללכת איתו בשיטה של Cross-cut, לכל האיזורים שמעניינים ב-Security - 
      • ללכת איתו ממש ברמת ה-IDE, להגיד לו, למשל, “תפתח עכשיו ב-Visual Studio ותראה לי בבקשה איך אתה עושה Authentication ל-User-ים”, “תראה לי איך אתה חותם על JWT Tickets”, “קח אותי, למשל, לאותוריזציה (Authorization) - אני רוצה לראות את המודל-הרשאות שלך”
      • או “אמרת לי שיש לך Database מסוג SQL - תגיד, אתה משתמש ב-Dynamic queries?” או “אמרת לי שאתה עובד ב-ORM - אני רוצה לראות בעיניים . . . קח אותי בבקשה ל-DALL, אני רוצה לראות בעיניים . . . “
    • למה אני אומר את הדברים? כי אני יודע שעוד מעט אני אעשה את ה-Pen-Test, ואחד הדברים שאני אסתכל עליהם זה, למשל, זה SQL Injection . . . כשאני אבוא ל-SQL Injection, אם אני יודע, היה לי מידע פנימי, שאומר שלמשל - אין מצב ל-Dynamic queries בקוד, כי ראיתי בעין שהמתכנת משתמש ב-ORM, בסדר . . .
    • אז נניח שאני אומר שיש ORM - הסבירות שבה יש SQL Injection, שה-Run-time בכלל ג’ינרט (Generated) על מנת לגשת לדבר הזה - היא קלושה . . .
      • זאת אומרת שאני יודע שאני אולי, בקטנה ככה, אוודא SQL Injection - אבל בשעות היקרות האלה, שהייתי אמור לבדוק SQL Injection - אני אשים אותן על משהו אחר . . . אני אמצא בעיה אחרת.
    • ושוב אני מזכיר - זה משחק של הסתברויות . . . התפקיד של ה-Pen-Tester הוא לבוא ולראות איפה לשחק עם השעות שלו.
    • אם אני אלך רגע קדימה - אז היום של ה-Pen-Tester הוא כזה שבהתחלה הוא סוג של, אם מתחיל הפרויקט, אז הוא סוג-של עושה Reconnaissance על המערכת, Information gathering . . . עובר על המערכת, אילו API-ים יש, כן WebSocket, לא WebSocket, מה עובר . . . אם זה עובר ב-JSON או עובר ב-Proto-Buff, או מה . . . .
    • אגב, היסטוריה - פעם זה לא היה ככה, פעם ה-HTTP Request היה פשוט פרמטרים, כל מה שהיה צריך לעשות זה לשחק עם פרמטרים . . . 
      • היום פתאום זה הרבה יותר מורכב, יש Single Page authentication, אתה כבר לא יכול לעשות Crawling על כל המערכת ולדעת בצורה פשוטה, היום הדברים הרבה יותר מורכבים.
    • ולכן, אחד הדברים החשובים ש-Pen-Tester עושה בהתחלה - הוא בונה לעצמו מודל של איך שהמערכת בנויה, והוא חושב כמתכנת - 
      • “אם אני הייתי בונה את זה . . .” - אני נכנס לראש של המתכנת ואני מבין את השיקולים שלו . . . 
      • “למה, למשל, את ה-Request הזה הוא העביר over WebSocket, ואת זה הוא העביר ב- REST API?” - כנראה שהייתה סיבה . . . 
      • כנראה שאת ה-WebSocket הוא צריך ל-Long-running Connection או משהו, ואני אראה שאם יש לו Long-running Connection, אז כנראה שבצד השני ה-User הוא כנראה Authenticated ברגע שהוא פתח Connection . . . 
      • זאת אומרת שיכול להיות שב-WebSocket אני אומתתי רק בפעם הראשונה שפתחתי את ה-Connection, ויכול להיות שכשאני אני אשלח את הבקשות הבאות, אם אני אעשה משחק על פרמטרים ואזין ID של User אחר או של Resource אחר - יש סיכוי גבוה יותר שאני אמצא אותו . . . 
      • למה? כי ב-REST API, מראש, בגלל שהוא State-less, בהקשר הזה - אז תמיד בודקים . . . 
      • יש כל מיני ניואנסים קטנים, שברגע שאתה נכנס לראש של כל מתכנת, זה נותן לך כל מיני טיפים על איפה כדאי לך להסתכל . . .
    • בקיצור - אחרי שעשינו את כל שלב ההכנה ואיך שהמערכת בנויה ואיפה כנראה יש בעיות ו . . . 
    • אחד הדברים זה גם למפות פיצ’רים - למשל, יש Features של File upload או Download . . . מדי פעם זה Import או Export של כל מיני קבצים וזה - אז כבר אני יודע שב-Security test-cases שלי אני צריך לכסות Vulnerabilities כגון Directory traversal ו-Path manipulation ודברים כאלה . . . 
      • אם לא היה פיצ’ר כזה, שימו לב - זה Feature-Driven - אם לא היה פיצ’ר בכלל של File-ים, כנראה שלהתחיל לחפש Directory traversal היה נמוך יותר ברשימה שלי . . .
    • זאת אומרת שאחד הדברים שה-Pen-Tester עושה - הוא גם בונה לו סוג של “רשימה ממויינת”: אילו Test-cases יותר מעניינים, ספציפית במערכת הזאת.
      • זה קטע מאוד מעניין ומאוד מאתגר - וככל שיש יותר ניסיון, אנחנו גם רואים את זה, ש-Pen-Testers מנוסים יותר, הראשי-צוותים, הרבה פעמים . . . 
      • גם אם יש Pen-Tester מאוד טוב, שיודע לזהות בעיה מאוד מאוד טוב - הוא צריך את הניסיון של ה-Pen-Tester המנוסה יותר, שיגיד לו “שמע, יש לי תחושת בטן . . . יש לי הרגשה שבאיזור הזה יהיה לך Directory traversal . . . “
      • הצעיר יותר, שיודע למצוא Directory traversal, ו”שד בזה” - יסתכל על המישהו המנוסה יותר ויגיד לו “איך אתה יודע?, מאיפה יש לך את התחושת בטן הזאת?” - וזה בדיוק הניסיון, שגורם לך להבין לאיפה לחלק את השעות . . . 
    • ואם אני כבר קופץ רגע לסוף, רק לשלב האחרון - אחרי שמצאנו, במהלך הפעילות, מצאנו Vulnerabilities . . .
      • היועץ שם לו אותן בצד - ובשלב הסופי הוא כותב דוח שממפה את כל אותן בעיות, ואני אשמח עוד מעט להרחיב על מה נמצא בדוח ומה עושים איתו . . .

(רן) כן . . . אז אני מניח שאיזשהו Sub-text שלא כל כך דיברנו עליו הוא שלך יש אולי איזושהי מגבלת זמן, אבל אתה יוצא מתוך נקודת הנחה שלפורץ אין מגבלת זמן . . . זאת אומרת, גם אם אין לו, כמובן, גישה ל-White-Box, אין לו גישה ל-Source-Code - או לפחות אנחנו מקווים שאין לו את הגישה הזאת, אם לא התכוונו לתת לו . . . .
אבל כן יש לו הרבה מאוד זמן לשחק - אז הוא לא יודע אם יש Directory traversal או לא אז הוא פשוט מנסה, והוא לא יודע אם יש פה בעיה ב-WebSocket אז הוא פשוט מנסה - ולפורץ יש, נגיד, “אינסוף זמן”, אבל לך אין . . . יש סוף לזמן שלך, יש סוף לשעות שאותן אתה יכול להשקיע, לפי החוזה, ולכן אתה צריך לתעדף לפי סיכונים.
רציתי לשאול - יש לנו בסך הכל הרבה נושאים שאנחנו רוצים לכסות והזמן קצר, כמו ב-Pen-Testing . . .  - אז רציתי להתמקד על כמה דברים - ואחד הדברים המשמעותיים, אני חושב, ביותר בעולם של ה-Security activities זה ההתפתחות של שפות התכנות, זאת אומרת - אם בעבר פריצות טיפוסיות היו משתמשות ב-Buffer overflow ודריסות זכרון ודברים כאלה בשפות שהן פחות מנוהלות כגון C, היום השפות הן כבר הרבה יותר מנוהלות, ועדיין יש להן פגיעויות - אבל הן מסוג שונה.
אז שפות שהן הרבה יותר מתקדמות, דוגמאת הגרסאות האחרונות של Java ו-TypeScript ו-Go ו-Rust מנהלות בצורה מאוד מאוד יפה את הזכרון שלהן, ויש להן  לא מעט פיצ’רים של Security כבר Built-in בתוך השפה - אבל אני מנחש שיש להן פגיעויות אחרות . . .
אז איך אתם ניגשים, נגיד, אם אתם לומדים שיש Code base שכתוב, לצורך העניין, ב-Go או ב-Rust או ב-TypeScript או בשפה מודרנית אחרת - האם אתם ניגשים לזה בצורה שונה, עם סט שונה של כלים או מתודולוגיה אחרת?
  • (ארז) חד משמעית כן, כי בכל שפה יש את ה-Common Vulnerabilities שלה, או שאני אגיד את זה אחרת - לכל שפה יש את “המקומות האפלים האלה”, שמתכנת עלול “לירות לעצמו ברגל” . . .
    • מה הכוונה? הסביבה והשיטה וכל ה-Community הרבה פעמים מעודד אותך לעבוד בצורה מסויימת, שהיא, בוא נגיד את זה ככה - קצת יותר מסוכנת מהממוצע, או יותר מסוכנת מבשפה אחרת . . . 
    • בעיקר בדברים דינאמיים או בדברים שאתה עושה בצורה שכזו, שנגיד שאולי בשפות אחרות לא היית עושה
    • אז יש סביבות שבהן ה-Package זה האיום המרכזי, ויש סביבות שבהן אתה יודע שהסביבה עצמה היא כזו שבה יש יותר סבירות לטעות . . .
    • אגב, דיברת על זיכרון מנוהל וכו’ - גם לפני 10 שנים, הרוב היה זיכרון מנוהל . . . בעיות כמו Buffer overflow ו-Format String ו-XSS וכו’ - אלו בעיות שבאמת עוד בעבר הפסקנו להסתכל עליהן.
      • זאת אומרת שהסבירות שאתה תמצא Buffer overflow באיזו Web-App הוא קלוש.
      • לכן, רוב הבעיות מתמקדות בעיקר בבעיות טכניות - זה המונח, “בעיה טכנית”.
    • “בעיה טכנית” זו בעיה כגון Directory traversal שהזכרתי קודם ו-SQL Injection ו-XSS ועוד כל מיני בעיות.
    • ויש “בעיות לוגיות” . . . .
(רן) כן, אני אוסיף לרשימה דברים שאני ראיתי -  שימוש לא נכון ב-Encryption או בכל הספריות שקשורות ל-Encryption . . . 
  • (ארז) זה בעיות לוגיות . . . 
(רן)  . . . ושימוש לא נכון באות’נטיקציה (Authentication) . . .
  • (ארז) . . . לוגיות!
(רן) אוקיי . . .
  • (ארז) בדיוק . . . זה בדיוק מה שבאתי להגיד - לשם העולם הולך.
  • אני אתן רקע - בעיות טכניות אלו בעיות שקל מאוד לפרמל (Formalize) אותן - לצורך העניין, אם אני עכשיו סורק את הקוד, קל לי, יחסית, לזהות או להגדיר Pattern של איך שנראה SQL Injection
    • תחשוב שמשהו רץ על הקוד, יש איזשהו Static Code Analysis, איזשהו מוצר של Security שעושה scanning, וידע לזהות איך נראה SQL Injection או XSS או כל בעיה אחרת . . .
    • יש לזה Pattern  בקוד, אני יכול להגדיר ולהגיד “אם אתה רואה קוד שיש בו Class של SQL Query ויש “הדבקת String-ים” בלה-בלה-בלה . . . “ - אני יכול לפרמל, לוגיקה כזו - “… - אז יש בעיה”.
    • אלו בעיות טכניות.
  • בעיות לוגיות, מהצד השני, הן בעיות יותר קשות - כי מכונה לא יכולה להסתכל על מכונה ולהכריע . . . 
    • זה הולך כל כך רחוק, עד כדי בעיית עצירה של Turing . . . זאת אומרת שאנחנו לא נוכל אף פעם, גם אם יש הרבה חברות AI שמספרות לנו כל מיני סיפורים - זה לא יקרה . . .
    • בבעיות לוגיות, מכונה לא תוכל להכריע - זאת אומרת, יש דברים שהיא תוכל אולי, אני לא ראיתי . . . - אבל לדוגמא, הכי פשוטה:
      • מי אמר שעל שדה מסויים, סופר-רגיש, צריך להיות Encryption? מי אמר שעל השדה הזה ב-Database או על השדה ההוא ב-Database צריך להיות Encryption? זה לא צריך להיות Encryption . . . מכונה לא תוכל להגיד לך את זה, בסדר?
      • נכון שיהיה אפשר להסיק  . . .
(רן) אתה עושה את החלוקה בין “לוגיות” ל”טכניות” מנקודת הראות שלך, כ-Pen-Tester . . . דברים שבצורה טכנית, באופן טכני, אני יכול למצוא - ודברים שבאופן טכני אני לא יכול למצוא, ולכן אתה קורה לזה “לוגי”.
אבל כמפתח, אני לא כל כך מודע לחלוקה הזאת . . . מבחינתי, הכל זה . . . לא יודע אם אפשר לקטלג את זה, אבל הכל זה בעיות לוגיות, כנראה . . . - זאת אומרת, מימוש לא נכון, הליכה כנגד ה-Best-Practices, בהרבה מקרים, או סתם חוסר הבנה או חוסר ידע שלי . . .
  • (ארז) כן, תראה - הטרמינולוגיה של “בעיה טכנית” או “בעיה לוגית” היא לא טרמינולוגיה  . . . זו טרמינולוגיה שבאה מעולם הPenetration Testing - זה מונח מקובל ונהוג לעשות את החלוקה הזאת.
  • בשורה התחתונה - אתה צודק, מנקודת מבטו של מתכנת “הכל לוגי, כי הכל זה קוד שאני כותב”, ברור . . .
    • אבל בהקשר של בעיה, כן - רוב הבעיות שאנחנו רואים היום הן בעיות כגון  זה שלא שמת Encryption או שעשית Encryption לא נכון, או שלא עשיתי אות’וריזציה (Authorization), בסדר? לא עשית אות’וריזציה או שיכול להיות שהאות’וריזציה שלך לא טובה . . . .
    • או למשל - מישהו שעושה Parameter Manipulation על איזה ערך, כן? . . . והוא נותן ערך Valid-י, זאת אומרת, תחשוב רגע שיש איזשהו ערך שאני מעביר - הערך עצמו, כערך, הוא אחלה ערך! הוא עובר RegExr, הכל תקין . . .
      • אממה, לי אסור לשלוח אותו - הוא ה-CartID שלך, לא שלי, לדוגמא . . . . 
      • שזו בעיה לוגית, זו בעיה שמאוד קשה לעלות עליה מבחוץ - אתה ממש צריך להבין את ה-Business-Logic של המערכת.
    • וזה, אגב, משהו שאומר שאיפשהו, ככל שהטכנולוגיה תתקדם ויהיו ל-Pen-Testing יותר שיטות ויותר כלים - תמיד אנחנו נצטרך Human בתמונה . . .

(רן) אז נושא אחד שככה קצת נגעת בו מקודם, כשדיברנו על Node.js - הזכרנו קוד פתוח והזכרנו Package Managers, ורציתי קצת להכליל את זה ולדבר עוד כמה דקות על הנושא של Supply-Chain Attacks - התקפות על שרשרת האספקה.
עכשיו, מי שמגיע מעולם התפעול מכיר שרשרת אספקה - זה אוניות, זה משאיות, זה מטוסים, זה מחסנים וכו’ . . . . אבל מה, למעשה, זו שרשרת האספקה בעולם התוכנה? אז בעולם התוכנה, שרשרת האספקה כוללת כמה דברים - 
    • זה כולל את כל ה-Tool-ים שעוזרים לנו בסופו של דבר לכתוב את התוכנה ולדלבר (Deliver) אותה, אם זה IDE, אם זה ה-Package Manager, אם זה חבילות ה-Open-Source השונות, ה-CI, ה-Deployment System, ה-Docker ו-Kubernetes וכו’ - כל מה שעוזר לנו בסופו של דבר - כל מה שהוא לא התוכנה שלנו, אבל עוזר לנו לייצר את התוכנה.
ובזמן האחרון - טוב, אני לא יודע אם זה בזמן האחרון אבל שאולי זה רק עלה יותר למודעות בזמן האחרון - יש לא מעט התקפות על שרשרת האספקה הזאת, אם זה התקפה על ה-CI, אם זו התקפה על החבילות, Hijacking וכו’ . . .
איך זה משנה את עולם ה-Pen-Testing?
  • (ארז) תראה, בשורה התחתונה אני אגיד שזה משהו שחלקית אנחנו  . . . זאת אומרת, אפשר להתייחס אליו ב-Pen-Testing.
  • ולמה אני אומר את זה? כי אם יש בעיה, כשהבעיה הזו היא, לצורך העניין, חשופה כלפי חוץ - אז אתה תראה אותה ב-Pen-Test, 
    • וזה לא משנה אם המתכנת טעה ועשה Bug של Security, שזה רוב המקרים, או אם המתכנת בכוונה הזריק וקטור לקוד - נדיר, אבל קורה . . . .
    • או אם זה סוג של . . . מישהו אחר, נגיד, הכניס בכוונה Bug איפשהו - בסוף זה יצא כלפי חוץ, 
    • זאת אומרת - ב-Pen-Testing אתה אמור לזהות את הבעיות שקיימות.
  • מה אתה לא תזהה ב-Pen-Testing? אם למשל מישהו החביא, איפשהו ב-Supply-Chain עמוק בפנים, איזשהו Backdoor שכזה  . . . אין סיכוי שאתה תעלה עליו, אתה יודע . . .
    • אתה לא יכול לחזות, למשל שאם אתה תוסיף איזה ערך מאוד-מאוד-מאוד מיוחד ל-Request - פתאום ה-Backdoor יתעורר  . . . זה לא משהו, זה לא סביר שאתה תעלה על זה ב-Pen-Test.
    • אגב - מאוד יהיה קשה לעלות על זה גם בשיטות אחרות.
    • לכן Supply Chain אלו בעיות מאוד קשות . . . 
  • כי תחשוב רגע, הזכרת למשל אוניות ומחסנים וכאלו - בעולם ה-Software זה יותר באמת מישהו החביא לי איזושהי הפתעה, עוד לפני שאני, כמתכנת, קימפלתי ל-Production בכלל, מישהו החביא הפתעה עמוק בתוך ה-Complier” . . . סתם דוגמא - בתוך ה-IDE החביאו לי איזושהי הפתעה, החביאו לי בתוך ה-Docker Image . . . 
    • תחשוב - אם אני מושך איזה איזשהו Docker Image, והוא כבר בפנים החביא לי הפתעה . . . 
    • הקוד שלי סבבה, פצצה - עבר Code Review, עבר Pen-Test - על הסביבה הרגילה . . . אבל כשהוא רץ על ה-Docker Image הזה, אני בבעיה.
  • לא חסרות סיבות שכאלו, שבהן אתה אומר שיכול להיות שאיפשהו לאורך הדרך מישהו שתל לי איזה משהו - ולכן, בהקשר של Supply Chain, מאוד חשוב לשים לב שבאמת, זה מאוד טריוויאלי - שכל השרשרת מאובטחת.
    • שאת ה- Package-ים אתה לוקח ממקום תקין, שאת הסביבה אתה מעלה נקי . . . Docker Image? אין בעיה, אבל אל תביא Docker Image שמישהו אחר אפה, בוא תאפה אתה . . . תעשה את ה-Build
    • יש בפנים Binaries מיוחדים? תקמפל אתה . . . 
    • וכמובן שים לב מאיפה אתה מושך את הקוד . . .
  • היום זה גם מאוד קל, כי היום להרבה מאוד דברים יש Digital Signature - פעם לא היה לנו Digital Signature כמעט על כל דבר, והיום יש.
    • היום אתה יכול לוודא שהחבילה הגיעה מה-Trusted source שאתה מצפה לו.
    • היום אתה יכול לאמת חתימות של כמעט כל דבר שיש.
    • אפילו היום אתה יכול - הנה דוגמא למשהו שפעם לא היה - CDN, בסדר? נהוג למשוך כל מיני Static content מ-CDN
      • היום זה כל כך טריויאלי . . . פעם הייתה שם את הכל אצלך, את כל ה-JavaScript-ים והכל
      • היום יש יכולת להגיד, אני בתור מפתח המערכת שלי - כשאני מושך External backend, כשאני מושך למשל jQuery ממקור חיצוני, אני לספק את החתימה שלו כחלק מה-HTML - לא הייתי יכול לעשות את זה בעבר.
      • בעבר הייתי צריך למשוך JavaScript ולכניס אותו “לקודש הקודשים” - ל-Domain שלי, בתוך ה-Domain שלי, להכניס משהו מבחוץ שאין לי מושג מאיפה הוא בא, אין לי מושג האם מישהו שינה אותו מאיפה שמשכתי אותו וכו’
      • היום אני יכול ממש לספק Hash עם חתימה של מה שאני מצפה לקבל - ואם ה-Browser יקבל Package לא מתאים הוא ידחה אותו, הוא לא יטען אותו - שזה נהדר.
    • יש הרבה מאוד שיפורים מהסוג השזה, שפעם לא היו לנו - וזה אגב אחד הטריקים שאני ממליץ להשתמש בהם.

(רן) זה באמת מביא אותי לשאלה הבא - אולי לא יהיה לנו זמן לדבר על ה-Report שאתם מייצרים, אבל האם, אחרי שמצאתם אוסף של Vulnerabilities - רגישויות, פגיעויות - האם אתם גם הולכים הלאה ומספקים בסופו של דבר פתרונות, או מיטיגציות (Mitigations) לאותן בעיות?
  • (ארז) יש הפרדה בין עולם ה-Pen-Testing לעולם הייעוץ - זאת אומרת שכשאתה עושה Penetration Testing, יש לך Mission - וה-Mission שלך זה לבוא ולמצוא כמה שיותר בעיות ולהנגיש אותן, זה חלק מהמשימה.
    • מה זה אומר להנגיש אותן? - זה אומר שאני צריך לקחת בחשבון שמי שקורה את הדוח הוא לא Penetration Tester, ואני לא יכול לדבר בשפה שלי . . .
    • אני צריך להסביר לו את הבעיות, אני צריך להסביר לו איפה הבעיות . . .
    • אני צריך לשים לב לא ליפול לטעות הנפוצה - שהוא יחשוב שהבעיה שנתתי לו היא רק בדוגמא מסויימת, ויתקן רק אותה . . .
    • ואחד הדברים שחשוב מאוד להנגיש  במסמך זה את ה-Mitigations . . .
  • אז לשאלתך - כן, נהוג לתת Mitigations במסמך, להגיד איך ניתן לטפל בזה - 
    • אמרתי לך, סתם לדוגמא, שה-Encryption שלך לא טוב - אגב יש לזה שם, משחק מילים: En-crap-tion . . . 
    • אם אתה עושה En-crap-tion, וה-Encryption שלך לא טוב, אז אחד מהדברים שאני ארשום לך במסמך זה שהשתמשת, למשל, בהצפנה סימטרית מסוג  . . . . וה-Encruption mode שלך הוא ECB - זה לא טוב, תחליף בבקשה ל-CBC, ויכול להיות שאני אפילו אתן לך את ה-Flag המתאים בשפה שלך, כי אני, נגיד, יודע באיזו שפה אתה עובד וואני אתן לך גם ממש דוגמת קוד שעובדת.
  • זה החלק של הדוח, זה החלק של ה-Pen-Test - מי שמקבל דוח, צריך שיהיה לו את כל מה שצריך בשביל לתקן את זה.
  • יש לקוחות ויש מקרים שבהם באים ואומרים “תשמע - בואו תסייעו לי גם ממש ליישם את ההמלצות”
    • אבל הנחת הייסוד היא שלא - אתה לא חייב להישען עלינו בשביל זה
    • מי שעושה Pen-Test אמור לקבל את כל המידע ואמור לקחת מישהו שמבין מספיק, מפתח נורמלי, שידע מה לעשות עם הדברים - וכל מפתח נורמלי יידע איך לעשות את המיטיגציות (Mitigations) בהתאם להנחיות שהוא קיבל.

(רן) אוקיי, הזמן שלנו כבר קצר ואני עדיין מאוד סקרן, אז אני אבחר לעצמי עוד שאלה אחת וננסה לענות עליה - 
בעצם, היום הרבה מאוד שירותים נשענים על שירותי-צד-שלישי - אם זה לצורך, נגיד, Monitoring אז Datadog וכאלה, אם זה לצורך תשתיות אז AWS או GCP או Azure . . . זאת אומרת, הרבה מאוד הישענות על שירותי-צד-שלישי, והשאלה האם זה גם משהו שאתה לוקח בחשבון כשאתה בא לעשות Pen-Testing? 
זאת אומרת - לא רק את הקוד שאני כתבתי, אלא גם את כל השירותים האחרים שבהם אני משתמש ואולי ה-Data שאני שולח אליהם, ואולי הפגיעויות שלהם, עצמם . . . לצורך העניין יש Vulnerability ב-PagerDuty - איך זה הולך להשפיע עלי?
  • (ארז) שאלה מצויינת . . . מה שאתה מדבר עליו, יש לו שם כללי בעולם שלנו: זה נקרא TCB, שזה Trusted Computing Base
  • זה בעצם אומר אילו דברים מבחינתך זה הבסיס, שכהנחת יסוד אתה אומר “את זה אני לא בודק” . . .
  • לדוגמא - כשאתה עכשיו עושה Pen-Test לאיזה Web Application שכתוב ב-Node.js, אתה לא תלך ותבדוק את המערכת הפעלה שלו . . .  למה? כי אתה אומר ש”הנחת היסוד שלי היא שהמערכת הפעלה שלו היא תקינה” . . .
  • כמובן שאתה יכול לעשות Pen-Test על לראות שאין Vulnerabilities במערכת הפעלה, אבל באנלוגיה, נגיד - אני עכשיו עושה Pen-Test על איזשהו Web App, שפתאום משתמש בשירות צד-שלישי . . . 
    • נגיד שהוא משתמש עכשיו בשירות שליחת SMS של Twilio או לא יודע מה, משהו של צד שלישי
    • אני לא הולך לעשות עכשיו Pen-Test על Twilio  . . . מבחינתי, Twilio הוא בהנחת יסוד שלנו, והוא צד שלישי שהוא Secure.
      • קודם כל - אני לא יכול ללכת עד אינסוף ולבדוק את כל הלוויינים סביבי . . . זוכר? זה משהו עסקי . . . 
      • דבר שני - חוקית, אני לא יכול
      • דבר שלישי - גם אם הייתי יכול, הם היו אומרים לי “לך מפה” . . .
      • דבר רביעי - תשמע, זו אחריות שלהם . . .
      • [כל זה לא משנה אם הטלויזיה מאזינה . . . ]
  • מה שכן עושים זה מסתכלים על ה-Interface, זאת אומרת - אם אני עכשיו עובד עם צד-שלישי, אז כן אני אסתכל - וזה כן דברים שמסתכלים עליהם- כן אני אסתכל שאם למשל אני עובד מולו, אז אני עובד עם HTTPS, לדוגמא.
    • כי אני רוצה לוודא שה-Data עובר לשם כשהוא Encrypted בצורה נכונה.
  • כלל נוסף - אני עובד מולו אז אני רוצה לעשות Server Authentication.
    • זה Concern שלי, אני רוצה כשכשאני הולך לצד שלישי, לעשות אות’נתיקציה (Authentication) שלו, אני רוצה לוודא שכשאני עובד  עם שירות צד-שלישי, אני רוצה לוודא שבאמת אני עובד איתו ולא עם איזה Man-in-the-Middle . . . .
    • למשל, אחד הדברים שעולים ב-Pen-Test זה שבזמן הפיתוח, כיבו את ה-Certificate Validation . . . למה? כי בפיתוח לא היה לי Certificate של צד-שלישי כלשהו וביטלתי, עשיתי  . . . . דרסתי את המתודה שעושה Certificate Validation, ואמרתי “ניתן True - עזוב אותי באמא’שך . . . פונקצית-עזוב’תי-באמא’שך . . . ”
      • וכשבאים ל-Production - “וואלה מעולה - זה עובד!”, כי זה עבד גם מקודם . . . .
    • אלא הם דברים שב-Pen-Test, למשל,  כן בודקים אותם - כי כשמכניסים Man-in-the-Middle, ורואים שכשאני מגיש Certificate שהוא לא חתום ע”י ה-CA שאותו Client אמור לוודא, אז באמת אני מבין שיש בעיה . . . 
  • בקיצור - לא בודקים את הצד-שלישי, כן בודקים את האינטגרציה מולו ואת ה-Interface-ים מולו - מה נשלח? איך מאמתים אותו? כו’ . . .
(רן) אני מניח שבהקשר הזה, יש גם עניין של זליגה של מידע פרטי - אולי אם שלחת SMS, או שאתה שולח רק את הפרטים שאתה רוצה ולא בטעות מידע של מישהו אחר . . . 
  • (ארז) נכון, וברשותך אני אקח דוגמא מעולם ה-Mobile Apps - בעולם ה-Mobile Apps אתה רואה שפתאום, Out-of-the-blue . . . 
    • כאילו, זה בדיוק מהכיוון ההפוך, כן? . . .  אם מקודם אמרתי שאני יודע שיש תקשורת לשרת מסויים, פתאום אני מזהה תקשורת שהולכת לאיזשהו שרת כלשהו, שאין לי מושג מי הוא, מאיפה הוא, מהו . . . 
    • ומסתבר שה-Vendor, ברוב נחמדותו, הוסיף בפנים לוגיקה של Monitoring ושל טלמטריה . . . ולפעמים זה נעשה אפילו בצורה זדונית.
  • אגב, אחד מה-Side-effects של Pen-Test זה פתאום, במקרה, לזהות תקשורת שבכלל לא ידענו שהיא קיימת, שמגיעה מתוך איזשהו SDK שלקחנו והכנסנו פנימה . . . 
    • אנחנו רואים את זה מלא, וזה אגב אחד הדברים ש”על הדרך” פתאום אנחנו יכולים להאיר עליהם . . .
  • לפעמים, אגב, זה לא עניין של Security - לפעמים אנחנו, על הדרך, רואים משהו שעוזר לצד השני והוא אומר “וואלה, לא ידעתי בכלל שדברים כאלה קורים . . . .”
(רן) אז לדוגמא, יכול להיות מקרה שבו אתה מתקין SDK בתוך ה-Mobile-App שלך ובלי ידיעתך הוא שולח כל מיני אנליטיקות על ה-User שלך, אולי אפילו PII, זאת אומרת Personally Identifiable Information על ה-User-ים שלך, בלי שבכלל ידעת ובלי, כמובן, שהסכמת.
  • (ארז) נכון - ופתאום אתה מגלה שאתה לא עומד ברגולציה . . . שבעצם אותו צד שלישי, אותו Package תמים, שכל מה שהוא אמור לעשות זה לספק לך איזשהו חישוב של משהו מסויים
  • פתאום אתה מגלה שהוא, ברוב חוצפתו, לוקח את אותו מידע של ה-End-user ושולח לשרת שלו . . . 
  • עכשיו - גם אם זה לא בצורה זדונית, גם אם הם צריכים את זה בשביל לשפר את המוצר שלהם או לבנות איזשהו מודל Data-Science כזה או אחר - אני בבעיה, אני כ-Vendor
    • כי פתאום הוא גורם לי לא לעמוד ברגולציה שאני אמור לעמוד בה - בגלל שהוא שולח את הנתונים של הלקוחות שלי אליו . . . 
    • זה מסבך אותנו וכמובן שהרבה פעמים זה גם גובל בבעיות Security - אבל זה חלק מהדברים שעלולים למצוא ב-Pen-Test על הדרך.
(רן) כן, ברור

אז כמו שאמרנו קודם - זמננו קצר ואנחנו צריכים לסיים.
אז תודה, ארז! היה כיף והיה מעניין - ותודה על העדכון, אני מקווה שניפגש שוב ולא בעוד 10 שנים . . . .
אז עולם ה-Pen-Testing מתחדש, אני מניח, כל יום, וזה מרתק - וזהו. תודה!
(ארז) בכיף - שמחתי מאוד לבוא, שמחתי מאוד לדבר, וכמובן שאם יש עוד נושאים מעניינים אז אני בכיף אבוא וארחיב עליהם, תמיד כיף לדבר ולספר ככה את מה שבסופו של דבר עובד בצד הזה, כי אני גם רואה שברגע שגם עולם הפיתוח רואה ומבין את השיקולים של ה-Pen-Test, בסוף זה נותן יכולת טובה יותר לבצע את הפעילות הזאת.
תודה ארז, ולהתראות!
 

 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

אין תגובות:

הוסף רשומת תגובה