Ticketmaster, Santander Bank и други големи фирми са претърпели изтичане на данни от голяма облачна услуга, което подчертава, че компаниите трябва да обръщат внимание на удостоверяването.

Групата киберпрестъпници, известна като UNC5537, е в подем.

През последния месец бандата за откупи, вероятно свързана с ShinyHunters или Scattered Spider, открадна над 560 милиона клиентски записа от Ticketmaster и ги публикува за продажба на възстановения сайт за изтичане на данни BreachForums на 28 май, като поиска 500 000 USD. Два дни по-късно групата твърди, че е откраднала 30 млн. записи на сметки от испанската банка Santander, като иска 2 млн. долара. И двете компании признаха за нарушенията след публикациите.

Според анализ от 10 юни, направен от фирмата за реагиране на инциденти Mandiant, част от Google, причината за изтичането на данни – и за поне 163 други нарушения – изглежда не е уязвимост, а използването на откраднати идентификационни данни и лош контрол на многофакторното удостоверяване (MFA).

„Разследването на Mandiant не откри никакви доказателства, които да сочат, че неоторизираният достъп до клиентски акаунти на Snowflake е резултат от пробив в корпоративната среда на Snowflake“, заявява Mandiant в своя анализ. „Вместо това всеки инцидент, на който Mandiant е реагирал, свързан с тази кампания, е бил проследен до компрометирани клиентски идентификационни данни.“

Въпреки че кражбата на данни от системите на Snowflake е можело да бъде предотвратена чрез MFA, провалите на компаниите надхвърлят липсата на този единствен контрол. Предприятията, използващи облачни услуги, трябва да се уверят, че имат видимост към своите повърхности за атаки, като бързо премахват акаунтите на бивши служители и изпълнители и намаляват пътищата, по които опортюнистичните нападатели биха могли да компрометират системи, мрежи или услуги, казва Крис Морган, старши анализатор по разузнаване на киберзаплахите в доставчика на платформа за сигурност в облака ReliaQuest.

„Най-големият научен урок е, че не е необходимо  заплахите да използват сложни техники“, казва той. „Насочването към ниско висящите плодове – в този случай несигурните пълномощия – може да се постигне с малко усилия от страна на извършителя на заплахата, но предоставя широки възможности.“

Ето пет поуки от последната вълна от нарушения в облака.

1. Започнете с MFA, но след това продължете

Има много възможности за растеж при въвеждането на MFA. Въпреки че според доклад, публикуван преди година, 64% от работниците и 90% от администраторите използват MFA, според доклада „2024 State of Cloud report“ на Orca Security повече от шест от всеки 10 организации имат поне един потребител или администратор без активиран MFA в акаунта.

Предприятията трябва да достигнат до последователни – и проверими – 100 %, казва Офер Маор, съосновател и главен технологичен директор на фирмата за сигурност в облака Mitiga.

Компаниите трябва да „се уверят, че MFA се прилага и изисква, а ако използват [single sign-on], да се уверят, че не-SSO входът е забранен“, казва той. „Излезте извън рамките на традиционното MFA [и] включете допълнителни мерки за сигурност, като например хардуерно базирано удостоверяване за чувствителна инфраструктура.“

2. Използвайте списъци за контрол на достъпа, за да ограничите оторизираните IP адреси

Организациите трябва също така да въведат списъци за контрол на достъпа (ACL), като ограничат местата, откъдето потребителите могат да получат достъп до дадена облачна услуга, или поне да позволят ежедневни прегледи на дневниците за достъп, за да се открият всякакви аномалии.

Това допълнително ограничава възможностите на кибератаките – казва Джейк Уилямс, преподавател-анализатор и специалист по киберсигурност в анализаторската фирма IANS Research.

„Наистина, за почти всяка инфраструктура в облака … е най-добра практика да се ограничава от какви IP адреси могат да идват хора“, казва той. „Ако не можете, тогава проверките на достъпа са още по-важни, за да сте сигурни, че хората не идват от място, от което не очаквате.“

3. Увеличете максимално видимостта на облачните услуги

Компаниите трябва да разполагат и със смислен начин за непрекъснато наблюдение на приложенията. Лог данните, активността на достъпа и услугите, които обединяват източниците на данни в цялостна картина, могат да помогнат на компаниите да откриват и предотвратяват атаки, като тези на Snowflake.

Освен това организациите трябва да могат да предупреждават за специфично поведение или открити заплахи – подход, който би открил опитите на киберпрестъпниците за достъп до техните данни в облака, казва Брайън Соби, главен технически директор и съосновател на AppOmni, фирма за управление на позициите за сигурност на базата на софтуер като услуга.

„Въпреки че екипите за операции по сигурността са разпръснати и обикновено нямат възможност да развиват задълбочени експертни познания за различните приложения, използвани от техните компании, техните инструменти и платформи за сигурност би трябвало бързо да идентифицират тези проблеми“, казва той. „В този сценарий със сигурност е имало аномални влизания от необичайни места и свързване на много съмнителни приложения на атакуващите към инстанциите на клиента Snowflake.“

4. Не разчитайте на настройките по подразбиране на доставчиците на облачни услуги

Въпреки че доставчиците на облачни услуги обичат да подчертават, че сигурността е модел на споделена отговорност, освен ако нападателят не пробие инфраструктурата или софтуера на доставчика на облачни услуги – като например при миналогодишните уязвимости в услугата MoveIT Cloud и софтуера MoveIT Transfer на Progress Software – отговорността почти винаги пада върху клиента.

И все пак често доставчиците на облачни услуги дават приоритет на използваемостта пред сигурността, така че компаниите не трябва да разчитат на сигурността на доставчиците си по подразбиране. Има много неща, които Snowflake, например, можеше да направи, за да улесни управлението на MFA, включително да включи контрола на сигурността по подразбиране, казва Маор от Mitiga.

„Това, което позволява тази атака да бъде успешна, и то в такъв мащаб, е, че настройката по подразбиране на акаунтите на Snowflake не изисква MFA, което означава, че след като получите компрометирани потребителско име и парола, можете да получите пълен достъп веднага“, казва той. „Обикновено високочувствителните платформи изискват от потребителите да активират MFA. Snowflake не само че не изисква MFA, но и много затруднява администраторите да наложат това.“

5. Проверете третите си страни

И накрая, компаниите трябва да имат предвид, че – дори да не използват Snowflake или друга облачна услуга – доставчик от трета страна може да използва услугата за своя бек енд, излагайки данните им на риск, казва Уилямс от IANS Research.

„Вашите данни може да са в Snowflake, дори и да не я използвате“, казва той. „Това е сложността на днешните вериги за доставки… вие предоставяте данните си на доставчик на услуги от трета страна, който след това ги вкарва в Snowflake и може да използва или да не използва най-добрите практики.“

Организациите трябва да се свържат с всички свои доставчици на услуги, които имат достъп до техните данни, и да се уверят, че те предприемат подходящи стъпки за защита на тази информация, казва Уилямс.