ארגונים פיננסיים, בנקים, חברות ביטוח, חברות ממשלתיות, חברות ציבוריות בישראל, וחברות הנסחרות בארה"ב, מחויבים ביישום סעיף 404 לחוק סארבאנס אוקסלי (להלן: "ההוראות"), אם במתכונתו הרחבה - כפי שאומצה על ידי המפקח על הבנקים והמפקח על הביטוח, ואם במתכונתו הצרה - כפי שאומצה על ידי ועדת גושן והרשות לניירות ערך(ISOX) .
על פי ההוראות, הן הנהלת החברה והן רואה החשבון המבקר נדרשים להצהיר על קיומן של בקרות אפקטיביות על הדיווח הכספי.
התהליך העיקרי המהווה תשתית לקיומו של תהליך דיווח כספי מבוקר ולבקרות נוספות בתהליכים העסקיים הנו תהליך מערכות מידע או ITGC (IT General Controls).
ה-ITGC הנו תהליך חוצה ארגון ומקיף את כל תשתיות ה-IT של הארגון ואת מרבית מערכות המידע התפעוליות והפיננסיות, שהארגון עושה בהן שימוש.
במסגרת התהליך נבדקת אפקטיביות הבקרות הקיימות בתחומים הבאים:
- סביבת הבקרה של המחשוב (IT Control Environment)
- גישה לתוכניות ולנתונים (Access to Program, & Data)
- ניהול שינויים ((Change Management
- רכש ופיתוח מערכות תוכנה (SDLC)
- תפעול מערכות מידע ((System Operation
- מחשוב משתמשי קצה (End User Computing)
כדי לתחזק את התהליך, נדרשת יחידת מערכות מידע ליישם שורה רחבה של בקרות אוטומטיות וידניות ולתעד את פעולתה של כל בקרה קיימת (נתיב ביקרות).
בחלקו הראשון של המאמר אתרכז בתחומים המתייחסים לגישה לתוכניות ונתונים, לניהול שינויים ולרכש ופיתוח מערכות מידע, ואציג פתרונות מיכוניים שיסייעו בידי יחידת מערכות מידע ביישום תיעוד וניטור של הבקרות. התייחסות לתחומים האחרים תפורסם במאמר נפרד בהמשך.
יש לציין כי הכלים המיכוניים המוזכרים בהמשך המאמר מהווים כלי מסייע בידי יחידת ה-IT ביישום הבקרות ותיעודן, והטמעתם איננה חובה.
גישה לתוכניות ולנתונים (Access to Program & Data)
מטרת הבקרות בתחום זה הנה לקבוע האם קיימות בקרות נאותות של גישה לתוכניות ולנתונים, לשם הקטנת הסיכון לגישה בלתי מורשית/ בלתי הולמת למערכות המידע הרלוונטיות הקשורות לדיווח הכספי. זאת באמצעות יישום של בקרות גישה אפקטיביות, יישום מנגנון של הפרדת תפקידים ועיקרון הצורך לדעת (Need to Know ).
על מנת לאתר, לנטר ולפעול במקרה של אירוע אבטחת מידע, נדרשת הקצאה של כוח אדם לסקירת יומני אירועים (קבצי ה-Log) ממערכות המידע, לניתוח האירועים, לדיווח הממצאים ולקבלת החלטה לגבי מהות הפעולה הנדרשת (אם נדרשת).
לאנשי יחידת מערכות מידע קיים קושי בביצוע קורלציה וחיתוכים שונים בין יומני האירועים השונים המדווחים על אלפי אירועים (Events ) מידי יום.
ככלי מסייע ניתן להשתמש בטכנולוגיית(Security Information and Event Management) SIEM . טכנולוגיה זו כוללת, בין היתר, את התכונות הבאות:
1. איסוף התראות ואירועים (Events) ממערכות שונות ובפורמטים שונים.
2. ניתוח התראות על סמך חוקים שהוגדרו מראש.
3. הפקת חיוויים למפעילים על אירוע, כולל נתונים מלאים ורלוונטיים לאירוע.
4. ניהול הטיפול באירוע כולל העברת הטיפול לגורמים שונים למעקב אחר סטטוס הטיפול.
תפקידן של מערכות מבוססות טכנולוגיית SIEM הוא ללקט מידע מהלוגים שמיוצרים במערכות האבטחה ובציוד התקשורת בארגון. המערכות אוספות מידע זה, מתעדפות אותו, מנתחות אותו (זיהוי תבניות, סטטיסטיקה וכדומה), מצליבות אותו ומאפשרות להציג אותו בתצוגות בעלות ערך מוסף רב.
למשל, ניתן לזהות פרצות אבטחה או אירועי אבטחה כמעט בזמן אמת. באמצעות ה-SIEM ניתן להשתמש בלוגים רבים כדי לקבל תמונת אבטחה כוללת ומדויקת.
לשם המחשה, נניח כי הארגון עושה שימוש במערכות הבאות: Active Directory , Firewall, אפליקציית Web, ובסיס נתוניםOracle . כל אחד מהם מייצר, לדוגמה, את ההתראות הבאות:
• Active Directory: הוספת משתמש לקבוצת ה-Administrators.
• Firewall: ממצאי סריקת פורטים (Port Scan) מכתובת חיצונית.
• אפליקצייתWeb : לוגים על ניסיונות כושלים רבים במסך ההזדהות.
• בסיס נתונים Oracle: שליפת נתונים רגישים באמצעות שרת האפליקציה מטבלאות רגישות שהאפליקציה אינה אמורה לגשת אליהן.
התוצר המתקבל מיישום מוצלח של מערכת SIEM הנו זיהוי של אירועי אבטחת מידע אמיתיים ודוחות ברמות שונות אודות אותם אירועים, ומצבה הכללי של אבטחת המידע בארגון.
נציין כי תוצרי מערכת מבוססת טכנולוגיית SIEM יכולים וראויים לשמש בתחומים שונים מלבד אבטחת תשתית. התחומים הניתנים לכיסוי באמצעות תוצרי המערכת כוללים גם: זיהוי הונאות ומניעתן, בקרה על מרכזי שירות לקוחות, בקרת תשתיות הנדסה, ניהול מרכזי SOC, תגובה וניתוח אירועי אבטחת מידע, בקרה על תהליכים עסקיים, בקרה במערכות SCADA ועוד.
אחד הסיכונים העיקריים בתחום הרשאות הגישה לתוכניות ונתונים הנו, מתן הרשאות עודפות למשתמשים. בארגונים רבים, שיטת הענקת ההרשאות מבוססת על העתקת הרשאות ממשתמש קיים למשתמש חדש. המשפט "תן לה הרשאות כמו ל..." הוא משפט נפוץ. זאת, מבלי לתת את הדעת על העובדה שהמשתמש הקיים עבד בארגון תקופה ארוכה וייתכן שההרשאות שהוגדרו עבורו כוללות הרשאות שנוספו לו במהלך תקופת עבודתו.
כמו כן, ארגונים רבים אינם נוטים לשלול הרשאות גישה ממשתמשים שקודמו בתפקידם. לדוגמה: משתמש שהחל את עבודתו כקניין המפיק הזמנות רכש ממערכת הרכש בארגון, קודם לתפקיד מנהל רכש שבמסגרת תפקידו מאשר את הזמנות הרכש. בסופו של יום, יוכל הן להפיק הזמנות רכש והן לאשרן ובכך לבצע את תהליך הרכש במלואו. כל זאת מבלי עין נוספת שתבקר.
הסיכון גובר כאשר בארגון מיושמת מערכת ERP, כיוון שמדובר במערכת המרכזת את כל פעילות הארגון (רכש, ניהול מלאי, שכר, הנהלת חשבונות ועוד) ומאחר שמערכות אלו בדרך כלל מאופיינות במספר רב של מסכים, תפריטים, פרמטרים וטרנזקציות.
כלי ממוכן, המאפשר מתן מענה נאות לצמצום הסיכון הנובע ממתן הרשאות עודפות ועל ידי פגיעה בעיקרון הפרדת התפקידים (SOD- Segregation of duties) ובעיקרון מתן הרשאות על פי הצורך לדעת הוא כלי מבוסס GRC (Governance, Risk Management and Compliance).
GRC Access Control הנו כלי תפעולי המאפשר ניהול דינאמי של הרשאות, תוך שמירה על כללי הפרדת תפקידים נאותה, ניתוח הסיכונים הקיימים בהרשאות הקיימות, וכן בקרה על תהליך מתן ההרשאות ותחזוקתן בארגון באופן שוטף. קיים כיום מודול כזה במערכות ה - ERP SAP ואורקל וקיימים גם פתרונות GRC ייעודיים.
ניהול שינויים / רכש ופיתוח מערכות
הבקרות הנדרשות בתהליכי ניהול שינויים ופיתוח מערכות מידע נוגעות בעיקר להתאמה ושיתוף הפעולה בין פעילות ה- IT והיחידות העסקיות.
הבקרות בתהליכים אלה יתייחסו למחזור החיים של תהליך הפיתוח ובכלל זאת: לתחומי יזום השינוי, אישור איפיון הפיתוח / שינוי והתאמתו וכדאיותו לארגון, בדיקות אבטחת איכות QA, בדיקות משתמשים טרם הטמעה וההסבה, בקרות גישה שונות של מתכנתים וצוותי הבדיקות לסביבת הייצור, עמידה בתוכנית הפרויקט, לוחות הזמנים וכן בקרות תקציביות על עלויות הפיתוח והמשאבים המושקעים.
מערכת ממוכנת התומכת בתהליכי ניהול שינויים /תהליכי פיתוח אמורה להיות פיתרון מודולארי אשר תתמוך ב- Workflow באמצעות המודולים הבאים: כלים לניהול תצורה, כלים לניהול טסטים.
1. מודול דרישות - שימוש במודול ניהול הדרישות המאפשר לערב גורמים שונים במחזור חיי הדרישה וליצור שקיפות ושפה משותפת בארגון. יוזמי דרישות לשינויים/ פיתוח מהיחידות העסקיות יכולים לעקוב אחר מחזור החיים של כל אחת מדרישותיהם, אנשי יחידת ה - ITיכולים לצפות ולתכנן את הדרישות למשאבים בהתאם לדרישות המאושרות. מתן אפשרות להנהלת הארגון לבחון דרישות טרם אישורן, מידת תרומת הפיתוח לאסטרטגיה העסקית של הארגון תוך קביעת מדדים ומתן ציונים, יצירת תרחישים ותעדוף הדרישות.
2. מודול ניהול מסמכים - מתודולוגיות פיתוח שונות (כגון:נוהל מפת"ח) מבוססות על מסמכים כגון: מסמכי יזום אפיון ועוד במקרה זה נדרשת מערכת מידע שתיישם ניהול מסמכים על פי גרסאות תוך כדי מתן הרשאות גישה למשתמשים מורשים בלבד.במודול זה ינוהלו
3. מודול ניהול משאבים - בסיס נתונים המשותף לפרויקטים המתנהלים ולדרישות והיוזמות השונות מאפשר להציג תמונה אגרגטיבית ופרטנית של המשאבים בארגון לפי דרישה ארגונית,כישורים, הגדרות תפקיד. הצגת הדרישות השונות למשאבים השונים בארגון ניהול סט המיומנויות לכל משאב וקבלת תמונת מצב המשאבים, כישורים והגדרות תפקיד קריטיים המהווים צוואר בקבוק בארגון. מודול דיווח נפרד המאפשר מעקב אחר דיווחי שעות בפועל אל מול התכנון עדכון סטאטוס המשימות בהתאם לדיווחי השעות ואינטגרציה לשעון הנוכחות הארגוני.
4. מודול ניהול ובקרה פיננסי ולוחות זמנים - מודול זה יכלול ממשק למערכות התקציב והרכש הארגוניות. במסגרת זאת, יבוצע מעקב על ידי מנהלי הפרויקטים אחר תקציב הפרויקט והתקדמותו בפועל, הוצאות ספקים ועוד. במסגרת אפיון המודול יכללו דוחות לשימוש הנהלת הארגון על מנת לקבל תמונת מצב של השקעות בפיתוח לעומת תחזוקה ומעקב אחר ההוצאות עבור סעיפי התקציב השונים. כמו כן ניתן לאפיין מנגנון התראות מהמערכת שיאפשר התראות בזמן אמת ב Email עבור אירועים חריגים כגון חריגה מתקציב ובחינת השפעתם.
כלים לניהול בדיקות
כלים לניהול בדיקות הנם כלים אשר עוזרים לנהל את תהליך הבדיקות בפרויקט. הכלי מאפשר לרכז את השליטה על כל תהליך הבדיקות בפרויקט החל משלב התכנון ועד לשלבים האחרונים בפרויקט. שימוש בכלי לניהול בדיקות יספק לצוות הבודקים, מנהלי צוותי הבדיקות ולמנהלי הפרויקט את היכולות הבאות:
- יישומם של סטנדרטים ונהלים אחידים בכתיבת הבדיקות ותיעוד התקלות.
- ניהול הבדיקות הידניות והאוטומטיות במקביל במקום מרכזי אחד, ללא קשר ותלות האחד עם השני.
- חלוקת משימות הבדיקות בין חברי הצוות- ראשי צוותים, בודקים וכדומה בצורה קלה ופשוטה.
- תיעוד לתסריטי הבדיקות ותוצאותיהן תוך פירוט של צעדי הבדיקה ומתן הסבר לפעולות המערכת (למהדרין מומלץ לשקול יכולת הקלטה של פעילות המשתמש).
- שליטה בקצב ההתקדמות של ביצוע הבדיקות.
- ניתן להשתמש בכלי ככלי תקשורת בין צוות הבודקים לצוות המפתחים להעברת באגים ותיקונים.
- הפקת דוחות ניהולים לבחינת סטטוס ביצוע הבדיקות וקבלה של תמונת מצב בזמן ביצוע בהקשר דרישות אל מול תקלות. ודוחות נוספים כגון: דוחות באגים, דוחות סיכום.
- מנגנון חתימות בכל שלב ושלב של הבדיקות. מחסור בחתימה בשלב קודם ימנע העברת תהליך הבדיקות לשלב הבא.
הירשם לניוזלטר
Please fill out the following form to access the download.