דעה | אתם בטוחים שאימצתם מודל Zero Trust?
דניאל אלפרוב, מהנדסת פתרונות במגזר הפיננסי והפינטק בחברת F5, טוענת: ״אבטחת API אינה חזות הכל״
ישראל דיפנס
| 22/06/2023
תמונה: חברת F5
מודל Zero Trust זוכה לעניין רב בשנים האחרונות, אך הוא לא תמיד מובן במלואו. לעתים קרובות משווים אותו לטכנולוגיה ספציפית (לדוגמא SDP) או לשילוב בין תהליכים וסטנדרט מסוים בעולם אבטחת המידע, כמו ניהול זהויות וגישה (IDAM). ראינו את אותו בלבול כאשר הוצגו טכנולוגיות מחשוב הענן, וכל מוצר או טכנולוגיה חדשה נקראו ״ענן״.
מודל Zero Trust הוא בבסיסו תפיסה אבטחתית שממנה נובעות טכניקות וסדר פעולות. זאת, כמובן לצד מינוף של טכנולוגיות ספציפיות מתאימות, אשר אותן ניתן ליישם כדי להתמודד עם קשת רחבה של איומי אבטחה. תפיסה זאת מבוססת על הנחות, והשימושים הרבים בטכנולוגיות אלו הן התוצאות של יישום ההנחות האלו.
אם יישמתם פתרון טכנולוגי לאבטחת API, זה עדיין לא אומר שאימצתם את כלל המודל. אין מוצר אחד שיישומו משמעותו שהארגון הפך לפתע לארגון שמיישם Zero Trust באופן מלא ולכן חסין מפני התקפות, פריצות או הונאות. למעשה, טכנולוגית אבטחת ממשקי API משמשת ככלי טקטי בלבד במסגרת המודל. אבל כדי להגיע לשם יש להתחיל עם כמה הנחות יסוד ורק לאחר מכן להחליט באופן הגיוני מהם הכלים והטכנולוגיות הטובות ביותר שנובעים מהן.
חלק מההנחות שמרכיבות את המודל, מצביעות על צורך טכנולוגי ממשי בהגנה מפני רכיבי אוטומציה (BOT protection) והגנת ממשקי ה-API של הארגון, לדוגמא:
יציאה מנקודת הנחה שישנה פרצה. משתמשים פנימיים לגיטימיים יכולים להשתמש במחשב שכבר נוצל על ידי התוקפים, ובכך ללא ידיעתם, הם הופכים לאיום ממשי על הארגון. תוקפים מבינים שיותר קל להיכנס לארגון דרך החלון (המשתמש) ולא מדלת הכניסה (הרשת הארגונית), בייחוד כאשר מדובר בארגון שלא סיפק לעובדיו כלים וידע בנושא. לכן, המשתמשים אשר נמצאים תחת איום מתמיד, צריכים להיחשב ככאלו שנוצלו לרעה.
תוקף יכול לבצע מגוון רב של פעולות אם הוא מצליח לפרוץ מחשב נייד או טלפון נייד של משתמש, כולל התקפות נגד אתרים ואפליקציות באמצעות נוזקות או תוכנות כופר. הוא יכול גם לנצל חולשות אבטחה כדי להשיג גישה ושליטה מרחוק במערכות הארגוניות.
מכיוון שהשימוש היום בממשקי API גדל משמעותית, גדל אתו משטח התקיפה של האפליקציות והמערכות הארגוניות, וחשוב יותר מתמיד לבדוק כל תוכן שמגיע, אפילו ממשתמשים לגיטימיים ומאומתים, כדי לקבוע אם הוא זדוני או לא.
ההנחה שפרטי התחברות לא מספקים. בין אם מדובר במערכת, משתמש או תוכנה, נקודת ההנחה היא, שגם אם מוצגים פרטי התחברות (משתמש וסיסמא) לגיטימיים, ייתכן שהמשתמש בפועל אינו לגיטימי.
קיים מספר רב של דרכים בהן תוקף יכול להשיג פרטי התחברות של משתמשים רבים והתקפות מסוג credential stuffing הפכו שכיחות מאוד, ובבסיסן שימוש בפרטים לגיטימיים שנגנבו מהמשתמשים שלנו. ליתר דיוק, אנו יודעים על כמיליון שמות משתמש וסיסמאות המודלפים או נגנבים מידי יום.
על פי ניתוח של F5 כ-0.5%–2% מכל רשימת משתמשים שנפרצה תהיה תקפה באתר או באפליקציה בנייד בעת התקפה. לכן, המודל כולל נקיטת צעדים המאמתים, לא רק את פרטי ההתחברות, אלא את עצם זהות המשתמש.
הדבר כולל חשיפת מנגנוני אוטומציה המתחזים למשתמשים לגיטימיים. טקטית, הגנה מפני BOT, מורידה משמעותית את הסיכון להתקפות מסוג זה אשר בדרך כלל מתבצעות בצורה אוטומטית, שכן לתוקף אין זמן ומשאבים לעבור ידנית על רשימות של מיליוני משתמשים במגוון אתרים.
הנחה שהמצב תמיד משתנה. המודל דוחה את ההנחה שאין כל סיכון ברגע שמשתמש מאומת והגישה שלו מאושרת למשאב. על פי הגישה כל בקשה או טרנזקציה נחשבת מסוכנת והיא מוערכת בהתאם לתוכן שהיא נושאת ולמשתמש ששולח אותה.
ניקח לדוגמא את התקפת Session hijacking, המאפשרת למשתמש זדוני להשתלט על session תקין של משתמש לגיטימי ולקבל גישה למשאב המבוקש. אבטחת ממשקי ה-API וזיהוי אוטומציה הופכים למרכיבים קריטיים, שיסייעו לצמצם את הנזק שייגרם על ידי התקפה שכבר מתקיימת על הארגון.
בנוסף להנחות אלו, גישת Zero Trust מובילה גם לכלים וטכנולוגיות אחרות, כמו SDP ובקרת זהות וגישה, FW ו-CASB, ושלל פתרונות נוספים אשר אכן מצמצמים סיכונים ידועים. אבל לא ניתן ליישם רק אחד מהם כדי להשיג מודל שלם.
מודל Zero Trust דורג כאחת משלוש המגמות ה"מרתקות" על פי דוח State of Application Strategy 2022 report של F5, ואף זכה לציון גבוה באופן עקבי ברמת העניין ב-Google Trends בשנה האחרונה. הוא עדיין לא מושלם כתפיסה שמובילה לצמצום סיכונים – אף שיטה אינה מושלמת - אבל הוא יצליח לקדם את הארגון ולאפשר לו להסתגל ולהתמודד בהצלחה רבה יותר עם התקפות חדשות, המתפתחות מהר.
דניאל אלפרוב, מהנדסת פתרונות במגזר הפיננסי והפינטק בחברת F5, טוענת: ״אבטחת API אינה חזות הכל״
תמונה: חברת F5
מודל Zero Trust זוכה לעניין רב בשנים האחרונות, אך הוא לא תמיד מובן במלואו. לעתים קרובות משווים אותו לטכנולוגיה ספציפית (לדוגמא SDP) או לשילוב בין תהליכים וסטנדרט מסוים בעולם אבטחת המידע, כמו ניהול זהויות וגישה (IDAM). ראינו את אותו בלבול כאשר הוצגו טכנולוגיות מחשוב הענן, וכל מוצר או טכנולוגיה חדשה נקראו ״ענן״.
מודל Zero Trust הוא בבסיסו תפיסה אבטחתית שממנה נובעות טכניקות וסדר פעולות. זאת, כמובן לצד מינוף של טכנולוגיות ספציפיות מתאימות, אשר אותן ניתן ליישם כדי להתמודד עם קשת רחבה של איומי אבטחה. תפיסה זאת מבוססת על הנחות, והשימושים הרבים בטכנולוגיות אלו הן התוצאות של יישום ההנחות האלו.
אם יישמתם פתרון טכנולוגי לאבטחת API, זה עדיין לא אומר שאימצתם את כלל המודל. אין מוצר אחד שיישומו משמעותו שהארגון הפך לפתע לארגון שמיישם Zero Trust באופן מלא ולכן חסין מפני התקפות, פריצות או הונאות. למעשה, טכנולוגית אבטחת ממשקי API משמשת ככלי טקטי בלבד במסגרת המודל. אבל כדי להגיע לשם יש להתחיל עם כמה הנחות יסוד ורק לאחר מכן להחליט באופן הגיוני מהם הכלים והטכנולוגיות הטובות ביותר שנובעים מהן.
חלק מההנחות שמרכיבות את המודל, מצביעות על צורך טכנולוגי ממשי בהגנה מפני רכיבי אוטומציה (BOT protection) והגנת ממשקי ה-API של הארגון, לדוגמא:
יציאה מנקודת הנחה שישנה פרצה. משתמשים פנימיים לגיטימיים יכולים להשתמש במחשב שכבר נוצל על ידי התוקפים, ובכך ללא ידיעתם, הם הופכים לאיום ממשי על הארגון. תוקפים מבינים שיותר קל להיכנס לארגון דרך החלון (המשתמש) ולא מדלת הכניסה (הרשת הארגונית), בייחוד כאשר מדובר בארגון שלא סיפק לעובדיו כלים וידע בנושא. לכן, המשתמשים אשר נמצאים תחת איום מתמיד, צריכים להיחשב ככאלו שנוצלו לרעה.
תוקף יכול לבצע מגוון רב של פעולות אם הוא מצליח לפרוץ מחשב נייד או טלפון נייד של משתמש, כולל התקפות נגד אתרים ואפליקציות באמצעות נוזקות או תוכנות כופר. הוא יכול גם לנצל חולשות אבטחה כדי להשיג גישה ושליטה מרחוק במערכות הארגוניות.
מכיוון שהשימוש היום בממשקי API גדל משמעותית, גדל אתו משטח התקיפה של האפליקציות והמערכות הארגוניות, וחשוב יותר מתמיד לבדוק כל תוכן שמגיע, אפילו ממשתמשים לגיטימיים ומאומתים, כדי לקבוע אם הוא זדוני או לא.
ההנחה שפרטי התחברות לא מספקים. בין אם מדובר במערכת, משתמש או תוכנה, נקודת ההנחה היא, שגם אם מוצגים פרטי התחברות (משתמש וסיסמא) לגיטימיים, ייתכן שהמשתמש בפועל אינו לגיטימי.
קיים מספר רב של דרכים בהן תוקף יכול להשיג פרטי התחברות של משתמשים רבים והתקפות מסוג credential stuffing הפכו שכיחות מאוד, ובבסיסן שימוש בפרטים לגיטימיים שנגנבו מהמשתמשים שלנו. ליתר דיוק, אנו יודעים על כמיליון שמות משתמש וסיסמאות המודלפים או נגנבים מידי יום.
על פי ניתוח של F5 כ-0.5%–2% מכל רשימת משתמשים שנפרצה תהיה תקפה באתר או באפליקציה בנייד בעת התקפה. לכן, המודל כולל נקיטת צעדים המאמתים, לא רק את פרטי ההתחברות, אלא את עצם זהות המשתמש.
הדבר כולל חשיפת מנגנוני אוטומציה המתחזים למשתמשים לגיטימיים. טקטית, הגנה מפני BOT, מורידה משמעותית את הסיכון להתקפות מסוג זה אשר בדרך כלל מתבצעות בצורה אוטומטית, שכן לתוקף אין זמן ומשאבים לעבור ידנית על רשימות של מיליוני משתמשים במגוון אתרים.
הנחה שהמצב תמיד משתנה. המודל דוחה את ההנחה שאין כל סיכון ברגע שמשתמש מאומת והגישה שלו מאושרת למשאב. על פי הגישה כל בקשה או טרנזקציה נחשבת מסוכנת והיא מוערכת בהתאם לתוכן שהיא נושאת ולמשתמש ששולח אותה.
ניקח לדוגמא את התקפת Session hijacking, המאפשרת למשתמש זדוני להשתלט על session תקין של משתמש לגיטימי ולקבל גישה למשאב המבוקש. אבטחת ממשקי ה-API וזיהוי אוטומציה הופכים למרכיבים קריטיים, שיסייעו לצמצם את הנזק שייגרם על ידי התקפה שכבר מתקיימת על הארגון.
בנוסף להנחות אלו, גישת Zero Trust מובילה גם לכלים וטכנולוגיות אחרות, כמו SDP ובקרת זהות וגישה, FW ו-CASB, ושלל פתרונות נוספים אשר אכן מצמצמים סיכונים ידועים. אבל לא ניתן ליישם רק אחד מהם כדי להשיג מודל שלם.
מודל Zero Trust דורג כאחת משלוש המגמות ה"מרתקות" על פי דוח State of Application Strategy 2022 report של F5, ואף זכה לציון גבוה באופן עקבי ברמת העניין ב-Google Trends בשנה האחרונה. הוא עדיין לא מושלם כתפיסה שמובילה לצמצום סיכונים – אף שיטה אינה מושלמת - אבל הוא יצליח לקדם את הארגון ולאפשר לו להסתגל ולהתמודד בהצלחה רבה יותר עם התקפות חדשות, המתפתחות מהר.
