אבטחת מידע – הבלוג של חץ ביז

התקלה של Crowdstrike ומשהו שהכנתי

כמו שכבר כולם יודעים, עדכון של Falcon Sensor מבית Crowdstrike הצליח לגרום למכונות Windows שקיבלו את העדכון – לקרוס לחלוטין (BSOD). התיקון שהחברה מציעה – הוא למחוק איזה קובץ ולבצע Reboot

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

ממש "כיף"

ולכן, החלטתי להכין קובץ ISO לינוקס מקוסטם קלות (מבוסס Debian Bookworm) שיעשה את העבודה, וכל מה שצריך לעשות זה לבצע את ההוראות הבאות:

יש להוריד את קובץ ה-ISO מכאן (זה הגוגל דרייב שלי, אם גוגל מחליט לחסום עקב פופולריות יתר, צרו איתי קשר ואני אארח את הקובץ במקום אחר)
מכיוון שמדובר בקובץ ISO, אפשר להתקין אותו על דיסק און קי (עם RUFUS לדוגמא ב-Windows או Media Writer בלינוקס), או להוסיף אותו לדיסק Ventoy
ה-ISO תומך גם BIOS וגם UEFI, וניסיתי לתמוך גם ב-Secure Boot ולבדוק זאת, אך אין לי אפשרות לבדוק זאת על כל חומרה וכל פיפס של אבטחת Boot, כך שאם המערכת מתחילה לדבר על Secure Boot – תבטלו זמנית את ה-Secure Boot.
ברוב המחשבים אין אפשרות להפעיל דיסק און קי מ-USB מיידית, ולכן יש להיכנס ל-BIOS/UEFI ולבחור את ה-USB כ-Boot Device ראשי
אין תמיכה ב-Bit Locker. במכונות כאלו תצטרכו לעשות את הניקוי ידנית
המערכת בנויה לסביבות וירטואליות ופיזיות שכוללות דיסק יחיד.

לאחר ששיניתם ב-BIOS וביצעתם BOOT – תקבלו מסך גרפי של DEBIAN. כל מה שצריך לעשות – זה ללחוץ Enter. מערכת הלינוקס תתחיל לעלות ובסיום אתם תהיו בתוך הלינוקס ללא הקשת שם משתמש וסיסמא

על מנת להפעיל את הניקוי, יש להריץ את הפקודה sudo cs-fix.sh

מכאן והלאה, המערכת תנסה לעשות את הדברים אוטומטית. היא תנסה לבצע mount של Windows, ובמידה וזה יכשל – היא תנסה לבצע Fix לפרטישן של ה-Windows (אתם תקבלו הסברים על כך אם זה קורה). לאחר ה-Mount, הוא יחפש את הקבצים, יציין אם הוא מוצא אותם, ואם הוא ימצא – הוא מוחק אותם

לאחר שהסקריפט רץ – הוא יוצא החוצה. מכאן, כל מה שיש לעשות זה לכבות את המחשב (לא עם פקודות Poweroff או Shutdown, אלא ממש כיבוי פיזי או ביצוע STOP אם מדובר במכונת VM), לנתק את הדיסק און קי ולבצע Boot. המערכת אמורה לעבוד בצורה נורמלית

כמה הערות:

הסקריפט נכתב לפי ההוראות ש-CrowdStrike פרסמה. אין לי את המערכת, כך שאין לי אפשרות לבדוק זאת מעבר לנסיונות יצירת קבצים מזוייפים, ומחיקה עם הסקריפט.
אני לא יכולה לתת תמיכה לכל דבר, אבל אתם יכולים לשלוח מייל עם צילום מסך אם יש בעיה עם הסקריפט ואני אשמח לנסות לסייע, אם כי, כפי שציינתי – לא יכולה להבטיח
תודה ל-Debian שבנו מערכת Live כזו נחמדה (ניסיתי לבצע את הדברים עם אובונטו, היה מחריד וזה נכשל שוב ושוב).

תהנו 🙂

על גניבת הרשאות ואותנטיקציות של מיקרוסופט

ארגונים רבים בישראל "מכורים" לפתרונות של מיקרוסופט, ובמקרים רבים, פתרונות של מיקרוסופט מיושמים באותם ארגונים – רק בגלל שזה "מיקרוסופט" והם (מיקרוסופט) בהחלט "מבינים באבטחה".

אחת הבעיות הגדולות שכל ארגון צריך להתייצב בפניה – היא תופעת ה"פישינג" – אתרים שנבנים על ידי גורמים עוינים שמתחזים לאתרים הרשמיים של חברות גדולות (מיקרוסופט, גוגל, אמזון וכו') ואותם גורמים עושים כל שלאל ידם כדי לגרום לעובדי הארגונים להיכנס לאותם אתרים מתחזים, ולהזין את פרטי האותנטיקציה שלהם, על מנת לגנוב את אותם פרטים ואם אפשר – גם את ה-Cookies של ה-Session על מנת להתחבר לאתר האמיתי ולגנוב / להזיק לארגון.

גופים רבים עדיין משתמשים בשיטות כמו 2FA שאמנם ימנעו (בחלק מהמקרים) את העברת פרטי האותנטיקציה של שם משתמש/סיסמא, אולם הדבר אינו יעזור כשיש לגנב את ה-Session Cookies, כנ"ל במקרים משתמשים ב-Microsoft Authenticator בשיטת ה-Passworldless (שימו לב – Passworldless ו-Passkeys הם דברים שונים לחלוטין) שבהם הגנב עדיין מקבל, שוב, את ה-Session Cookies ויכול להתחזות בהצלחה למשתמש הלגיטימי ולגנוב או לגרום נזקים.

בן, מערוץ Syn/Ack Time הכין קליפ קצר (7 וחצי דקות) שמדגים בעזרת כלי כמו Evilginx על מנת להתחזות לאתר מיקרוסופט והוא מדגים שימוש בשיטות אותנטיקציה שונות, וכיצד הוא מצליח לקבל את פרטי כניסת המשתמש ואת ה-Session Cookies. להלן הקליפ:

אם צפיתם בקליפ, אתם יכולים להבין את הדברים הבאים:

שימוש ב-Yubikey (או פתרון חומרתי אחר שתומך ב-FIOD2) עדיין נותן את הפתרון הכי חזק, תוך תמיכה בכל פלטפורמה (Windows, Mac, Linux) ובכל דפדפן, ואם בארגון מחליטים להשתמש ב-Microsoft Authenticator – זהו הפתרון היחיד שהוא מספיק חזק ויכול לתמוך בכל המשתמשים, כולל אלו שאין ברשותם מכשירי טלפון חכמים.
תמיכה ב-Passkeys של מיקרוסופט היא בעייתית לארגונים גדולים, הואיל והיא דורשת את גירסת האנדרואיד האחרונה או גירסת IOS האחרונה (גירסה 17, נכון לרגעים אלו), דבר שלא קיים בטלפונים רבים ישנים יותר. Google passkey שבנוי לתוך הדפדפן והטלפונים, דורש אנדרואיד גירסה 9 או IOS גירסה 16, דבר שקיים בד"כ ברוב הטלפונים כיום.

אסכם את הדברים כך: הגיע הזמן להיפתר מ-2FA ולעבור לשימוש ב-passkey (או לפחות במפתחות חומרה כמו Yubikey). בשיטות אלו, טריקים של SMS ו"חטיפת" מכשיר הסלולר לאישור אותנטיקציה לא יעזרו (יש צורך בקירבה פיזית למחשב, passkey משתמש ב-Bluetooth ו-Yubikey מצריך חיבור USB), וגם אם הקורבן הכניס את שם המשתמש והסיסמא שלו, הפורץ לא יוכל "לדוג" אותם, ובמקרים של שימוש ב-passkey, יהיה אפשר לוותר על תוכנת Authenticator (הגירסה של גוגל מסתמכת אותנטיקציה לכניסה לטלפון ואינה מצריכה אותנטיקציה מחודשת על מנת ליצור מספרים חדשים, בניגוד לגירסה של Yubikey לדוגמא).

הפרטים לגבי הפריצה ל-Lastpass

בימים האחרונים יצאו החדשות העדכניות והנכונות לגבי הפריצה ל-Lastpass שאירעה לפני מספר חודשים. בהתחלה החברה לא ממש ששה לספר בהרחבה מה נפרץ ומה נגנב, ואילו עתה – יש יותר פרטים.

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

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

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

אולם לשם פריצת ה"כספת" – הפורץ יצטרך את כתובת המייל והסיסמא. בלי הפרטים הללו, ה"כספת" היא לא יותר מאשר ערימת זבל דיגיטלי, ולכן – מי שהגדיר סיסמא מורכבת, סביר להניח שהפורצים לא יצליחו לפרוץ ל"כספת" הגנובה שלו. מצד שני, למי שהגדיר סיסמא כמו abcd1234! – יכול להיות ששם הפורצים כן יצליחו לפרוץ, אם הן ינסו את הסיסמא מול ערימה שלמה של כתובות מייל. מכיוון שהמידע גנוב ונמצא (בסבירות גבוהה) offline, הפורצים יכולים להריץ סקריפטים של שילוב כתובות מייל + Rainbow Table על מנת להצליח אולי לפרוץ לחלק מאותן "כספות".

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

אז, אם יש לך חשבון ב-Lastpass ושמרת דרכו סיסמאות רבות לאתרים חדשים, אך סיסמת ה-master שלך (אותה סיסמא שמקישים כדי להיכנס ל-Lastpass) היתה סיסמא קלה לניחוש, יהיה מומלץ שתיכנס לתוך אותו Vault ותתחיל לחפש מהם האתרים החשובים שנמצאים, ולשנות סיסמא בכל אחד מהם. תהליך ארוך, מייגע – אבל זה המחיר לסיסמאות חלשות.

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

שימוש ב-Wireguard כפתרון VPN מלא

יש לא מעט מקרים בהם VPN הוא דבר חיוני ונדרש, בין אם בחיבור בין 2 אתרים (Site to site), בין אם חיבור חיצוני לתשתית בענן ציבורי, בין אם חיבור מהבית לתשתית בעבודה וכמובן – כשרוצים להתחבר לתשתית בבית כדי לבדוק דברים או כדי להשתמש בשרותים שונים שרצים בבית – מבחוץ.

עד כה הפתרונות המוכרים ורצים במקומות שונים, היו פתרונות כמו IPsec, או OpenVPN או פתרונות קנייניים של יצרנים שונים (גם יצרני נתבים ביתיים כמו ASUS הוציאו פתרונות VPN כמו Instant Guard … שלא נתמך ב-Windows , Mac או לינוקס אלא רק למובייל) שעובדים בצורה מעולה. הבעיה בדרך כלל כשמדובר על גוף עם תקציב קטן (או ברצון לא להוציא כסף) – הפתרונות הנ"ל לא היו יכולים לבוא בחשבון, ומה שכן בא בחשבון סבל ממגבלות של רישוי (OpenVPN – מקסימום 2 משתמשים), ניצול גרוע של רוחב פס (במיוחד כשמתחברים לתשתית ביתית או upload בכמות מגהביט מזערית) והבעיה הגדולה מכולן – חוסר עדכונים לפתרונות הללו. בנוסף, פתרונות רבים מבוססי נתבים ביתיים מקבלים כמות קטנה מאוד של עדכוני תוכנה, כך שפתרון VPN מבוסס נתבים כאלו יכול להיות פתרון די מסוכן.

הפתרון שמקבל תאוצה בשנים האחרונות מגיע מכיוון אחר, מעולם הלינוקס, והוא פתרון ה-Wireguard. למי שלא מכיר, Wireguard מממש פתרון VPN, אולם הוא עושה זאת תוך שימוש בצופנים מודרניים שאינם "חונקי מעבד" ולא מצריכים פתרונות חומרה במעבדים. כך לדוגמא, Wireguard שרץ על Raspberry Pi 4 ויכול לתת תעבורה מוצפנת במהירות של 400 מגהביט, מספר הרבה יותר גבוה מ-OpenVPN (שנותן רבע או שליש מזה) ובחלק מהמקרים הוא עוקף פתרונות IPSec שונים מבחינת ביצועים ורוחב פס.

ל-Wireguard יש מספר יתרונות גדולים:

ההגדרות עצמן די קלות, ולמי שמסתבך, יש כלי שנקרא PiVPN (שגם רץ על דביאן ואובונטו על מכונות X86-64) שעוזר להגדיר את ה"שרת" ואת ה-Clients בקלות.
אין צורך בהגדרות משתמשים וסיסמאות. שרת ה-VPN צריך בסך הכל את המפתח הציבורי של ה-Client וה-Client צריך את המפתח הציבורי של השרת. השאר – הם הגדרות כתובת IP, DNS ומספר דברים נוספים לא ממש מורכבים.
מבחינת שינויים בנתב – השינוי היחיד שצריך לבצע הוא הגדרת Port forward ב-UDP אל המכונה שמריצה את ה-Wireguard כשרת. אפילו הנתבים של בזק יכולים לתת זאת בלי בעיה. (הערה: בימים האחרונים פרסמתי כי יש לי בעיה בנתבים מסויימים עם הגדרות ל-Wireguard, מסתבר כי זו היתה בעיית הגדרה של firewalld במכונה)
אתה יכול לנצל את מלוא רוחב הפס Upload שיש לך להנאתך. במקרים של חיבורים כמו DSL או כבלים, רוחב ה-Upload הוא מספר נמוך מאוד של Megabits (בד"כ עד 5) ופתרונות VPN מתחרים יוציאו מתוך זה אולי 1-2 מגהביט. עם Wireguard לפי נסיון שערכתי – מתוך 4 מגהביט Upload, קיבלתי רוחב פס של כ-3.5 מגהביט מוצפן החוצה (Upload).
מבחינת Clients – כל מערכת הפעלה תומכת ב-Wireguard – כל הפצות הלינוקס, אנדרואיד, iOS, מק, Windows, כולל Tizen (אם יש לך את ה-SDK ואתה רשום כמפתח..).
הגדרות Client די קלות במובייל – צור Tunnel, צלם תמונה (עקוב אחר ההוראות של PiVPN), שמור. נגמר. ההגדרות גם קלות ב-Windows ומק – העבר קובץ conf שיצרת עבור ה-client למערכת ההפעלה הנבחרת, הפעל Wireguard client, בצע יבוא (Import tunnel) והפעל.
הקץ להעברת כל התעבורה דרך VPN – הגדרת AllowedIPs תאפשר להגדיל ניתוב VPN רק לתשתית מסויימת (Split DNS), וכל השאר יעבור בצורה רגילה דרך האינטרנט. הקץ לגלישה שעושה "טיול" בחו"ל – לאתרים מקומיים.
כשמדברים על מערכות עם עדכוני אבטחה, כל הפצת לינוקס שתתקין (למעט Fedora) תגיע עם הבטחת עדכונים ל-5 שנים לפחות (גרסאות כמו Rocky/Alma/Oracle לינוקס – ל-10 שנים)

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

על חוות שרתים מעל ומתחת לאדמה

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

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

התשובה עצמה – קצת מורכבת, וברשותכם – אפרט.

ישנם כאלו שמתכננים או משתמשים בענן, כאילו מדובר באיזו חוות שרתים של סלקום/נטויז'ן או פרטנר או בזק: הם מקימים פתרון DR שאמור לעבוד באופן ידני או אוטומטי, במקרה של תקלת חשמל, תקשורת וכו'. כלומר אותם לקוחות מראש "ננעלים" על חוות שרתים זו או אחרת של ספק ענן ציבורי, וכאן המציאות העגומה עלולה לטפוח בפרצופו של הלקוח שעובד כך: אם חיזבאללה מחר ירה טילים כבדים לאזורים בהם נמצאים חוות שרתים והוא יפגע באותו בניין או מבנה עם חוות שרתים – ישנו סיכוי גבוה מאוד כי חוות השרתים תושבת, בין אם השרתים נמצאים מעל האדמה או 20 קומות מתחת לאדמה! מה שלא מספרים לאנשים, זו העובדה הפשוטה שיש תשתית שלמה (שאינה כוללת שרתים) שנמצאת מעל האדמה (מה לעשות, אותה תשתית דורשת חמצן…) וכשטיל פוגע באותה חווה, יש סיכוי גבוה שאותה תשתית שנמצאת למעלה – תושבת, וכתוצאה מכך, גם השרתים שנמצאים למטה יהיו מושבתים או מנותקים, כך שבסופו של יום, בין אם השרתים נמצאים עמוק באדמה או מעליה, הסיכוי גדול כי הפגיעה תשבית את התשתית.

מה שתמיד מומלץ ללקוחות לעשות, זה לעבוד עם הכלים והפלטפורמות של ספקי הענן הציבורי הגדולים בכל הקשור לשרידות, ולהזניח את שיטות ה-DR הקלאסיות. שלושת ספקי הענן הגדולים, לדוגמא, מאפשרים להקים תשתית וירטואלית של שרותים ומכונות VM שפועלות במקביל במספר Availability zones (או Regions), כך שאם AZ או Region (תלוי בטרמינולוגיה של ספק הענן הציבורי) נופל או נפגע, התשתית הוירטואלית של הלקוח תמשיך לפעול מה-AZ או ה-Region האחר שנמצא גיאוגרפית במיקום שונה. לאלו שמוכנים להשקיע עוד, ניתן אפילו לבנות זאת בצורה של שימוש ב-3 Regions (או Region נוסף מחוץ לישראל ו-2 Availability zones), כך שלא חשוב מה יקרה בישראל, המערכת של הלקוח עדיין תמשיך לעבוד. אפשרות נוספת (ותמיד מומלצת) היא שימוש ב-Multi Cloud תוך שימוש בשרותים של ספקי ענן ציבורי שונים והקמה של התשתית אצל ספקי ענן ציבורי שונים, כך שאם קורה מקרה נדיר בה כל התשתית של ספק ענן ציבורי כלשהו נופלת – המערכת של הלקוח תפעל אוטומטית מהתשתית של ספק ענן ציבורי אחר.

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

הפריצה הגדולה למשרדי ממשלה בחו"ל

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

אחד הדברים היחודיים בפריצה הזו היא הדרך הגאונית שבו החליטו לפרוץ לאותם משרדים ממשלתיים ולתשתיות. ב-APT29 לא ניסו לפרוץ חומות אש, או כל דבר מבחוץ. הם החליטו לעשות שיעורי בית ולבדוק לגבי מכנה משותף בין משרדי ממשלה, ארגונים בטחוניים ועוד – מהו הכלי/פלטפורמה/תוכנה שרובם משתמשים?

התשובה היתה: פלטפורמת Orion של Solarwinds לניטור המערכות של הארגון.

אחרי שהם הבינו זאת, ב-APT29 פשוט פרצו אל Solarwinds ולקחו שליטה על שרת העדכונים, ומדי פעם הם החליפו את קבצי העדכונים בקבצים שהם Weaponized (כלומר – קבצים הכוללים כלי שליטה ושלל כלים אחרים עבור הפורצים). מערכת ה-ORION היתה מקבלת שדרוג מהשרת הפרוץ, השדרוג היה מותקן אוטומטית בארגון (שום מערכת IPS/IDS לא קופצת על עדכונים כאלו, כי אין להן שום דרך לדעת על העדכון), ולאחר מכן הקבוצה יכלה "לדבר" עם שרת הניטור דרך C&C, לשלוח פקודות, לקבל פלט, לקבל קבצים ומידע וכו'. הכניסה הזו הוותה בעצם "שער אחורי" שממנו הקבוצה חקרה את התשתית הפנימית של הארגון והחלה "לעבוד".

מדוע אני חושב ששיטה זו "גאונית"? הסיבה לכך פשוטה: לא חשוב כמה הארגון הגדיר את התקשורת ואת חוקי ה-Firewall או ה-IPS/IDS בארגון. בדרך כלל נותנים גישה לתוכנת הניטור לכל שרתי הפרודקשן. אינני מדבר על גישת username/password אלא גישה ספציפית לנטר את השרת, הן מבחינת משאבים (דיסק, רשת, CPU וכו') והן מבחינת שרותים שרצים על השרתים. במילים אחרות, גם בלי Agent בכל שרת, במערכת הניטור יש מספיק ידע כדי לדעת מה השרתים שיש, כמה, ומה רץ עליהם, ובחלק מהמקרים מוגדרים שם משתמש וסיסמא כדי להיכנס לשרות. במקרים שיש Agent מותקן, אז כל מה שצריך הוא להכניס Agent "נגוע" לשרת הניטור שיפיץ את ה-Agent לכל השרתים המנוטרים ומשם אפשר להיכנס ולשאוב את המידע מבלי "להקפיץ" מערכות אבטחה. זיכרו: התקשורת בדרך כלל בין שרת הניטור לשרתים האחרים ברוב הארגונים אינה מנוטרת מבחינת אבטחה/רוחב פס, DLP וכו'.

אבל כאן זה לא נגמר.

בימים האחרונים התברר לחרדתם של אותם משרדי ממשלה, שהרוסים "ישבו" על השרתים זמן רב – שנע בין חודשים לשנים, ולכל ארגון או משרד ממשלתי, הם עשו עבודה רצינית של מיפוי, בדיקת חולשות ופריצה שלא הקפיצה שום מערכת IPS/IDS. קחו לדוגמא את המקרה שחברת האבטחה Volexity מצאה כי APT29 מצאו שיטות לעקוף MFA, וגניבת תעודות פנימיות על מנת ליצור/לעקוף חתימות ובכך להיכנס למערכות פנימיות מסווגות. ניתן לקבל עוד פרטים בקישור הזה ואני מאמין שאחרים יוסיפו קישורים נוספים עם יותר מידע.

אז מה ניתן לעשות?

אם אתם משתמשים ב-Orion, כדאי בדחיפות לבדוק איזו גירסה יש לכם ולעקוב אחר ההוראות של Solarwinds. במקביל, אני ממליץ לעבור על קבצי LOG לבדוק התנהגות חשודה (לא שתגלו הרבה אם זה APT29, הם עושים את כל המאמצים לא להתגלות ולא להקפיץ מערכות). בנוסף, יכול להיות שהגיע הזמן לרכוש ביטוח סייבר ולמצוא חברה רצינית (לא אדם יחיד) לבצע בדיקות Penetration Testing לארגון.

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

"הר" פתרונות האבטחה שאינו רלוונטי כל כך

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

אפשר לצקצק בלשון ואפשר לתהות על ההתנהלות של חברת שירביט בכל הנוגע לאבטחת מידע והגנה על התכנים, אך לפחות ממספר שיחות עם חברים ועמיתים – לא מעט ארגונים גדולים חשופים לא פחות ממה ששירביט היו חשופים לפריצות, ולצערי הרב, עדיין התפיסה של "יש לנו חומת אש, WAF, IPS/IDS, אז אנחנו מוגנים" – שולטת באותם ארגונים.

המציאות פשוטה: גם אם תקים "הר" של Appliances לצרכי אבטחת מידע בכדי להגן על חדירה מבחוץ, הפורצים יכולים לעקוף את כל ההגנות הללו עם פעילות Phishing וכניסה למערכת עם פרטים גנובים. חשוב לזכור: הנקודה הכי חלשה ברוב הארגונים – היא המשתמשים, ולא יעזרו חידודי נהלים לא לפתוח לינקים, לא להוריד/להריץ קבצים במייל וכו' מהסיבה הפשוטה ביותר: אם משתמש קיבל מייל Phishing והוא הזין בו פרטי חיבור אמיתיים, ברוב המקרים הוא לא ירוץ למחלקת IT או אבט"מ לספר על כך. אחרי הכל, מדוע לו לחטוף על הראש? עדיף להפעיל ראש קטן ולהתעלם מכך.

הנקודה הכי חשובה בכל הסתכלות על אבטחת מידע היא Zero Trust. לא לתת שום Trust בין אם מדובר בתקשורת מבחוץ פנימה או בין שרתים או בין מכונות דסקטופ לשרתים. אחרי הכל, אם מאן דהוא הצליח להשיג פרטי גישת VPN למערכת שלכם, מהרגע שהוא מתחבר, הוא נמצא בתוך התשתית של החברה, גם אם יש לו הרשאות מוגבלות (גם עם הרשאות מוגבלות אפשר ליצור נזקים גדולים). יקח לחברה זמן להבין שהפורץ משתמש בפרטי גישת VPN שנגנבו בפעולות Phishing ממשתמש לגטימי, ומאותו רגע שהפורץ מחובר, גרימת הנזק היא פנימית, ה-Firewall וה-WAF שלך לא עוזרים במאומה באותו זמן – וכאן, כדאי לזכור, פורץ חכם לא יחפש לגרום מיידית נזק, אלא יחפש בתשתית נקודות חולשה או תשתית "צדדית" שעליה הוא יכול להתקין את ה-Payload ורק לאחר מספר ימים להפעיל זאת ולהתחיל לגרום נזק/להצפין תוכן או להעביר תכנים.

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

להיפטר מסיסמאות: סיסמאות היו ויהיו – מקור לאחד מכאבי הראש הגדולים, כולל כל ה-Policies ליצור אותם, החלפתם וכו'. גם במיקרוסופט ובחברות תוכנה אחרות הבינו זאת מזמן והם מציעים פתרונות שונים המבוססים על טביעת אצבע, Windows Hello, מפתחות כמו Yubikey של Yubico (או Tian של גוגל, ויש גם מפתחות המבוססים בכלל על קוד פתוח כמו Solokeys). בנוסף, שימוש במפתחות מאפשר להשתמש בהצפנות שונות (נתמכות בעיקר ב-Yubikey) ויחסית די קל להטמיע את הפתרונות בכל מערכות ההפעלה.
הצפנת תכנים: הסיוט הכי גדול לחברות מבחינת אבטחת מידע, הוא גניבה ו/או הצפנה באמצעות כופרה של המידע, וארגונים גדולים מאוד (חברות כמו קאנון, אוניברסיטאות, בתי חולים ועוד) חוו את הסיוט ונזק משמעותי נגרם לאותם ארגונים. אחד הפתרונות שניתן לבצע הוא הצפנה של רוב התכנים החשובים, וביצוע Decryption דרך Gateway שאליו מחוברים מספר מצומצם של משתמשים. ניתן לדוגמא לבצע זאת בעזרת הקמת LUN שיחובר למערכת לינוקס וירטואלית. מערכת הלינוקס תבצע encryption/decryption עם כלי כמו LUKS-2 או בכלים אחרים, ושיתוף (לאחר decryption) עם SAMBA. אפשר להתגונן נגד כופרה תוך שימוש ב-snapshots (במכונת הלינוקס בשימוש LVM).
ביצוע Snapshots – באופן עקרוני, Snapshots ברמת File systems לא אמורים לצרוך כמות משאבים גדולה ליצירה ולכן מומלץ ליצור Snapshots בפתרון האחסון ל-File systems בצורה תכופה מאוד (כל שעה לדוגמא, ובמקרים חשובים כמו הנח"ש – כל מחצית שעה). כך, אם ישנה התקפת כופרה, ניתן לשחזר מה-Snapshot במהירות במקום לשחזר מקלטות.
Pen testing הוא פתרון חלקי שלדעתי אינו מספק: לצערי לא מעט ארגונים וחברות שוכרים מישהו מחברה שיבצע בדיקות (Penetration testing), ורובם גם משתמשים באותם כלים וב-Kali Linux (מתי אנשים יבינו ששימוש ב-Kali Linux הוא "אות קין" שלמשתמש אין הבנה רצינית בלינוקס? כל הפצת לינוקס כוללת את כל הכלים הדרושים!) כדי לבצע את הבדיקות, ובמתודה זו הבדיקות והסריקות פשוט אינן מספקות את התשובה המלאה.
בדיקות הקשחה וחדירה זה לא רק שימוש בכלים כמו nmap, nessus ו-1001 כלים נוספים, אלא לימוד כל המערכת ועבודה בצוות כדי לחשוב על נסיונות חדירה מכל מערכת שרצה בארגון, חולשות שקיימות לכל שרת, לכל Appliance ולכל ציוד (במיוחד ציוד ישן שאין לו עדכונים כבר מספר שנים – ציוד כזה מומלץ להחליף כמה שיותר מוקדם), מי הם האנשים בחברה שפעולות Phishing עליהם יכולות לגרום נזק מהותי, היכן ניתן לעצור או להאט דליפת מידע אם גורם כלשהו הצליח לפרוץ, האם יש עצירה אוטומטית של תעבורת Upload ל-IP שאינו white listed לאחר כמה מאות מגהבייט לדוגמא (כשהפורץ מנסה לגנוב כמה שיותר קבצים), ובקיצור – הכלים הם רק חלק קטן מהעבודה, ודרוש צוות רציני כדי לנסות לפרוץ (מבלי להגביל את הצוות, אבל עם הנחיה לגבות את הכל ולרשום כל גילוי ושינוי) ולא מישהו שהקים Kali Linux על מכונה וירטואלית ומכיר כמה כלים.
"קמצנות כרונית" של הרשאות: תופעה שקיימת בכל ארגון – עודף הרשאות שניתנו למשתמשים שונים, הרשאות שנפתחו "זמנית" ונשארו פתוחות או הרשאות שנפתחו ברמת worldwide (בלינוקס/יוניקס זה מוכר כ-777) בגלל שמישהו התעצל לחפש בגוגל ולקרוא איך מגדירים הרשאות בלינוקס. מאוד מומלץ לבצע אחת לחודש או לתקופה לעבור על כל ההרשאות (גם הרשאות מקומיות!) ולצמצם את ההרשאות. אם רוצים להשתמש לדוגמא ב-passwordless ssh, יש להגביל את החיבוריות להרצת פקודות מסויימות, כניסה מכתובות IP מסויימות, ועוד.
עדכוני תוכנה ללא תאריכון: אחת הבעיות שכתבתי לגביה שוב ושוב בבלוג זה – מנמ"ר מחליט שעדכונים יהיו אחת ל-X חודשים ותו לא. לך תסביר לאותו מנמ"ר שחולשות אבטחה מתגלות כל הזמן ויש לא מעט מקרים שיש צורך דחוף בהתקנת עדכונים, אחרת התשתית חשופה. דוגמא פשוטה: אם אתם משתמשים ב-vSphere, האם עדכנתם את הטלאי הדחוף הזה?

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

השינוי המהותי ש-VMware מתכננת לבצע

כנס VMWorld נערך באופן וירטואלי השנה ב-29-30/9 וכלל מגוון הרצאות, שרובם נעו על מוצרים ונושאים שב-VMWare כבר דיברו עליהם בעבר. אחד הנושאים שעבר "הכרזה מחדש" (3 פעמים! פעם אחת בשנה שעברה, פעם שניה בכנס VMworld ופעם שלישית רק לפני יומיים בכנס GTC) הוא נושא ה"DPU" (כלומר Data Processor Unit) של חברת מלאנוקס, עם מעבדי ה-Bluefield-2. חשבתי לכתוב פוסט על ה-DPU, אך מכיוון שיש עוד מספר שחקנים שהולכים להיכנס בדיוק לתחום זה עם שמות משלהם, החלטתי לכתוב פוסט יותר כללי בנושא.

תכירו – פרויקט Monterey

לפני שניכנס לפרטי הפרויקט, נסתכל על המצב הנוכחי, עוד ברמת ה-Hypervisor, ה-ESXi. כיום, ה-ESXi בעצם מריץ את כל השרותים כ-Hypervisor על מעבדי ה-X86 (ה-Xeon או EPYC) – בין אם מדובר בשרותי רשת, שרותי אחסון, אבטחה, Host Management ועוד. כל זה טוב ויפה, אך זה גוזל לא מעט משאבים מהשרת, וזה גם לא נותן מענה מלא לצרכים של הלקוחות כיום, שרוצים מהירות תקשורת יותר גבוהה, שימוש בכרטיסי FPGA וכרטיסים אחרים, חלוקה יותר טובה של נתיבי PCIe (העבודה שרוב יצרני השרתים, למעט חברת Supermicro ו-TYAN עושים בשרתים שלהם בכל הקשור ל-IOMMU, שלא לדבר על SR-IOV ומיפוי הנתיבים – היא פשוט בושה!), ועוד.

ישנה קטגוריה שלמה של כרטיסים חכמים שיכולים לבצע את כל התהליכים הללו, ובצורה הרבה יותר מאובטחת, יותר מהירה ויותר אמינה. הקטגוריה הזו נקראת SmartNIC. בדרך כלל מדובר בכרטיס רשת שכולל בתוכו מעבד ARM, אחסון Flash קטן, זכרון, ויכולות רציניות לטפל בתעבורה במהירות של 100-200 ג'יגהביט, כולל אבטחה בכל רמות התקשורת, הצפנה, שרותי אחסון NVME "על סיב" ועוד. ב-VMware עסקו בשנתיים האחרונות במיגרציה של קוד ה-ESXi ל-ARM על מנת לאפשר ל-ESXi בעצם לרוץ מהכרטיס ואותו מעבד ARM יתן את כל השרותים שה-ESXi כיום נותן – רק מבלי להשתמש במעבדי ה-X86 בשרת. מעבדי ה-X86 הנ"ל יוכלו להריץ מכונות וירטואליות, קונטיינרים, ומעתה – גם Bare Metal. תוכלו להריץ בעצם כל מערכת הפעלה על "הברזל", כאשר ה-OS יקבל את שרותי התקשורת, אחסון, ניהול וכו' דרך ה-SmartNIC באופן שקוף. בנוסף, בעזרת ה-SmartNIC ופרויקט אחר (פרויקט Bitfusion) – נוכל גם לקבל שרותים מציוד שאינו נמצא על השרת עצמו, כמו שרותי GPU, שרותי אחסון NVME Over Fiber ועוד.

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

אם העניין הזה נשמע לכם מוכר ולא מעולם VMware – אתם לא טועים. כך בדיוק עובדת אמזון עם כרטיס ה-Nitro שלהם ומאפשרת ללקוחות לשכור מיידית שרתים פיזיים, מבלי שהשרתים יעברו תהליך Provision כלשהו. הכל רץ מכרטיס עם מעבד ARM ומערכת לינוקס שרצה על הכרטיס ומבצעת את כל הפעולות, ונותנת את כל השרותים הנחוצים בצורה שקופה לשרת. גם ספקי ענן ציבורי אחרים עובדים בשיטות דומות.

פרויקט Monterey נמצא כרגע במצב Preview, אך מי שחושב כבר לקפוץ ולהתחיל להשתמש בפירות של הפרויקט, כדאי שיעצור לרגע. כרטיסי ה-SmartNIC מתחברים בחיבור של 100-200 ג'יגהביט ומעלה, כך שסביר להניח שתצטרכו מתגים אחרים יותר מהירים ויותר יקרים. מבחינת סוגי כרטיסי SmartNIC, אין כרגע הרבה הצעות (יש את Bluefield-2 של חברת מלאנוקס, אינטל, ברודקום ועוד מספר חברות יצאו עם כרטיסים כאלו בשנה הבאה) וסביר להניח שתצטרכו גם בדרך להחליף שרתים, הואיל ויש צורך בשינויים על לוח האם, כולל שינויים מהותיים לקוד ה-UEFI שבשרתים.

לסיכום: זהו עוד מקרה שטכנולוגיה שמתחילה להיווצר ולהיות משומשת אצל ספקי ענן ציבורי (hyperscalers) ומגיעה לאט לאט ל-Enterprise. הפרויקט עצמו, לכשיפעל ויוכרז כ"יציב", וכל הציוד יהיה זמין – יתן פונקציונאליות חדשה וביצועים טובים יותר, אך בשלב זה הפרויקט אינו יותר מאשר "מעניין".

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

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

לא מעט חברות תוכנה יוצרות קשר בתערוכות, כנסים ודרכי שיווק אחרים כדי למכור את מרכולתן מעבר לים. בחלק מהמקרים התוכנה תינתן להורדה בחינם/כ-DEMO/לאחר תשלום בצורה מקוונת, ובחלק מהמקרים התוכנה תישלח ללקוח באמצעים קונבנציונליים (כן, יש עדיין מקרים כאלו).

אחד החששות הכי גדולים של אותן חברות – הוא שהתוכנה תיגנב, תועתק ו/או תופץ ברבים באמצעים פיראטיים ובמקרים מסויימים – חלקים ממנו יופיעו בתוכנות אחרות מתחרות (אחרי הכל, לא ממש מסובך להעתיק קובץ so או DLL – אלו קבצים של ספריות משותפות).

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

כאן בדרך כלל כותב שורות אלו מקבל פניות (היו לא מעט כאלו) מהחברה ובה בקשה להצעת מחיר להקשחת מחשב שישלח ללקוח, החל מרמת ה-BIOS, המשך ב-OS ובכל מה שצריך, הכל על מנת שהלקוח הפוטנציאלי לא יפרוץ למכונה ויגנוב את התוכנה..

מערכות הפעלה שונות ניתנות להגנה ברמות שונות. לינוקס ניתן להקשיח בצורה הרבה יותר רצינית מאשר כל גירסת Windows. ניתן להצפין את הדיסק, ניתן לנעול BIOS/UEFI, ניתן גם לבטל אפשרות הפעלת כניסות USB, רשת וכו', אולם מהרגע שהמכונה מגיעה ללקוח הפוטנציאלי, הסיכוי שההגנות הללו ימנעו ממנו להיכנס/להעתיק – שואפים לאפס. אפשר להשתמש בטריקים רבים, אבל המקסימום שהם יגרמו, זה עיכוב בפריצה. (אגב, אני מכיר לא מעט אנשים שבטוחים שתוכנות כמו BitLocker מצפינות דיסקים בצורה יוצאת מן הכלל ולא ניתן בשום מצב לחלץ את המידע. אני ממליץ להם לקרוא את הפוסט הזה).

אז מה ניתן לעשות? לשכנע את הלקוח לנסות משהו אחר. אחת ההצעות: מכונה שתהיה זמינה Online.

מכונות וירטואליות אשר זמינות אונליין – קלות יותר להגנה והרבה יותר קשות לפריצה מאשר ברזל שמגיע ללקוח ב-Fedex. אפשר להתקין מספר תוכנות שעוקבות אחר ההתנהגות של המשתמש ושתדענה לחסום נסיונות שונים של "התחכמות". כמובן שאין 100% הגנה, אך ניתן לנעול ולסגור דברים רבים, במיוחד בלינוקס.

ב-Windows לעומת זאת, אם רוצים להקשיח ברצינות מכונה כזו, יהיה צורך בלהכין אותה מחדש, בלי WDS ולהשתמש בגירסת ה-IoT. בגירסה זו ההתקנה היא הרבה יותר פרטנית ויש צורך לבחור חלקים שונים מתוך מאות חלקים (בניגוד למה שמותקן ב-WDS) ובכך להקטין באופן משמעותי את אפשרויות הפריצה למכונה, ועל זה ניתן להתקין תוכנות צד ג' שחוסמות כניסות USB, חוסמות את תפריט ה"התחל", חוסמות תעבורת רשת, כתיבות לתיקיות לא מאושרות וכו' וכו'.

חוץ מהפתרונות הנ"ל, ישנם עוד פתרונות אחרים שתלויים כמובן בסוג האפליקציה ומה רוצים להריץ, החל מקונטיינרים, מכונות וירטואליות עם פתרונות הצפנה של ה-VM מבוססי מעבדים כמו Ryzen או EPYC, שימוש ב"שוק" של ספקי הענן ועוד ועוד, אך גם חשוב לזכור: אלו פתרונות שיותר קשים לפריצה, אך הם אינם בלתי פריצים לאלו המומחים בנושאים אלו.

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

גישות SaaS/PaaS והגישה ההיברידית

כמעט בכל חברה יתקיים מצב בו החברה תחפש תוכנה שתבצע שרות X או שתתן שרותי פלטפורמה Y במקום "להמציא את הגלגל" מחדש בכל פעם. אם לדוגמא העסק מעוניין לשלוח איחולי חג שמח לכל הלקוחות, ניתן יכול לשכור שרותי Saas של חברה כמו Mailchimp לדוגמא ובתמורה תקבלו ממשק קל לשימוש וסיכוי מאוד גדול שכל לקוחות העסק יקבלו את המייל. מצד שני אפשר בעזרת מעט סקריפטולוגיה ושימוש באמזון SES לבצע את אותו דבר אך במחיר זול בהרבה (יכול לחסוך לא מעט אם לחברה יש מאות אלפי או מיליוני לקוחות לדוגמא). אפשר כמובן לקחת גם את האופציה החינמית ולהקים שרת מייל או להשתמש בשרת מייל מקומי כדי לשלוח את הררי האימיילים, אבל במקרים כאלו הסיכוי שהמייל יתקבל אצל כל הלקוחות הוא די קלוש – אם לא משקיעים בכל עניין של Whitelist, RBL, דבר שלוקח לא מעט זמן ומשאבים.

יותר ויותר חברות תוכנה מקצצות בהשקעה של כתיבת תוכנות והפצת כ-Stand alone המיועדות לרוץ על שרתים בתשתית מקומית של הלקוח, וזאת ממספר סיבות, הנה 2 העיקריות:

עלויות תמיכה – ככל שתוכנה נמכרת כ-Stand Alone, עלות התמיכה ליצרן התוכנה תהיה גבוהה, מכיוון שיש לא מעט סיכוי שהתוכנה לא תעבוד בסביבות או מכונות שונות, הרשאות שגויות, חוסר ידע טכני של הלקוח ועוד. ככל שהתומכים הטכניים יהיו עסוקים יותר ויותר שעות בפתרון בעיות של לקוח ספציפי זה או אחר, הרווח של יצרן התוכנה ירד. אחרי הכל, אף אחד לא משלם ליצרן התוכנה אם מחלקת התמיכה השקיעה 10 שעות בפתרון בעיה אצל לקוח יחיד לדוגמא.
פיראטיות – בהרבה מאוד חברות הצוות מוריד אפליקציה או פלטפורמות מסויימות למטרת Trial ומיד לאחר מכן הם מחפשים כל מיני כלים ודרכים כדי לפרוץ את ה-Trial. הרווח של יצרן התוכנה ממקרים כאלו – אפס.

מהרגע שיצרן התוכנה מציע את מוצריו כ-PaaS או SaaS, הדברים נהיים יותר קלים עבורו:

אין פיראטיות
עלויות התמיכה מצטמצמות משמעותית הואיל והכל רץ בתשתית וירטואלית של יצרן התוכנה בעננים שונים ומקרי התמיכה נהיים יותר ויותר פשוטים כי ניתן לשחזר את התקלות במחלקת התמיכה של יצרן התוכנה.
תזרים הכנסות חודשי/שנתי רציף מהלקוחות.
קצב הפיתוח מואץ יותר, באגים ופונקציונאליות חדשה נכנסת ל-Life Cycle של השרות במהירות גבוהה יותר ובכך דרישות לדברים חדשים שלקוחות מבקשים – נענים במהירות גבוהה יותר.
אין צורך בתמיכת Legacy הואיל וכולם עובדים על גירסה אחת או שתי גרסאות.

אך יש גם חסרונות:

עלויות תשתית הרבה יותר גבוהות בענן ציבורי. בניגוד למכירת תוכנת Stand Alone שלא מתחברת החוצה, כאן פתרון ה-Saas/PaaS יצטרך חיבור קבוע למשאבים שונים של יצרן התוכנה.
אבטחת המידע צריכה להיות הרבה יותר רצינית בהשוואה למקרים של תשתית סגורה החוצה. מהרגע שמתגלה אצל יצרן כזה דליפת מידע, יש סיכוי לא רע שחלק מהלקוחות יעדיפו לנטוש ולחפש פתרון מתחרה.

אלו, פחות או יותר הסיבות שבגללן חברות תוכנה יעדיפו להציע שרותי PaaS/SaaS.

אחת הנקודות שבמקרים רבים אינני רואה התייחסות מצד אותן חברות – היא למקרים שהלקוח אינו מוכן "לעבור All In", כלומר הלקוח לא מוכן שכל ה-DATA שלו ישב בתשתית של יצרנית תוכנה ולו (ללקוח) לא תהיה שליטה על הנתונים מבחינת אבטחת מידע או בכלל מהבחינה העקרונית שזה ישב בתשתית של חברה אחרת שאין לו מושג ירוק לגביה. זו לדוגמא אחת הסיבות שחברות יעדיפו לוותר על פתרון SaaS/PaaS שמוצע רק על ענן ובמקומו הם יעדיפו פתרון שרץ מההתחלה ועד הסוף על תשתית מקומית (On Prem).

מה שלעניות דעתי אותן יצרניות תוכנה PaaS/SaaS צריכות להציע – הן את האפשרויות הבאות (אחת או יותר), משהו שהוא יותר מעין "Hybrid":

ה-DATA של הלקוח יכול להיות מאוחסן On Prem עם Agent שמתחבר לענן. לשרות תהיה גישה עם הרשאות מאוד מוגבלות
אם ללקוח יש חשבון בענן ציבורי כלשהו, הלקוח יוכל להגדיר אחסון אובייקטים כלשהו (S3 לדוגמא) עם הרשאות מוגבלות שינתנו בעת הפעלה ראשונית של שרות ה-SaaS/PaaS והרשאות אלו יהיו תחומים למשאבים מסויימים בלבד (נניח Bucket כלשהו)
הלקוח יצטרך לבחור כבר בהתחלת שימוש ה-PaaS/SaaS את ה-Passphrase שלו (ובלבד שיהיה מורכב) ועם אותו Passphrase (ואולי יחד עם עוד מספר נתונים) יוצפן ה-DATA של הלקוח כך שגם ליצרן התוכנה לא תהיה גישה לנתונים. (אפשר כמובן במקום Passphrase יהיה אפשר להשתמש במפתחות פרטי/ציבורי יחד עם Passphrase)

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