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

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

תמיר חסון · עדכון · מדריכים לקבלת החלטות

לכתוב את שתי העמדות מול רשימה יחידה

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

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

לחפש את האמצע בין למחוק ללהשאיר

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

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

תלוי באיזה כיסא יושבים

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

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

מה לבדוק לפני שמחליטים

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

שאלות נפוצות

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

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

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

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

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

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

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

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

מי אמור להכריע כשזיכויי כרטיסים תקועים בין שרשרת ספקים שונים?

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

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

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

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

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

סנכרון נתונים בין בית חולים לקופת חולים נתקע על מי מממן את הממשקים, איך מזיזים את העסק?

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

איך אני יכול לעזור בהחלטה הזו

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