ืจืืืื ืืช
Craig Riddell, Global Field CISO at Wallarm – Interview Series

Craig Riddell, Global Field CISO at Wallarm, הוא מנהל ביטחון סייבר מנוסה המתמקד בסיוע לתאגידים לנהל את הסיכונים הגדלים הקשורים ל-API ומערכות המונעות על ידי AI. בתפקידו הנוכחי, הוא עובד בצמוד עם CISO, CIO ומנהיגי הנדסה כדי לתרגם דפוסי התקפה אמיתיים ותרחישי התעללות לאסטרטגיות אבטחה מעשיות, עם דגש חזק על תצפית – הבנת איך API ומערכות AI מתנהגות בייצור לאורך משתמשים, יישומים ואינטגרציות. הקריירה שלו כוללת תפקידי הנהלה ברחבי ניהול זהות וגישה, ארכיטקטורת אפס אמון ואבטחת תאגידים בארגונים כולל Netwrix, Kron, ו-HP, שם הוא הוביל הפיכות IAM בקנה מידה גדול ומודרניזציה של מסגרות אבטחה. מומחיותו של Riddell מתרכזת באיומים חדשים כגון התקפות לוגיקה עסקית, התעללות API, נדידת מערכות AI והונאה, עם דגש עקבי על גישור הפער בין אסטרטגיית אבטחה ברמה גבוהה לביצוע מבצעי. Wallarm היא חברת אבטחת סייבר המתמחה בהגנה על API, יישומים ומערכות המונעות על ידי AI בסביבות ענן מודרניות. פלטפורמתה מספקת גילוי רציף, בדיקה והגנה בזמן אמת נגד איומים כגון התעללות API, התקפות לוגיקה עסקית וניצולים אוטומטיים, תוך הצעת ראות עמוקה לאיך מערכות מתנהגות לאורך תשתיות מורכבות. שנועדה לארכיטקטורות רב-ענן וענן-יליד, Wallarm משתלבת לתוך זרימות DevOps ואבטחה קיימות, מאפשרת לארגונים לגלות ולחסום התקפות כאשר הן קורות ולא לאחר מכן. על ידי שילוב מלאי API, גילוי איומים המונע על ידי AI ויכולות תגובה אוטומטיות, הפלטפורמה פותרת מציאות גדלה שבה API ומערכות AI הפכו לפני התקפה העיקריים של עסקים דיגיטליים מודרניים. התחלתך את הקריירה בעבודה ישירות עם מערכות ותשתיות ומאז התקדמת לתפקידי הנהלה המתמקדים בזהות, גישה, API ואבטחת AI. מהם השינויים המפתח שהובילו אותך למסקנה שהסיכון האמיתי עבר מהפריפריה ל-API ומערכות מונעות על ידי מכונה?
בתחילת הקריירה שלי, הדגש היה על הגנה על הקצה. אשפים, חלוקה, קשיחות תשתית. המודל הזה עבד כאשר מערכות היו יותר סטטיות וגבולות אמון היו קלים יותר להגדיר.
מה שהשתנה הוא איך יישומים נבנים ואיך מערכות מתאימות. API הפכו לרקמה החיבורית של הכל, ו-AI זירז את זה עוד יותר. עכשיו מערכות עושות החלטות, קוראות למערכות אחרות ומבצעות פעולות בקנה מידה ומהירות שאינן כוללות בני אדם בלולאה.
נקודה זו, הפריפריה הופכת לפחות רלוונטית. הסיכון האמיתי עובר לשם שהחלטות מתקבלות ופעולות מבוצעות, בתוך API וזרימות מונעות על ידי מכונה.
אם אין לך ראות ושליטה שם, אתה בוטח בהתנהגות שאינך יכול לראות לגמרי. זה המקום שבו סיכון עסקי מופיע, מחשיפה פיננסית לתוצאות בלתי מכוונות והפרעה מבצעית.
תיארת את לחיצת היד הסייברית כשבורה, בהתייחס לאופן שבו מערכות קובעות אמון ומחליפות פעולות לאורך שרשראות API ותהליכים אוטומטיים מורכבים יותר ויותר. מהי המראה של התפרקות זו בסביבת תאגיד מודרנית?
ברוב הסביבות, מערכות בוטחות זו בזו על בסיס זהות ואימות. טוקן תקף, בקשה מעוצבת היטב, והאינטראקציה מותרת.
הבעיה היא שזה מניח שתקף שווה לבטוח. זה לא נכון יותר.
אנו מאמתים זהות, אבל איננו מאמתים כוונה. אנו מאמתים גישה, אבל לא התנהגות לאורך השרשרת.
שירות עשוי להיות מורשה לקרוא לשירות אחר, שמפעיל פעולות המורכבות לאורך מספר API. כל צעד נראה לגיטימי בנפרד, אבל לאורך כל השרשרת, אתה מתחיל לראות התנהגות בלתי מכוונת או התעללות בלוגיקה.
בסביבות המונעות על ידי AI, זה מוגבר.
סוכנים יכולים לשרשר פעולות ולבצע זרימות עבודה ללא ביקורת אדם.
לחיצת היד עדיין קורית, אבל איש אינו שואל אם ההתנהגות מובנת בהקשר.
למה סיכון AI ו-API נוטה ליפול בין גבולות ארגוניים במקום להיות בבעלות ברורה?
בגלל שהמערכות אינן תואמות את האופן שבו הארגונים מאורגנים.
DevOps בעלים של מסירה. אבטחה בעלים של מדיניות. צוותי עסקים בעלים של תוצאות. צוותי נתונים בעלים של מודלים. כל קבוצה בעלים של חלק, אבל איש אינו בעלים של המערכת כפי שהיא מתנהגת בייצור.
API מבצעים לוגיקה עסקית לאורך מערכות. AI מציג החלטה לא-דטרמיניסטית על גבי זה. יחד, הם חוצים כל גבול.
הם נבנים על ידי קבוצה אחת, מאובטחים על ידי קבוצה אחרת, ונצרכים על ידי קבוצה שלישית, עם מעקב אחיד לאורך כולם.
הפערים שזה יוצר אינם כישלונות של קבוצות. הם כישלונות של מודל הפעלה לשקף איך מערכות מודרניות אכן עובדות.
בניסיונך, אילו קבוצות נוטות להניח שהן בעלות סיכון AI, והיכן הפערים העיוורים הגדולים ביותר קיימים בין אבטחה, DevOps ויחידות עסקיות?
קבוצות אבטחה נוטות להיות בעלות סיכון AI מנקודת מבט של ממשל והתאמה.
DevOps בעלים של פריסה ואמינות. יחידות עסקיות מתמקדות בתוצאות.
הפערים העיוורים מופיעים בין אזורים אלו.
אבטחה מגדירה מה צריך לקרות. DevOps מבטיח שהמערכת פועלת. העסק מתמקד בתוצאות. אבל מעט קבוצות בודקות באופן עקבי מה המערכת עושה בזמן אמת.
הפער הזה הוא שם שהסיכון חי, במיוחד כאשר ההתנהגות היא טכנית תקפה אבל לא נכונה בהקשר.
רבות מההתקפות המודרניות נראות כהתנהגות מאומתת ומאושרת במקום פלישות בולטות. כיצד ארגונים צריכים לחשוב מחדש על גילוי במציאות החדשה הזו?
אנו צריכים לעבור מעבר לזיהוי “בקשות רעות”.
במקרים רבים, הבקשה תקפה. הטוקן לגיטימי. הקריאה ל-API צפויה. מה שאינו צפוי הוא רצף הפעולות, הנפח או התוצאה.
גילוי צריך להפוך להתנהגותי והקשרי. זה פחות על בלוק בקשה יחידה ויותר על הבנת איך מערכות מתאימות במשך הזמן.
הגישות שאכן עומדות בקנה מידה גדול עוברות מעבר להתאמה לדפוסים. הן מפרקות בקשות מבנית, מטפלות בכל אינטראקציה כסט של טוקנים התנהגותיים ולא מנסות להתאים לדפוסים ידועים-רעים.
זה מאפשר לך להבין כיצד ההתנהגות מתפתחת והיכן היא סוטה, אפילו כאשר הכל נראה תקין בשטח.
אם אתה סומך על כללים סטטיים או חתימות, אתה תפספס את רוב מה שחשוב.
הדגשת את החשיבות של תצפית להתנהגות בעולם האמיתי. מהי תצפית משמעותית עבור API ומערכות AI בייצור?
תצפית משמעותית אינה רק לוגים ומטריקות. זה הבנת ההתנהגות בהקשר.
עבור API, זה אומר ראות מלאה של בקשה ותשובה, איך נקודות קצה משמשות, ואיך אינטראקציות מתפתחות במשך הזמן.
עבור מערכות AI, זה אומר הבנת קלט, החלטות ופעולות תוצאה.
החשוב ביותר, זה אומר חיבור אותם לאורך מערכות שלמות, לא אירועים מבודדים.
בלעדי זה, אתה פועל על הנחות על התנהגות המערכת במקום מציאות.
למה מודלים מסורתיים של ביקורת ואישור אנושיים הופכים להיות פחות יעילים בסביבות מונעות על ידי מכונה?
בגלל שהמהירות והקנה השתנו.
מערכות עושות אלפים או מיליוני קריאות בדקה, והתקפות או התנהגות בלתי מכוונת יכולות להתפתח בדקות או שניות. אינך יכול להכניס אדם ללולאה עבור כל החלטה מבלי לשבור ביצועים.
מערכות AI גם אינן תמיד דטרמיניסטיות, מה שהופך מודלים של אישור מוקדם לפחות יעילים.
פיקוח אנושי עדיין חשוב, אבל הוא צריך לעבור מאישור פעולות יחידות להגדרת מעקות ומעקב אחר תוצאות.
מהם הפערים המופעים הנפוצים ביותר שאתה רואה כאשר חברות מנסות לאבטח מערכות AI באמצעות מסגרות אבטחה מורשת?
הפער הגדול ביותר הוא תלות יתר בקנטרולים בזמן עיצוב.
ארגונים מתמקדים באבטחת מודלים, בדיקת קוד והגדרת מדיניות לפני פריסה. זה חשוב, אבל זה מניח שמערכות יתנהגו כפי שצפוי להן פעם שהן חיות.
במציאות, מערכות מתפתחות. API משתנות. מודלי AI מתאימים עם נתונים חדשים וזרימות עבודה. התנהגות משתנה במשך הזמן.
בלעדי אימות רציף של התנהגות בייצור, ארגונים בעצם עיוורים אחרי הפריסה.
מהי מודל הפעלה מעשית כאשר מספר בעלי עניין חולקים אחריות לסיכון AI ו-API?
זה מתחיל בהכרה שאין קבוצה יחידה שיכולה להיות בעלים של זה end-to-end.
מודל מעשי מגדיר אחריות משותפת, מעוגנת סביב מקור אמת אחד: התנהגות בזמן ריצה.
אבטחה מגדירה סיכון ומדיניות. הנדסה בונה ומפעילה מערכות. העסק מגדיר תוצאות מקובלות.
הקבוצות שמתקדמות מפעילות בלולאה סגורה. גילוי רציף, אכיפה ושיפור נהוגים על ידי מה שמערכות עושות באמת בייצור, לא מה שהונחש בזמן עיצוב.
כל בעלי עניין צריכים להיות בעלי ראות לאיך מערכות פועלות בייצור. משם, קבוצות יכולות להתאים על מה “טוב” נראה, לגלות סטיות ולהגיב.
המעבר הוא מבעלות מבודדת לאחריות מתואמת, מונחית על ידי ראות בזמן ריצה.
בהסתכלות לעתיד, האם אתה צפוי שאחריות אבטחה תהפוך למרכזית יותר שוב, או שהיא תמשיך להתפצל ככל שמערכות הופכות יותר אוטונומיות?
אחריות תישאר מפוצלת כי זה משקף איך מערכות נבנות.
מה שישתנה הוא איך אחריות זו מתואמת.
נראה יותר מודלים של ממשל יחידים שבהם קבוצות בעלות בתחומיהן אבל פועלות עם ראות והקשר משותפים.
הארגונים שיצליחו לא יהיו אלו שינסו לרכז הכל. הם יהיו אלו שיתאימו בעלי עניין סביב איך מערכות אכן מתנהגות בעולם האמיתי.
כי אם איש אינו מבין התנהגות בזמן ריצה, איש אינו באמת בעלים של הסיכון.
תודה על הראיון הגדול, קוראים שרוצים ללמוד יותר צריכים לבקר Wallarm.












