מה קרה ב-ServiceNow
ServiceNow פרסמה הודעה רשמית על אירוע דלף מידע שבו הצליחו תוקפים לגשת לנתוני לקוחות דרך נקודת API שהייתה חשופה לאינטרנט ללא כל מנגנון הזדהות. לפי הדיווחים, כתובת ה-IP שזוהתה כמקור התקיפה היא 51.159.98.241, וארגונים המפעילים מערכות ServiceNow (SNOW) מומלצים לבדוק לאלתר את לוגי הגישה שלהם לאותה כתובת.
החברה הודיעה כי יצרה קשר עם כל הלקוחות שנפגעו. מניית החברה הגיבה בירידה של כשישה אחוזים בעקבות הפרסום.
הבעיה שמאחורי האירוע: API שלא מאובטח
מבחינה טכנית, הפרצה אינה חדשנית, אך היא מדגישה כשל שנמצא בארגונים רבים: חשיפת ממשקי API לרשת הציבורית מבלי לאכוף הזדהות ואימות משתמש. בסביבות SaaS כמו ServiceNow, שבהן כמויות גדולות של נתונים ארגוניים וכוח אדם עוברים דרך ממשקים אוטומטיים, כל API חשוף הופך לשער כניסה פוטנציאלי.
הניסיון שצברנו ב-R.A.S Systems בליווי ארגונים שמטמיעים מערכות ליבה ומשלבים שירותי SaaS מראה כי הבעיה לרוב אינה טכנולוגית בלבד, אלא ניהולית: ממשקי API נפתחים לצורך פיתוח או אינטגרציה ומעולם לא נסגרים, מתועדים, או נבדקים מחדש.
מה על ארגונים לעשות עכשיו
- בדיקת לוגים לכתובת 51.159.98.241: ארגונים שמשתמשים ב-ServiceNow צריכים לסנן את לוגי הגישה לממשקי ה-API ולבדוק אם הייתה תנועה מהכתובת הזו.
- מיפוי ממשקי API חשופים: רישום מלא של כל נקודות ה-API הפעילות, כולל אלה שנפתחו לצורך אינטגרציות ישנות.
- אכיפת הזדהות (Authentication) בכל ממשק: אין API ציבורי שאמור לפעול ללא OAuth, API Key מנוהל, או מנגנון הזדהות מקביל.
- הגדרת התראות חריגות: ניטור נפח שאילתות חריג בממשקי ה-API כחלק ממערך ה-SIEM הארגוני.
הקשר רחב יותר לאבטחת מערכות ליבה
אירועים כמו זה ב-ServiceNow מזכירים שגם פלטפורמות בוגרות ומוכחות בשוק חשופות לכשלים כאשר ההגדרות הבסיסיות אינן נאכפות. כשארגון מטמיע מערכת ליבה מורכבת, בין אם מדובר ב-ITSM, CRM או ERP, אבטחת ממשקי ה-API אינה רכיב שניתן להשאיר לברירת המחדל של הספק.
מבחינת R.A.S Systems, כל מערכת ליבה שאנו מפתחים ומטמיעים כוללת מדיניות אבטחת API מוגדרת מראש, כולל הזדהות, הגבלת גישה לפי תפקיד, ורישום מלא של כל פעולה. זו אינה תוספת, אלא תנאי יסוד. האירוע בServiceNow מדגים בדיוק מה קורה כשרכיב הזה נשמט.