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

שרתים, ציוד קצה, ציוד רשת, מערכות מחשוביות ועוד, כל אלה יוצרים רישום (לוג) לגבי פעולות שונות שהתרחשו. רישום בודד בדרך כלל לא מועיל וחסר משמעות, ורק החיבור למערכות המתאימות יניב תמונה מלאה ויסייע להתריע על אירועי אבטחת מידע שמתרחשים בחברה. לשם כך החברה נדרשת לרכוש מערכות SIEM (Security Information and Event Management) המשמשות לניהול אירועי אבטחת מידע. המערכת מקבלת נתונים ממערכות ארגוניות שונות, מנתחת אותם ומאפשרת בקרה על תהליכים ואירועים, הפקת דוחות, זיהוי פרצות אבטחה, ותגובה למתקפות המתרחשות בזמנים שונים (וקרוב לזמן אמת ככל הניתן).

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

במאמר זה אפרט צעדים מהותיים שעל מערך הביקורת הפנימית לבצע כדי לבחון אם מערכי ה- SIEM/SOCהקיימים בארגון הם אפקטיביים ומסוגלים לספק מענה הולם, הן באיתור מוקדם של ניסיונות אירוע אבטחת מידע/סייבר מהותי והן בהתממשות בפועל של אירוע מסוג זה. שאלה בסיסית שנשאל היא האם בארגון שלנו יש "אח גדול" שרואה מה מתרחש, רושם, ומתריע בפני צוות ה- SOC (Security Operation Center)?

רקע

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

• פנימי באופן מלא

הן מערך ה-SIEM (ממוחשב) והן ה-SOC (מערך כוח אדם) הם בבעלות החברה ומתופעלות על ידה באופן מלא.

• חיצוני באופן חלקי

מערך ה-SIEM הוא של חברה חיצונית ומתופעל על ידה, ואילו ה-SOC הוא פנים ארגוני.

• חיצוני באופן מלא

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

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

1. מערכות משולבות במערך ה-SIEM

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

2. מעורבות מנהל סיכונים בתהליך

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

3. מיפוי התרעות

מערך ה-SIEM מקבל מאות התרעות ביום וחשוב לבחון את רשימת החוקים שבגינם מתקבלות התראות: האם מדובר בחוקים כלליים שלא עברו התאמה לחברה, כמה חוקים הותאמו והאם יש חוקים ייעודיים.

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

4. טיפול באירוע אבטחת מידע

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

5. 24/7

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

6. מבדק חדירה מול מערך ה-SIEM

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

7. התראות אודות פעילות עסקית חריגה

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

8. יכולת מערך ה-SIEM לזהות תקיפה בתהליך

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

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

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

9. לסיכום

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

The post אז יש לכם "אח גדול" בחברה? appeared first on IIA ישראל - לשכת המבקרים הפנימיים בישראל.

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

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

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

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

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

• שלמות ואיכות המידע שמבצעים הממשקים.
• אמצעי הניטור והבקרה על תשתיות המערכות ופעילות הממשקים.
• יכולות הממשקים להתאושש מכשלים.
• שרידות תשתיות הממשקים.

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

• שלימות ואיכות המידע שמבצעים הממשקים

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

הפרקטיקה המקובלת בפיתוח תהליכי ממשק היא לבדוק את כמות הרשומות שהתקבלו בשלושה היבטים:

• מספר הרשומות שהתקבלו במשלוח המידע הנוכחי ביחס למספר שמדווח השולח.
• כמות הרשומות הכוללת שהתקבלה מהשולח בחלון זמן נתון.
• איכות המידע שעבר בממשק.

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

• אמצעי הניטור והבקרה על תשתיות המערכות ופעילות הממשקים

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

יש להתייחס לניטור והבקרה בהיבטים הבאים:

• ניטור תשתיות.
• דיווח האפליקציה וניטור שוטף על תקלות אפליקטיביות.

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

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

• יכולות הממשקים להתאושש מכשלים

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

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

• שרידות תשתיות הממשקים

בפרק זה, נדרש להתייחס לנושאים הבאים:

1. ארכיטקטורת המערכת לטובת התמודדות עם עומסים ותקלות
2. הגדרות ובדיקות עמידות בעומסים
3. גיבויים ושחזורי המידע

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

לסיכום,

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

[1] מערכות אסינכרוניות להעברת מסרים מעבירות מסרים מהשולח למקבל, מבלי לחכות שהמקבל יהיה מוכן. היתרון של תקשורת אסינכרונית הוא בכך שהשולח והמקבל יכולים לעבוד במקביל מכיוון שהם לא מחכים האחד לשני.

The post דגשים לביקורת הממשקים במערכות המידע הארגוניות appeared first on IIA ישראל - לשכת המבקרים הפנימיים בישראל.