Проблемы с безопасностью у Snowflake после недавнего ряда кражи данных клиентов, можно сказать, нарастают.
После того, как Ticketmaster была первой компанией, связавшей свою недавнюю утечку данных с облачной компанией по обработке данных Snowflake, сайт сравнения кредитов LendingTree теперь подтвердил, что его дочернее предприятие QuoteWizard имело украденные данные из Snowflake.
"Мы можем подтвердить, что мы используем Snowflake для наших бизнес-операций и что они уведомили нас о том, что наше дочернее предприятие QuoteWizard может быть затронуто этим инцидентом", - сказала представитель LendingTree Меган Грейлинг журналу TechCrunch.
"Мы относимся к этим вопросам серьезно и сразу после получения уведомления [от Snowflake] запустили внутреннее расследование", - сказал представитель. "На настоящий момент кажется, что информация о финансовых счетах потребителей и информация о родительском субъекте, LendingTree, не пострадали", - добавил представитель, отказавшись комментировать дальше со ссылкой на продолжающееся расследование.
По мере того, как обращается все больше затронутых клиентов, Snowflake пока мало сказала за пределами краткого заявления на своем веб-сайте, подчеркивающего, что на его собственных системах не было нарушений данных, а его клиенты не использовали многофакторную аутентификацию, или MFA - меру безопасности, которую Snowflake не накладывает или не требует от своих клиентов активировать по умолчанию. Snowflake сама была поймана в капкане этого инцидента, сказав, что учетная запись "демо" бывшего сотрудника была скомпрометирована, поскольку она была защищена только именем пользователя и паролем.
В своем заявлении пятницы Snowflake продолжила утверждать, что ее позиция "остается неизменной". Ссылаясь на свое более раннее заявление от воскресенья, главный информационный директор Snowflake Брэд Джонс заявил, что это была "целенаправленная кампания, направленная на пользователей с однофакторной аутентификацией" и использующая украденные учетные данные из программного обеспечения для похищения информации или полученные из предыдущих утечек данных.
Отсутствие MFA, кажется, позволило киберпреступникам загрузить огромные объемы данных из среды клиентов Snowflake, которые не были защищены дополнительным уровнем безопасности.
На протяжении недели TechCrunch находил онлайн сотни украденных учетных данных клиентов Snowflake, похищенных вредоносным программным обеспечением, заражающим компьютеры сотрудников, имеющих доступ к среде Snowflake своего работодателя. Количество учетных данных показывает, что для клиентов Snowflake, которые еще не сменили свои пароли или не включили MFA, остается риск.
На протяжении недели TechCrunch отправлял более десятка вопросов Snowflake о действующем инциденте, влияющем на его клиентов, поскольку мы продолжаем освещать эту историю. Snowflake отказалась отвечать на наши вопросы хотя бы по шесть раз. Это некоторые из вопросов, которые мы задаем, и почему.
Пока неизвестно, сколько клиентов Snowflake пострадало, или знает ли Snowflake об этом.
Snowflake заявила, что на данный момент уведомила "ограниченное количество клиентов Snowflake", которых компания считает могли пострадать. На своем веб-сайте Snowflake говорит, что у нее более 9800 клиентов, включая технологические компании, телекоммуникационные компании и поставщиков здравоохранения.
Представитель Snowflake Даника Станчжак отказалась сказать, является ли число пострадавших клиентов десятками, десятками, сотнями или более.
Скорее всего, несмотря на несколько сообщенных нарушений безопасности клиентов на этой неделе, мы находимся только в начале понимания масштаба этого инцидента.
Возможно, даже само Snowflake не знает, сколько из его клиентов пока пострадало, поскольку компании придется полагаться на свои собственные данные, такие как журналы, или узнавать непосредственно от пострадавшего клиента.
Неизвестно, насколько скоро Snowflake могло бы узнать о вторжениях в учетные записи своих клиентов. В заявлении Snowflake сказано, что 23 мая компания узнала о "угрозовой активности" - доступе к учетным записям клиентов и загрузке их содержимого - но позже нашла доказательства вторжений, датированных не более конкретным временем, чем середина апреля, что указывает на то, что у компании есть некоторые данные для опоры.
Но это также оставляет открытым вопрос, почему Snowflake не обнаружило вовремя выноса больших объемов данных клиентов со своих серверов до гораздо поздней даты в мае, или если обнаружило, почему Snowflake не предупредило своих клиентов заранее.
Консультационная фирма по реагированию на инциденты Mandiant, которую Snowflake пригласила для помощи в контактах с его клиентами, сообщила Bleeping Computer в конце мая, что фирма уже помогала затронутым организациям "несколько недель".
По-прежнему не ясно, что было в учетной записи демо бывшего сотрудника Snowflake или является ли это связанным с нарушениями данных клиентов.
Ключевая фраза из заявления Snowflake гласит: "Мы обнаружили, что хакер получил персональные учетные данные и получил доступ к учетным записям демо, принадлежавшим бывшему сотруднику Snowflake. Они не содержали чувствительных данных."
Некоторые из украденных учетных данных клиентов, связанных с вредоносным программным обеспечением для похищения информации, принадлежат тогдашнему сотруднику Snowflake, согласно обзору TechCrunch.
Как мы уже отмечали, TechCrunch не называет сотрудника, поскольку не ясно, делал ли он что-то неправильное. Факт того, что Snowflake был пойман из-за собственного отсутствия принуждения к MFA, позволяющего киберпреступникам скачать данные из учетной записи "демо" тогдашнего сотрудника, используя только его имя пользователя и пароль, подчеркивает фундаментальную проблему в модели безопасности Snowflake.
Однако пока неясно, какую роль, если вообще, играет эта учетная запись демо в кражах данных клиентов, поскольку еще не известно, какие данные были сохранены внутри, или содержат ли они данные других клиентов Snowflake.
Snowflake отказалась сказать, какую роль играет, если вообще, учетная запись демо бывшего сотрудника Snowflake в недавних нарушениях безопасности клиентов. Snowflake подтвердила, что учетная запись демо "не содержала чувствительных данных", но неоднократно отказывалась сказать, как компания определяет, что считает "чувствительными данными".
Мы спрашивали Snowflake, считает ли компания, что личная идентификационная информация отдельных лиц является чувствительными данными. Snowflake отказалась комментировать.
Неясно, почему Snowflake не проактивно сбросила пароли или не требовала и не обеспечила использование MFA в учетных записях своих клиентов.
Необычно, чтобы компании принудительно сбросили пароли своих клиентов после нарушения безопасности. Но если спросить Snowflake, не было никакого нарушения. И хотя это может быть верно в том смысле, что не было видно компрометации его центральной инфраструктуры, клиенты Snowflake все равно очень много страдают.
Совет Snowflake своим клиентам - сбросить и изменить учетные данные Snowflake и обеспечить MFA на всех учетных записях. Ранее Snowflake сообщила TechCrunch, что ее клиенты несут ответственность за свою собственную безопасность: "Согласно общей модели ответственности Snowflake, клиенты должны обеспечивать использование MFA своими пользователями".
Но поскольку эти кражи данных клиентов Snowflake связаны с использованием украденных имен пользователей и паролей учетных записей, которые не защищены MFA, необычно, что Snowflake не вмешалась от имени своих клиентов для защиты их учетных записей сбросом паролей или обязательным включением MFA.
Это не без прецедента. В прошлом году киберпреступники извлекли 6,9 миллиона пользовательских и генетических записей из учетных записей 23andMe, которые не были защищены MFA. 23andMe сбросила пароли пользователей из осторожности для предотвращения дальнейших атак и требовала использовать MFA для всех учетных записей своих пользователей.
Мы спросили Snowflake, планирует ли компания сбросить пароли учетных записей своих клиентов, чтобы предотвратить дальнейшие возможные вторжения. Snowflake отказалась комментировать.
Похоже, что Snowflake движется к внедрению MFA по умолчанию, согласно технологическому новостному сайту Runtime, цитирующему CEO Snowflake Сридхара Рамасвами в интервью на этой неделе. Это позднее подтвердил в пятничном обновлении главный информационный директор Snowflake Джонс.
"Мы также разрабатываем план по требованию нашим клиентам внедрить продвинутые средства безопасности, такие как многофакторная аутентификация (MFA) или политики сети, особенно для привилегированных учетных записей клиентов Snowflake," - сказал Джонс.
Сроки для этого плана не сообщались.
Знаете больше о вторжениях в аккаунт Snowflake? Свяжитесь с нами. Чтобы связаться с этим журналистом, свяжитесь через сигнал и WhatsApp по номеру +1 646-755-8849 или по электронной почте. Вы также можете отправлять файлы и документы через SecureDrop.