00:00 Смотрим статистику по прошлому эпизоду 03:26 Максим сходил на Технологии SOC 05:45 Финансирование государственных ИБ систем 08:52 Интересная уязвимость раскрытия данных в ownCloud (CVE-2023–49103) 11:59 Уязвимость Chrome в распространенной библиотеке Skia (CVE-2023–6345). 15:25 «Яндекс.Еда» заплатит по 5 тысяч рублей двум пострадавшим от утечки данных 19:00 Персональный заход: аферисты обновили схему для доступа к аккаунтам на «Госуслугах» 20:44 Легализации «белых» хакеров 23:22 Прощание от Mr.X
Про наказания за утечки. Каждый раз, когда происходит громкая утечка персональных данных поднимается волна возмущения и призывов ужесточить наказание за это. Я не сторонник ужесточения наказания и вот почему.
1. Какие ваши доказательства? Возьмём последний кейс с Бизонами. Что мы видим? Пара скриншотов, на которых фрагменты ~50 записей. Само по себе ни о чем не говорит. Можно за пару часов по открытым данным нарисовать такие скрины и будет вполне убедительно. Даже если выложат полный дамп, где доказательства, что это не генеренка по данным из других утечек? Даже если доказано, что утечка имела место, где доказательства, что утечка произошла из конкретной организации, а не от партнёров? В общем, доказательство факта утечки это сложная процедура, это не "в одном анонимном телеграмм-канале написали". Если жёстко наказывать по сообщениям в телеге, то подставить можно будет любую организацию.
2. Вы точно хотите жёсткого наказания? Допустим доказали факт утечки из конкретной организации. В качестве наказания предлагается использовать оборотные штрафы, которые должны существенно повлиять на работу компании. Дескать тогда будут бояться и до утечек не доводить. Ну были, например, масштабные утечки из Яндекса (Еды) или СДЕКа. Вот вы правда считаете, что нам, как российскому обществу, будет лучше, если загнётся Яндекс или СДЕК? У нас много таких компаний? Нам без них лучше будет? Или если забрать у этих компаний значительную часть кэша, там уровень безопасности повысится? Вряд ли. Или, возвращаясь к Бизонам, это одна из ТОП5 ИБ компаний в РФ, если по ней ударят оборотными штрафами, значит злоумышленники, которые выполнили атаку, добились своего. Мы прям точно-точно этого хотим?
3. За каждой утечкой кроется проблема в базовых ИБ процессах, например забыли обновить уязвимый плагин в CMS-ке (и это наш любимый Vulnerability Management) или DLP не поймал инсайдера. Не стоит ли в таком случае вместо угроз мега-штрафами уделять больше усилий регуляторному контролю за этими базовыми ИБ процессами в организациях? Да, это сложнее, но цель ведь не в том, чтобы посильнее и без того пострадавшие российские компании наказать, а чтобы таких утечек стало меньше.
Год с великого исхода западных вендоров: судьба специалиста. С трудом уже верится, но раньше в РФ было возможно строить IT/ИБ системы, используя западные решения. 🙂 Более того, это был абсолютный мейнстрим. Как следствие, сотрудники российских компаний естественным образом развивались в крутых специалистов по продуктам Microsoft, Oracle, CISCO, PaloAlto, AWS, Tenable/Qualys/Rapid7 и т.д. 😉 Собирали комплекты вендорских сертификатов, выстраивали красивые CV-шки.
Безусловно, в этом была своя прелесть. Ты используешь те же решения, что и крупные компании во всем развитом мире, твои скилы также востребованы в общемировом масштабе. А значит релокация туда, где лучше, выглядит как вполне себе план Б (а у кого-то и как план А). Минусом шла привязка к западным вендорам и их судьбе в России. Но что с ними сделается-то? 😏
Однако оказалось, что сделаться может много чего и очень быстро. И перед российскими специалистами по решениям западных вендоров всерьез встал выбор:
- продолжать делать то, что делали, а значит релоцироваться туда, где можно продолжать строить системы на западных решениях; - остаться и строить системы на тех решениях, которые остались/появились в РФ; - остаться, перестать строить системы и принять участие в копировании западных решений.
Релокация это всегда мероприятие на любителя. Тем более сейчас, когда "жить на 2 страны" стало совсем не так просто и комфортно. Переезд на запад теперь выглядит скорее как дорога в один конец.
Остаться и развиваться в чем-то другом это и потеря конкурентных преимуществ, и необходимость быстро учиться новому, и переход в новый локальный контекст. Опыт с Яндекс Клауд и Астра Линукс безусловно менее универсален, чем с AWS и RHEL. 🙂 Это нужно осознать и принять.
Никого не осуждаю, у всех свои ситуации. Но милей мне, безусловно, оставшиеся. Мы в одной лодке, выгребем. 🛶 🙂
О стоимости одного сканирования. Продолжая тему со сканером Яндекс Клауда. 13,2 рубля / 7,2 рубля за скан это много или мало? По сравнению с бесплатными продуктами всё что угодно будет дорого, конечно. 😏 Но вот, для сравнения, цены на API кредиты Vulners (один кредит — один вызов API для проверки одного Linux хоста или Docker-образа, если не заморачиваться оптимизациями):
Получается у Яндекса как в 2–4 раза дешевле. 🙂 Но, конечно, далеко не всё определяется ценой. Нужно смотреть на реальные возможности детекта и оценивать прежде всего качество сканирования.
Про сканер уязвимостей в Yandex Cloud. На днях были новости, что Yandex открыл доступ к своему сканеру уязвимостей. Из этих новостей было не очень понятно что за сканер, для чего сканер. Но я нашел первоисточник — блогопост на сайте Яндекс Клауда.
1. Речь о сканере для Docker-образов, интегрированный в сервис Yandex Container Registry. Это аналог Aqua Trivy, Clair, Falco, Docker scan. Ну и моего Scanvus-а. 🙂 И видимо имеется ввиду Сканер уязвимостей описанный в документации, поддерживающий Alpine, CentOS, Debian, Redhat, Ubuntu в качестве ОС, на которых могут быть собраны пользовательские Docker-образы.
2. В чем преимущество: "Чтобы использовать сканер уязвимостей Yandex Cloud, не требуется выделять дополнительную инфраструктуру, обслуживать её, заниматься разворачиванием и поддержкой продукта или глобально менять процесс выкладки кода. "
3. Описание сканера частично понятно, детект по пакетам: "по результатам сканирования образа пользователь получает отчёт об уязвимостях, обнаруженных в конкретных пакетах ОС, и о версиях этих пакетов с исправлениями, если такие имеются". А то, что понимается под "сканер уязвимостей с использованием статического анализа" — загадочно.
4. Уровни сканирования: реестра целиком и выбранных репозиториев. Сканирование отдельных образов и фильтрации по тегам пока нет, но обещают.
5. Сколько стоит: "Первые шесть первичных и шесть последующих сканирований бесплатны. Начиная с седьмого раза нужно будет платить: за каждое первичное — 13,2 рубля, а за последующее — 7,2 рубля."
Некоторые заметки по итогам митапа Яндекс‑а. Зафиксирую, чтобы не забылось. Для тех, кто не смотрел, полное видео уже доступно.
1. Прикольная тема из Яндекс Финтех про "одна команда — один Golden Image":
"У нас большой стек. У нас сервисы пишутся и на Kotlin, и на плюсах, и для разных языков мы используем разные Golden Image‑ы. Но стараемся, чтобы внутри команды, которая пишет на одном фреймворке и на одном языке сформировался какой-то единый образ, который будет использоваться внутри этой команды. У нас есть набор этих золотых образов, которые используются конкретными командами. Все контейнеры, которые получаются мы пушим в наш registry. Вопрос сколько их сложный, т.к. у нас микросервисная архитектура и у нас очень много микросервисов."
➡️ Вопрос: Используете ли вы distroless образы в Банке, да и в Яндексе в целом, к примеру Google distroless, чтобы минимизировать поверхность атаки и уменьшить размер самих образов? Ответ: нет, но очень хотим к этому прийти ➡️ Вопрос: Если не секрет, что у вас за базовый образ? Аstra Linux? 😉 Ответ: отвечу, что такой же как и во всем Яндексе )
Вполне возможно это секрет полишинеля на основе какого Linux-дистрибутива базовые образы в Яндексе делают, но я не знаю. Если кто знает — шепните в личку, любопытно. 😉
2. То, что Яндекс Финтеху комфортно в Яндекс Облаке это понятное дело. Но будет ли так же комфортно другим банкам и финтехам?
➡️Вопрос: Возвращаясь к сертификации банка в облаке по стандартам PCI DSS и ГОСТам. Я смогу запустить такой банк в я.облаке и получить содействие при прохождении аудита со стороны Команды облака или это единичный случай для «родственной» компании? Ответ: Можно это получить как отдельную услугу в Облаке. ➡️ Вопрос: прям услуга Облака или рекомендованная внешняя команда? Ответ: В Облаке есть архитекторы и premium support.
3. В Wildberries и Яндекс Финтех для организации привилегированного доступа к Linux-инфраструктуре используют Teleport. Почему именно его? Как минимум половина доклада команды Wildberries была про обоснование этого выбора. Очень подробно и убедительно. Единственное жаль, что тема в основном крутилась про то как безопасно дать доступ до нужных серверов и дать/не дать root‑а, но не про хитрое ограничение прав пользователя на хосте. А это у Wildberries есть, т.к. Teleport у них сильно допиленный:
"Команда переписала админку Teleport‑а полностью с нуля. Написала свой PAM-модуль, который учитывает роли, которые передаются телепортом при аутентификации и на основе этого настраивает sudo. Но мы сегодня про это подробно не рассказывали, потому что оно опять же не поместилось."
Про sudo тема интересная, будем ждать следующего раза. 🙂
Свести к минимуму непредсказуемый интерактивчик в текущей ситуации и правда выглядит весьма разумным решением. Мало ли что журналисты по итогам свободной дискуссии ИБшников могли себе додумать и нагенерить. Яндексу сейчас такое точно ни к чему. 🤫
