3side кибербезопасности

❤️ Что зарезервировать, чтобы пережить потерю ЦОДа: памятка За неделю из строя вышли три площадки Яндекса: Сасово, Калуга и Владимир. Yandex Cloud перешёл в аварийный режим. К сожалению, быстро восстановить работу проекта в такой ситуации помогает только наличие резерва и/или бэкапов у другого провайдера. Мы подготовили для вас памятку: Что можно и нужно проверить сейчас, чтобы в случае подобного форс-мажора иметь возможность быстрого восстановление проекта. Бэкапы должны храниться у другого провайдера или на собственном оборудовании вне основного дата-центра. ➡️Что обязательно нужно сохранить 1. Базы данных • Полные бэкапы PostgreSQL, MySQL и других используемых СУБД. • Журналы транзакций (WAL, binlog), если важно восстановление на конкретный момент. • Конфигурации СУБД, роли, права и расширения. • Для критичных систем в иделе иметь реплику у независимого провайдера. Важно: автобэкапы managed-баз не заменяют независимую копию. 2. Файлы и объектные хранилища • Пользовательские загрузки, документы, медиафайлы. • Содержимое S3-бакетов и файловых хранилищ. • Данные с постоянных дисков, которые нельзя воссоздать автоматически. На резервном хранилище включите версионирование и, по возможности, защиту от удаления (Object Lock). 3. Код и CI/CD • Git-репозитории, включая историю и теги. • Конфигурации пайплайнов. • Настройки CI/CD, раннеров и интеграций. • Необходимые переменные и секреты — в отдельном защищённом хранилище. 4. Docker-образы и зависимости • Все образы, которые сейчас используются в production, с точными версиями или digest. • Собственные базовые образы. • Критичные пакеты и зависимости, если их повторная загрузка не гарантирована. 5. Конфигурации инфраструктуры • Terraform, Ansible, Helm charts и values. • Terraform state. • Конфигурации Nginx, HAProxy, приложений и балансировщиков. • Сетевые настройки, правила firewall, маршрутизацию. 6. Секреты, ключи и сертификаты • Секреты приложений и сервисных аккаунтов. • Ключи шифрования резервных копий. • TLS-сертификаты или механизм их автоматического перевыпуска. 7. Очереди, кеши и другие stateful-сервисы • RabbitMQ, Kafka: конфигурации, топологию, права и критичные данные, если их необходимо сохранить. • Redis: настройки и резервные копии, если он используется не только как кеш. • Поисковые индексы и другие хранилища, которые невозможно быстро пересоздать. 8. Внешние интеграции и сетевые соединения Составьте и сохраните вне основной инфраструктуры список внешних сервисов, с которыми взаимодействуют ваши приложения. С кем интегрированы: внешние API, платёжные системы, партнёры, SaaS-сервисы и другие системы. Для каждой интеграции зафиксируйте: - Адреса, порты, протоколы и направления соединений. - Используемые IP-адреса и правила whitelist. - VPN-туннели, приватные соединения и маршруты. - Конфигурации подключений и необходимые сертификаты. - Контакты технических специалистов и ответственных со стороны партнёров. Отдельно: если у вас Kubernetes Для восстановления Kubernetes недостаточно сохранить манифесты приложений. Проверьте, что у вас есть: • Описание инфраструктуры: Terraform или другие инструменты для создания нового кластера, сетей, узлов и балансировщиков. • Бэкапы Persistent Volumes: независимые копии данных, а не только снапшоты дисков текущего облака. • План развёртывания: порядок восстановления системных компонентов, операторов, баз данных и приложений. Если кластер managed, отдельно проверьте, что его можно создать у другого провайдера, а приложения не зависят от специфичных сервисов текущего облака. ➡️Что сделать прямо сейчас, если времени мало? 1. Выгрузить актуальные резервные копии баз и критичных файлов на независимую площадку. 2. Сохранить production-образы и убедиться, что доступны исходный код и конфигурации. 3. Проверить доступность секретов, ключей шифрования, DNS и административных учётных записей. 4. Зафиксировать порядок восстановления и ответственных. 5. Проверить восстановление хотя бы одного критичного сервиса из резервной копии.

Третий удар, массовая миграция, фатальные ошибки. Сейчас многие компании занимаются миграцией из дата‑центров Яндекса, и самое страшное — то, что, торопясь, они допускают фатальные ошибки. Самая частая из них — опасные настройки фаерволов! При экстренной миграции велик соблазн настроить «так, чтобы как можно быстрее заработало». Но вместе с трафиком от ваших пользователей к вам зайдут и злоумышленники. Это может стать вторым эффектом от ударов: массовый взлом компаний из‑за экстренной миграции. А дальше — слив данных, шифрование и остановка работы на ещё больший срок. Будьте осторожны, держите безопасность в фокусе. Если нужно, мы можем помочь и оперативно проверить вашу новую инфраструктуру. P. S. Последний удар задел частично и нас, но далеко не так серьёзно, как множество бизнесов по всей России.

Рунет: чем централизованнее, тем уязвимее. Удар по дата‑центру Яндекса побудил многих «околовоенных» экспертов высказаться на темы, близкие к кибербезу. Давайте мы, как профильный канал, тоже прокомментируем эту тему. Все мы помним, что Рунет у нас уже много лет суверенен, независим и достаточно централизован. Он буквально завязан на несколько ключевых провайдеров и их дата‑центры. Проект централизации первично децентрализованной технологии «Интернет» выполнялся по различным причинам — их мы обсуждать в этом посте не будем. Но фактически успех этого проекта привёл к тому, что буквально на около десятка дата‑центров в европейской части России завязано функционирование примерно всего Рунета. Поэтому, господа военные эксперты: может, суммарно дата‑центров у нас и сотни по всей стране, может, и очень крупных много. Но вывести из строя нужно гораздо меньше, и они вовсе не на Камчатке. Их нужно питать, обслуживать, обеспечивать логистикой. Они все в полётной доступности средств поражения по вполне прагматичным причинам. Могут ли облачные провайдеры быстренько «переехать» в безопасные дружественные страны? Конечно, нет. 152‑ФЗ («О персональных данных») жёстко ограничивает в этом, а 187‑ФЗ (регулирующий безопасность критической информационной инфраструктуры) вводит прямо запрет на зарубежные облака и SaaS‑сервисы. Централизация тут однозначно стреляет нам в ногу: в плане физического поражения инфраструктуры мы стали уязвимее.

Девушка в мини репортаже говорит, что нужен дейтинг на Госуслугах, чтобы видеть весь бэкграунд человека. Дмитрий Григоренко поддерживает, что знать прошлое человека перед знакомством — это очень удобно.

В рамках дейтинга будет доступна легализованная услуга "Глаз Государства"! 😂

Сегодня смотрел предварительный список вопросов Эфир обещает быть очень конкретным!

Клуб ИТ-лидеров Global CIO приглашает вас принять участие в живом разговоре «После атаки: как сохранить работу бизнеса, когда ИТ-инфраструктура частично недоступна» 🗓 9 октября | 11:00–12:30 | онлайн Ламповый формат для своих, без рекламы. Киберустойчивость — это не только защита от атаки. Что делать, когда часть инфраструктуры уже недоступна, а бизнес должен продолжать работу? Обсудим, как сохранить критичные процессы и какие сценарии стоит отработать заранее. Модератор: 🙋🏻‍♂️ Владимир Дрюков, Директор по услугам и технологиям, ГК Инностейдж Эксперты эфира: 🙋🏼‍♂️Михаил Хавин, CISO, Аскона Лайф Групп 🙋🏼‍♂️Анатолий Скородумов, руководитель отдела кибербезопасности, Лента 🙋🏻‍♂️ Антон Бочкарев, Эксперт по информационной безопасности, Сооснователь компаний 3side/4sec Участие бесплатное ПРОГРАММА И РЕГИСТРАЦИЯ Присоединяйтесь! Материал по итогам будет доступен в Клубе ИТ-лидеров Global CIO.

Подписывайтесь на сообщество Global CIO в МАХ и ВКонтакте

#Клуб_ИТлидеров

ИНТЕНСИВ ПО БЕЗОПАСНОСТИ: ПРОВЕРКА НА ПРОЧНОСТЬ 2026 Друзья, 14 октября в Москве (Холидей Инн Сокольники) стартует главная практическая конференция для тех, кто занимается анализом защищенности. - Почему «мы проверились» — это не равно «мы поняли риски»? - Как не купить красивый отчет вместо реального уровня защиты? - Где грань между пентестом, Red Team и Purple Team? В программе — 3 потока: 🔹 Стратегия для CISO и руководителей (бюджеты, приоритеты, выбор инструментов). 🔹 Практика для технических специалистов (сканирование, ASM, человеческий фактор). 🔹 Спецпрактики (АСУ ТП, право на взлом, этичный хакинг и ИИ). 🎤 Вас ждут пленарные дискуссии, круглые столы CISO, мастер-классы от пентестеров и живое общение с вендорами. 📅 Когда: 14 октября 2026 г. 📍 Где: Москва, Холидей Инн Сокольники ⏳ Программа и регистрация по ссылке. P.S. Мы как обычно инфопартнер

«Может ли взлом быть госизменой?» Это не тема нашей лекции. Это запрос, который военный связист армии США вбил в Google. Теперь у него будет почти шесть лет, чтобы подумать над ответ. Что известно? — Кэмерон Вагениус, 21 год, связист армии США, служил на базе в Южной Корее. В сети — kiberphant0m. — С апреля 2023 по декабрь 2024 вместе с двумя подельниками взламывал американские технологические и телеком-компании. Жертв минимум десять, среди них AT&T и Verizon. Это часть той самой волны взломов через облако Snowflake, где пострадало больше 165 организаций. — Данные качали и шантажировали владельцев: заплатите, или выложим на BreachForums и XSS. Всего пытались выбить минимум миллион долларов. — Задержали его в декабре 2024 в Техасе, рядом с армейской базой. Вину признал. Приговор: 70 месяцев тюрьмы и $294 978 компенсации. А теперь лучшее из материалов обвинения. Почти весь ноябрь 2024 он переписывался с адресом, который считал почтой иностранной разведки, и предлагал ей купить украденное. В октябре гуглил «куда дезертировать из армии, чтобы меня не выдали», «американские военные, перебежавшие в Россию» и адрес посольства России в Вашингтоне. Сразу после переписки с «разведкой» появился тот самый запрос про госизмену. А ещё в ноябре 2024-го, сразу после ареста подельника, он выложил на хакерском форуме «журналы звонков» Трампа и Харрис из AT&T. Не записи разговоров, а кто кому и когда звонил. Были ли они настоящими, так и не подтвердилось. Армейский связист гуглил план побега от американского правительства в американском Google. Это не opsec, это явка с повинной в рассрочку. Как ломали? Никаких zero-day и голливудских сцен. Пароли подбирали перебором по SSH: инструмент для этого Вагениус сам помогал писать. Вся волна Snowflake держалась на украденных учётках к облачным хранилищам, где не было второго фактора. Ни одна из этих компаний не проиграла гениям. Они проиграли перебору паролей и отсутствию MFA. Что делать? Включить второй фактор везде, куда можно войти из интернета. Одна эта мера сорвала бы всю схему.

Совместный проект с Ингосстрахом — финалист премии "За вклад в безопасность цифрового будущего" Наш совместный проект с Ингосстрахом — Кибер-Инго Смарт — стал финалистом в номинации "Лучший проект – сервисы цифрового будущего". Хотим сказать большое спасибо коллегам из Ингоса что поверили в наш общий продукт. Будем делать его еще лучше. А пока — новый AI-SOC на ИИ-агентах активно пилотируется в нескольких компаниях, мы дорабатываем его. Все идет хорошо, посмотрим что получится на выходе. Но в любом случае приятно.

🎃 ИБЭЛЛУИН – костюмированная вечеринка от по ибэ 🦇 Суббота, 31 октября, 20:00 Мы превратили нетворкинг в несложную ролевую игру… 🤩ОХОТА НА ВАМПИРОВ 🩸 Праздник в Пэйпервилле обратился в ужас: ➖вампиры проникли в город, уничтожили книгу города и обращают людей ➖жители помогают провести перепись населения, знакомясь друг с другом ➖стражи пытаются вычислить убийц, пока не стало поздно А еще: пицца, конкурс костюмов и дискотека! 🐬 Алкоголь: свои любимые напитки приносим с собой, но всем, кто придет в костюме - велком-банка пенного 🍻 🎟 Билеты — в боте: @ibtusa_bot (18+) ❗Количество билетов сильно ограничено p.s как мы тусили летом

Вебинар: 5 нетривиальных примеров того, как компании взламывали через C-level Дата проведения: 7 октября 2026 г. | 14:00 (МСК) Формат: онлайн Регистрация: по ссылке 7 октября в 14:00 проведём вебинар о пяти необычных атаках, в которых злоумышленники пошли не через корпоративный периметр, а через руководителей компании. C-level — привлекательная цель: доступ к критичной информации и системам сочетается с личными устройствами, сторонними сервисами, поездками, встречами и коммуникациями вне контролируемой корпоративной среды. И иногда для атаки на компанию вообще не нужно взламывать её серверы. Разберём 5 реальных кейсов: · Умный дом как точка входа — что, если корпоративный периметр злоумышленникам вообще не нужен? · Дипфейк на реальной сделке — насколько опаснее становится дипфейк, когда атакующий знает внутренний контекст? · Коуч для CEO как цепочка поставок — как внешний сервис, не связанный напрямую с IT компании, может оказаться частью атаки? · Девушка из бара — где заканчивается личная жизнь руководителя и начинается информационная безопасность бизнеса? · Игра вдолгую — на что готовы злоумышленники, если цель достаточно ценна, а на подготовку атаки есть целый год? Этот вебинар для вас, если вы хотите разобраться: · Почему защищённого корпоративного периметра может быть недостаточно · Какие точки входа появляются вокруг CEO и других топ-менеджеров · Как личные устройства, сервисы и окружение руководителя связаны с безопасностью компании · Почему классические средства защиты могут не заметить такую атаку · Как учитывать C-level при построении реальной модели угроз На вебинаре покажем, как сегодня могут выглядеть целевые атаки на руководителей и где искать риски, которые обычно остаются за пределами корпоративной информационной безопасности. Регистрация

Как правильно признавать кибератаки Вот тут Додо Пицца сделали совершенно фантастическую по российским меркам вещь. Они просто сказали "да, нас взломали, будем разбираться". Вроде бы так просто, но для нашего рынка это редкая история. Обычно все происходит немножко иначе — сначала пара недель отрицания и сообщений о том, что "сервера погрызли мыши", потом признание компрометации данных, а дальше молчание в надежде, что все забудут. В общем, ребятам огромный респект и уважение. И пожелания разобраться в инциденте как можно быстрее.

Открытый вебинар Архитектура доступа: IAM, ролевые модели, жизненный цикл учётных записей 🗓 29 сентября в 10:00 (МСК) ➡️ Регистрация На занятии разберем: 1) Из чего состоит IAM — Идентичности, роли, ресурсы, политики — и как эти сущности связаны — Где заканчивается «завести учётку» и начинается управление доступом 2) Ролевые модели на практике — RBAC и его границы, наследование прав, межпроектный доступ — Как спроектировать ролевую модель, которая переживёт реорганизацию 3) Жизненный цикл доступа — Приём, перевод, увольнение (joiner-mover-leaver) — Пересертификация прав, владельцы ролей — Как держать модель актуальной силами бизнеса, а ИБ оставить контроль Эксперт: Данила Вайсбург, руководитель направления кибербезопасности в государственной компании Вебинар пройдет в рамках шестого модуля курса «Директор по кибербезопасности 8.0», в котором участники разберут одну из самых быстро меняющихся зон ИБ — управление доступом и идентификацией в эпоху ИИ-агентов. За 6 блоков разберём: IAM → Zero Trust → MFA и passwordless → PAM → машинные идентичности → доступ ИИ-агентов. Финальный результат — модель управления доступом своей компании, которую можно использовать в работе. ➡️ Посмотреть программу 6 модуля Приходите на открытое занятие — и загляните в модуль, который уже совсем скоро станет частью вашей работы с ИБ.

И в продолжение предыдущего поста Сходил я позавчера на прекрасное мероприятие ФРИИ. Хорошая дискуссия, много правильных слов, прекрасные очень умные спикеры. Но вот буквально всем участникам задавали один вопрос: "окей, но чем вы отличаетесь от того, что уже есть на рынке"? Но меня удивило другое. Во-первых, ИИ буквально изменил рынок стартапов во всем мире, и мы тут несколько отстаем, но проблема не в этом. В венчуре есть такое понятие "ров" — это буквально то, что "защищает" вас от появления аналогичного продукта. Грубо говоря это вот буквально то, что мешает завтра школьнику Васе с нейронкой (или команде из энтерпрайза) сделать все то же самое. И вот нейронки этот "ров" основательно размыли — если раньше им была "грамотная команда которая пол-года делала продукт", то сейчас есть огромная вероятность, что пара человек вечерами за месяц сделает что-то подобное. Во-вторых, когда я презентовал 4sec (точнее ИИ SOC на его базе), рассказывая о том, что у нас есть свой SIEM, свой прото-SOAR, куча фишек с хранением данных, сканер на ИИ, элементы анализа траффика и прочее, меня с искреннем удивлением спросили — а что из этого реально работает? Да все работает, иначе я бы этого не презентовал. Баги отловим на пилотах. SIEM в первом приближении — это не радиотелескоп и не таблетка от рака. Это просто некоторая инструментальная вещь, которая закрывает необходимость в определенной функции. Нет "рва" — извините, я знаю примеры, когда человек в соло писал аналог продукта, который стоит на рынке миллионы долларов. Нужен — сделали. Реальная ценность перемещается в JTBD — решение продуктом конкретной бизнесовой задачи. Пройдет 5 лет, и вопрос (за пределами регуляторики) будет стоять так: не "нам нужен NGFW", а "нам нужно отреагировать на атаку за минуту". Не важно как сделать, каким классом продуктов. Важно сделать. Мир меняется, просто разные индустрии видят эти изменения по-своему. И очень хочется, чтобы "ров" между ИБ и финтехом постепенно был размыт и забыт.

Памфилова: «Вся эта киберсволочь не смогла прорваться через нашу мощную защиту». А что такое киберсволочь? Читайте тут → киберсволочь.рф Репост ссылки крайне приветствуется! P.S. Обязательно попытайтесь сообщить о киберсволочи

Кибербез с ИИ и ML Тут один широко известный в узких кругах замечательный ИБ-журналист сказал в общем очень правильную вещь. Что будущие СЗИ — они на стыке ИИ, ML и классической безопасности. Причина простая до неприличий — скорость развития атаки будет сокращаться до минут. Пару лет назад один хороший человек из Тинька сказал про европейский банковский бизнес: "то, что они считают передовыми технологиями, в России считается достойной задачей для умного джуна". И вот сейчас мы здесь. Я сейчас наверное не очень хорошую вещь скажу, что в плане использования ИИ-инструментов и ML ИБ на фоне финсектора выглядит примерно как английский танк Первой мировой на фоне боевого человекоподобного робота. И в плане разнообразия моделей, умения ими управлять, и много чего. Полноценный фреймворк по управлению моделями, например, я увидел еще в 2015 году. Про ИИ-разработку как отдельный навык (это когда ИИ использует профи) я просто молчу. Мы на 4sec это в общем хорошо увидели. Современный ИИ+ML в виде "слоеного пирога" — это вот буквально оркестрация десятков моделей с возможностью "на лету" их мониторить, калибровать, дообучать, работать с отдельными массивами данных, "переключаться" между моделями и многое другое. То, что к этому прикручен кастомный SIEM/SOAR — дело десятое, будущая ценность совсем не в этом. И собственно мы много говорим про "агентную безопасность" но забываем какой огромный пласт обработки данных за этим лежит. А все самое ценное — там.

Про киберстраховки и кому их продавать ИБ-страхование в России вообще интересный зверь. Продукт финансовый, но прямо завязанный на ИБ. И вот тут возникает совершенно волшебный дуализм: продавать его CISO напрямую как правило неэффективно, но любая покупка рано или поздно на CISO упадет. И вот тут вообще самая главная проблема этого рынка в России: бизнесу оно может быть и нужно, но лично CISO как правило нет. Потому что у него задача — в первую очередь не допустить ущерб, потому что если будет проблема, крайним будет он. Ну или он и вендор, тут ведь как. После чего возникает главный конфликт интересов: страховаться из ИБ-бюджета CISO очень не хочется. Страховаться из иного бюджета — вроде как не логично, вопрос то чисто ИБшный. Так и живем. Собственно, 4sec вместе с Ингосстрахом мы собирали именно в формате "страховка+СЗИ" в том числе чтобы эту проблему решить. К слову, самым перспективным "покупателем" киберстрахования в перспективе выглядит именно CRO. Но здесь другая очевидная проблема: вспомните, в каком количестве компаний эта роль вообще есть.

Не Скайнет, а зомби Нам активно продают восстание машин. А будет зомби-апокалипсис на стероидах. Хайп вокруг «ИИ-атак» выгоден прежде всего тем, кто продаёт ИИ: страх перед сверхразумным хакером хорошо превращается в бюджеты. Но нейросеть, которая ломает лучше сильного профессионала, в обозримом будущем вряд ли появится. Будет страшно, но по-другому. Первое — количество атак. Порог входа падает до нуля: уровень хактивиста теперь равен уровню инструмента, который он смог достать. Это и есть зомби. По отдельности слабые, но их много, они не устают и перебирают каждый открытый сервис. Второе, и главное, — скорость. APT вряд ли станут атаковать сильно качественнее, но станут атаковать быстрее. Нули появляются чаще (CopyFail и Fragnesia, предположительно, найдены с помощью ИИ), наружу торчит всё больше сервисов, а окно реагирования сжимается до сроков, в которые человеческий процесс не помещается. Типовой ответ CISO — укрепить существующее, расширить эшелонирование, докупить ИИ-продукты. Разумно, но это всё про стену на периметре. А за стеной часто пусто: по нашему опыту, подавляющее большинство пентестов внутренней инфраструктуры успешны и заканчиваются доступом к критичным системам. При этом, как признаёт даже CrowdStrike, пост-эксплуатация почти не меняется: атакующему всё равно нужно двигаться внутри сети и оставлять следы. Вопрос лишь в том, успеет ли защита их заметить. Итог: атакующая безопасность останется прежней, вырастет только интенсивность. Меняться придётся «синим»: реагировать внутри периметра со скоростью атаки, считать время в минутах, а не в сменах. Человеческий SOC такой темп не держит. Под эту модель угроз мы и строим 4sec — AI SOC, ИИ-команду безопасности. Восстания машин не будет. Будет гонка скоростей.

Безопасники шутят)) Настоящий безопасник не будет вам рассказывать, как происходит эксплуатация уязвимостей. Он просто наглядно вам продемонстрирует ... УДАЛЕННО. Почему, догадаетесь? На скриншоте черным по бело-зеленому: 272 УК РФ, ч.1, до 2 лет — база. Статья рабочая (не такая рабочая как 159-я "народная", но тоже). Ч.2 подтянуть сильно сложнее, но можно. 273 УК РФ — опционально по используемому инструментарию, сложная. 137/138 УК РФ — за домашний компьютер, сложная. А потом вы будете долго и нудно объяснять, что он просто пошутил, а не

... осуществил неправомерный доступ к охраняемой законом компьютерной информации, содержащейся на средствах вычислительной техники, повлёкший её копирование и модификацию, при отсутствии законных оснований и в нарушение установленного порядка доступа ...

Мы на каждый чих берем LOA, не работаем до подписания документов (однажды стартовали через 10 секунд после подписи) и прочее — не потому, что мы такие зануды. А потому, что в индустрии люди не очень хотят поднимать с пола статью. И то ведь безобидную шутку в НКЦКИ зарепортят и вперед) Кстати, в США это тоже прямое нарушение федерального закона. Такие занудные дела.