סעיף 61.4 להוראה 364, קריאה של אנשי תפעול

הוראת ניהול בנקאי תקין 364 — ניהול סיכוני טכנולוגיית המידע, אבטחת המידע והגנת הסייבר היא המסמך שאליו מפנה מבקר כשהוא שואל על עדכוני אבטחה. סעיף 61.4, «ניהול טלאים (Patches)», הוא שתי פסקאות. שווה לקרוא אותן לאט, כי כמעט כל מילה בהן היא החלטה תפעולית שמישהו צריך לקבל.

מה הסעיף אומר

בתמצית, הוא דורש שני דברים:

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

טלאי חירום שאי אפשר להעביר בתהליך הרגיל מנותב לסעיף 97 (שינויי חירום).

ארבע ההחלטות שמסתתרות בפסקה הראשונה

«תהליך» — לא רשימת משימות

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

«בתוך פרק זמן שתואם את הקריטיות» — כלומר אתם קובעים את הזמנים

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

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

«פונקציונליים ולא פונקציונליים» — לא רק אבטחה

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

«בסביבה נפרדת» — ומי מוודא שזה קרה

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

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

מה צריך להיות רשום בסוף

זו הרשימה שלפיה כדאי לבדוק את עצמכם. לכל חלון תחזוקה:

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

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

שני הסעיפים הצמודים

§97 — שינויי חירום. נדרשים נהלים מוגדרים להערכה, לאישור ולקידום לייצור של שינויים שלא יכולים לעבור בתהליך הרגיל, וכן ציון מי מוסמך לאשר. בשפה תפעולית: מסלול מהיר שהוא עדיין מסלול, ולא «התקשרנו למנהל והוא אמר בסדר».

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

ולמה כתוב כאן 364 ולא 357

כי 357 הוחלפה. הוראה 364 מאחדת ומחליפה את 357, 361 ו‑363, וההפניה הנכונה היום היא אליה. הרחבנו על כך בנפרד: מה קרה להוראה 357.