תיאום עדכוני אבטחה לארגונים מפוקחים
התיקון היה מוכן במרץ.
החלון נקבע ליולי.
סורקי החולשות אומרים לך מה לעדכן. כלי ההפצה דוחפים את העדכון. Regulaxy מנהל את מה שבאמצע — לקבוע את החלון, לקבל את אישור בעל המערכת, לזהות מערכות שאסור להשבית באותו הלילה, ולתעד הכול.
מותקן ברשת שלכם. עובד גם ללא חיבור לאינטרנט.
- מרץהתיקון פורסם
- אפרילהקפאת סוף רבעון
- מאיבעל המערכת לא זמין
- יוניהלילה כבר תפוס למערכת אחרת
- יוליהחלון נקבע, אושר ובוצע
המחשה של מקרה טיפוסי. אלה אינם נתוני לקוח.
למה להאמין לנו
נבנה בייצור, בתוך בנק.
Regulaxy לא תוכנן עבור שוק ואז נמכר לתוכו. הוא נבנה בידי צוות תשתיות כדי לנהל את מבצעי העדכון של עצמו, ברשת מנותקת, תחת פיקוח בנק ישראל.
לא נדרשת יציאה לאינטרנט
אין CDN, אין טלמטריה, אין דיווח החוצה. המערכת רצה ברשתות שמעולם לא ראו את האינטרנט הפתוח.
בסיס הנתונים שלכם, השרתים שלכם
Regulaxy מותקן אצלכם. המידע על המצאי שלכם לא עוזב את הרשת.
עברית ואנגלית, RTL מלידה
לא ממשק מתורגם. נבנה מימין לשמאל מהמסך הראשון.
הבעיה
אף אחד לא תקוע על זיהוי החולשה.
הסורק מפיק את הרשימה בזמן. הרשימה היא לא צוואר הבקבוק. צוואר הבקבוק הוא שלושים בעלי מערכות, שכל אחד מהם מוכן לחלון — רק לא החלון הזה, ולא החודש, ולא לפני סגירת הרבעון.
וכך התיאום עובר לגיליון אקסל, לשרשור מיילים ולקבוצת ווטסאפ. אף אחד מהשלושה לא יודע מה קורה במערכת השנייה.
- 02:40
החלון שאיש לא אישר
השינוי נקבע, בעל המערכת מעולם לא אישר, ובשתיים ארבעים בלילה הוא בוטל כי מישהו עוד הריץ סוף חודש.
- אותו הלילה
ההתנגשות שאיש לא תפס
שתי מערכות עודכנו באותו הלילה. הן היו תלויות זו בזו. שום דבר בגיליון לא ידע את זה.
- אפריל
התיעוד שאיש לא שמר
הביקורת שואלת מי אישר את השינוי. התשובה נמצאת בדואר היוצא של מישהו, והוא עזב באפריל.
איך זה עובד
מרשימת CVE לחלון שמישהו חתום עליו.
חמישה שלבים. בכל אחד מהם נוצר פריט שאדם אמיתי מקבל — לא סטטוס במסך.
קיבוץ
חולשות מגיעות מהסורק או מפיד ה־SOC. Regulaxy מקבץ אותן לפי הדבר שבאמת אפשר לתזמן — התיקון. תיקון אחד, הרבה חולשות, הרבה שרתים.
מה נוצרקבוצת תיקון אחת
דירוג
כל תיקון מקבל ציון מול המערכות שהוא נוגע בהן, לפי ניתוח ההשפעה העסקית שלכם — לא לפי CVSS לבדו.
מה נוצרציון עם פירוט הרכיבים
הצעה
Regulaxy מציע חלון שמתחשב בתדירות העדכון של המערכת, ברמת החשיפה שלה, ובמה שכבר קבוע לאותו הלילה.
מה נוצרחלון מתוארך
אישור
בעל המערכת מקבל זימון ליומן שאפשר לאשר, לא מייל שאפשר להתעלם ממנו. לפני פתיחת החלון יוצאת הודעת SMS.
מה נוצראישור וזימון ביומן
הוכחה
במהלך החלון המפעיל ממלא צ'קליסט. בסיום נשלח סיכום לבעל המערכת, והרישום נשאר ביומן ביקורת.
מה נוצררשומת ביקורת
איור 2 — מחזור החיים של חלון תחזוקה
יכולות
מה יש בפנים.
שש מתוך שתים־עשרה. כל יכולת מייצרת פריט אחד שאפשר להצביע עליו.
תזמון חלונות
אשף בחמישה שלבים שמכיר את המצאי שלכם. סוג העדכון, השרתים, בעל המערכת, החלון — הוא ממלא מה שהוא כבר יודע וזוכר מי היה מעורב בפעם הקודמת.
חלון מתוארך ומאושר
זיהוי התנגשויות
Regulaxy ממפה אילו מערכות מדברות זו עם זו, ולא ייתן לקבוע שתי מערכות מקושרות לחלונות חופפים בלי להתריע.
אזהרה לפני הקביעה
דירוג לפי השפעה עסקית
דירוג לפי מה שהמערכת עושה לעסק, לא רק לפי CVSS. שקוף: כל נקודה בציון ניתנת למעקב עד לרכיב שיצר אותה.
ציון שמראה את החישוב
יומן ותזכורות
זימוני Outlook אמיתיים — בשני עותקים, כדי שגם המתאם יוכל לאשר את הפגישה של עצמו. SMS לבעל המערכת לפני פתיחת החלון.
שני זימוני ICS ו‑SMS
צ'קליסטים
בונים את הטופס פעם אחת לכל סוג עדכון. המפעיל ממלא אותו בשלוש לפנות בוקר, והסיכום נשלח לבעל המערכת בסיום.
טופס חתום ונשלח
תיעוד וייצוא
ייצוא ל־Excel מעוצב ול־CSV מכל טבלה, יומן ביקורת לכל שינוי, ורישום שנשאר גם אחרי שהאירוע נמחק.
ייצוא ויומן ביקורת
הוכחה
אפשר להסתכל לפני שמדברים איתנו.
Regulaxy מגיע עם מצאי הדגמה מלא מובנה — טופולוגיית מערכות אמיתית, התנגשות מכוונת בין שתי מערכות מקושרות, ומרשם חולשות מלא. אפשר להריץ את כל המוצר בלי בסיס נתונים, בלי רישיון ובלי שיחת מכירה.
- שרתים
- 401שרתים
- מערכות עסקיות
- 50מערכות עסקיות
- אירועי תחזוקה
- 285אירועי תחזוקה
אותו מצאי בדיוק הוא מקור צילומי המסך שבאתר. הוא נוצר ממחולל אחד עם זרע קבוע, ולכן צילום חוזר בעוד חצי שנה מראה את אותם הנתונים.
מסך המצאי, עם סינון פעיל ושתי הערות מסומנות
ממתין לאישור פרסום של מצאי ההדגמה
מסך המצאי מרכיב שורת שרת אחת משלושה מקורות קריאה־בלבד, ומסמן את מי שעבר את תאריך היעד.
אינטגרציות
משתלב במה שכבר רץ אצלכם.
Regulaxy לא מחליף את הסורק, את כלי ההפצה או את מערכת הקריאות. הוא מתאם סביבם, וקורא את המצאי שכבר יש לכם במקום לבקש מכם להזין אותו מחדש.
- זהויות והרשאות
- Active Directory
- LDAP
- דואר ויומן
- Microsoft Exchange
- Outlook
- ICS
- SMTP
- בסיסי נתונים
- Microsoft SQL Server
- Oracle
- מצאי וטופולוגיה
- Dynatrace
- SolarWinds
- WSUS
- פידים וייצוא
- CSV
- JSON
- Excel
- התראות וקריאות
- SMS gateway
- SOAP ticketing
אבטחה ופריסה
נפרס במקום שבו המידע שלכם כבר נמצא.
On-premises, תמיד
Regulaxy מותקן על השרתים שלכם, מול בסיס הנתונים שלכם. אין ענן של Regulaxy, ואין גרסה שבה מצאי השרתים שלכם עוזב את הרשת.
מותאם לרשת מנותקת
אין CDN, אין פונטים חיצוניים, אין הורדות בזמן ריצה. עדכונים מגיעים כקובץ שמעבירים פנימה.
הרשאות וביקורת
מנהלים ומפעילים מופרדים ברמת ה־API, לא רק בממשק. כל שינוי נרשם, והרישום שורד את מחיקת מה שהוא מתאר.
Regulaxy
שרת יישום ובסיס נתונים, אצלכם
- Active Directory — זהויות ואנשי קשר
- Exchange — זימוני יומן
- SQL Server ו‑Oracle — מצאי ובסיסי נתונים
- Dynatrace ו‑SolarWinds — טופולוגיה וציוד
עבור הפיקוח על הבנקים בישראל, Regulaxy תוכנן סביב דרישות ניהול הטלאים, שינויי החירום ונתיב הביקורת שבהוראת ניהול בנקאי תקין 364 — שהחליפה את 357, 361 ו‑363.
אנחנו מספקים את הראיות. הציות עצמו הוא של הבנק, ואף ספק לא יכול לעמוד בו במקומו.
- §61.4
- ניהול טלאיםהחלת תיקונים בזמן שתואם את קריטיות הנכס
- §97
- שינויי חירוםנוהל אישור מוגדר ומאשר מוסמך בשמו
- §98
- נתיב ביקורתשמירת תיעוד הפעולות שבוצעו במהלך השינוי
תמחור
מתומחר לפי המצאי שאתם מנהלים.
מדד אחד: מספר השרתים ש־Regulaxy מתאם. משתמשים ללא הגבלה, כל המודולים, On-premises, וללא חיוב לפי מושב עבור בעלי מערכות שרק מקבלים זימון.
שרתים מנוהלים
תראו לנו את החלון הכי בעייתי שלכם.
תביאו את זה שכל הזמן נדחה. שלושים דקות, המצאי שלכם, בלי מצגות.
- המערכת עם ארבעה בעלים
- האשכול שאף אחד לא מוכן להשבית
- הקפאת סוף הרבעון