בהתקרב סיומו של העשור הראשון של המאה ה-21 מוצאים עצמם ארגונים רבים במדינת ישראל נאבקים בסיוט חדש: חובת הציות לערב רב של חוקים ודרישות רגולטוריות שבדרך זו או אחרת משפיעים על מערכות המידע בארגון.
לציית כמובן צריך. הסיכון שבאי ציות הנו העמדה לדין, שבסיומו עלול למצוא עצמו הארגון משלם קנס בן מאות אלפי ש"ח, סכום שבעתות הידוק החגורה עלול להיות מכה קשה וכואבת ובעיקר מיותרת.
אבל תהליך ההכנה של הארגון עלול להיות ארוך, קשה, מורכב ויקר. הסיבה העיקרית עלולה להיות שהארגון לא השקיע בעבר בנושא אבטחת מידע וכעת בטווח זמן קצר יחסית נאלץ לסגור פער גדול. באם ההתמודדות הייתה עם הוראה רגולטורית אחת, ניתן להתמודד באופן סביר. אלא שעל הארגונים בסקטורים השונים "מתנפלות" רגולציות שמספרן גדל והולך. חלקן "תוצרת הארץ".
החוקים עליהם מבוססת אבטחת מידע במדינת ישראל הנם:
1. החוק והתקנות להגנת הפרטיות. שני עדכונים מהותיים בחוק זה. האחד בשנת 1996 והשני בשנת 2005. עדכונים נוספים במהלך השנים שלאחר 2005. בימים אלה משגר רשם מאגרי המידע במשרד המשפטים הודעות על הפעלת הקנס המנהלי, וכדאי לשים לב לעניין זה.
2. החוק להסדרת הביטחון בגופים ציבוריים. בשנת 2005 עובר עדכון בעיקר על מנת לכלול את גופי התשתיות החיוניות (התוספת הרביעית לחוק).
רגולציות עיקריות במדינת ישראל:
1. הוראת המפקח על הבנקים לעניין ניהול תקין של טכנולוגיית המידע, משנת 2003. ההוראה חלה על תאגידים בנקאיים.
2. הוראת המפקח על הביטוח באגף שוק ההון במשרד האוצר לעניין ניהול סיכוני אבטחת מידע החלה על גופים מוסדיים (חברות ביטוח, וקרנות פנסיה וגמל).
חקיקה בעולם הרלוונטית לחלק מהארגונים במדינת ישראל:
1. חוק סרבנס-אוקסלי (SOX). הן המפקח על הבנקים והן המפקח על הביטוח אימצו את עקרונות החוק ומחייבים את הארגונים הסרים לפיקוחם לעמוד בחלק מדרישות החוק, למרות שאין במדינת ישראל חקיקה מחייבת לעניין זה.
רגולציות בעולם המחייבות חלק מהארגונים במדינת ישראל:
1. בזל II. רגולציה לסקטור הבנקאי שעיקרה ניהול סיכונים, בין היתר סיכונים תפעוליים. מרכיבי ניהול סיכוני טכנולוגיית המידע כלולים (עפ"י הגדרת המונח סיכון תפעולי) במסגרת הסיכונים התפעוליים.
2. PCI-DSS. רגולציה שמקורה בחברות כרטיסי האשראי. מטרתה לאפשר, בהתקיים תנאי סף מסויימים, לקבוע דרישות מינימום בתחום אבטחת המידע עבור סוחרים וספקי שירותים בעולם כרטיסי האשראי.
ארגון אשר רגולציה כזו או אחרת מושת עליו יפעל באופן כללי בצורה הבאה:
1. מיפוי הדרישות למול יחידות ארגוניות רלוונטיות בארגון. לדוגמה: דרישות לדירקטוריון, דרישות להנהלה, דרישות ליחידת טכנולוגיות המידע, דרישות למנהל אבטחת המידע וליחידתו וכד'. תוצר השלב: טבלת דרישות למול יחידות ארגוניות בארגון.
2. בחינת הדרישות בפועל – דוח סטאטוס המציג את הפער בין כל דרישה לבין המצב בפועל בארגון. תוצר השלב: דוח פערים עפ"י יחידות בארגון למול הדרישות.
3. תוכנית עבודה לסגירת/צמצום הפערים – כמקובל. כולל לו"ז, משאבים, סדרי עדיפויות , אחראים על הבצוע, אבני דרך ותהליכי דיווח ובקרה על התקדמות.
ככל שהחוק הנדון או הרגולציה מפורטת יותר כך הדרישות ברורות יותר, אבל בה בעת תהליך איתור הפערים מורכב וארוך יותר. כך גם תתארך לה מן הסתם "רשימת המכולת" להצטיידות לעמידה בדרישות.
בהינתן חקיקה/רגולציה חדשה (לאומית, או אימוץ דרישה בינלאומית) בהיקף של לפחות אחת לשנתיים, ימצא עצמו מנהל אבטחת המידע מהר מאד עוסק ללא הרף באיתור פערים למול דרישה שאיננה מתבססת ברוב המקרים על מתודולוגיה אבטחתית מספיק רחבת היקף, שכן חקיקה או רגולציה נולדים מתוך צורך לספק מענה להתרחשות ספציפית או רק לסקטור ספציפי..
והדוגמאות הרי הן לפניכם:
1. חוק הגנת הפרטיות להגנה של צנעת הפרט ללא התייחסות בכלל למידע עסקי,
2. חוק SOX (סרבנס-אוקסלי) לאמינות הדיווחים החשבונאיים, ולא לכלל מערכות המידע בארגון,
3. רגולציית בזל II מתייחסת רק לתאגידים בנקאיים,
4. הוראת המפקח על הבנקים לניהול תקין של מערך ה-IT בבנקים מתייחסת באופן ספציפי למספר מאד מצומצם של הבטי אבטחת מידע בבנקים. לדוגמה אין כל התייחסות להיבט האנושי.
5. הוראת המפקח על הביטוח לגבי גופים מוסדיים, חלה רק עליהם. בהמשך בדומה לסקטור הבנקאות תחול בסקטור הביטוח הוראת Solvency II העוסקת בניהול סיכונים בדומה לבזל II.
כל חקיקה או רגולציה הנה רלוונטית למקטע כזה או אחר, בין סקטוריאלי או בחתך אחר, אך עיקר הבעיה שאיננה רגולציה יחידה ובחלוף השנים הארגון מוצא עצמו נדרש לעמוד ביותר משתיים ואפילו שלוש חקיקות/רגולציות שונות בתחום אבטחת מידע ואבטחת טכנולוגיית המידע.
על מנת להימנע מהקשיים והעלויות הגבוהות אשר כבר נדרשות וימשיכו להידרש לכל הפחות בעתיד הקרוב ממעגלים גדלים והולכים של סקטורים, מומלץ לאמץ גישה שבה ניהול סיכוני טכנולוגיית המידע מתבסס על תקן אבטחת מידע בינלאומי, תקן 27001/27002.
תקן 27001/27002. הנו תקן לניהול סיכוני טכנולוגיית המידע האמור לספק מענה לכל סוגי הארגונים בכל מדינות העולם. ככזה ברור שאיננו מספק מענה ככתבו וכלשונו, ונדרשות התאמות החל מרמת המדינה, המגזר והארגון הספציפי. התקן אומץ ע"י מכון התקנים הישראלי ככתבו וכלשונו. היתרון המשמעותי של התקן הנו אי תלותו בסקטור או ארגון מסויים. בכך תהליך ההתייחסות לאבטחת מידע באמצעות התקן מחייב התאמתו לארגון הספציפי, תוך שילוב של דרישות חוקיות / רגולטוריות הרלוונטיות לאותה מדינה / אותו סקטור / ארגון. התקן מאפשר מתן מענה מותאם לכל ארגון בהיבטים הרחבים של ניהול סיכוני המידע והשימוש בטכנולוגיית המידע ומאפשר שילוב "תוך כדי תנועה" ושילוב תקופתי של רגולציות / חקיקות הן ברמה הלאומית והן ברמה הבינלאומית.
דווקא הליך זה מספק את הסיכוי המיטבי למימוש טוב, רחב ומלא של ניהול סיכוני טכנולוגיית המידע. התקן כולל את מכלול הדרישות לייסוד, הטמעה, הפעלה, ניטור, סקירה תחזוקה ושיפור של מערכת מתועדת לניהול אבטחת המידע בארגון. בכך כולל התקן למעשה את כל הבקרות אשר על הארגון להפעיל בנושא הטיפול בסיכוני סודיות, זמינות, שרידות, שלמות ואמינות של השימוש במידע ובטכנולוגיית המידע בהבטים הפיזיים, המחשוביים, האנושיים והתהליכיים לאורך כל מחזור החיים של השימוש במידע ובמערכות טכנולוגיית המידע. חשוב לציין שיש לשלב בתהליך מתחילתו את הדרישות החוקיות/רגולטוריות על מנת למנוע כפל/סתירה ביישום התקן.
התהליך הנדרש כולל על כן התאמה של מרכיבים רבים עפ"י המבנה, תהליכי העבודה ומרכיבי הטכנולוגיה בארגון ואיננו מאפשר כלל וכלל אימוץ אוטומאטי של דרישות.
כדוגמה ניתן לציין את החובה לבצע סיקרי סיכונים ע"י גורמים חיצוניים, מקצועיים ובלתי תלויים בהתאם להערכת הסיכונים של מערך טכנולוגיית המידע, ובתדירות כפי הנדרשת ע"י הרגולטורים, המפקח על הבנקים לתאגידים בנקאיים, והמפקח על הביטוח לגופים מוסדיים. לעומת זאת, בתקן לא קיימת חובה שהסקרים יבוצעו ע"י גופים חיצוניים. זו אחת האפשרויות אבל אין הכרח. על כן שילוב הדרישות במקרה זה יגדיר את תהליכי הביקורת הבאים: קיום הנהלים וביצוע הפעילויות המתחייבות מהם יכול להתבצע ע"י גורמים פנים ארגוניים (בלשון 27001: מבדק פנימי), בעוד שסקרי הסיכונים עצמם, המהווים את מבדק הבקרות האבטחתיות חייב להיעשות בידי גורמי חוץ עפ"י דרישת הרגולאטורים.
27002 הנה תורת האבטחה עפ"י מכון התקנים הבינלאומי, תורה שאומצה גם היא ככתבה וכלשונה ע"י מכון התקנים הישראלי. תורה זו מסבירה "מה כוונת המשורר" (מכון התקנים) בכל בקרה ובקרה המנוסחת ב-27001 וכיצד מכון התקנים מניח שיש ליישמה.
ראוי לציין ששני המסמכים מהווים התפתחות של שני מסמכים שהיוו את התקן הקודם ונודעו במספרם 17799. אלו התבססו על תקינה בריטית BS7799 מסוף העשור הקודם, אשר מקורה במסמכים פנימיים לניהול אבטחת המידע בחברת של הבריטית.
יישום התקן הכולל גם תהליך של הסמכה פורמאלית ומתמשכת של הארגון לתקן 27001 מהווה אם כך את "אבן הראשה" לציות לכל אחד מהחוקים/רגולציות ההולכים ומתפתחים החל מתחילת המאה הנוכחית ואשר באופן ישיר או עקיף מתייחסים לנושאי מידע וטכנולוגיית מידע.
המשמעות אם כך הנה שעל מנת להימנע מזעזועים גדולים שמשמעותם הקצאה לא מתוכננת של משאבים ומיקוד יתר לטווח קצר לנושאי ניהול סיכוני טכנולוגיית המידע (שיגרור לאחריו מיקוד חסר בטווחים הבינוני והארוך), על ארגונים להיערך להסמכתם לתקן אבטחת מידע 27001, וזאת מומלץ שיבוצע ככל האפשר בטרם יידרשו לעמוד בחקיקה/רגולציה מגזרית. תהליך כזה יביא את הארגון להתאמה אופטימלית של ניהול סיכוני המידע וטכנולוגיית המידע כאשר חקיקה/רגולציה ספציפית עשוייה בדרך כלל להוסיף אולי תוספת שולית (בעיקר התמקדות לסעיף זה או אחר, אך קשה להניח שתתווסף דרישה אבטחתית חדשה לחלוטין שלא נדרשה כבר ויושמה), אך לא לגרור את הארגון לפרוייקט במועד שלא תוכנן על ידו ובלוחות זמנים שעלולים לשבש תוכניות ארגוניות אחרות.
ותרשו לי הערה אישית קטנה:אני ובת זוגתי יורדים היום לאילת להנות ממספר קונצרטים במסגרת הפסטיבל הבנלאומי למוזיקה קאמרית. אז שיהיה שבוע טוב ונקי מוירוסים ושאר מרעין בישין, ולהתראות בשבוע הבא
לציית כמובן צריך. הסיכון שבאי ציות הנו העמדה לדין, שבסיומו עלול למצוא עצמו הארגון משלם קנס בן מאות אלפי ש"ח, סכום שבעתות הידוק החגורה עלול להיות מכה קשה וכואבת ובעיקר מיותרת.
אבל תהליך ההכנה של הארגון עלול להיות ארוך, קשה, מורכב ויקר. הסיבה העיקרית עלולה להיות שהארגון לא השקיע בעבר בנושא אבטחת מידע וכעת בטווח זמן קצר יחסית נאלץ לסגור פער גדול. באם ההתמודדות הייתה עם הוראה רגולטורית אחת, ניתן להתמודד באופן סביר. אלא שעל הארגונים בסקטורים השונים "מתנפלות" רגולציות שמספרן גדל והולך. חלקן "תוצרת הארץ".
החוקים עליהם מבוססת אבטחת מידע במדינת ישראל הנם:
1. החוק והתקנות להגנת הפרטיות. שני עדכונים מהותיים בחוק זה. האחד בשנת 1996 והשני בשנת 2005. עדכונים נוספים במהלך השנים שלאחר 2005. בימים אלה משגר רשם מאגרי המידע במשרד המשפטים הודעות על הפעלת הקנס המנהלי, וכדאי לשים לב לעניין זה.
2. החוק להסדרת הביטחון בגופים ציבוריים. בשנת 2005 עובר עדכון בעיקר על מנת לכלול את גופי התשתיות החיוניות (התוספת הרביעית לחוק).
רגולציות עיקריות במדינת ישראל:
1. הוראת המפקח על הבנקים לעניין ניהול תקין של טכנולוגיית המידע, משנת 2003. ההוראה חלה על תאגידים בנקאיים.
2. הוראת המפקח על הביטוח באגף שוק ההון במשרד האוצר לעניין ניהול סיכוני אבטחת מידע החלה על גופים מוסדיים (חברות ביטוח, וקרנות פנסיה וגמל).
חקיקה בעולם הרלוונטית לחלק מהארגונים במדינת ישראל:
1. חוק סרבנס-אוקסלי (SOX). הן המפקח על הבנקים והן המפקח על הביטוח אימצו את עקרונות החוק ומחייבים את הארגונים הסרים לפיקוחם לעמוד בחלק מדרישות החוק, למרות שאין במדינת ישראל חקיקה מחייבת לעניין זה.
רגולציות בעולם המחייבות חלק מהארגונים במדינת ישראל:
1. בזל II. רגולציה לסקטור הבנקאי שעיקרה ניהול סיכונים, בין היתר סיכונים תפעוליים. מרכיבי ניהול סיכוני טכנולוגיית המידע כלולים (עפ"י הגדרת המונח סיכון תפעולי) במסגרת הסיכונים התפעוליים.
2. PCI-DSS. רגולציה שמקורה בחברות כרטיסי האשראי. מטרתה לאפשר, בהתקיים תנאי סף מסויימים, לקבוע דרישות מינימום בתחום אבטחת המידע עבור סוחרים וספקי שירותים בעולם כרטיסי האשראי.
ארגון אשר רגולציה כזו או אחרת מושת עליו יפעל באופן כללי בצורה הבאה:
1. מיפוי הדרישות למול יחידות ארגוניות רלוונטיות בארגון. לדוגמה: דרישות לדירקטוריון, דרישות להנהלה, דרישות ליחידת טכנולוגיות המידע, דרישות למנהל אבטחת המידע וליחידתו וכד'. תוצר השלב: טבלת דרישות למול יחידות ארגוניות בארגון.
2. בחינת הדרישות בפועל – דוח סטאטוס המציג את הפער בין כל דרישה לבין המצב בפועל בארגון. תוצר השלב: דוח פערים עפ"י יחידות בארגון למול הדרישות.
3. תוכנית עבודה לסגירת/צמצום הפערים – כמקובל. כולל לו"ז, משאבים, סדרי עדיפויות , אחראים על הבצוע, אבני דרך ותהליכי דיווח ובקרה על התקדמות.
ככל שהחוק הנדון או הרגולציה מפורטת יותר כך הדרישות ברורות יותר, אבל בה בעת תהליך איתור הפערים מורכב וארוך יותר. כך גם תתארך לה מן הסתם "רשימת המכולת" להצטיידות לעמידה בדרישות.
בהינתן חקיקה/רגולציה חדשה (לאומית, או אימוץ דרישה בינלאומית) בהיקף של לפחות אחת לשנתיים, ימצא עצמו מנהל אבטחת המידע מהר מאד עוסק ללא הרף באיתור פערים למול דרישה שאיננה מתבססת ברוב המקרים על מתודולוגיה אבטחתית מספיק רחבת היקף, שכן חקיקה או רגולציה נולדים מתוך צורך לספק מענה להתרחשות ספציפית או רק לסקטור ספציפי..
והדוגמאות הרי הן לפניכם:
1. חוק הגנת הפרטיות להגנה של צנעת הפרט ללא התייחסות בכלל למידע עסקי,
2. חוק SOX (סרבנס-אוקסלי) לאמינות הדיווחים החשבונאיים, ולא לכלל מערכות המידע בארגון,
3. רגולציית בזל II מתייחסת רק לתאגידים בנקאיים,
4. הוראת המפקח על הבנקים לניהול תקין של מערך ה-IT בבנקים מתייחסת באופן ספציפי למספר מאד מצומצם של הבטי אבטחת מידע בבנקים. לדוגמה אין כל התייחסות להיבט האנושי.
5. הוראת המפקח על הביטוח לגבי גופים מוסדיים, חלה רק עליהם. בהמשך בדומה לסקטור הבנקאות תחול בסקטור הביטוח הוראת Solvency II העוסקת בניהול סיכונים בדומה לבזל II.
כל חקיקה או רגולציה הנה רלוונטית למקטע כזה או אחר, בין סקטוריאלי או בחתך אחר, אך עיקר הבעיה שאיננה רגולציה יחידה ובחלוף השנים הארגון מוצא עצמו נדרש לעמוד ביותר משתיים ואפילו שלוש חקיקות/רגולציות שונות בתחום אבטחת מידע ואבטחת טכנולוגיית המידע.
על מנת להימנע מהקשיים והעלויות הגבוהות אשר כבר נדרשות וימשיכו להידרש לכל הפחות בעתיד הקרוב ממעגלים גדלים והולכים של סקטורים, מומלץ לאמץ גישה שבה ניהול סיכוני טכנולוגיית המידע מתבסס על תקן אבטחת מידע בינלאומי, תקן 27001/27002.
תקן 27001/27002. הנו תקן לניהול סיכוני טכנולוגיית המידע האמור לספק מענה לכל סוגי הארגונים בכל מדינות העולם. ככזה ברור שאיננו מספק מענה ככתבו וכלשונו, ונדרשות התאמות החל מרמת המדינה, המגזר והארגון הספציפי. התקן אומץ ע"י מכון התקנים הישראלי ככתבו וכלשונו. היתרון המשמעותי של התקן הנו אי תלותו בסקטור או ארגון מסויים. בכך תהליך ההתייחסות לאבטחת מידע באמצעות התקן מחייב התאמתו לארגון הספציפי, תוך שילוב של דרישות חוקיות / רגולטוריות הרלוונטיות לאותה מדינה / אותו סקטור / ארגון. התקן מאפשר מתן מענה מותאם לכל ארגון בהיבטים הרחבים של ניהול סיכוני המידע והשימוש בטכנולוגיית המידע ומאפשר שילוב "תוך כדי תנועה" ושילוב תקופתי של רגולציות / חקיקות הן ברמה הלאומית והן ברמה הבינלאומית.
דווקא הליך זה מספק את הסיכוי המיטבי למימוש טוב, רחב ומלא של ניהול סיכוני טכנולוגיית המידע. התקן כולל את מכלול הדרישות לייסוד, הטמעה, הפעלה, ניטור, סקירה תחזוקה ושיפור של מערכת מתועדת לניהול אבטחת המידע בארגון. בכך כולל התקן למעשה את כל הבקרות אשר על הארגון להפעיל בנושא הטיפול בסיכוני סודיות, זמינות, שרידות, שלמות ואמינות של השימוש במידע ובטכנולוגיית המידע בהבטים הפיזיים, המחשוביים, האנושיים והתהליכיים לאורך כל מחזור החיים של השימוש במידע ובמערכות טכנולוגיית המידע. חשוב לציין שיש לשלב בתהליך מתחילתו את הדרישות החוקיות/רגולטוריות על מנת למנוע כפל/סתירה ביישום התקן.
התהליך הנדרש כולל על כן התאמה של מרכיבים רבים עפ"י המבנה, תהליכי העבודה ומרכיבי הטכנולוגיה בארגון ואיננו מאפשר כלל וכלל אימוץ אוטומאטי של דרישות.
כדוגמה ניתן לציין את החובה לבצע סיקרי סיכונים ע"י גורמים חיצוניים, מקצועיים ובלתי תלויים בהתאם להערכת הסיכונים של מערך טכנולוגיית המידע, ובתדירות כפי הנדרשת ע"י הרגולטורים, המפקח על הבנקים לתאגידים בנקאיים, והמפקח על הביטוח לגופים מוסדיים. לעומת זאת, בתקן לא קיימת חובה שהסקרים יבוצעו ע"י גופים חיצוניים. זו אחת האפשרויות אבל אין הכרח. על כן שילוב הדרישות במקרה זה יגדיר את תהליכי הביקורת הבאים: קיום הנהלים וביצוע הפעילויות המתחייבות מהם יכול להתבצע ע"י גורמים פנים ארגוניים (בלשון 27001: מבדק פנימי), בעוד שסקרי הסיכונים עצמם, המהווים את מבדק הבקרות האבטחתיות חייב להיעשות בידי גורמי חוץ עפ"י דרישת הרגולאטורים.
27002 הנה תורת האבטחה עפ"י מכון התקנים הבינלאומי, תורה שאומצה גם היא ככתבה וכלשונה ע"י מכון התקנים הישראלי. תורה זו מסבירה "מה כוונת המשורר" (מכון התקנים) בכל בקרה ובקרה המנוסחת ב-27001 וכיצד מכון התקנים מניח שיש ליישמה.
ראוי לציין ששני המסמכים מהווים התפתחות של שני מסמכים שהיוו את התקן הקודם ונודעו במספרם 17799. אלו התבססו על תקינה בריטית BS7799 מסוף העשור הקודם, אשר מקורה במסמכים פנימיים לניהול אבטחת המידע בחברת של הבריטית.
יישום התקן הכולל גם תהליך של הסמכה פורמאלית ומתמשכת של הארגון לתקן 27001 מהווה אם כך את "אבן הראשה" לציות לכל אחד מהחוקים/רגולציות ההולכים ומתפתחים החל מתחילת המאה הנוכחית ואשר באופן ישיר או עקיף מתייחסים לנושאי מידע וטכנולוגיית מידע.
המשמעות אם כך הנה שעל מנת להימנע מזעזועים גדולים שמשמעותם הקצאה לא מתוכננת של משאבים ומיקוד יתר לטווח קצר לנושאי ניהול סיכוני טכנולוגיית המידע (שיגרור לאחריו מיקוד חסר בטווחים הבינוני והארוך), על ארגונים להיערך להסמכתם לתקן אבטחת מידע 27001, וזאת מומלץ שיבוצע ככל האפשר בטרם יידרשו לעמוד בחקיקה/רגולציה מגזרית. תהליך כזה יביא את הארגון להתאמה אופטימלית של ניהול סיכוני המידע וטכנולוגיית המידע כאשר חקיקה/רגולציה ספציפית עשוייה בדרך כלל להוסיף אולי תוספת שולית (בעיקר התמקדות לסעיף זה או אחר, אך קשה להניח שתתווסף דרישה אבטחתית חדשה לחלוטין שלא נדרשה כבר ויושמה), אך לא לגרור את הארגון לפרוייקט במועד שלא תוכנן על ידו ובלוחות זמנים שעלולים לשבש תוכניות ארגוניות אחרות.
ותרשו לי הערה אישית קטנה:אני ובת זוגתי יורדים היום לאילת להנות ממספר קונצרטים במסגרת הפסטיבל הבנלאומי למוזיקה קאמרית. אז שיהיה שבוע טוב ונקי מוירוסים ושאר מרעין בישין, ולהתראות בשבוע הבא
רשומות
אין תגובות:
הוסף רשומת תגובה