✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

איך ניתן להשתמש ב-DLP כדי לסייע בהתמודדות מול מתקפות סייבר?

Erez Epstein
|
Jan 5, 2021
alt="blogs"
alt="blogs"
CloudEdge for Startups
Vmware
title="Google"

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

ארז אפשטין, מהנדס בכיר בפורספוינט. קרדיט: יח"צ

בעבר ראינו כי האקרים במרבית פעולותיהם מבצעים תקיפה ממספר סיבות מרכזיות:

* הוכחת עליונות / קבלת הכרה מהקהילה, תקיפה שאין לה מטרת ממשית לעשות נזק לחברה

אלא בעיקר להראות שזה אפשרי לקבל גישה לחברה 

* ביצוע Defacement / השחתה של אתרי החברה הפומביים כאשר המטרה המרכזית היא נזק תדמיתי

* כופר כספי, בעיקר על ידי החדרת Crypto-Locker ודומיו ובכך "החזקת" החברה ומשאביה כבני ערובה עד לביצוע התשלום

* וכמובן זירת התגוששת ברמה המדינית (Nation State Hacking)


בבחינה של מרבית ההתקפות האחרונות בישראל ובעולם אנו רואים כי ה"גביע הקדוש" של קבוצות התקיפה הינו גישה למידע ה-IP (Intellectual Property) של החברה המותקפת. חשיפה ל-IP & Data נותנת לתוקף כוח עצום, ומאפשרת לו לגרום לנזק ממשי וכמובן רווח כספי עצום.

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

במהלך השבועות האחרונים אנו עדים לשאלות רבות ופרשנויות מגוונת – "האם מערכת DLP אמורה להגן על המידע ממתקפה ממקור חיצוני ובכך לעצור דלף מידע באופן מוחלט?"

בכל תשובה מקצועית יש לייחס משמעות לעובדה שחלק ממתקפות אלו מאופיינות בכך שהארגון בעצם "איפשר" לתוקף נגישות למידע (רגיש ושאינו רגיש) מ- unmanaged device מחוץ לארגון, בנוסף לכך אנו מבינים כי מרבית

התקיפות בוצעו תחילה מאתר שירותי באינטרנט שאינו היה מאובטח כראוי (חשוב לזכור שמטרת האתר הינה במרבית המקרים צפייה במידע רגיש – לדוגמא אתר פעולות ללקוחות).

כאשר אנו מתעלמים מתשובות פופוליסטיות עם אינטרסים כלכליים כאלו ואחרים- התשובה הישירה, הנכונה והמדוייקת הינה: לא, מערכות DLP Enterprise לא נועדו להתמודד עם use case שכזה.

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

לפי שאענה, חשוב להסביר כיצד עובד פתרון DLP, הליך הטמעת DLP מתחלק לשלושה עולמות עצמאיים בהן קיימת אינטרקציה עם ה-Data, בכל אחד מה"עולמות" מערכת ה-DLP נדרשת לתת מענה מתאים:

Data-In-Motion

מידע בתהליך יציאה מהארגון באמצעות הערוצים הרשמיים (לדוגמא – מייל לגורם חיצוני, העלאת קובץ לאתר).

Data-In-Use

מידע אשר מבוצע בו שימוש (לדוגמא – ביצוע Copy/Paste למידע רגיש בין אפליקציות על גבי ה-laptop).

Data-At-Rest

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

יכולת ביצוע Discovery עבור Data-At-Rest מאפשרת לזהות מידע רגיש אשר מאוחסן ברשת (DB, Exchange, שרתי קבצים ועוד). כמו גם במחשבי העובדים (ניידים/נייחים) בקלות רבה.

בעולמות ה-Data in Use/Data In Motion כאשר קבוצת התוקפים עושה שימוש בפרוטקול סטנדרטי אשר באינטגרציה למערכת דלף המידע (כגון web, email, כספות, ענן ואפליקציות מנוהלות)- מערכת ה DLP יכולה לסייע בצמצום חלון הסיכון לדלף מידע ואף לחסום זאת לחלוטין -  בנוסף, למערכות DLP מובילות יש יכולות DTP (Data Threat Prevention) שמסייעות באיתור אינדיקטורים מקדימים לדלף מידע כחלק ממתקפה בהתאם למגוון "התנהגויות" חשודות (בניגוד למניעת דלף מידע מבוססת תוכן).

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

ועדיין, יש דרך נוספת ומהירה לצמצם את ה- Impact של מתקפות מסוג אלו.

הגנה מדלף מידע כחלק מאירוע סייבר

 

גישת ה-“Risk avoidance & Mitigation”

מדובר בחשיבה מחוץ לקופסה ביחס לתפיסות Security קיימות המתמקדות בשלושה מהלכים מרכזים בהתמודדות עם אירוע סייבר- Prevent, Detect ו- Mitigate.

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

הרעיון ב- “Risk avoidance” הינה לצמצמם את הסיכון וכמובן הנזק שיכול להיגרם היה וכל שאר מנגנוני ההגנה והשכבות כשלו או לא היו אפקטיביים מספיק. מימוש גישה זאת מתבצע באמצעות מודול ה- Discovery של מערכת ה DLP, מודול פחות מוכר וחבל, כי במיוחד היום- הוא מאוד רלוונטי.

לדוגמא, אם לא נשמור צילומי תעודות זהות בשרת הדואר ו/או הקבצים- גם אם תוקף יצליח לקבל גישה לשרת - תצלומי תעודות זהות להדליף הוא לא יצליח... (הרצת Discovery & OCR נותנת מענה ל- use case זה).

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

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

הרצת הליך Discovery (עם/בלי *remediation) תורמת גם להיבטי cyber security נוספים כגון:

1. מיפוי מאגרי מידע (חובה רגולטיבית)

2. איתור מידע אישי כחלק מ GDPR וחקיקה אחרת בתחום ההגנה על הפרטיות. לרבות מענה לדרישות כגון "The right to be forgotten"

3. סיוע בגיבוש מדיניות ניהול המידע הארגוני על ידי איתור מידע רגיש ו- Broken business process

4. תמיכה בהליכים עסקיים של Data work flow והעברת מידע מאובטחת עם content awareness בן רשתות

*Remediation- מעבר לדיווח, המערכת מאפשר ביצוע action כגון מחיקה, העברה, הצפנה וכו'

 

על הטכנולוגיה:

באמצעות שימוש ברכיב Crawler מקומי (על בסיס הסוכן) או רשתי ניתן להריץ סריקה מהירה וזאת בהתאם לאותה מדיניות DLP אשר מבוססת על רגולציות ותקנים, מילונים, החתמות וכמובן M/L.

היופי ביכולת זו הוא כמובן קלות ההטמעה, כל מה שצריך בכדי לקבל Value מהיר הוא התקנת רכיב הניהול (FSM) וכן רכיב ה Crawler המבצע סריקה ברשת, אין שום צורך להתקין רכיב GW כלשהו או לבצע שינוי תשתיתי ברשת. ברמת תחנת הקצה- יכולת ה-Discovery הינה חלק מהסוכן.

ברגע שתסתיים הסריקה נקבל דוח מפורט על הקבצים הרגישים אשר נמצאו, לרבות מאפייני הקובץ ומדיניות ההרשאות.

 

על ידי ביצוע צעדים פשוט אילו נוכל במאמץ מינימלי להגן על ה-IP של החברה אשר לעיתים רבות אינו מאובטח כראוי ולכן מהווה יעד קל ביותר לתוקף אשר השיג גישה לרשת כפי שראינו בהתקפות האחרונות.

ברור לכולנו כי עולם ה-DLP הינו רחב הרבה יותר ובכדי לתת הגנה מספקת ולהקטין את הסיכון יש לנטר

עוד ערוצים (Web,Mail,Cloud,API,MFT ועוד') וכמובן לשלב מספר שכבות הגנה נפרדות - אך התחלה בצעד כה פשוט כגון הטמעת DLP Discovery  יכולה בזמן קצר מאוד להקפיץ את רמת האבטחה על ה IP של החברה.

ערוצי דלף מידע המכוסים למול data flow בפתרון DLP Enterprise

 

גילוי נאות: הכותב הינו מהנדס בכיר ב-Forcepoint בעל ניסיון רב בהטמעות DLP מורכבות ב-10 השנים האחרונים,

אשר מאוד לא אוהב פרוייקטי DLP ארוכים שאינם נותנים ללקוח Value מהיר מהשקעה.

מידע נוסף על הפתרון תוכלו לקרוא כאן:

https://www.forcepoint.com/sites/default/files/resources/files/brochure-dlp-en.pdf

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

ארז אפשטין, מהנדס בכיר בפורספוינט. קרדיט: יח"צ

בעבר ראינו כי האקרים במרבית פעולותיהם מבצעים תקיפה ממספר סיבות מרכזיות:

* הוכחת עליונות / קבלת הכרה מהקהילה, תקיפה שאין לה מטרת ממשית לעשות נזק לחברה

אלא בעיקר להראות שזה אפשרי לקבל גישה לחברה 

* ביצוע Defacement / השחתה של אתרי החברה הפומביים כאשר המטרה המרכזית היא נזק תדמיתי

* כופר כספי, בעיקר על ידי החדרת Crypto-Locker ודומיו ובכך "החזקת" החברה ומשאביה כבני ערובה עד לביצוע התשלום

* וכמובן זירת התגוששת ברמה המדינית (Nation State Hacking)


בבחינה של מרבית ההתקפות האחרונות בישראל ובעולם אנו רואים כי ה"גביע הקדוש" של קבוצות התקיפה הינו גישה למידע ה-IP (Intellectual Property) של החברה המותקפת. חשיפה ל-IP & Data נותנת לתוקף כוח עצום, ומאפשרת לו לגרום לנזק ממשי וכמובן רווח כספי עצום.

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

במהלך השבועות האחרונים אנו עדים לשאלות רבות ופרשנויות מגוונת – "האם מערכת DLP אמורה להגן על המידע ממתקפה ממקור חיצוני ובכך לעצור דלף מידע באופן מוחלט?"

בכל תשובה מקצועית יש לייחס משמעות לעובדה שחלק ממתקפות אלו מאופיינות בכך שהארגון בעצם "איפשר" לתוקף נגישות למידע (רגיש ושאינו רגיש) מ- unmanaged device מחוץ לארגון, בנוסף לכך אנו מבינים כי מרבית

התקיפות בוצעו תחילה מאתר שירותי באינטרנט שאינו היה מאובטח כראוי (חשוב לזכור שמטרת האתר הינה במרבית המקרים צפייה במידע רגיש – לדוגמא אתר פעולות ללקוחות).

כאשר אנו מתעלמים מתשובות פופוליסטיות עם אינטרסים כלכליים כאלו ואחרים- התשובה הישירה, הנכונה והמדוייקת הינה: לא, מערכות DLP Enterprise לא נועדו להתמודד עם use case שכזה.

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

לפי שאענה, חשוב להסביר כיצד עובד פתרון DLP, הליך הטמעת DLP מתחלק לשלושה עולמות עצמאיים בהן קיימת אינטרקציה עם ה-Data, בכל אחד מה"עולמות" מערכת ה-DLP נדרשת לתת מענה מתאים:

Data-In-Motion

מידע בתהליך יציאה מהארגון באמצעות הערוצים הרשמיים (לדוגמא – מייל לגורם חיצוני, העלאת קובץ לאתר).

Data-In-Use

מידע אשר מבוצע בו שימוש (לדוגמא – ביצוע Copy/Paste למידע רגיש בין אפליקציות על גבי ה-laptop).

Data-At-Rest

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

יכולת ביצוע Discovery עבור Data-At-Rest מאפשרת לזהות מידע רגיש אשר מאוחסן ברשת (DB, Exchange, שרתי קבצים ועוד). כמו גם במחשבי העובדים (ניידים/נייחים) בקלות רבה.

בעולמות ה-Data in Use/Data In Motion כאשר קבוצת התוקפים עושה שימוש בפרוטקול סטנדרטי אשר באינטגרציה למערכת דלף המידע (כגון web, email, כספות, ענן ואפליקציות מנוהלות)- מערכת ה DLP יכולה לסייע בצמצום חלון הסיכון לדלף מידע ואף לחסום זאת לחלוטין -  בנוסף, למערכות DLP מובילות יש יכולות DTP (Data Threat Prevention) שמסייעות באיתור אינדיקטורים מקדימים לדלף מידע כחלק ממתקפה בהתאם למגוון "התנהגויות" חשודות (בניגוד למניעת דלף מידע מבוססת תוכן).

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

ועדיין, יש דרך נוספת ומהירה לצמצם את ה- Impact של מתקפות מסוג אלו.

הגנה מדלף מידע כחלק מאירוע סייבר

 

גישת ה-“Risk avoidance & Mitigation”

מדובר בחשיבה מחוץ לקופסה ביחס לתפיסות Security קיימות המתמקדות בשלושה מהלכים מרכזים בהתמודדות עם אירוע סייבר- Prevent, Detect ו- Mitigate.

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

הרעיון ב- “Risk avoidance” הינה לצמצמם את הסיכון וכמובן הנזק שיכול להיגרם היה וכל שאר מנגנוני ההגנה והשכבות כשלו או לא היו אפקטיביים מספיק. מימוש גישה זאת מתבצע באמצעות מודול ה- Discovery של מערכת ה DLP, מודול פחות מוכר וחבל, כי במיוחד היום- הוא מאוד רלוונטי.

לדוגמא, אם לא נשמור צילומי תעודות זהות בשרת הדואר ו/או הקבצים- גם אם תוקף יצליח לקבל גישה לשרת - תצלומי תעודות זהות להדליף הוא לא יצליח... (הרצת Discovery & OCR נותנת מענה ל- use case זה).

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

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

הרצת הליך Discovery (עם/בלי *remediation) תורמת גם להיבטי cyber security נוספים כגון:

1. מיפוי מאגרי מידע (חובה רגולטיבית)

2. איתור מידע אישי כחלק מ GDPR וחקיקה אחרת בתחום ההגנה על הפרטיות. לרבות מענה לדרישות כגון "The right to be forgotten"

3. סיוע בגיבוש מדיניות ניהול המידע הארגוני על ידי איתור מידע רגיש ו- Broken business process

4. תמיכה בהליכים עסקיים של Data work flow והעברת מידע מאובטחת עם content awareness בן רשתות

*Remediation- מעבר לדיווח, המערכת מאפשר ביצוע action כגון מחיקה, העברה, הצפנה וכו'

 

על הטכנולוגיה:

באמצעות שימוש ברכיב Crawler מקומי (על בסיס הסוכן) או רשתי ניתן להריץ סריקה מהירה וזאת בהתאם לאותה מדיניות DLP אשר מבוססת על רגולציות ותקנים, מילונים, החתמות וכמובן M/L.

היופי ביכולת זו הוא כמובן קלות ההטמעה, כל מה שצריך בכדי לקבל Value מהיר הוא התקנת רכיב הניהול (FSM) וכן רכיב ה Crawler המבצע סריקה ברשת, אין שום צורך להתקין רכיב GW כלשהו או לבצע שינוי תשתיתי ברשת. ברמת תחנת הקצה- יכולת ה-Discovery הינה חלק מהסוכן.

ברגע שתסתיים הסריקה נקבל דוח מפורט על הקבצים הרגישים אשר נמצאו, לרבות מאפייני הקובץ ומדיניות ההרשאות.

 

על ידי ביצוע צעדים פשוט אילו נוכל במאמץ מינימלי להגן על ה-IP של החברה אשר לעיתים רבות אינו מאובטח כראוי ולכן מהווה יעד קל ביותר לתוקף אשר השיג גישה לרשת כפי שראינו בהתקפות האחרונות.

ברור לכולנו כי עולם ה-DLP הינו רחב הרבה יותר ובכדי לתת הגנה מספקת ולהקטין את הסיכון יש לנטר

עוד ערוצים (Web,Mail,Cloud,API,MFT ועוד') וכמובן לשלב מספר שכבות הגנה נפרדות - אך התחלה בצעד כה פשוט כגון הטמעת DLP Discovery  יכולה בזמן קצר מאוד להקפיץ את רמת האבטחה על ה IP של החברה.

ערוצי דלף מידע המכוסים למול data flow בפתרון DLP Enterprise

 

גילוי נאות: הכותב הינו מהנדס בכיר ב-Forcepoint בעל ניסיון רב בהטמעות DLP מורכבות ב-10 השנים האחרונים,

אשר מאוד לא אוהב פרוייקטי DLP ארוכים שאינם נותנים ללקוח Value מהיר מהשקעה.

מידע נוסף על הפתרון תוכלו לקרוא כאן:

https://www.forcepoint.com/sites/default/files/resources/files/brochure-dlp-en.pdf

לפרטים נוספים ויצירת קשר עם נציג אורקל

תודה הודעתך התקבלה

הודעתך לא התקבלה - נסה שוב מאוחר יותר

Erez Epstein

הירשם לרשימת הדיוור של IsraelClouds

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

מילון מונחיםהשירותים שלנו תנאי שימושהרשמה לניוזלטרמדיניות פרטיות