S3 Ep142: הצבת ה-X ב-X-Ops

S3 Ep142: הצבת ה-X ב-X-Ops

צומת המקור: 2756318

הכנסת ה-X ב-X-OPS

קודם היה DevOps, אחר כך SecOps, ואז DevSecOps. או שזה צריך להיות SecDevOps?

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

אין נגן אודיו למטה? להקשיב ישירות בסאונדקלאוד.

עם פול דאקלין ומאט הולדקרופט. מוזיקת ​​אינטרו ואאוטרו מאת אדית מדג'.

אתה יכול להאזין לנו ב Soundcloud, Apple Podcasts, Google Podcasts, Spotify ובכל מקום שבו נמצאים פודקאסטים טובים. או פשוט זרוק את כתובת האתר של הזנת ה-RSS שלנו לתוך הפודקטצ'ר האהוב עליך.


קרא את התמליל

ברווז.  שלום לכולם.

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

כפי שאתה יכול לשמוע, אני לא דאג, אני ברווז.

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

מאט, אתה ואני חוזרים לימים הראשונים של סופוס...

...והתחום בו אתה עובד כעת הוא חלק אבטחת הסייבר במה שמכונה "DevSecOps".

כשזה מגיע ל-X-Ops, היית שם עבור כל הערכים האפשריים של X, אפשר לומר.

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


מאט.  העבודה הראשונה שלי ב-Sophos הייתה מנהל ומפתח של Lotus Notes, ועבדתי בחדר ההפקה דאז, אז הייתי אחראי על שכפול תקליטונים.

אלה היו תקליטונים אמיתיים, שבאמת אפשר היה לפלופ!


ברווז.  [צחוק רם] כן, המיון בגודל 5.25 אינץ'...


מאט.  כן!

אז זה היה קל.

הייתה לנו אבטחה פיזית; יכולת לראות את הרשת; ידעת שמחשב מחובר לרשת כי יצא לו מעט כבל מאחור.

(אם כי זה כנראה לא היה מחובר לרשת כי מישהו איבד את הטרמינטור בקצה [של הכבל]).

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


ברווז.  כיום, זה כמעט הפוך, לא?

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

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

זה כמעט מצב של Catch-22, לא?


מאט.  כן.

זה התהפך לגמרי.

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

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


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


מאט.  כן, הרעיון של Bring Your Own Device [BYOD] לא יעוף באותו היום, נכון?

אבל כן היה לנו בנה מכשיר משלך כשהצטרפתי ל-Sophos.

ציפו ממך להזמין את החלקים ולבנות את המחשב הראשון שלך.

זה היה טקס מעבר!


ברווז.  היה די נחמד…

... יכולת לבחור, לפי היגיון, לא?


מאט.  [צחוק] כן!


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


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

אני זוכר שהפנטיום הראשונים נכנסו לחברה, וזה היה, "וואו! תראה את זה!"


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

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


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

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

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


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


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

בעוד שבימים אלה הם רוצים לתפוס מערכת.

אז הם לא מעוניינים להדביק כל קובץ הפעלה.

הם רק רוצים שליטה על המחשב הזה, לכל מטרה שהיא.


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

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

...הם יגידו, "בואו רק נמצא אילו כלי מערכת ערמומיים כבר קיימים בהם אנו יכולים להשתמש בדרכים שמנהל מערכת אמיתי לעולם לא יעשה זאת."


מאט.  במובנים רבים, זה לא היה ממש זדוני עד ש...

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

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

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

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

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

הווירוסים הראשונים נכתבו כתרגיל אינטלקטואלי.

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

...שתמיד היה רגיש להיקלט על ידי השלטונות.

ואז, כמובן, הגיע הביטקוין. [צחוק]

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


ברווז.  אז בוא נחזור לטיפים המובילים האלה, מאט!

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


מאט.  אישור.

כולם שמעו את זה בעבר: תיקון.

אתה חייב לתקן, ואתה צריך לתקן לעתים קרובות.

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

סביר יותר שתגיע לשינוי שובר.

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


ברווז.  אכן, הרבה הרבה יותר קל לשדרג מ-OpenSSL 3.0 ל-3.1, נניח מאשר לשדרג מ-OpenSSL 1.0.2 ל-OpenSSL 3.1.


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

בעוד שמישהו שתוקן לגמרי... כנראה שהוא יותר בעניינים.

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

אז אם אתה מעודכן לגמרי, כנראה שאתה על כל השאר.


ברווז.  אז, אנחנו מתקינים.

מה הדבר השני שאנחנו צריכים לעשות?


מאט.  אתה יכול לתקן רק מה שאתה יודע עליו.

אז הדבר השני הוא: ניטור.

אתה חייב להכיר את האחוזה שלך.

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

כי אנשים הבינו שזו כל השרשרת...


ברווז.  בְּדִיוּק!


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

לדעת אילו מכונות פועלות, ומה פועל על המכונות האלה...

...ואם מחזירים את זה לתיקון, "האם הם באמת התקינו את התיקונים?"


ברווז.  או שנוכל התגנב והלך, "אהה! הם חושבים שהם מתוקנים, אז אם הם לא בודקים שוב שהם נשארו מתוקנים, אולי אני יכול לשדרג לאחור את אחת מהמערכות האלה ולפתוח לעצמי דלת אחורית לנצח, כי הם חושבים שיש להם את הבעיה מְמוּיָן."

אז אני מניח שהקלישאה שם היא, "תמיד למדוד, לעולם לא להניח."

עכשיו אני חושב שאני יודע מה הטיפ השלישי שלך, ואני חושד שזה הולך להיות הכי קשה/שנוי במחלוקת.

אז תן לי לראות אם אני צודק... מה זה?


מאט.  הייתי אומר שזה: לַהֲרוֹג. (אוֹ סגר.)

עם הזמן, מערכות מצטברות... הן מתוכננות ונבנות, ואנשים ממשיכים הלאה.


ברווז.  [צחוק] הצטיין! [צחוק חזק יותר]

סוג של הסתיידות...


מאט.  או חבטות...


ברווז.  כן! [צחוק]


מאט.  נופים על הספינה הגדולה של החברה שלך.

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

כולנו יודעים איך מפתחים אוהבים ערכת כלים חדשה או שפה חדשה.

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

ושוב, כמו עם תיקון, ככל שתעזוב אותו זמן רב יותר, כך גדל הסיכוי שתסתובב ותגיד, "מה המערכת הזו בכלל עושה?"

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

תחשוב על, "בסדר, זו גרסה 1 שלי, אבל איך אני הולך להרוג אותה? מתי זה ימות?"

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


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

לדוגמה, "אינך רשאי יותר לקודד עם OpenSSL 1. אתה צריך לעבור לגרסה 3. לא אכפת לי כמה זה קשה!"

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


מאט.  קודם כל... אתה לא יכול להכתיב.

אתה צריך לתת סטנדרטים ברורים וצריך להסביר אותם.

המכירה שקיבלת בגלל ששלחנו מוקדם בלי לפתור בעיה?

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

תמיד עדיף למנוע מאשר לתקן.


ברווז.  בהחלט!


מאט.  אני מבין, משני הצדדים, שזה קשה.

אבל ככל שאתה עוזב את זה יותר, קשה יותר לשנות.

להגדיר את הדברים האלה עם, "אני הולך להשתמש בגרסה הזו ואז אני הולך להגדיר-ושכח"?

לא!

אתה צריך להסתכל על בסיס הקוד שלך, ולדעת מה יש בבסיס הקוד שלך, ולומר, "אני סומך על הספריות האלה; אני סומך על כלי השירות האלה", וכן הלאה.

ואתה צריך לומר, "אתה צריך להיות מודע לכך שכל הדברים האלה נתונים לשינוי, ולהתמודד עם זה."


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

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


מאט.  אתה לא יכול להיות תגובתי לגבי הדברים האלה.

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

[צחוק] זה לא טוב! [עוד צחוק]

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

יש כמה גדולים באופק, אולי, עם דברים כמו הצפנה.

יום אחד, NIST עשוי להכריז, "אנחנו כבר לא סומכים על שום דבר שקשור ל-RSA."

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

בשלב זה, זה הולך להיות, "כמה מהר אתה יכול להוציא את התיקון שלך?"

כולם יעשו את אותו הדבר.

אם אתה מוכן לזה; אם אתה יודע מה לעשות; אם יש לך הבנה טובה של התשתית שלך והקוד שלך...

...אם אתה יכול לצאת שם בראש החבילה ולהגיד, "עשינו את זה בימים ולא בשבועות"?

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


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

טיפ 1 הוא ישן וטוב תיקון מוקדם; תיקון לעתים קרובות.

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

אפילו שבועיים זה יותר מדי זמן; אתה צריך לחשוב, "אם אני צריך לעשות את זה תוך יומיים, איך אני יכול לעשות את זה?"

טיפ 2 הוא צג, או במילות הקלישאה שלי, "תמיד למדוד, לעולם לא להניח."

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

טיפ 3 הוא להרוג/להרוג, כלומר אתה בונה תרבות שבה אתה יכול להיפטר ממוצרים שאינם מתאימים יותר למטרה.

וסוג של טיפ 4 עזר הוא תהיה זריז, כך שכאשר הרגע הזה של Kill/Cull מגיע, אתה באמת יכול לעשות את זה מהר יותר מכל אחד אחר.

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

האם זה הבין נכון?


מאט.  נשמע כמו זה!


ברווז.  [TRIUMPHANT] ארבעה דברים פשוטים לעשות אחר הצהריים. [צחוק]


מאט.  כן! [עוד צחוק]


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


מאט.  כן!

ואל תתנו ל"טוב ביותר" להיות האויב של "טוב יותר". (או "טוב").

לכן…

תיקון.

צג.

לַהֲרוֹג. (אוֹ סגר.)

ו: תהיה זריז… להיות מוכן לשינוי.


ברווז.  מאט, זו דרך מצוינת לסיים.

תודה רבה על הגעתך למיקרופון בהתראה קצרה.

כמו תמיד, למאזינים שלנו, אם יש לך הערות אתה יכול להשאיר אותן באתר Naked Security, או ליצור איתנו קשר ב-social: @nakedsecurity.

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


שניהם.  הישאר בטוח!

[מודם מוזיקלי]


בול זמן:

עוד מ ביטחון עירום