Author Archive for CISO



22
מרץ
15

המקור לדלף מידע בארגונים

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

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

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

רבות מהפרצות הגדולות ביותר של השנים האחרונות מתבססות על גניבת מידע המצוי במערכות הארגון. לפי חברת האנטי וירוס "סימנטק" העלות הממוצעת לחברה עבור רשומת מידע שנגנבה הינה בממוצע כ- $157 (הפסד עסקי וכן במוניטין החברה), כאשר הסיבה לכ- 47% מאירועי גניבת מידע היא עובדים פנימיים בארגון. נתון מפתיע ביותר הינו שיותר מ- 66% מהפריצות שבוצעו ע"י עובדים התגלו רק לאחר מספר חודשים. דבר המעיד על כך שהעובדים הינם החוליה החלשה באבטחת המידע המסווג בארגון.

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

התממשות האיום, שבו גורם יוציא מידע מסווג מהארגון ללא אישור, תלויה רבות בערוצי הוצאת המידע מהארגון ובנגישות שלהם למקור האיום לדלף מידע (העובדים). כגון: שליחת מיילים חיצוניים מתוך המייל הארגוני, שליחת מסרים אוטומטיים ממערכות הארגון באמצעות מערכת הפצה (מייל, פקס ו- SMS), הצגה וקבלת מידע באתרי הארגון, הדפסת מסמכים, גישה למייל הארגוני מהאינטרנט (OWA), מכשירי מובייל המחוברים למייל הארגוני (Active Sync), ממשקים פנימיים וחיצוניים, דיסקים/DOK כוננים וכד'.

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

כיצד ניתן להוריד את רמת הסיכון לדלף מידע בארגון שלך:

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

מערך הרשאות
יש ליישם מערך הרשאות במערכות המידע בארגון כך שיעמדו בעקרון “הצורך לדעת” (Need to Know) – תוך הגבלת הגישה למידע לבעלי התפקידים הזקוקים לו בלבד ועמידה בעיקרון הפרדת תפקידים לדוגמא: עובדים (בעלי הרשאה) הנחשפים למידע מסווג מתוקף תפקידם, עובדים (בעלי הרשאה) הנחשפים למידע מסווג בסביבות נמוכות (טסט, פיתוח), גורמים חיצוניים (עובדי קבלן וכדומה).

טכנולוגיה
רכישת כלים חזקים לשליטה בכל פעילות הארגון. פתרונות DLP – Data Leakage Prevention system מאפשרים לנו להגביל הוצאה של נתונים בנקודות הקצה בארגון ואף לשלוט בהפעלה של יישומים – על פי רשימה שחורה (לא מורשים) או לבנה (מורשים). מערכות ה – UTM (Unified Threat Management) למשל, שנחשבות כדור הבא של חומות האש (Firewalls), כבר הטמיעו את התכונות וכוללות יכולות סינון דואר אלקטרוני, סינון תכנים ושליטה ביישומים.

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

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

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

המידע הארגוני חָשּוב לך: חְשֹוב איך להגן עליו.

על כותב המאמר:
ליאור מזור, מהנדס תוכנה. בעל תואר ראשון .B.Sc. למדעי המחשב ומתמטיקה, ניסיון של למעלה מ- 10 שנים באבטחת מידע ביישום והטמעה של מערכות אבטחת מידע בחברות מובילות וניסיון בניהול פרויקטים בארץ ובחו"ל. מוסמך מת"י כ Leading Auditor לתקן ISO 27001 , מוסמך CISSP. וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

 

07
מרץ
15

פגיעה במידע בשירות מיקור חוץ

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

הוצאת שירותים עסקיים מצריכה לאפשר אחת מהשתיים:

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

 

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

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

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

אין הרבה מה לעשות כנגד הסיכונים האלה, אך ניתן לנקוט את הצעדים הבאים:

  1. הסכם משפטי מחמיר הכולל נספח אבטחת מידע מפורט הכולל דרישות אבטחה רבות ונוקשות
  2. ביצוע ביקורות פתע (יש לעגן בהסכם המשפטי)
  3. סגירת שטח אצל הספק והקמת רשת תקשורת מבודדת במתחם הסגור
  4. בדיקות מהימנות לעובדי הספק והדרכות אבטחה תקופתיות

 

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

 

24
פבר
15

Windows כבר לא מערכת ההפעלה הפרוצה מכולן

המאמר הבא שובר כמה מיתוסים לגבי פגיעות מערכות הפעלה בשנת 2014. עפ"י המחקר שהם מצטטים, שבוצע ע"י GFI, מסתבר ששלוש מערכות ההפעלה הפגיעות בשנה שעברה היו:

  1. Mac OS X: נמצאו 149 פגיעויות, 64 מתוכן בסיכון גבוה
  2. Apple’s iOS : נמצאו 127 פגיעויות, 32 מתוכן בסיכון גבוה
  3. Linux (ברמת Kernel): נמצאו 119 פגיעויות, 24 מתוכן בסיכון גבוה

 

שתי הפגיעויות (Vulnerabilities) שעשו הכי הרבה כותרות (לא בטוח שהן היו הכי חמורות) הן Heartbleed, ShellShock. אני אוסיף לרשימה את POODLE שחיסל את פרוטוקול SSL, למרות שזה לא שייך למערכת ההפעלה.
הדפדפן Internet Explorer ממשיך 'לככב' ברשימת האפליקציה הכי פגיעה (224 פגיעויות). שימו לב גם ל – Chrome וגם ל – Oracle Java.
לאור הפריצות הרבות שהיו ב – 2014, כדאי שתמשיכו לפצ'פץ'/להטליא את מערכות ההפעלה שלכם.

22
פבר
15

חדש: צור קשר

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

09
ינו
15

ניהול סיכונים וכימות הנזק

נוהגים לומר שניהול נכון של אבטחת מידע מחייב ניהול סיכונים אשר מאפשר להעריך האם יישום של בקרה מסוימת מצדיק את העלות אל מול התועלת הצפויה. זה נכון לכל דיסציפלינה ולא רק לאבטחת מידע.
את עלות יישום הבקרה קל יחסית לאמוד. בד"כ ישנה עלות הקשורה ברכש חומרה, תוכנה או רשיונות, וישנה עלות כח אדם ליישום הפתרון (ועוד מרכיבים חשבונאיים כמו פחת, תחזוקה שנתית, שטחי אחסון וכדומה).
לעומת זאת, את מידת הסיכון לארגון קשה מאוד להעריך. את הערכת הסיכון ניתן בגסות לחלק לשני מרכיבים. הנזק לארגון כתוצאה מזליגת מידע, אובדן זמינות או פגיעה באמינות הנתונים (CIA), שאמור להיות מתורגם לנזק כספי זה המרכיב הראשון. המרכיב השני זו ההסתברות שאירוע כזה יתרחש. מדובר בשני רכיבים שאין בשבילם נוסחה מתמטית שתנבא אותם. במקרה הטוב, מנהל כלשהו יעריך בצורה גסה את עוצמת הנזק ובמקרה הרע זה יישאר כהערכה איכותית ולא כמותית. גם את ההסתברות לא ניתן להעריך, ובפרט כאשר ההסתברות עשויה להשתנות כל הזמן כיוון שכלי הפריצה הממוכנים הולכים ומשתכללים כל הזמן.
מה בכל זאת ניתן לעשות כדי לקחת את ההערכות הגסות האלה רמה אחת יותר גבוהה (אבל עדיין לא מספקת)? התשובה היא לא הרבה. אפשרות אחת היא לחפש פרסומים על אירועים דומים המציינים מה היה גובה הנזק לארגון. למשל, כמה עלה לחברה מסוימת גניבת X מספרי כרטיסי אשראי ומכאן לגזור הערכה מעט יותר מושכלת לארגון. דוגמא נוספת, מה היו אובדן ההכנסות לחברה אחרת מכך שאתר האינטרנט שלהם הושחת או לא היה זמין.
אפשרות נוספת היא לחפש מחשבונים. אומנם בד"כ המחשבונים מותאמים יותר לשוק האמריקאי שם, כנראה, ההוצאות המשפטיות גבוהות יותר, אבל זו נקודת התחלה טובה. נתקלתי במחשבון נחמד של חברת Synantec ומכון The Ponemon Institute בלינק הזה. שחקו עם הפרמטרים השונים ונסו להתאים את התוצאות לארגון שלכם ותדביקו אותם לסיכונים השונים שלכם כך שבפעם הבאה תציגו הערכה ראשונית של נזק לכל סיכון. מול הערכות מספריות, יהיה למנהל הכספים או למנהל ה – IT יותר קשה להתווכח על הצורך בהוצאות הקשורות באבטחת מידע.

21
אוק
14

המלך SSL מת, יחי המלך החדש TLS

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

בשבוע האחרון נפל דבר בעולם אבטחת המידע. הדבר הזה הוא כמו כוכב שביט שנופל על כדור הארץ, משהו שמשנה סדרי עולם. פירצה שהובילה לכך שפרוטוקול ה – SSL מת, והפודל מקשקש בזנב. מדובר בפירצה שהתגלתה ע"י חוקרי Google בפרוטוקול עצמו ולא בספרייה שמממשת קריפטוגרפיה. הפירצה כונתה POODLE וקיבלה את המזהה CVE-2014-3566. לא ניכנס לפרטים הטכניים, מי שמעוניין שיחפש באינטרנט.

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

בד"כ כשמתגלית פירצה, ניתן להתקין עדכון אבטחה שפותר את הבעיה. במקרה הזה, הבעיה נמצאה בפרוטוקול עצמו ולכן ההמלצה היחידה היא להפסיק להשתמש ב – SSL ולעבוד TLS. כיוון שאני מכיר את המוח הישראלי, אני רוצה להדגיש שיש צורך בביטול האפשרות לעשות שימוש ב – SSL; לא מספיק להגדיר/להפעיל TLS. אני אסביר בצורה מאוד כללית מדוע.

בתהליך ה – Negotiation, צד ה – Client וצד ה – Server מציגים לצד השני באיזה פרוטוקולים הם תומכים. הפרוטוקול המשותף הכי חזק בשני הצדדים נבחר – נאמר TLS v1.0. לכאורה הכל בסדר. הפירצה שהתגלתה אפשרה לתוקף באמצע (Man-in-the-Middle) להתחזות ולדווח שהוא תומך רק ב – SSL v3. זה מחייב את הצד השני להפסיק להשתמש ב – TLS. עכשיו, התוקף יכול לנצל את הפירצה שהתגלתה ב – SSL. לכן, הפתרון חייב להיות ביטול בקובץ ב – conf או ב – Registry של האפשרות לעשות שימוש ב – SSL.

 

13
ספט
14

סיכונים בהפעלת שירותי רשת

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

ברשתות המורכבות משכבות תקשורת שונות, לא כל המידע עולה לשכבות גבוהות יותר ולתתי רשתות אחרות (Broadcast Domain). בכדי לקבל מידע עשיר יותר במערכות הניהול והניטור, נהוג להפעיל שירותים ופרוטוקולים שונים המעשירים את נתוני הרשת.

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

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

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

השימוש ב – UDP מעצם טבעו אינו מאפשר הזדהות (Authentication) של המקור. בנוסף, המידע נשלח ב – Clear Text כך שניתן להאזין לו ע"י Sniffer. לכן, לפני ש – CISO מאשר הפעלת שירות כזה, כדאי שיבחן את וקטור התקיפה והאפשרות לשלוח מידע כוזב ע"י גורם לא מורשה, והסיכונים והתועלות הנובעים משירות רשת כזה. במקרים בהם ניתן להפעיל שירות מסוים על גבי TCP, רצוי לעבוד במוד זה. במקרים בהם ניתן לשלוח את המידע על גבי תווך מוצפן (למשל IPSEC), מומלץ מאוד להגדיר את התווך כמאובטח.

 

26
אוג
14

מפת תקיפות בזמן אמת

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

29
יול
14

סיסמאות ותחתונים

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

סיסמאות הן כמו תחתונים

תחליף אותם בתכיפות

אל תחלוק אותם עם אנשים אחרים

אל תשתמש בהם במקומות ציבוריים (לפחות ללא שכבה נוספת)

תפתיע עם תחתונים יצירתיים

ככל שיותר ארוכים, יותר בטוחים

אם לא תמנע גישה אליהם, תגלה דליפה

 

25
יונ
14

התגוננות בפני התקפות סייבר Cyber Defense

בכדי להגיע להסכמה מה משמעות Cyber Defense אפשר להקדיש דיונים שלמים (ולא להגיע להסכמה). לכן כדי שאוכל לתאר כאן פתרון אבטחתי לנושא, אני בוחר בהגדרה הבאה – הגדרה שהרבה אנשים הסכימו איתה כשדנתי איתם בנושא סייבר. בעבר כבר כתבתי על הנושא כאשר היה פחות ברור על מה מדובר.

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

התפיסה שיושמה ונוסתה, כוללת את המרכיבים הבאים (רשימה חלקית וראשונית).
הפרדת רשתות: הרגולציה בתחום אבטחת מידע בגופים פיננסיים בארץ, הינה מהמתקדמות בעולם. אחת הדרישות הכי חשובות במספר רגולציות (בנקים, ביטוח) מחייבת הפרדה או חציצה בין רשתות ארגוניות פנימיות לבין רשתות ציבוריות/אינטרנט. החציצה מונעת תקשורת החוצה. (לכל היצרנים/ספקים, מוצר פרוקסי אינו נחשב פתרון כזה.) בשפה תקשורתית, ניסיון ליצור צינור תקשורת החוצה בכל מיני פורטים (80, 443, 22, 21 ועוד) ייחסם ע"י ה – Firewall.
גלישה לאינטרנט תיעשה ע"י פתרונות גלישה מאובטחת. העברת קבצים ע"י פתרונות כספות. וכך הלאה. בטכנולוגיה של היום, הפגיעה בחוויית המשתמש אינה גדולה (חוץ מתלונות מפונקות ע"י עובדים שלא מעניין אותם שהארגון יישאר פרוץ). החריגה היחידה שציינתי בעבר נוגעת לשימוש במייל, שבמקרה זה הפגיעה במשתמשים גדולה ולא מספקת פתרון מקובל מבחינת עלות תועלת.

מעטפת/רכיבי הגנה חיצוניים: כל אותם רכיבים שהיו נהוגים בתפיסת אבטחת המידע הכוללת, רלוונטיים גם כאן. מערכת IPS להגנה מפני התקפות חיצוניות על הרשת, שרת WAF להגנה על אתרי אינטרנט, מערכת סינון תכנים (Content Filtering) ואנטי ספאם, מערכת הגנה נגד APT, הגנה מפני DDoS.
מהיכרות שלי עם ארגונים, ובעיקר עם מנהלי מערכות מידע ומנהלי תשתיות, הם חוטאים בכל קשור לרכיבי האבטחה. במקום לנצל 100% מיכולות החסימה של המוצרים האלה, הרבה הגדרות (לפעמים 50%) אינן מופעלות מהחשש לפגוע בשירות או מכך שזה יביא לעבודה מיותרת בעיניהם. החטא הזה מוביל לכך שפורצים מצליחים ע"י כך לנצל פרצות במעטפת החיצונית. אקווריום אטום "למעט" שני חורים זה עדיין אקווריום דולף. חייבים לחסום הכל, בלי פשרות. מנהלים, תעבדו יותר קשה.

חסימת SPF: לכאורה, זוהי הגדרה שלא הייתי אמור לפרט בנפרד, אלא תחת הסעיף מעטפת/ רכיבי הגנה חיצוניים. הסיבה שאני מקדיש לכך סעיף נפרד היא שניסיון Phishing מתוחכם יכלול שליחת מייל הכוללת כתובת מקור (Sender) המתחזה לדומיין הפנימי/ארגוני. כלומר, המייל ייראה לעובד כאילו הוא נשלח ע"י עובד אחר בתוך החברה. במקרה כזה, גם עובד ערני ימהר ללחוץ על לינק זדוני (למשל סקר שביעות רצון או פעילות רווחה) בגוף המייל ולא יחשוד שמדובר בתרמית.
SPF זוהי הגדרה שנועדה לחסום קבלת מיילים מבחוץ הכוללים בכתובת דומיין פנימי/ארגוני (שכן מיילים פנימיים לא מגיעים משרת חיצוני אלא משרת Exchange פנימי).

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

מערכת ניהול אירועים SIEM: האם אתם מודעים מי סרק או ניסה לתקוף את רשת הארגון מבחוץ? האם אתם עוקבים אחר ניסיונות נוספים של מקורות אלה? מישהו מכם מטפל בניסיונות אלה?
אם יש לכם מערכת SIEM המותקנת בארגון, חברו אליה כל מקור מידע (שרתים, מערכות אבטחה…) והגדירו חוקים שיתריעו על תבניות תקיפה או סריקה. במיוחד חשוב שיהיו חוקים שיתריעו על תקשורת שמקורה ברשת הארגון לכתובת שנצפתה ככתובת שפנתה לרשת שלכם בעבר.
מספר חוקים והגדרות חשובים:

  • צרו רשימת כתובות חשודות. לרשימה זו הכניסו כתובות שביצעו Port Scanning, שלחו מיילים חשודים שהכילו נסיונות Phishing או כתובות שה – WAF זיהה כמקור לתקיפה לאתר החברה.
  • הגדירו חוק המתריע על פתיחת תקשורת (מה – Firewall) לכתובת המצויה ברשימת הכתובות החשודות.
  • חוק המתריע על Port Scanning.
  • חוק המתריע על נסיונות תקיפה (מה – WAF) על האתר. אפשר לעדן את החוק ע"י סינון סוגי מתקפות מסויימים/רלוונטיים או רמת קריטיות של התקפות.
  • חוק המתריע על נסיונות DoS/DDoS (מה – IPS).
  • חוק המתריע על שליחת מייל למעל X נמענים (ממערכת האנטי ספאם). אפשר להוסיף חוק דומה המזהה שליחת מיילים לעובדים רגישים העשויים להיות מושא לנסיונות Phishing (מנהלי רשת, מנהלים בכירים, עובדים בעלי הרשאות רגישות).
  • חוק המתריע על מספר תחנות הנגועות בוירוס או מתקפת APT.
  • חוק המתריע על תקשורת לכתובות הידועות כשרתי Command & Control.

מערך ניטור SOC: חיברתם את כל המערכות והשרתים ל – SIEM וראיתם שמתקבלים חיווים טובים ויש התראות על אירועים חשודים. מה עושים עם כל זה?
כדי להתגונן באופן יעיל מפני התקפות סייבר, יש חשיבות גבוהה להקים מוקד SOC אשר יטפל בהתראות השונות שקופצות במערכת בתוך פרק זמן קצר. במוקדי SOC טובים, המוקדנים יידעו לטפל גם באופן אקטיבי באירועים. למשל, לחסום כתובות IP חשודות ב – Firewall, ב – WAF או ב – IPS, למחוק משרת הדוא"ל מיילים שזוהו כהתקפות Phishing, ואפילו לנתק מהרשת או להעביר לסגמנט רשת מבודד תחנות קצה חשודות.
חשוב להגדיר, בכתב, נהלי טיפול באירועים לכל סוג אירוע שהוגדר לו חוק ב – SIEM, וגם לתרחישים נוספים שאין להם חוקי SIEM. הנהלים יגדירו למי מדווחים, מתי פועלים אקטיבית וכיצד.

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

  • נסיונות חדירה ע"י מייל Phishing המכילים לינקים לאתרים זדוניים והמכילים צרופות המכילות סוסים טרויאניים שעשויים לאפשר מתקפות APT.
  • נסיונות חדירה לרכיבי תשתית ברשת הארגונית.
  • נסיונות חדירה אפליקטיביים ותשתיתיים לאתר האינטרנט.
  • נסיונות חדירה למערכת ה – VPN לגישה מרחוק.
  • נסיונות חדירה ל – IVR.

 




ספטמבר 2020
א ב ג ד ה ו ש
 12345
6789101112
13141516171819
20212223242526
27282930