Най-големият научен урок от пробивите в сигурността напоследък е, че не е нужно нападателите да използват сложни техники (снимка: CC0 Public Domain)
Няколко големи организации, включително Ticketmaster, Santander Bank и други, претърпяха изтичане на данни от популярна облачна услуга, което подчертава, че компаниите трябва да обърнат внимание на технологиите за удостоверяване.
Наскоро кибербанда за откупи, вероятно свързана с ShinyHunters или Scattered Spider, открадна повече от 560 милиона клиентски записи от Ticketmaster и ги публикува за продажба на своя възстановен сайт за течове на информация, BreachForums, като поиска 500 000 долара. Два дни по-късно групата потвърди, че е откраднала сметки на 30 милиона потребители от базираната в Испания банка Santander, като поиска откуп от 2 милиона долара. И двете компании признаха нарушенията след публикациите.
Причината за изтичането на данни – и най-малко 163 други пробиви – изглежда не е уязвимост, а използване на откраднати идентификационни данни и лош контрол върху многофакторното удостоверяване (MFA), според анализ на фирмата за реагиране при инциденти Mandiant, част на Google.
„Разследването на Mandiant не откри никакви доказателства, които да подсказват, че неоторизиран достъп до акаунти на клиенти на Snowflake произтича от нарушение на корпоративната среда на Snowflake”, се казва в анализа на Mandiant. „Вместо това всеки инцидент, който Mandiant изследва във връзка с тази кампания, беше проследен до компрометирани идентификационни данни на клиента”.
Докато кражбата на данни от системите на Snowflake можеше да бъде предотвратена от MFA, провалите на компаниите надхвърлят липсата на този единствен контрол. Фирмите, използващи облачни услуги, трябва да се уверят, че имат видимост в техните повърхности за атака, бързо премахват акаунти на бивши служители и контрагенти и намаляват пътищата, чрез които опортюнистични нападатели могат да компрометират системи, мрежи или услуги, казва Крис Морган, старши анализатор по киберзаплахи в доставчика на облачната платформа за сигурност ReliaQuest.
„Най-големият научен урок е, че не е нужно заплахите да използват сложни техники”, споделя Морган. „Насочването към „ниско висящия плод” – в този случай несигурни идентификационни данни – може да бъде постигнато с малко усилия от страна на нападателите, но предоставя достатъчно възможности”.
Ето пет урока от последната вълна от пробиви в облака, които Dar Reading обобщава:
1. Започнете с MFA и след това отидете отвъд
Има много място за растеж, когато става въпрос за възприемане на MFA. Въпреки че 64% от служителите и 90% от администраторите използват MFA, повече от 6 от всеки 10 организации имат поне един root потребител или администратор без активиран MFA в акаунта си, според доклад на Orca Security за състоянието на облака през 2024 г.
Бизнесът трябва да достигне консистентност – и проверимост – на 100%, казва Офер Маор, съосновател и главен технологичен директор във фирмата за облачна сигурност Mitiga. Компаниите трябва „да се уверят, че MFA е наложена и задължителна и ако използвате еднофакторна идентификация (single sign-on), се уверете, че влизането без SSO е деактивирано”, казва той.
„Преминете от традиционната MFA и включете допълнителни мерки за сигурност, като удостоверяване, базирано на устройство или хардуер за чувствителна инфраструктура”, препоръчва Маор.
2. Използвайте списъци за контрол на достъпа, за да ограничите разрешените IP адреси
Организациите трябва също така да въведат списъци за контрол на достъпа (ACL), които ограничават достъпа на потребителите до облачната услуга или поне позволяват ежедневни прегледи на регистрационните файлове за достъп, за да се открият аномалии.
Това допълнително ограничава способността на кибернападателите, казва Джейк Уилямс, анализатор и специалист по киберсигурност в IANS Research. „Наистина, за почти всяка облачна инфраструктура най-добрата практика е да се ограничат IP адресите, от които хората могат да идват”, казва той. „Ако не можете, тогава прегледите за достъп са още по-важни, за да сте сигурни, че хората не идват от място, което не очаквате”.
3. Увеличете максимално видимостта в облачните услуги
Компаниите също трябва да имат смислен начин за непрекъснат мониторинг на приложенията. Регистрационните данни, активността на достъпа и услугите, които дават пълна картина на източниците на данни, могат да помогнат на компаниите да открият и предотвратят атаки, като тези на Snowflake.
Освен това организациите трябва да могат да предупреждават за конкретно поведение или откриване на заплахи – подход, който би засякъл опитите на киберпрестъпниците за достъп до техните облачни данни, казва Браян Соби, технически директор и съосновател на SaaS фирмата за сигурност AppOmni.
„Въпреки че екипите за операции по сигурността са разпръснати и като цяло нямат възможност да развият задълбочен опит в различните приложения, използвани от техните компании, инструментите и платформите за сигурност трябва бързо да идентифицират проблемите”, казва той. „В този сценарий със сигурност имаше аномални влизания от необичайни местоположения и свързване на силно съмнителни атакуващи приложения към клиентски екземпляри на Snowflake”.
4. Не разчитайте на настройките по подразбиране на вашите облачни доставчици
Докато доставчиците на облачни услуги обичат да подчертават, че сигурността е модел на споделена отговорност, освен ако нападател не наруши инфраструктурата или софтуера на облачния доставчик, отговорността почти винаги пада върху клиента.
И все пак често облачните доставчици дават приоритет на използваемостта пред сигурността, така че компаниите не трябва да разчитат на настройките по подразбиране на своите доставчици, за да бъдат сигурни. Има много неща, които Snowflake можеше да направи, за да улесни управлението на MFA, например включване на контрола за сигурност по подразбиране, казва Маор от Mitiga.
„Това, което позволи тази атака да бъде успешна и в този мащаб, е, че настройката по подразбиране на акаунтите на Snowflake не изисква MFA, което означава, че след като получите компрометирано потребителско име и парола, можете да получите пълен достъп веднага”, казва той. „Обикновено платформите с висока чувствителност ще изискват от потребителите да активират MFA. Snowflake не само не изисква MFA, но също така затруднява администраторите да наложат това”.
5. Проверете вашите „трети страни”
И накрая, компаниите също трябва да имат предвид, че – дори и да не използват Snowflake или друга облачна услуга – доставчик „трета страна” може да използва услугата в своя бекенд, излагайки данните им на риск, казва Уилямс от IANS Research.
„Вашите данни може да са в Snowflake, дори и да не го използвате”, казва той. „Това е сложността на веригите за доставки днес… вие давате данните си на доставчик на услуги трета страна, който след това ги поставя в Snowflake и може да не използва най-добрите практики”.
Организациите трябва да се свържат с всички свои доставчици на услуги с достъп до техните данни и да се уверят, че предприемат правилните стъпки за защита на тази информация, заключава Уилямс.
Преводът е през куп за грош, отделни изречения са със сбъркан словоред, други нямат смисъл.