רשומות

בעיות בסייבר סיקוריטי והשפעתן על ערך החברה

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

מה נכנס לארגון שלכם ?

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

למה מצב באבטחת מידע בארגונים עדיין גרוע ?

תמונה
לפי היסטוריה, התקפות של  ransomware  החלו במאי 2005. מאז אחת  השנים הכי פוריות של מתקפות  ransomware  היתה שנת 2017, בה התבצעו התקפות של  WannaCry, של  Petya , ושל  Bad Rabbit.  מאז כמובן היו התקפות יותר גדולות ומוצלחות, אך השאלה היא - למה מ-2005, או מ-2017 עדיין הרבה חברות נופלות קורבן להתקפות אלו, ולא רק להתקפות  ransomware  , כי נכון להיום, התקפות  ransomware  הן השלב המסכם של גניבת מידע. אז הבעיה לא רק בהצפנת קבצים, היא הרבה יותר עמוקה - במערך אבטחת המידע בחברות, בארגונים ציבוריים, עד לתשתיות ממשלה (במדינות שונות).  כידוע אבטחת מידע זה רצף הגנות - גדרות אשר מקשות על התוקף להיכנס פנימה לתוך הארגון. בניה נכונה של מערך ההגנה זה הדבר הנכון שצריך לעשות, והוא צריך לכלול את הדברים הבאים לפי דעתי: בניה נכונה ומאובטחת של ארכיטקטורת הארגון בנית מפת סיכונים ועדכונה בצורה תקופתית ניהול נכון של סיכוני אבטחת מידע שכוללת גם סיכוני טעיות אנוש בתשתיות ובפיתוח שימוש במוצרי הגנה מטוייבים בנית מערך הבקרות כן בתחום הטכנולוגי וכן בתחום התהליכי בניה נכונה של מערך הניתור העלאת מודעות בתחומי אבטחת מידע אצל
המשך לקרוא

הגנות ‏בגישה ‏מרחוק

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

קורונה ב IT

תמונה
בגלל ההיסטריה שמתפשטת יותר מקורונה החלטתי לכתוב כמה מילים על זה.  אז בזמן האחרון הרבה חברות נערכות לתת לעובדים גישה מרחוק שימשכו לעבוד מהבית, כי גם בתי הספר עכשיו נסגרו ואין מה לעשות עם ילדים. הכוונה בסך הכל טובה, לא להשבית את המשק ולאפשר לאנשים לעבוד מהבית שזה גם מנמיך את אפשרויות ההדבקה בקורונה. יחד עם זאת את הגישה מרחוק מן הסתם צריך לאבטח ברמה טובה, על מנת שהתוקפים לא ינצלו אותה לחדירה לארגון.  יצא לי לבדוק כמה פתרונות בנושא זה, ובכולם הצלחתי "לפרוץ" - הכוונה לגשת למקומות שלא היתי צריך לגשת אליהם מרחוק. אז מכל הבדיקות שעשיתי אספתי כמה טיפים לשיפור אבטחת המידע בגישה מרחוק: 1. כדאי מאוד שהגישה תהיה באמצעות VPN. 2. כדאי מאוד שהזדהות תהיה 2fa 3. כדאי מאוד לתת גישה רק לאפליקציות הנחוצות ולא גישה לטרמינל מלא 4. כדאי מאוד להקשיח את התפריטי context (קליק ימני בעכבר) 5. כדאי מאוד לחסום גישה לאפליקציות לא נחוצות של windows וכן לסגור הרצה של סקריפטים: vbs, ps1, js, hta וכו' 6. כדאי מאוד לחסום גישה לאינטרנט מהמחשב כל עוד החיבור לארגון פעיל 7
המשך לקרוא

ליווי אבטחת מידע אפליקטיבית

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

הגנה על Web services 2

בחלק הראשון סיפרתי על הזדהות בהגנה על ה WS. עכשיו אני רוצה לספר קצת על אבטחה בארכיטקטורה של ה WS. אז על מה כדאי לשים לב בארכיטקטורה של WS ? באחד הסקרים שעשיתי מזמן, גיליתי שה-WS עוברים מהאיזור של DMZ אל האיזור של שרתים פנימיים דרך ה FW אך ללא שום הגנה נוספת. כלומר הסיכון כאן שהתוקף במידה ופורץ לאחזור ה-DMZ יוכל בקלות להפעיל WS ב-ESB. אני המלצתי כמקובל לשים XML FW בין הסביבות (ולפעמים מקובל לשים 2), אך בגלל יוקר המוצר (DATAPOWER), לא רצו לשים כלום. ומכוון שאני בעבר בא מתחום הפתוח, איפיינתי אפליקציה שתעשה הגנה בסיסית על ה-WS במעבר בין האיזורים. באפליקציה זו דרשתי את הדברים הבאים: * בדיקת גודל ה-Request * בדיקת Schema Validation * בדיקת RegEx על השדות * הזדהות עם X.509 בין כל ה-WS * שבירת פרוטוקול ל-MQ וחזרה * בדיקת Response על RegEx * בדיקת גודל ה-Response כמובן היו עוד כמה דרישות על log, מיסוך וכו. והאפליקציה עשתה את שלה - נתנה הגנה מינימלית בין הסביבות. זה כמובן לא DP, אבל גם משהו. מכוון שהמוצר לא כלל חתימות התקפתיות, דרשתי גם להעביר את הפניה דרך WAF הפנימי. בצור
המשך לקרוא