מי שתל פרצות בתיקון שלי?

למה עדכונים לא מצילים אותך

Photo by Neeqolah Creative Works on Unsplash

ברוכים הבאים לתיאטרון האבטחה

לכל תיקון אבטחה יש משהו מיוחד גם למגינים וגם לתוקפים. לכל “תיקון”, בהכרח יחדרו שינויים – עוד קוד שנבנה מאותם חומרים פגיעים כמו המקור!

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

ABP: תמיד לתקן

אזהרה: תיקון עשוי להכיל תיקונים של היום (ובהחלט פגיעויות של מחר.)

המציאות מבולגנת יותר ממה שהייתי רוצה. שאל כל מנהל מערכת מנוסה על עדכונים מהירים ותשמע חוכמה שנרכשה קשה: “חכה שישה חודשים. אל תהיה בודק הבטא החינמי שלהם.”

בואו ניקח רגע להעריך את הדילמה של צוות ה-IT:

• לתקן עכשיו: סיכון לשבור את הייצור.
• לתקן מאוחר יותר: סיכון להיפרץ.
• לא יכול (או לא מתקן): סיכון רציני להיפרץ.
• להגן ולצמצם: להקשיח מערכות, צפנים חלשים, להחליף סיסמאות וכו’. למי יש זמן לכל זה?!? לקרוא CVEs? אוי, ילד מתוק, יש לי חדשות רעות…

הכוונות הטובות ביותר

תיקונים הורגים מערכות גם בלי תוקפים.

תקרית CrowdStrike ביולי 2024 הוכיחה אמת קשה: מעקב אחרי “שיטות עבודה מומלצות” לא מעניק חסינות כשקוד שלא נבדק מפיל תשתיות קריטיות. תוך שעות, טיסות קורקעו ברחבי העולם ובתי חולים שותקו ברובם.

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

השקרים שאנחנו מספרים לעצמנו

זריקת כסף על אבטחה לעתים קרובות מתהפכת. בקרות מורכבות ורבות-שכבות הופכות לבלתי ניתנות לניהול—ובלתי ניתנות לניטור.

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

זה תלוי. (כן, התשובה האהובה על היועצים.)

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

עוזבים את מחנה תיאטרון האבטחה

תפסיקו עם התיאטרון והתחילו בניהול סיכונים פרואקטיבי.

קבע ותעד את כל מה שחשוב:

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

האם יש שיטות עבודה מומלצות אוניברסליות? כן, אך היישום משתנה:

שיקולים מרכזיים

• אמצו מפתחות אבטחה חומרתיים כמו YubiKeys לכל המשתמשים, או כפו לפחות passkeys.
  • OTPs חשופים להנדסה חברתית; אסימונים חומרתיים לא.
  • דרשו MFA בכל השירותים באופן אוניברסלי.
• גיבויים חזקים ומאומתים.
  • ודאו שלתשתית הענן יש גיבויים לא מקוונים—באופן אידיאלי בלתי ניתנים לשינוי ומפוזרים גאוגרפית.
    • “לא מקוון” פירושו בין-ספק או בין-חשבון (למשל, גיבויי AWS ב-GCP או Azure, או פתרונות צד שלישי כמו Backblaze B2).
  • הרחיבו אסטרטגיות גיבוי למכשירי עובדים, תוך התחשבות בתרחישי שחזור כמו Wi-Fi כנסים לא אמין (בהתאמה ל-SLAs ויעדי שחזור).
• בצעו תרגילי שחזור רבעוניים: שחזרו תשתית מלאה באזור לא בשימוש באמצעות גיבויים, snapshots וכלי infrastructure-as-code.
• הציבו CanaryTokens לצד כל פרטי כניסה אמיתיים כדי להיות הראשונים לדעת מתי מתחילה פריצה.

הצד השני של הפחד

דעו את פרופיל הסיכון שלכם: איזה נתונים אתם מגנים? אילו איומים חשובים? כמה השבתה אתם יכולים להרשות לעצמכם? מה זול יותר—שחזור או בנייה מחדש?

שקלו את החשיפה האמיתית שלכם:

• גישה לנתונים רגישים (בנקאות/קריפטו)
• פגיעויות יישומי רשת (XSS/CSRF)
• סיכוני שרשרת אספקה ואיומים פנימיים
• שירותים פונים לציבור (יעדי zero-day)
• סבילות לכופרה, קנסות, נזק למוניטין

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

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