"לקוחות מחפשים פתרונות ייעודיים להגנה על ממשקי API"

חשש ממתקפות כופר, עמידה ברגולציות בנקאיות, פרטיות וההבנה כי תחרות עסקית מתחילה בשירות מוגן – כל אלו הופכים את ההגנה על ממשקי API להכרחית. ראיון מיוחד עם דר' דורון שמע, מנכ"ל חברת L7 Defense

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

"ממשקי API נמצאים היום בכל מקום. אפליקציות נבנות במהירות באמצעותם וכמעט כל הקשר הארגוני, הדיגיטלי, עם ספקים ולקוחות מבוסס על שימוש בממשקים אלו. למעשה, רובה המכריע של תעבורת האינטרנט מורכבת מממשקים כאלו", מסביר דר' דורון שמע, מייסד שותף ומנכ"ל של חברת L7 Defense. "במקביל, האקרים מצאו בשנים האחרונות את ממשקי API כמטרה נוחה ומועדפת מבחינתם, בעיקר לאור ההגנה הלא מספקת עליהם ברוב הארגונים, כאשר כלי הגנה הנפוצים כיום בארגונים "תפורים" להגנה על אפליקציות שלמות ולא על API  בודד  – היעד המרכזי להתקפה. נזכיר כי בארגון בגודל בינוני קיימים מאות ולעיתים אלפי ממשקי API, דבר ההופך הגנה "אנושית" עליהם לבלתי סבירה בעליל." 

תהליך הגנה מבוסס תוכן

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

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

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

הגנה על ממשק API דורשת הבנת מאפייני הן של תעבורת משתמש ספציפית (Session) לממשק, לצד מאפייני התעבורה הכלליים לאורך זמן. "זה עולם חדש לגמרי של הגנת סייבר. ככל שמודל השימוש ב-API משתכללים, כך גם תהליכי התקיפה", מסביר שמע. "הצורך להגן על כל ממשק API בנפרד, הופך לאתגר משמעותי כאשר מערכות הגנה קיימות פשוט לא בנויות להגנה ברזולוציה כזו ובטח שלא ברמת מורכבות מודל ההגנה הנדרש. בד"כ מדובר על מערכות הפועלות במודל  ”one size fits all”. כלומר מודל פתרון אחד לכל הממשקים. אם אם אתה רוצה משהו ייעודי לאחד מהם, נדרש לפתח וכמובן לתחזק אותו לאורך זמן."

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

האתגר הנו הגנה על ממשק בודד

בהסתכלות על המתחרים בתחום, אנחנו רואים שני טרנדים בולטים.

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

"מודלים אלו חלקיים מאד לבעיה. ראשית, ישנם לא מעט ממשקי API שכמעט ואינם מייצרים תעבורה. ולכן שיטות ה Behavioral analysis הקיימות המסוגלות בעיקר לתפוס דפוסים חריגים בולטים יחסית, מתקשות מאד לייצר סטטיסטיקה אמינה. בנוסף, Behavioral analysis לא מתפקד טוב בעולם הסלולר שאחראי לכמות נכבדה מקריאות ה API , בשל היות Session הלקוח מקוטע, מה שאינו מאפשר בניית עץ שימוש סביר.

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

הפתרון – מודל בינה מלאכותית מבוזר וסינרגטי  

"מודל ה-AI/ML שלנו בנוי לזיהוי ועצירת מתקפות סייבר על שירותי API באופן אוטומטי לחלוטין,  Inline. המודל מגן על תעבורת ממשקי API רבים, כשכל אחד מהם יכול לחיות עם קצב תעבורה משתנה, מנמוך ועד גבוה מאד", אומר שמע. "הוא עובד "מלמטה למעלה", כאשר בתחילה הוא ממוקד בזיהוי איומים ברמת השרות הבודד, ובהמשך הוא מרכיב תמונת איומים כללית יותר מצירוף המידע המתקבל מהמודלים המופעלים עבור השירותים הבודדים."  

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

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

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

"למרבה הפלא ולמרות המורכבות לכאורה של הפתרון שלנו, הוא אינו דורש תשתית IT משמעותית. למעשה, שרת 8 core סטנדרטי יכול לספק הגנה מספקת לממשקי API של בנק ישראלי ממוצע.

"המערכת משמשת כיום לקוחות בארץ ובעולם כמערכת הגנת ממשקים Inline אוטומטית מלאה, כאשר הלקוחות חווים בד"כ אפס אירועי שווא ( False positive), תוך זיהוי מדוייק מאד של איומים המגיעים בצורה סמוייה מאד בתעבורה הקיימת. כתוצאה, הארגון להמשיך לעבוד רגיל. ללא הפרעות לליבת פעילותו, וכמעט ללא השקעת כוח אדם בתחזוקה."

עד כמה הלקוחות מבינים את חשיבות ההגנה הייעודית על API?

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

"גם פתרונות API gateway אינם מיועדים להגנה על הממשק, אלא לצורך ניתוב תעבורה אליו וממנו. פתרונות אלו הפכו להיות שרתי האפליקציות החדשים דה-פקטו, הם חשובים, אך אינם פתרון הגנה. לקוחות כיום מתמודדים גם עם רגולציות מעולם הפרטיות כמו GDPR ורגולציה בנקאית על API שצוברת תאוצה בארץ ובעולם. אלו רגולציות שיכולות לעלות לארגון מליוני דולרים בקנסות. ארגון שעומד בפני שאלות כלכליות כאלו, מחפש פתרונות מוכחים כמו שלנו. ישנה גם דרישה להפחתה משמעותית של הוצאות כוח אדם, כמו גם מחסור קבוע במקצועני הגנת סייבר, שדוחפים באופן ברור את הדרישה לאוטומצית תהליכי ההגנה. 

"המבחן הוא כמה אנשים צריך בשביל להחזיק את המערכת ב 100% תפוקה. האם צריך להפעיל אנליסט אחד פעם בשבוע לשעה, או שנדרש צוות של עשרות טכנאים ואנליסטים לתחוזקת המערכת. בבנקים ישנם באופן הסטורי צוותי אבטחה שעוסקים באופן שוטף בתחזוקת מערכות ה-WAF. זוהי למעשה הודאה בכשלון האוטומציה המובטחת ע"י היצרן. באנלוגיה ברורה, אם נדרש צוות ייעודי לתחזוקת הגנת API, בוודאות נכשלת, זה לא כלכלי."