בלילה שבין רביעי לחמישי, צוות SaaS ישראלי מקבל התראה על ניסיונות התחברות חריגים לסביבת הייצור. אין עדיין השבתה, אין כותרת בעיתון, ואין אינדיקציה ברורה אם מדובר בסיסמאות שנגנבו, באוטומציה של credential stuffing או במישהו שכבר מחזיק גישה חלקית. אבל כבר בשעה הזאת ברור שהאירוע אינו "בעיה של ה־IT". הוא נוגע למוצר, לפיתוח, לתמיכה, ללקוחות, להנהלה ולפעמים גם ליועץ המשפטי.

זו הנקודה שבה אבטחת מידע וסייבר הופכים ממשהו שמטפלים בו "כשתהיה תקציב" למערכת החלטות יומיומית. אילו לוגים נשמרים. מי יכול להיכנס ל־prod. האם סודות יושבים ב־Git או ב־Vault. האם אפליקציית React מול API ב־Node.js בנויה עם הפרדה סבירה בין הרשאות, או עם קיצורי דרך שנוחים לשחרור גרסה אבל יקרים מאוד ברגע האמת.

בפועל, ארגונים בישראל לא צריכים עוד מדריך תיאורטי על סוגי מתקפות. הם צריכים תרגום של המציאות המקומית להחלטות הנדסיות ומוצריות. איזה MFA באמת עוזר. איפה Zero Trust משנה את הקוד ואת תהליך ה־CI/CD. איך תיקון 13, הנחיה 364 וטיוטת חוק ההגנה הלאומית לסייבר משנים את ה־runbook של צוותי פיתוח, DevOps ו־Product. זה החומר שבאמת משפיע על מה שנבנה השבוע.

תוכן עניינים

• למה אבטחת מידע הפכה לבעיה עסקית יומיומית
  • שלושת הכוחות שמשנים את סדר היום
  • מה זה אומר לצוותי פיתוח
• מפת האיומים הרלוונטית לישראל ב־2026
  • האיומים הרועשים מול האיומים השקטים
  • מה באמת בולט כרגע
  • איומי סייבר מרכזיים נגד ארגונים בישראל 2025 2026
• מודל ההגנה המודרני Defense in Depth ו Zero Trust
  • שכבות ההגנה שמתחברות לפיתוח
  • Zero Trust משנה את היום־יום
  • איפה נכון להחמיר ואיפה לפשט
• השוואת מסגרות אבטחה NIST ISO 27001 ו Zero Trust
  • מה כל מסגרת דורשת בפועל
  • השוואת מסגרות אבטחה NIST ISO 27001 Zero Trust ו Defense in Depth
  • הבחירה הנכונה לפי שלב החברה
• נהלים ארגוניים שכל חברה חייבת להטמיע
  • גישה מרחוק וזהויות
  • MFA, גיבויים והדרכה
  • ספקים ושרשרת אספקה
• תשתיות מאובטחות בענן ובפיתוח תוכנה
  • זהות לפני רשת
  • רשת, הצפנה וסודות
  • שרשרת אספקה של תוכנה
• ניטור תגובה לאירועים ועמידה ברגולציה
  • מה חייב להיכנס לטלמטריה
  • איך הרגולציה משנה את ה־runbook
  • תבנית תגובה טובה לאירוע
• מסלול יישום מעשי ל 90 יום והמלצות סיום
  • 30 הימים הראשונים
  • עד יום 60
  • עד יום 90

למה אבטחת מידע הפכה לבעיה עסקית יומיומית

בשנים האחרונות אני רואה אצל סטארטאפים וארגונים את אותו דפוס. בתחילת הדרך האבטחה נדחית לטובת time to market. זה מובן כשבונים MVP, מרימים SaaS ראשון ב־AWS או Azure, ומנסים להביא לקוחות משלמים. אחר כך מגיע לקוח אנטרפרייז, בדיקת נאותות, שאלון אבטחה, או אירוע קטן בייצור, ופתאום כל מה שנדחה חוזר בבת אחת.

שלושת הכוחות שמשנים את סדר היום

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

הכוח השני הוא הרגולציה. תיקון 13 לחוק הגנת הפרטיות מוסיף דרישות לאבטחת מידע, זכויות נשואי מידע וחובת דיווח על הפרות, ובמקביל בישראל נבנית שכבה רגולטורית רחבה יותר סביב סייבר, כולל סקירה על תיקון 13 והתגברות החובות הארגוניות. המשמעות המעשית למנהלי מוצר ולצוותי פיתוח פשוטה. החלטות מוצריות כמו retention של מידע, audit trail, והרשאות admin כבר אינן רק UX או engineering trade-off.

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

אבטחה ב־2026 לא נמדדת לפי כמה כלים רכשתם. היא נמדדת לפי כמה מהר אתם מזהים, מבודדים ומשחזרים בלי לשבור את המוצר.

מה זה אומר לצוותי פיתוח

ההשפעה היומיומית מורגשת כמעט בכל החלטה:

• בארכיטקטורה. האם המערכת היא monolith נוח לתחזוקה או microservices שמקלים על בידוד אבל מוסיפים שטח תקיפה ותפעול.
• בפיתוח MVP. האם דוחים SSO, RBAC ו־audit logs לסבב הבא, או בונים גרסה רזה אבל נכונה כבר מהתחלה.
• ב־DevOps. האם סודות נשמרים ב־GitHub Actions secrets, ב־AWS Secrets Manager, ב־Vault, או בקבצי env שאף אחד כבר לא יודע מי הוריד.
• ב־AI. האם agent שמבצע אוטומציות עסקיות מקבל הרשאות רחבות מדי, בלי בקרות approval ובלי traceability.

מפת האיומים הרלוונטית לישראל ב־2026

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

האיומים הרועשים מול האיומים השקטים

ב־2025 ישראל דורגה במקום השלישי בעולם בהיקף מתקפות הסייבר, עם 3.5% מכלל המתקפות הגלובליות, אחרי ארצות הברית ובריטניה, ולפי דיווחי מערך הסייבר הלאומי טופלו למעלה מ־26,000 אירועי סייבר, לצד כ־2,482 התרעות, כאשר כ־93% מהן כוונו לארגונים ספציפיים, לפי הדיווח על נתוני הסייבר בישראל ב־2025. זה נתון שמלמד משהו חשוב. ארגונים בישראל לא מתמודדים רק עם רעש רחב, אלא עם תקיפה ממוקדת.

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

מה באמת בולט כרגע

מוקד 119 של מערך הסייבר הלאומי קיבל ב־2025 כ־26,500 דיווחי אירועי סייבר, כאשר 52% מכלל הדיווחים היו פישינג, ו־13,700 מהם סווגו כפישינג. ביוני 2025, בזמן Operation Rising Lion, נרשמה קפיצה של 75% בדיווחים ביחס לממוצע החודשי, לפי הסיקור על מוקד 119 ודפוסי התקיפה בישראל. לכן, בארגון ממוצע, הזהות היא נקודת הכניסה הראשונה שצריך לסגור. לא עוד פינה צדדית.

בנוסף, לפי דוח Microsoft Threat Intelligence שפורסם ב־2026, ישראל דורגה במקום השני בעולם בהיקף הפעילות הסייברית שנצפתה נגדה בין יולי 2025 ליוני 2026, עם 7.6% מכלל הפעילות הנמדדת שיוחסה לישראל. באותה תקופה נפח אירועי ransomware שנמדדו נגד ישראל עלה ב־21% משנה לשנה, ו־39% מפעילות הסייבר האיראנית כוונה לישראל, כפי שדווח ב־ynet על בסיס דוח Microsoft Threat Intelligence. זה מחזק פרקטית את הצורך בהפרדת סביבות, immutable backups ויכולת recovery שנבחנה מראש.

איומי סייבר מרכזיים נגד ארגונים בישראל 2025 2026

קטגוריית איום	שכיחות	השפעה עסקית	זמן זיהוי ממוצע
פישינג וגניבת credentials	גבוהה מאוד. פישינג היווה 52% מהדיווחים ב־2025	השתלטות על חשבונות, חדירה לאימייל, כניסה ל־SaaS ולענן	משתנה לפי איכות ניטור הזהויות
כופרה	גבוהה ומתמשכת. זוהו למעלה מ־300 מתקפות כופרה ב־2024 ועלייה של 21% באירועים שנמדדו נגד ישראל בין 2025 ל־2026	השבתת מערכות, סחיטה, פגיעה בהתאוששות	לעיתים מתגלה רק אחרי lateral movement
תקיפות ממוקדות על ארגונים	גבוהה. 93% מהתרעות 2025 כוונו לארגונים ספציפיים	פגיעה ממוקדת במערכות קריטיות ונתונים	תלוי בבשלות SOC ו־IR
תנועה רוחבית ושרשרת אספקה	שכיחות איכותית, קשה למדידה פומבית	פגיעה עמוקה יותר, חשיפת סודות וקוד	לרוב איטי יותר לזיהוי
פגיעה בזמינות	קיימת בעיקר באירועי הסלמה	השבתת שירות ופגיעה בלקוחות	בדרך כלל מזוהה מהר

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

מודל ההגנה המודרני Defense in Depth ו Zero Trust

Defense in Depth ו־Zero Trust מוצגים לעיתים כאילו מדובר במוצרים. זו טעות. שניהם מודלים תפעוליים. הראשון אומר שבונים שכבות הגנה כך שכשל בשכבה אחת לא יפיל את המערכת. השני אומר שלא נותנים אמון אוטומטי רק כי משתמש, שירות או מכשיר "נמצאים בפנים".

שכבות ההגנה שמתחברות לפיתוח

אני ממפה את זה בדרך כלל לשש שכבות עבודה:

• זהות והרשאות. IdP מרכזי, SSO, MFA עמיד לפישינג, RBAC ו־JIT access למערכות רגישות.
• רשת. סגמנטציה בין dev, staging ו־prod, private subnets, וחשיפה חיצונית רק דרך רכיבים שנבדקו.
• אפליקציה. בדיקות הרשאה בצד השרת, audit logs, הגנה על session, וולידציה לקלט, rate limiting והקשחת APIs.
• נתונים. הצפנה במנוחה ובתנועה, tokenisation כשצריך, ו־retention policy שמוצר והנדסה באמת אוכפים.
• מכשירים ונקודות קצה. דרישות בסיס למחשבי צוות, ניהול patching, EDR והרשאות admin מצומצמות.
• שרשרת אספקה. סריקת תלויות, חתימת artefacts, ניהול packages פנימי וסודות מחוץ לקוד.

Zero Trust משנה את היום־יום

במודל Zero Trust, VPN כבר לא נחשב פתרון קסם. אם חשבון Slack, GitHub, Google Workspace או ספק הענן נפרץ, התוקף לא צריך "להיכנס לרשת". הוא כבר נמצא בערוץ הגישה המרכזי. לכן מודל הזהות קודם לרשת.

בפועל זה אומר:

1. אימות מתמשך. לא רק login ראשוני, אלא בחינה של הקשר הגישה, תפקיד, מכשיר, מיקום והרשאה.
2. הרשאות מינימליות. מפתח frontend ב־React לא צריך גישת כתיבה למסדי נתונים ב־prod רק כי "לפעמים צריך".
3. הנחת פשרה. מתכננים כאילו שירות פנימי יכול להיפגע, ולכן כל service-to-service access נבדק ומתועד.
4. סודות מבודדים. API keys לא גרים ב־repo, גם לא ב־README פנימי וגם לא ב־Notion.

איפה נכון להחמיר ואיפה לפשט

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

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

לכן אני מעדיף להחמיר ב־prod access, ב־admin actions ובספקים חיצוניים. לעומת זאת, בסביבות פיתוח פנימיות עדיף לפשט עם תבניות IaC מאובטחות מראש, תפקידי IAM מוכנים, ו־pipelines שמבצעים enforcement אוטומטי במקום מסמכי מדיניות שאף אחד לא קורא.

השוואת מסגרות אבטחה NIST ISO 27001 ו Zero Trust

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

מה כל מסגרת דורשת בפועל

NIST CSF מתאים כשצריך מפת דרכים תוצאתית. הוא עוזר לארגון לחשוב דרך Govern, Identify, Protect, Detect, Respond ו־Recover, ולתרגם כל תחום למשימות ממשיות. ניהול נכסים, מדיניות זהויות, playbooks לתגובה, ושגרות התאוששות. עבור סטארטאפ או scale-up, זו לרוב דרך טובה לעשות סדר בלי להעמיס מערכת ניהול כבדה מדי.

ISO 27001 מתאים כשיש דרישת שוק ברורה לתעודה, במיוחד ב־B2B enterprise, בפינטק, או כשיושבים מול procurement קשוח. הוא דורש מערכת ניהול, תיעוד, סקרי סיכונים מחזוריים ובקרות. היתרון שלו מסחרי וארגוני. החיסרון הוא שהוא עלול להפוך לתרגיל תיעוד אם צוותי פיתוח ו־DevOps לא מחוברים אליו ביום־יום.

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

Defense in Depth הוא הגיון התכנון השכבתי. הוא לא מחליף framework ניהולי, אבל הוא נשאר קריטי כשבונים מערכות Web, מובייל ו־SaaS שמישהו באמת צריך להגן עליהן תחת לחץ.

השוואת מסגרות אבטחה NIST ISO 27001 Zero Trust ו Defense in Depth

מסגרת	אופי	זמן יישום לסטארטאפ	דרישה מפיתוח	מתאים ל
NIST CSF	מפת דרכים תפעולית	בינוני	חיבור בין backlog הנדסי לניהול סיכונים	סטארטאפים בצמיחה וארגונים שרוצים סדר
ISO 27001	מסגרת ניהולית ותיעודית עם דרישות בקרה	ארוך יותר יחסית	תיעוד, נהלים, הוכחות ביצוע ומשמעת תהליך	חברות B2B עם דרישות לקוח או רגולציה
Zero Trust	ארכיטקטורת גישה וזהות	הדרגתי, אבל עמוק	שינוי בגישה ל־IAM, APIs, שירותים והרשאות	ארגונים בענן, עבודה היברידית ו־SaaS
Defense in Depth	עקרון תכנון שכבתי	מהיר להתחלה, מתמשך בבשלות	הטמעה בשכבות קוד, רשת, נתונים ותפעול	כמעט כל ארגון

הבחירה הנכונה לפי שלב החברה

לסטארטאפ שבונה MVP או מוצר ראשון, השילוב שאני בדרך כלל ממליץ עליו הוא NIST לחשיבת סדר עדיפויות יחד עם Defense in Depth ברמת הארכיטקטורה. ל־enterprise או ל־scale-up שכבר סוגר עסקאות גדולות, ISO 27001 נכנס לתמונה מהר יותר. Zero Trust צריך להיכנס מוקדם מספיק כדי לא להפוך לפרויקט כואב מדי מאוחר יותר.

נהלים ארגוניים שכל חברה חייבת להטמיע

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

גישה מרחוק וזהויות

לפי מדריך Chambers לישראל לשנת 2026, הנחיה 364 מתירה גישה מרחוק למערכות רגישות רק תחת הגנות מחמירות, כולל הצפנה, multi-factor authentication, ניטור רציף והגבלת גישה לפי צורך עסקי, כפי שמפורט ב־מדריך Chambers על פרטיות ואבטחת מידע בישראל. זה סט ברור, לא המלצה כללית.

בפועל, זה אומר שכל חברה צריכה לפחות:

• ניהול גישה מרכזי. SSO דרך IdP אחד, ביטול חשבונות orphaned, והרשאות לפי תפקיד ולא לפי "תבקשו אם צריך".
• הפרדת חשבונות שירות. שירותים אוטומטיים לא אמורים לרוץ על משתמשים אנושיים.
• אישור גישה מתועד. במיוחד ל־prod, למסדי נתונים ולכלי תשתית.

MFA, גיבויים והדרכה

כאן אין מקום לפשרות יפות על הנייר:

• MFA חובה. לכל עובד, קבלן, מנהל מערכת וספק עם גישה.
• עדיפות ל־WebAuthn או מפתחות חומרה. SMS פחות טוב, אפליקציות TOTP עדיפות עליו, אבל גישה עמידה לפישינג טובה יותר כשאפשר.
• גיבוי מבודד. לא מספיק שיש snapshot. צריך הפרדה בין סביבת הגיבוי לסביבת הייצור, ובדיקות שחזור תקופתיות.
• הדרכת עובדים. לא הרצאת onboarding שנשכחת. שגרה קבועה, עם תרחישים רלוונטיים לפישינג, שיתוף קבצים, גישה מרחוק ודיווח מיידי.

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

ספקים ושרשרת אספקה

טיוטת חוק ההגנה הלאומית לסייבר 5786-2026, שפורסמה ב־22 בינואר 2026, מציעה לראשונה הסדרה רחבה של הגנת סייבר בישראל, לרבות חובות של ניהול סיכונים, מוכנות לאירועים, רציפות תפעולית, אבטחת שרשרת אספקה, הצפנה, בקרת גישה, הדרכות ודיווח על אירועים, כפי שמתואר ב־סקירת הטיוטה של Arnon Tadmor-Levy. במילים פשוטות, ספקים הופכים לחלק מהיקף האחריות.

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

תשתיות מאובטחות בענן ובפיתוח תוכנה

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

זהות לפני רשת

אני מתחיל מ־IAM, ורק אחר כך מ־security groups. חומת אש יכולה לצמצם תנועה, אך היא לא מתקנת משתמש או שירות שקיבל הרשאות עודפות.

בסיס מעשי כולל:

• SSO ארגוני לכל חשבון ענן וכלי פיתוח, עם ניהול מרכזי של מחזור חיי המשתמשים.
• הפרדת חשבונות או subscriptions לפי סביבה. dev, staging ו־prod צריכים גבולות ברורים, גם אם הדבר מוסיף עבודה תפעולית.
• תפקידים מוכנים מראש ותהליכי שינוי מבוקרים, במקום attach policy אקראי בכל תקלה.
• חשבונות ייצור ללא גישה שוטפת ממחשבים אישיים, כאשר ניתן לתכנן זאת בלי לפגוע בזמן התגובה.

רשת, הצפנה וסודות

אחרי שהגישה מוגדרת, מקשיחים את המסלול שבו הקוד רץ:

• VPC או רשת פרטית מסודרת. שירותים פנימיים נשארים פרטיים, ו־debug מתבצע באמצעות גישה מבוקרת.
• WAF מול שירותים חשופים. הוא מסנן דפוסים מוכרים, אך אינו תחליף לאימות קלט, תיקון חולשות וקוד תקין.
• הצפנה במנוחה ובתנועה, עם KMS מרכזי ובעלות ברורה על מחזור חיי המפתחות.
• Secrets management באמצעות Vault, AWS Secrets Manager, Azure Key Vault או פתרון מקביל. קובצי env מקומיים אינם מאגר סודות.

שרשרת אספקה של תוכנה

ב־Node.js, Python, React, Angular, Vue ובשירותי backend, package שמתעדכן אוטומטית יכול להכניס סיכון שלא יופיע ב־code review. מצד שני, חסימה מוחלטת של עדכונים פוגעת בקצב התיקון. הפתרון הוא תהליך מדורג:

1. סריקת תלויות ב־CI לפני merge.
2. מאגרי חבילות פנימיים לחבילות קריטיות.
3. חתימת images ו־artefacts לפני deploy.
4. בדיקות SBOM תקופתיות במערכות רגישות.
5. הפרדת pipeline credentials, כדי שמפתח לא יקבל הרשאות עודפות לצורך שחרור מהיר.

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

ניטור תגובה לאירועים ועמידה ברגולציה

ארגונים רבים מפרידים בין SIEM, SOC ו־Incident Response כאילו מדובר בשלוש מערכות נפרדות. בפועל זו לולאה אחת. אם הטלמטריה דלה, ה־SOC עיוור. אם ה־SOC לא יודע להסלים, ה־IR איטי. אם ה־IR לא מתועד נכון, הרגולציה הופכת את האירוע לבעיה כפולה.

מה חייב להיכנס לטלמטריה

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

• Cloud event logs מכל חשבון וסביבה.
• IAM audit logs לשינויים בהרשאות, tokens וגישה חריגה.
• Network flow logs כדי להבין תנועה בין שירותים.
• EDR alerts ו־DNS queries לנראות על נקודות קצה והתנהגות חריגה.

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

איך הרגולציה משנה את ה־runbook

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

במקביל, הצעת החוק הלאומית מגדירה קטגוריות של ארגונים חיוניים וסקטורים כמו תקשורת, אנרגיה, בריאות ומים, וכוללת גם מנגנוני אכיפה, לרבות קנסות מינהליים של עד 300,000 ש"ח ואפשרות לאחריות פלילית במקרה של סירוב להוראות חירום, כפי שמתואר ב־סקירה המשפטית של Pearl Cohen על הצעת החוק.

תבנית תגובה טובה לאירוע

תגובה טובה לאירוע נראית כך:

1. Detection. זיהוי, triage וסיווג ראשוני.
2. Containment. ניתוק גישה, השבתת tokens, בידוד תחנה או service.
3. Eradication. ניקוי persistence, רוטציית סודות, patching ממוקד.
4. Recovery. העלאה בטוחה של שירותים, בדיקות תקינות, תקשורת ללקוחות לפי צורך.
5. Lessons learned. תיעוד, שיפור נהלים, backlog הנדסי ותיקוף פערים.

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

מסלול יישום מעשי ל 90 יום והמלצות סיום

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

30 הימים הראשונים

השלב הראשון מצמצם סיכונים שניתנים לטיפול מהיר:

• MFA חזק בכל החשבונות. מפעילים אותו בענן, ב־Git, בדוא"ל, ב־CRM ובכלי התמיכה, עם עדיפות למפתחות אבטחה או לאפליקציית אימות.
• מיפוי נכסים קריטיים. מתעדים מערכות ייצור, מסדי נתונים, סודות, חשבונות admin וספקים בעלי גישה.
• בדיקת גיבויים בפועל. מבצעים שחזור ובודקים שהמידע והשירותים חוזרים למצב שמיש.
• סגירת הרשאות עודפות. מתחילים מ־prod, מכלי תשתית ומחשבונות שלא נדרשים לעבודה היומיומית.

עד יום 60

כעת מחברים את הנהלים לארכיטקטורה ולתהליכי הפיתוח:

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

עד יום 90

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

• תרגיל Incident Response מבוקר סביב גניבת credentials או כופרה.
• בדיקת התאמה לדרישות רגולציה בנושאי פרטיות, תיעוד וגישה מרחוק.
• בחינת SOC חיצוני אם אין צוות פנימי שמסוגל לנטר ולהגיב ברציפות.
• החלטה על מודל תפעול. צוות פנימי, Team Extension, או CTO as a Service.

לא כל חברה צריכה CISO במשרה מלאה. כל חברה צריכה בעל אחריות מנוסה שמחבר בין מוצר, תשתית, רגולציה ופיתוח.

כאשר אין רוחב פס פנימי, סיוע חיצוני יכול לקצר החלטות בלי לעצור את המוצר. CTO as a Service מסייע לקבוע ארכיטקטורה וסדרי עדיפויות, ו־Team Extension מוסיף מומחי DevOps, backend, frontend או data/AI. סקר ממוקד צריך להוביל לרשימת פערים שניתנת לסגירה. לתכנית עבודה וליווי מעשי אפשר להתחיל מהיכרות עם מיסטרביט.