אי אפשר להגן על מה שלא מודדים

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

זו לא בעיית ידע. זו בעיית מדידה. והיא קריטית כי קישוריות OT היא בדיוק המקום שבו המתקפות מרוכזות. חברת Dragos דיווחה שקבוצות ransomware שתקפו ארגונים תעשייתיים זינקו ב-64% ב-2025, עם פגיעה ב-3,300 ארגונים ברחבי העולם. תעשייה היוותה יותר משני שלישים מהקורבנות, עם זמן שהייה ממוצע של 42 יום ל-ransomware בסביבות OT. חברת Claroty מצאה ש-82% מהפריצות המאומתות לסביבות OT נכנסו דרך כלי גישה מרחוק חשופים לאינטרנט. סקר ICS/OT של SANS לשנת 2025 גילה ש-22% מהארגונים דיווחו על אירוע סייבר שפגע במערכות OT בשנה האחרונה, ו-40% מהאירועים האלה גרמו להפרעה תפעולית.

המתקפות לא מכוונות ישירות ל-PLCs. הן מכוונות לשכבת הקישוריות – ה-VPNs, ה-jump servers, כלי הגישה מרחוק, ומנגנוני העברת הקבצים שמגשרים בין IT ל-OT. ולרוב הארגונים אין דרך מסודרת למדוד אם השכבה הזו נהיית מאובטחת יותר או פחות לאורך זמן.

המאמר הזה מגדיר חמישה מדדי KPI לאבטחת קישוריות OT שצוותי CISO צריכים לעקוב אחריהם, עם נוסחאות, benchmarks, מקורות נתונים ופורמטי דיווח מוכנים לדירקטוריון. אלה לא מדדי סייבר גנריים שהותאמו ל-OT. הם נבנו ייעודית עבור הגבול בין IT ל-OT – שם הסיכון מרוכז, פערי הנראות נמשכים, והלחץ הרגולטורי מתגבר.

KPI 1: מדד חשיפת פורטים נכנסים

מה מודדים

מספר הפורטים הנכנסים הפתוחים לאזורי OT מכל רשת חיצונית או רשת IT, משוקלל לפי סיכון פרוטוקול.

למה זה חשוב

כל פורט נכנס ב-firewall של OT הוא נקודת כניסה שאפשר לגלות, לסרוק ולנצל. דוח Dragos לשנת 2026 תיעד שקבוצות ransomware נכנסו באופן שיטתי דרך פורטלי VPN וממשקי firewall לפני שנעו לעבר רשתות OT. באוגוסט 2025, GreyNoise צפו בכ-2,000 כתובות IP זדוניות שסרקו בו-זמנית נקודות קצה של RDP Web Client. ככל שפחות פורטים נכנסים פתוחים ל-OT, כך שטח התקיפה קטן – והיעד הוא אפס.

איך מחשבים

מדד חשיפת פורטים נכנסים = Σ (פורטים נכנסים פתוחים × משקל סיכון פרוטוקול)

 

פרוטוקול	משקל סיכון	הסבר
RDP (3389)	5	הווקטור המנוצל ביותר לגישה מרחוק ב-OT; CVE-2025-48817 הדגים RCE בצד הלקוח
VPN (443/1194)	4	נתיב הכניסה הראשי ל-ransomware ב-OT; חולשות VPN של Ivanti, Fortinet, Palo Alto נוצלו בהיקף רחב ב-2025
SSH (22)	3	שכיח לגישת הנדסה; סיסמאות קבועות נפוצות ב-OT
HTTP/HTTPS (80/443)	2	ממשקי web של HMI וקונסולות ניהול SCADA
TCP מותאם	2	פרוטוקולים ייחודיים לספקים; לרוב לא מתועדים ולא מנוטרים
SFTP (22)	1	העברת קבצים; סיכון נמוך יותר כשמוגדר נכון

Benchmark

ציון	דירוג	מה זה אומר
0	מצוין	אפס פורטים נכנסים – ארכיטקטורת reverse-access מלאה
1–5	טוב	חשיפה מינימלית, כנראה פורט VPN או SFTP אחד
6–15	מוגבר	מספר פרוטוקולים חשופים; מוצרים משלימים יוצרים פערים
16+	קריטי	שטח תקיפה משמעותי; נדרשת סקירה ארכיטקטונית מיידית

דיווח לדירקטוריון

הציגו כמספר בודד שמשתנה לאורך זמן. הדירקטוריון לא צריך לדעת מה זה פורט RDP 3389. הם צריכים לראות: "מדד החשיפה שלנו היה 22 ברבעון 1. הוא 4 ברבעון 3. היעד הוא 0 עד רבעון 1 הבא." הסיפור הזה ברור ובר-פעולה.

מקור נתונים

ייצוא כללי firewall (אוטומטי, שבועי), מאומת בסריקה חיצונית (Shodan, Censys) חודשית. כל פער בין ספירת כללי ה-firewall לתוצאת הסריקה החיצונית הוא כשלעצמו ממצא – זה אומר שיש פורט פתוח שמישהו שכח ממנו.

KPI 2: יחס איחוד קישוריות

מה מודדים

מספר המוצרים הנפרדים שמנהלים קישוריות IT/OT, ביחס למספר סוגי הקישוריות שהם מטפלים בהם.

למה זה חשוב

כל מוצר נוסף בערימת הקישוריות IT/OT מוסיף ספק, קונסולה, פורמט לוגים, מחזור עדכונים, ושטח תקיפה. חברת Dragos דיווחה שקבוצות ransomware ניצלו פורטלי VPN וכלי גישה מרחוק – בדיוק המוצרים המשלימים שארגונים פורסים סביב Data Diodes כי הדיודה לא מסוגלת לטפל בסשנים אינטראקטיביים. ככל שהערימה מפוצלת יותר, כך קשה יותר לשמור על מדיניות אבטחה עקבית וכך חקירת אירועים לוקחת יותר זמן.

איך מחשבים

יחס איחוד קישוריות = מספר מוצרי קישוריות / מספר סוגי קישוריות

 

סוגי קישוריות (ספרו את אלה שקיימים אצלכם):

• גישה אינטראקטיבית לאפליקציות (RDP, SSH, HTTP ל-OT)
• שיתוף קבצים דו-כיווני (SMB, SFTP בין IT ל-OT)
• העברת מידע חד-כיוונית (שכפול historian, syslog)
• גישת ספקים מרחוק (סשנים של תחזוקה צד שלישי)
• קישוריות API בין מכונות (אינטגרציה בזמן אמת)

חישוב לדוגמה:

תרחיש	מוצרים	סוגים	יחס
טלאי על טלאי: Data Diode + VPN + Jump Server + SMB Proxy + מחבר TCP	5	5	1.0
איחוד חלקי: פלטפורמה + Data Diode	2	5	0.4
איחוד מלא: פלטפורמה אחת (דיודה נשמרת לזרימות מוסדרות)	1–2	5	0.2–0.4

Benchmark

יחס	דירוג	מה זה אומר
≤ 0.4	מצוין	פלטפורמה מאוחדת שמכסה מספר סוגי קישוריות
0.5–0.7	טוב	איחוד חלקי; חלק מהמוצרים המשלימים עדיין פעילים
0.8–1.0	מוגבר	מוצר אחד לכל סוג קישוריות; ניהול מפוצל
> 1.0	קריטי	מוצרים חופפים לאותו סוג קישוריות

דיווח לדירקטוריון

"אנחנו משתמשים כרגע ב-5 מוצרים מ-4 ספקים לניהול קישוריות IT/OT. תוכנית האיחוד שלנו מורידה את זה ל-2 מוצרים מספק אחד עד רבעון 2, ומצמצמת את מורכבות ניהול הספקים ותיאום תגובה לאירועים מ-4 נתיבי הסלמה ל-1."

למה ה-KPI הזה מניע החלטות

יחס מעל 0.8 מסמן שהארגון מוציא על ניהול ערימת הקישוריות יותר מאשר על אבטחתה. לכל מוצר יש מחזור עדכונים משלו, חשיפת CVE משלו, ודרישות אינטגרציה משלו. דוח M-Trends של Mandiant לשנת 2025 מצא שניצול חולשות היה הווקטור הראשוני המוביל ב-33% מהחקירות – וחולשות אלו מכוונות יותר ויותר ל-VPN concentrators, firewalls ורכיבי קצה שמרכיבים את הערימה המשלימה.

KPI 3: כיסוי שיוך סשנים

מה מודדים

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

למה זה חשוב

IBM דיווחו על ממוצע של 181 יום לזיהוי פריצה ו-60 יום לבלימה ב-2025 – מחזור חיים כולל של 241 יום. בסביבות OT, Dragos מצאו זמן שהייה ממוצע של 42 יום ל-ransomware, בין השאר כי נכסי OT כמו תחנות הנדסה שרצות Windows מסווגים בטעות כמערכות IT והאירוע מטופל כ"IT בלבד." כשצוות ה-IR לא יכול לשייך סשן למשתמש ספציפי ולמשאב OT ספציפי, זמן החקירה מתארך פי כמה.

ההבדל בין "מישהו נכנס לאזור SCADA דרך VPN מתישהו בחודש שעבר" לבין "דנה כהן הזדהתה עם MFA ב-14:32 ב-7 במרץ מהלפטופ הארגוני שלה, נכנסה ל-SCADA-HMI-01 דרך RDP, והנה ההקלטה המלאה של הסשן" – הוא ההבדל בין שבועות של עבודה פורנזית לחמש דקות של סקירת לוגים.

איך מחשבים

כיסוי שיוך סשנים = (סשנים עם שיוך מלא / סה"כ סשנים של קישוריות OT) × 100

 

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

• זהות משתמש אישית (לא חשבון משותף, לא חשבון גנרי "ספק")
• שיטת זיהוי וסטטוס MFA
• מזהה מכשיר ומצבו ברגע הגישה
• משאב OT יעד (תחנה, שרת, או אפליקציה ספציפיים)
• זמן תחילה/סיום ומשך סשן
• המדיניות שאישרה את הסשן
• הקלטת סשן (לסשנים אינטראקטיביים: וידאו + הקלדות)

Benchmark

כיסוי	דירוג	מה זה אומר
95–100%	מצוין	שיוך מלא; צוות IR יכול לחקור כל סשן תוך דקות
80–94%	טוב	רוב הסשנים משויכים; פערים בדרך כלל בגישת ספקים או מערכות ישנות
50–79%	מוגבר	נקודות עיוורות משמעותיות; חשבונות משותפים וסשנים לא מוקלטים שכיחים
< 50%	קריטי	רוב הגישה ל-OT לא משויכת; חקירת אירועים מסתמכת על תיאום בין לוגים מפוצלים

דיווח לדירקטוריון

"87% מסשנים של קישוריות OT שלנו משויכים במלואם עם זהות אישית, MFA, מצב מכשיר והקלטת סשן. ה-13% הנותרים הם סשנים של ספקים ישנים עם הרשאות משותפות – אנחנו מעבירים אותם לחשבונות אישיים עם MFA לכל סשן והקלטה עד רבעון 3."

בעיית גישת הספקים

גישת ספקים היא המקום שבו כיסוי השיוך קורס. ארבעה טכנאים חולקים שתי הרשאות VPN, מתחברים דרך אותו jump server, בלי הקלטת סשנים, בלי מגבלות זמן, ובלי תהליך אישור. כשמשהו משתבש – ודוח Dragos לשנת 2026 תיעד ששרשרת אספקה וגישת ספקים נשארים וקטורי תקיפה מרכזיים – צוות ה-IR לא יכול לקבוע איזה טכנאי התחבר, מה עשה, או אם הסשן בכלל אושר.

KPI 4: זמן חקירה ממוצע לסשן OT (MTTI-OT)

מה מודדים

הזמן הממוצע שנדרש לצוות IR לשחזר במלואו סשן קישוריות OT – מרגע ההתרעה הראשונית ועד להבנה מלאה של מי עשה מה, מתי, ולאיזה משאב OT.

למה זה חשוב

מדדי MTTD ו-MTTR סטנדרטיים מודדים מהירות זיהוי ותגובה לאירועי אבטחת IT. אבל לאירועי קישוריות OT יש אתגר חקירה ייחודי: המידע הנדרש לשחזור הסשן מפוזר בדרך כלל ב-4–6 מערכות שונות (לוגי VPN, לוגי Windows Event של jump server, לוגי firewall, לוגי אפליקציה, כללי תיאום SIEM, ואולי מערכת הקלטת סשנים נפרדת). דוח M-Trends של Mandiant לשנת 2025 מצא שזמן שהייה חציוני ירד ל-10–11 ימים למתקפות ממוקדות, אבל סביבות OT מפגרות משמעותית – Dragos דיווחו על 42 ימים ממוצע ל-ransomware ב-OT, בין השאר בגלל סיווג שגוי ומורכבות חקירה.

MTTI-OT תופס את הנטל הזה ישירות. זה לא מדד זיהוי – ההנחה היא שההתרעה כבר הגיעה. הוא מודד כמה זמן לוקח לענות על חמש השאלות שכל צוות IR צריך: מי? מאיזה מכשיר? לאיזה משאב OT? אילו פעולות? באיזה אישור?

איך מחשבים

MTTI-OT = Σ (זמן מהתרעה עד שחזור סשן מלא) / מספר סשנים שנחקרו

 

Benchmark

זמן	דירוג	מה זה מסמן ארכיטקטונית
< 15 דקות	מצוין	פלטפורמה אחודה עם עקבות ביקורת והקלטה לכל סשן
15–60 דקות	טוב	איחוד חלקי; נדרש תיאום ידני מסוים
1–4 שעות	מוגבר	ערימה מפוצלת; צוות IR מתאם 3+ מקורות לוגים
> 4 שעות	קריטי	מערכות מרובות, ספקים מרובים, ללא ציר זמן אחיד; חקירה = שחזור פורנזי, לא סקירת לוגים

דיווח לדירקטוריון

"ה-MTTI-OT שלנו כרגע הוא 3.2 שעות כי צוות ה-IR חייב לתאם לוגים מ-4 מערכות נפרדות. אחרי איחוד על פלטפורמה אחת, היעד הוא מתחת ל-15 דקות – עקבות ביקורת אחידים עם הקלטת סשן לכל חיבור OT."

מה מוריד את ה-MTTI-OT

שלושה גורמים ארכיטקטוניים קובעים את ה-MTTI-OT יותר מכל שיפור תהליכי:

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

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

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

KPI 5: כיסוי Zero Trust לקישוריות OT

מה מודדים

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

למה זה חשוב

כל מסגרת רגולטורית משמעותית מתכנסת על Zero Trust ל-OT. משרד ההגנה האמריקאי הוציא DTM 25-003 ביולי 2025 שמורה לכל הרכיבים להשיג רמת יעד Zero Trust בכל המערכות כולל OT. הנחיית Five Eyes מינואר 2026 של CISA, NCSC-UK, BSI, FBI וסוכנויות שותפות קבעה עקרונות קישוריות מאובטחת ל-OT שמדגישים גישה מבוססת זהות, אימות רציף, ואכיפת מדיניות מפורטת. תקן NIST SP 800-207 דורש החלטות גישה לכל בקשה על בסיס זהות, בריאות מכשיר והקשר.

Data Diode עומד בדרישת המידור אבל מספק אפס זהות, אפס אימות, אפס הרשאה ואפס ניטור סשנים. VPN מספק אימות אבל נותן גישה ברמת רשת, לא ברמת אפליקציה. Jump server מספק גישת RDP אבל בדרך כלל בלי MFA לכל סשן, בדיקת מצב מכשיר, או הקלטה. רק פלטפורמת קישוריות שמשלבת את כל חמשת האלמנטים מספקת כיסוי Zero Trust מלא לסשנים ב-OT.

איך מחשבים

לכל סשן קישוריות OT, ציון מול חמישה קריטריוני Zero Trust:

קריטריון	ציון 1 (כן)	ציון 0 (לא)
זהות מאומתת (חשבון אישי + MFA)	הסשן משתמש בחשבון משתמש אישי עם אימות רב-גורמי	חשבון משותף, ללא MFA, או סיסמה בלבד
מצב מכשיר נבדק	המכשיר המתחבר נבדק לגבי רמת עדכונים, סטטוס EDR, הצפנה, תאימות	ללא בדיקת מכשיר; כל מכשיר יכול להתחבר
מדיניות נבדקת לכל בקשה	החלטת גישה על בסיס משתמש/קבוצה + משאב יעד + חלון זמן + סטטוס אישור	גישה גורפת ברגע שה-VPN מחובר
הרשאות מינימליות נאכפות	המשתמש יכול לגשת רק למשאב ה-OT הספציפי שמורשה במדיניות	המשתמש יכול להגיע לכל מכשיר ברשת ה-OT
סשן מנוטר ומוקלט	הסשן מוקלט (וידאו + הקלדות לאינטראקטיביים), פעילות מתועדת, ניתוק אוטומטי במגבלת מדיניות	ללא הקלטה, ללא מגבלת זמן, ללא תיעוד פעילות

כיסוי Zero Trust = (סשנים עם ציון 5/5) / (סה"כ סשנים של קישוריות OT) × 100

 

Benchmark

כיסוי	דירוג	מה זה אומר
90–100%	מצוין	אכיפת Zero Trust מלאה; מיושר עם המסלול הרגולטורי
70–89%	טוב	רוב הסשנים באכיפה; פערים בגישת ספקים או מערכות ישנות
40–69%	מוגבר	סשנים משמעותיים עוקפים את שרשרת Zero Trust; פערי עמידה
< 40%	קריטי	רוב קישוריות OT משתמשת בארכיטקטורה שלפני Zero Trust (VPN, jump server, הרשאות משותפות)

דיווח לדירקטוריון

"42% מסשנים של קישוריות OT שלנו עומדים כרגע בכל קריטריוני Zero Trust. הפער מרוכז בגישת ספקים מרחוק (0% כיסוי – הרשאות VPN משותפות, ללא MFA, ללא הקלטה) ובהעברות קבצים ישנות (0% כיסוי – SMB proxy עצמאי ללא שילוב זהויות). התוכנית ל-12 חודשים מעלה כיסוי ל-90%+ על ידי העברת גישת ספקים ושיתוף קבצים לפלטפורמה המאוחדת."

מסלול עמידה רגולטורי

ה-KPI הזה הוא לא רק מדד אבטחה – הוא מדד מוכנות רגולטורית. ארגונים שלא יכולים להדגים כיסוי Zero Trust לקישוריות OT יתמודדו עם חיכוך רגולטורי הולך וגובר. למנדט Zero Trust של משרד ההגנה יש לוחות זמנים ספציפיים. NIS2 באירופה דורש בקרות גישה מבוססות סיכון לגורמים חיוניים. IEC 62443 SL3+ דורש אימות רציף. לעקוב אחרי ה-KPI הזה עכשיו מציב את ה-CISO במצב שבו הוא מדגים התקדמות – במקום לרוץ כשהביקורת מגיעה.

דשבורד ה-CISO: חמשת ה-KPIs ביחד

KPI	מצב נוכחי (דוגמה)	יעד	ציר זמן
1. מדד חשיפת פורטים נכנסים	18 (VPN + RDP + 3 פורטים מותאמים)	0	6 חודשים
2. יחס איחוד קישוריות	1.0 (5 מוצרים / 5 סוגים)	0.4 (2 מוצרים / 5 סוגים)	9 חודשים
3. כיסוי שיוך סשנים	62% (פערים בספקים ומערכות ישנות)	95%+	12 חודשים
4. MTTI-OT	3.2 שעות	< 15 דקות	9 חודשים
5. כיסוי Zero Trust	42%	90%+	12 חודשים

חמשת ה-KPIs תלויים זה בזה. הורדת מדד חשיפת הפורטים הנכנסים לאפס (KPI 1) דורשת שינוי ארכיטקטוני – בדרך כלל מעבר ל-reverse-access. אותו מעבר מאחד את ערימת הקישוריות (KPI 2), שמאחד את עקבות הביקורת (KPI 3), שמאיץ זמן חקירה (KPI 4), שמאפשר אכיפת Zero Trust מלאה (KPI 5). ה-KPIs הם לא חמישה פרויקטים נפרדים. הם חמש מדידות של טרנספורמציה ארכיטקטונית אחת.

איך להתחיל: מדידת בסיס ב-30 יום

CISOs לא צריכים לפרוס שום דבר כדי להתחיל לעקוב אחרי ה-KPIs האלו. תרגיל מדידת הבסיס ב-30 יום משתמש בנתונים קיימים:

שבוע 1 – ביקורת כללי firewall. ייצאו את כל כללי ה-firewall שמסדירים תעבורה לאזורי OT. ספרו פורטים נכנסים. חשבו את מדד חשיפת הפורטים הנכנסים. הריצו סריקה חיצונית (Shodan/Censys) והשוו. תעדו פערים.

שבוע 2 – מלאי מוצרים. רשמו כל מוצר שמעורב בקישוריות IT/OT: VPN, jump server, Data Diode, SMB proxy, שער קבצים, מחברי TCP, כלי גישה מרחוק. חשבו את יחס האיחוד. תעדו איזה ספק אחראי על כל מוצר ומתי הוא עודכן לאחרונה.

שבוע 3 – ביקורת שיוך סשנים. עבור 20 סשנים אחרונים של קישוריות OT (שילוב של RDP עובד, גישת ספק, העברות קבצים), נסו לשייך כל אחד במלואו. לכמה יש זהות אישית? MFA? מצב מכשיר? הקלטת סשן? חשבו כיסוי שיוך סשנים. מדדו כמה זמן לקח כל שיוך – זה ה-MTTI-OT הבסיסי שלכם.

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

בסוף 30 יום, ל-CISO יש בסיס מכומת לכל חמשת ה-KPIs, תמונה ברורה של איפה הפערים מרוכזים, ותשתית מבוססת נתונים ל-business case הארכיטקטוני.

סיכום

מדדי סייבר גנריים לא תופסים את מצב האבטחה של קישוריות OT. MTTD ו-MTTR מודדים מהירות זיהוי ותגובה, אבל הם לא אומרים ל-CISO אם הגישה ל-OT משויכת כראוי, אם ערימת הקישוריות מאוחדת או מפוצלת, או אם הארגון מתקדם לעבר עמידה ב-Zero Trust עבור הגבול IT/OT.

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

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