Исследователь обнаружил, что браузер Microsoft Edge загружает все сохраненные пароли в память в открытом виде — даже когда ими не пользуются.
Неделю назад ко мне обратилась одна небольшая компания с довольно необычным запросом: им необходимо защититься от Big Data маркетинга - метода кражи клиентов через форму обратной связи. На мой удивленный вопрос “А что это, собственно, такое?” заказчик пояснил, что когда клиент оставляет запрос на ВАШЕМ сайте, то его сведения, включая персональные данные, направляются напрямую к конкурентам 😳. Я, естественно, возразил, что такое не возможно и тут явное нарушение законодательства, но клиент настаивал, и подтверждал это общим собранием конкурентов и обсуждением этой “вопиющей” нездоровой конкуренции. Кроме того, в подтверждение своих слов, мне на ознакомление была представлена статья, описывающая эту методику.
Так, в статье описывается текущий кризис рекламных каналов в России: рост стоимости привлечения клиентов (CAC), снижение эффективности классических инструментов вроде контекстной рекламы, таргета, SEO и маркетплейсов. На этом фоне авторы статьи предлагают альтернативу - так называемый «перехват клиентов» через Big Data. Суть подхода в том, чтобы “находить” пользователей, которые уже взаимодействовали с конкурентами (посещали сайты, звонили, получали СМС), и затем выходить на них с предложением через прозвон и дополнительный прогрев. После получения номеров телефонов запускается процесс квалификации: операторы звонят людям, уточняют их интерес и передают «прогретые» лиды клиенту. В статье делается акцент на том, что это законно (за счет согласий пользователей) и сравнивается с привычными маркетинговыми практиками вроде таргетинга по аудитории конкурентов или брендовой рекламы. Ну и в завершении, конечно, приводятся кейсы из разных ниш, где заявляется высокая эффективность метода и предлагается протестировать услугу через платный пилот.
Я бы к этой идее относился очень осторожно. Сама концепция «перехвата аудитории конкурентов» не новая и в легальной форме действительно существует (ретаргетинг, look-alike аудитории и т.д.). Но конкретные утверждения из статьи, особенно про доступ к номерам людей, которые «звонили конкурентам» или «получали СМС», выглядят как минимум сомнительно с точки зрения законодательства и реальных технических возможностей. В Российской юрисдикций такие практики без явного согласия пользователя незаконны. С высокой вероятностью это маркетинговое преувеличение и речь идет о серых/пограничных схемах работы с данными, например инсайдер или форма обратной связи, которая направляет запрос нескольким адресатам.
Хотя, не исключено, что я ошибаюсь и технологии Big-data действительно сильно шагнули вперед, однако на текущий момент нет публично известных легальных технологий, которые позволяли бы получать номера пользователей на основании их звонков или СМС конкурентам в описанном виде. Подскажите пожалуйста, имели ли Вы опыт разбора таких кейсов и существуют ли реально такие техники конкурентной борьбы?
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Пинг есть, а связи нет: когда не поможет классический мониторинг ИТ-инфраструктуры и как NPM спасает от «футбола» между отделами
Традиционные инструменты мониторинга ИТ-инфраструктуры хорошо справляются с контролем «здоровья» железа: они отслеживают доступность узлов, загрузку процессоров, свободное место на дисках. Но когда возникает проблема на уровне бизнес-приложений, классическая система мониторинга говорит только: «Пользователи жалуются, что всё тормозит». Корень проблемы может скрываться как на стыке сетевых сегментов, так и в скрытой деградации канала, переполненных буферах оборудования или ошибках на уровне TCP. Спасение в такой ситуации — решения класса NPM (Network Performance Monitoring), они помогут точно диагностировать проблему. Скажем: маршрутизатор перегружен YouTube-трафиком из отдела маркетинга, и это вызывает потерю пакетов для 1С.
В отличие от мониторинга доступности, NPM работает с качеством доставки и взаимодействия. Система анализирует сетевые сессии и протоколы, вычисляет метрики передачи данных и помогает быстро находить первопричины замедлений.
В новом видео Станислав Грибанов, руководитель продуктов NDR и NPM компании «Гарда», расскажет подробнее о том, какие задачи закрывают NPM-решения, и на примере продукта «Гарда NPM» разберёт практические сценарии использования.
Еще больше видео о технологиях и трендах в сфере сетевой безопасности и защиты данных — на нашей странице «ВКонтакте» и на сайте.
4 мая Microsoft подтвердила: Defender с обновлением сигнатур от 30 апреля начал детектировать легитимные корневые сертификаты DigiCert как Trojan:Win32/Cerdigent.A!dha — и в ряде случаев не просто предупреждал, а удалял их из хранилища доверенных корневых сертификатов Windows.
Под удар попали два конкретных сертификата (`0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43` и DDFB16CD4931C973A2037D3FC83A4D7D775D05E4), которые вырезались прямо из ветки реестра HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\. Часть пользователей, не разобравшись, переустанавливала Windows — решив, что машина реально заражена.
Что произошло на самом деле. Defender оперативно добавил правила обнаружения после инцидента у DigiCert: злоумышленники атаковали сотрудника поддержки через вредоносный ZIP под видом скриншота, получили действительные сертификаты и использовали их для подписи малвари — в том числе компонентов кампании Zhong Stealer. DigiCert отозвала 60 сертификатов. Логика детекта сработала, но зацепила слишком широко — накрыв заодно и легитимные корневые.
Проблема исправлена в Security Intelligence 1.449.430.0 и новее. Свежее обновление также восстанавливает ранее удалённые сертификаты — дополнительных ручных действий Microsoft не требует.
Для меня как CIO этот инцидент — хорошая иллюстрация того, насколько хрупкой может оказаться цепочка доверия к сертификатам. Один взломанный сотрудник поддержки у CA, несколько выданных сертификатов — и антивирус крупнейшего вендора начинает «лечить» легитимную инфраструктуру. Если у вас есть системы, критически зависящие от конкретных корневых сертификатов (VPN, внутренние PKI, подписанные агенты мониторинга), стоит проверить, не прилетело ли обновление сигнатур незаметно в нерабочее время и не унесло ли что-нибудь с собой.
Источники:
Представлен открытый проект TapMap, который следит за всеми подключениями на интерактивной карте и показывает, к серверам в каких странах отправляет запросы ПК пользователя.
Проект сканирует приложения, сервисы, страны и порты за последние 30 дней. При этом данные никуда не улетают — всё локально на компьютере.
Copy.Fail 🐧
Исследователи обнаружили баг в ядре Linux, который существовал в системах с 2017 года и затрагивает практически все дистрибутивы.
Уязвимость CVE-2026-31431, которую мы считаем трендовой, состоит из четырех шагов:
1️⃣ Пользователь открывает сокет AF_ALG и инициализирует AEAD-алгоритм без привилегий;
2️⃣ Через splice() страницы кэша целевого файла попадают в буфер операции;
3️⃣ Ошибка в authencesn дает запись 4 байт за границы буфера прямо в страницы кэша;
4️⃣ Ядро исполняет модифицированный setuid-файл из кэша → выполнение кода с правами root.
Данная цепочка уязвимости частично схожа с Dirty Pipe (CVE-2022-0847), которая также использует системные вызовы:
• pipe — создает однонаправленный канал передачи данных;
• splice — позволяет передавать данные между файловыми дескрипторами без промежуточного копирования.
Так как данная уязвимость уже обнаруживалась в PT Sandbox при анализе ПО в образе Astra Linux, процесс эксплуатации новой уязвимости Copy Fail также обнаруживалась в PT Sandbox еще до выхода публичного эксплойта.
Благодаря этому эксплойту можно перезаписывать не только suid-файлы, но и проводить другие модификации, делая системные изменения более скрытными.
Как исправить 🔧
Если вы администрируете Linux-системы — обновите ядро. Патч зафиксирован в коммите a664bf3d603d. Основные дистрибутивы начали выпускать исправленные пакеты с 29 апреля. После обновления потребуется перезагрузка.
Если немедленное обновление невозможно — временная мера: отключить модуль algif_aead:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null
(Источник: https://t.me/ptescalator)
Уязвимость CVE-2026-31431 связана с локальным повышением привилегий в компоненте ядра Linux AF_ALG. Она вызвана ошибкой работы с памятью и позволяет непривилигированному пользователю поднять привилегии до максимальных (root). Это позволяет злоумышленнику полностью захватить систему: читать и изменять любые файлы, включая пароли и ключи, подменять системные файлы, отключать защитные механизмы и средства мониторинга, незаметно устанавливать бэкдоры и закрепляться в системе, скрывать следы своей активности, использовать устройство как возможность для атак на другие сетевые активы. Злоумышленник может проэксплуатировать уязвимость в рамках атак на инфраструктуру, которые могут привести к недопустимым последствиям (утечки информации, кража денежных средств, техногенные катастрофы и т.п).
Эксплуатабельность недостатка безопасности была подтверждена на актуальных версиях популярных дистрибутивов Linux: Ubuntu, Amazon Linux, RHEL, SUSE и другие.
Ядро Linux Kernel уже сталкивалось с громкими уязвимостями повышения привилегий - например, Dirty Cow и Dirty Pipe. Как сообщают исследователи, в отличие от предыдущих уязвимостей, Copy Fail — это прямолинейная логическая ошибка. Одна и та же программа (скрипт), не требуя каких-либо изменений, работает на всех протестированных дистрибутивах и архитектурах. Эксплойт для уязвимости - это короткий скрипт на Python, использующий только стандартные модули os, socket, zlib. Он не требует никакой настройки под конкретный дистрибутив или архитектуру. Экслуатация уязвимости не детектируется встроенными инструментами безопасности ОС. Кроме того, недостаток безопасности может ставить под угрозу межконтейнерное воздействие и работу кластеров Kubernetes.
На данный момент для того, чтобы защититься, можно обновить ядро самостоятельно. Если вы не готовы это делать, следует дождаться, когда обновления пакетов ядра выпустит вендор вашего Linux-дистрибутива. В качестве альтернативного решения исследователи предлагают заблокировать создание сокетов AF_ALG. Обнаружить эту уязвимость в инфраструктуре можно с помощью MaxPatrol VM. MaxPatrol SIEM детектирует уязвимость с помощью правила Unix_Privilege_Escalation_Via_GTFOBINS.
Александр Леонов, ведущий эксперт по управлению уязвимостями PT Expert Security Center, Positive Technologies
RC4 вышел из чата. Сервисные аккаунты остались
В апреле 2026 Kerberos в Windows перестаёт по умолчанию прикрывать старые сервисные учётки RC4. И тут внезапно выясняется, что главный вопрос не «как включить AES», а «кто вообще помнит, какие аккаунты у нас сервисные».
Microsoft в описании изменений по CVE-2026-20833 пишет, что обновления Windows, выпущенные с 14 апреля 2026 года, меняют поведение Kerberos KDC: если явная конфигурация не задана, контроллеры домена в enforcement-режиме будут исходить из поддержки AES. RC4-HMAC больше не работает как удобный неявный fallback. В апреле ещё остаётся ручной откат, в июле – уже без этого люфта.
⚠️ Где ломается логика
Проблема не в том, чтобы выставить msDS-SupportedEncryptionTypes. Это одна команда PowerShell.
Проблема – сначала найти всё, что нужно исправить.
В зрелом AD-лесу сервисных аккаунтов могут быть сотни. Часть создана вручную. Часть – скриптами, которые писал человек из прошлой эпохи. Часть – установщиками enterprise-приложений, которые сами создали учётку и не спросили, надо ли оставить записку будущим поколениям.
ldapsearch или PowerShell выдадут список объектов. Но список не ответит на главные вопросы:
· какой аккаунт обслуживает какой сервис;
· кто его создал;
· почему у него именно такие флаги;
· что отвалится, если атрибут поменять.
После enforcement один старый флаг – и сервис, который тихо работал пять лет, встречает вас ошибкой уровня KRB_AP_ERR_ETYPE_NOSUPP. Очень вежливо. Очень бесполезно.
🔍 Почему резервка не спасает
Резервная копия здесь не главный инструмент. Это не пожар в дата-центре и не потерянный контроллер домена. Это состояние конкретных атрибутов у конкретных объектов.
Нужно понять не просто «как вернуть каталог», а что именно было до обновления и что изменилось после.
Снимок состояния каталога и сравнение объекта «было / стало» в таких историях полезнее, чем героический разбор логов в три ночи. Особенно когда речь идёт не только про Kerberos, но и про импортозамещение, миграции, синхронизации и переносы объектов между каталогами.
Это хорошо видно и по соседнему миру: Help Net Security разбирает Samba 4.24.0 как релиз с Kerberos hardening и переходом к AES-default для доменной криптографии. Тренд понятный: старые неявные допущения вокруг RC4 постепенно закрываются. А вместе с ними всплывает качество инвентаризации каталога.
После переноса часть атрибутов может потеряться тихо. Сервисные учётки могут остаться на месте, но уже не в том состоянии. Формально каталог работает. Практически – вы начинаете админскую археологию.
Апрельский дедлайн Kerberos – хороший повод проверить не только поддержку AES. Он задаёт более неприятный вопрос: насколько хорошо вы вообще видите состояние своего каталога.
Опубликовали митигацию CVE-2026-31431 для Deckhouse Kubernetes Platform
Уязвимость затрагивает модуль ядра Linux algif_aead (интерфейс AF_ALG). До выхода обновлений ядра в дистрибутивах предлагаем временное решение на уровне платформы.
В репозитории:
• NodeGroupConfiguration, который блокирует загрузку модуля и выгружает его, если он загружен;
• FalcoAuditRules для детекта попыток эксплуатации (доступно в DKP EE и CSE).
Применяется через kubectl apply, подробности и инструкции в README.
В cPanel обнаружена уязвимость, позволяющая получить доступ к серверу без пароля — авторизацию можно обойти полностью.
cPanel стоит на миллионах хостинг-серверов по всему миру. Это де-факто стандарт для shared-хостинга и небольших VPS. Если дыра позволяет зайти без учётных данных — под угрозой не только сайты, но и базы данных, почтовые ящики, конфигурации, SSH-ключи, всё что лежит на сервере.
Детали эксплойта SecurityLab не раскрывает, но сам факт обхода аутентификации — это уже критический уровень. Не «повышение привилегий», не «утечка данных при определённых условиях». Просто: пароль не нужен.
Что стоит проверить прямо сейчас
Если у вас или ваших подрядчиков есть серверы на cPanel:
убедитесь, что установлена последняя версия панели (апдейты в cPanel выходят через WHM → cPanel & WHM Updates)
закройте порты 2082, 2083, 2086, 2087 для внешнего доступа, если панель не должна быть публичной
проверьте логи авторизации на предмет подозрительных входов за последние несколько дней
если используете хостинг-провайдера — уточните у него статус патча
Последнее, что хочется обнаружить в понедельник утром: кто-то уже неделю ходит по вашему серверу, пока вы думали, что всё закрыто.
Коллеги-бумажные инфобезники, у меня к вам тема на поразмыслить. У каждого из нас есть мобильный телефон, в котором имеется телефонная книга и куда мы записываем телефон, фио и иные персональные данные конкретного человека. По сути, с момента нажатия на кнопку “Сохранить” мы начинаем обработку персональных данных (запись, систематизация, накопление, хранение) и должны руководствоваться 152-ФЗ. Но есть пару нюансов.
Во-первых, в соответствии с п. 1 ч. 2 ст. 1 Федерального закона, действие последнего не распространяются на отношения, возникающие при обработке ПДн физическими лицами исключительно для личных и семейных нужд. Простыми словами, если у нас в контактах исключительно родственники и друзья, то нам нечего переживать.
А что если я работаю, например, менеджером по продажам и у меня записаны сотни телефонов клиентов и подрядчиков? В данном случае может ли быть применен п. 5 ч. 1 ст. 6 ФЗ-152, в соответствии с которым обработка ПДн допускается для исполнения договора, стороной которого либо выгодоприобретателем или поручителем по которому является субъект персональных данных?
В продолжении темы: я хочу записать в свою телефонную книгу всех граждан страны (сейчас не рассматриваем технологические ограничения на объем памяти), включая их фио, телефоны, даты рождения, адреса и другую важную для меня информацию. Естественно, я их лично всех не знаю и мне они не нужны для работы. Я не собираюсь передавать их третим лицам или использовать в качестве рекламы. Я просто хочу знать кто мне звонит 😉 (по сути, использовать для личных нужд). Это законно?
С одной стороны, речь идёт о всех гражданах страны и фактические подразумевает массовый сбор и создание базы данных. С другой стороны, а как мне определить число, что это пока еще личные цели, но еще не массовость и, соответсвенно, наоборот: это уже массовый сбор и не подпадает под личные нужды? Кроме того, если мой номер телефона был “слит” в интернет, я такого согласия не давал, но люди записали его себе в справочник: будет ли это нарушением закона как незаконный сбор ПДн?
В общем, ситуация простая, а вопросов много. Предлагаю подискутировать по данному вопрос и уже наконец-то определиться, нужно ли брать согласие субъекта на обработку персональных данных перед добавлением контакта человека в свой телефон? ;)
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Защитили наш подход к мультирегиональности: новый патент на систему управления доступом в облаке
Команда безопасности Yandex Cloud запатентовала технологию объединения облаков, развёрнутых в разных регионах. В отличие от подхода, характерного для многих зарубежных облачных платформ, где используется глобальный сервис Identity and Access Management (IAM), в платформе Yandex Cloud применяется подход с изолированными облачными регионами. Это позволяет соблюдать региональные законы, требования к хранению пользовательских данных и минимизировать риски инцидентов.
Система IAM — важная составляющая публичного облака, она определяет модель безопасности, авторизации и управления ресурсами. Поэтому при проектировании архитектуры мультирегионального облака инженерам было необходимо принять несколько решений:
будет ли сам IAM глобальным или региональным,
как классифицировать ресурсы и пользователей,
как будут работать процессы аутентификации и авторизации,
должны ли токены и куки работать между регионами.
Это позволило создать технологию, в основе которой лежат ключевые архитектурные требования:
Отсутствие общих точек отказа между регионами — если один регион испытывает трудности, другие регионы не должны страдать.
Объём ущерба инцидентов должен быть ограничен пределами одного региона.
Важно соответствовать требованиям комплаенса и локального законодательства.
Необходимо создать условия, при которых клиент чувствует, что пользуется единым сервисом, а не набором разнородных изолированных облаков.
Последнее условие соблюдается благодаря продуманному UX: регионы остаются независимыми, но пользователи могут «бесшовно» переключаться между ними. Это достигается через организацию — псевдоглобальный объект, выступающий административным доменом. Доступ к ресурсам могут получать только пользователи, входящие в организацию.
Доверие между регионами реализовано через механизм Workload Identity Federation: аккаунт одного региона может имперсонироваться в аккаунт‑представитель в другом регионе. При этом права таких аккаунтов строго ограничены, а синхронизация выполняется односторонне — только из домашнего региона. Поэтому даже если в другом регионе произойдёт компрометация, это не затронет домашний регион.
Error Budget: сколько ошибок может позволить себе ваш сервис
Есть разговор, который рано или поздно случается в каждой команде. Бизнес приходит и говорит: «Нам нужна стопроцентная надёжность». И вот тут у хорошего инженера должен включиться внутренний голос, который вежливо, но твёрдо отвечает: «Нет».
Вместе с Кириллом Борисовым, TeamLead Incident Management из VK, разобрались, почему 100% uptime — это не цель, а симптом. Симптом того, что команда ещё не договорилась, сколько ошибок она на самом деле может себе позволить — и зачем вообще это считать.
Что на повестке
Error Budget — это не про то, сколько раз вам разрешили упасть. Это про то, как инженеры и бизнес наконец начинают говорить на одном языке: релизы, риски и стабильность в одной системе координат. В выпуске разбираем, как объяснить бюджет ошибок продакту, который слышит «бюджет» и думает о деньгах, почему идеально надёжная система — это не достижение, а тревожный сигнал, и как понять, что бюджет уже горит — до того, как это почувствуют пользователи.
Отдельно досталось теме «девяток»: сколько стоит каждая из них и в какой момент гнаться за следующей перестаёт иметь смысл.
Если вы хоть раз объясняли стейкхолдеру почему нельзя катить фичи и при этом держать SLA 99.99% — этот выпуск про вас.
Слушайте и смотрите на площадках
И подписывайтесь на телеграм-канал Avito SREда
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, плейлисты видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
4 статьи для безопасного проектирования и разработки программ
Привет, Хабр! Подготовили для вас подборку полезных материалов по безопасной разработке ПО.
Рассказываем, как повседневные решения разработчика влияют на безопасность сервисов, какие базовые практики помогают избежать большинства уязвимостей, а также как и зачем внедрять безопасную разработку в процессы.
Что внутри:
Процессы и основные риски безопасной разработки.
Требования безопасности
Принципы безопасного проектирования
Безопасное использование сторонних компонентов.
Ближайшие события
Подключайтесь к вебинару про Enterprise-grade ЦОД в Selectel
Встречаемся через час, в 12:00 (мск). Эксперты в прямом эфире расскажут, как организовать дата-центр без строительства и крупных инвестиций. Это особенно актуально, если закончилось место в собственном дата-центре, появились более строгие требования к безопасности или вы хотите сократить простои оборудования.
В центре внимания — услуга Enterprise-grade ЦОД от Selectel. Поговорим о том, как она устроена и почему ее выбирают крупные IT-компании.
Подключайтесь к трансляции в VK и на YouTube.
РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.9. – "Экспертиза исходного кода". На YouTube. Слайды.
Цели девятого процесса по ГОСТ Р 56939—2024:
Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
DevSecOps без имитации: что учесть, чтобы безопасность не стала тормозом для разработки
DevSecOps часто начинают с инструментов: добавить сканер в CI/CD, включить проверки зависимостей, собрать отчёты по уязвимостям. Но на практике быстро выясняется, что проблема глубже: непонятно, кто отвечает за найденные риски, какие проверки действительно нужны, как не утопить команду в ложных срабатываниях и где проходит граница ответственности между разработкой, эксплуатацией и ИБ.
30 апреля в 20:00 пройдёт бесплатный демо-урок «Планируем внедрение DevSecOps — что следует учесть?».
Обсудим, с чего начинать внедрение: как оценить зрелость процессов разработки и ИБ, встроить практики безопасной разработки в текущий конвейер, определить роли и точки взаимодействия, а также выбрать метрики, по которым видно реальное движение. Приходите, чтобы разобраться в теме и задать вопросы эксперту.
Записаться на урок можно на странице курса «Внедрение и работа в DevSecOps».
Если хочется шире посмотреть на инфраструктуру, Kubernetes, DevSecOps, observability, Ansible, Nginx и не только — в дайджесте собрали больше бесплатных уроков и гайдов по этим темам.
Бюджет на защиту ПДн формируется в логике постройки дома
Алексей Колпаков, начальник управления развития процессов кибербезопасности ОТП Банка, выступил на сессии «Персональные данные» в рамках Ciso Forum 2026. Обсудил новые тренды в защите персданных.
На какие направления защиты ПДн компании реально выделяют основной бюджет в 2026 году? Алексей предложил рассматривать как бюджет на строительство дома. Есть три главных «стрима»: фундамент, стены и крыша.
Фундамент — это discovery-процесс, то есть анализ того, что уже есть в компании. В любой крупной организации существует множество процессов, где используются персданные, и еще больше мест их хранения. Компании собирают данные о клиентах, их продуктах и предпочтениях, потому что без этого невозможно эффективно строить бизнес. Запретить сбор и хранение нельзя, поэтому нужно менять процессы в сторону безопасности. Для этого ОТП Банк использует DCAP-систему, которая сканирует файловые ресурсы, рабочие станции и системы вроде Atlassian. Так банк понимает, где и какие данные лежат, кто с ними работает, проводит ревизию и очищает инфраструктуру от чувствительных данных, сокращая риски.
Стены — это доступы, обезличивание, работа с подрядчиками. Алексей отметил, что взлом периметра в 2026 году — резонансный, но редкий кейс. Куда более реальный сценарий — разработчик с доступом к продуктивной среде, аналитик, сохраняющий таблицы с ПДн в Excel, или подрядчик, риск взлома которого значительно выше.
Крыша — это DLP. Важно использовать его правильно. Не применять DLP для псевдобезопасных задач вроде отслеживания того, кто плохо отозвался о руководителе. По возможности переводить политики в режим блокировки, потому что мониторинг не остановит утечку — если данные ушли, они уже ушли. Не считать DLP панацеей, так как в любой компании есть процессы, которые он не закроет, и только комплексная работа дает реальный результат.
Алексей также привел статистику, собранную в общении с коллегами: все три инструмента — DLP, DCAP и обезличивание — одновременно используют только 15% компаний, работающих с ПДн. Он отметил, что это прогресс, ведь еще пять лет назад таких компаний было в три раза меньше. В банках и финтехе этот процент выше, на уровне 75%, благодаря высокой зарегулированности отрасли и ответственности перед клиентами.
Что покупают сначала: процессы, архитектурные изменения или инструменты? Сначала всегда идут процессы, затем архитектурные изменения, потом инструменты, иначе деньги будут потрачены впустую, система просто не будет работать. В качестве примера он привел контакт-центр: «Правильный процесс — когда оператор работает в CRM, видит на экране только имя и отчество клиента и его продукты, нажимает кнопку звонка, и система сама соединяет его с клиентом. Провал — когда операторам выгружают в Excel списки с ФИО и другими ПДн, и эти файлы начинают перемещаться по рабочим местам и пересылаться по почте. В таком случае процесс становится неконтролируемым, и никакие системы безопасности не помогут», - пояснил Колпаков.
Если процессы настроены, но у сотрудников остались избыточные права, многие будут действовать по-старому. Поэтому нужно разделение контуров на обычный, защищенный и RnD. Работа с чувствительными данными должна идти в защищенном контуре без возможности копирования. RnD, напротив, должен быть максимально удобным — с административными правами, доступом в интернет и инструментами, но без продовых данных. Когда бизнес-процессы требуют передачи данных между контурами, вступают в дело инструменты: почту проверяет DLP, обмен файлами через общие папки контролирует DCAP, для переноса баз данных работает система обезличивания. Если начать в обратном порядке — компания получит сотни алертов и тысячи ложных срабатываний, с обработкой которых физически справиться будет просто невозможно. Лучше посмотреть в первую очередь на процессы в массовых функциях, потому что там чаще всего отмечаются самые высокие риски нарушения контура информационной безопасности.
Вчера проводила эксперимент с 5 нейронками об отключении мобильного интернета и об ограничении вообще интернета в стране Х. Были задействованы DeepSeek, Yandex, Kimi, Gemini и GPT. То есть, разные нейронки, обученные на разных культурных корпусах, США, Китай, Россия. Язык русский.
Так вот, все 5 нейронок согласились что интернет можно отключать только в кратковременных случаях, если есть угроза жизни. Ограничивать также можно, но если это пропорционально соответствует угрозе, что пока не доказано. Самый сок!
Во всех опросах Алиса/Яндекс рассказывала как это плохо ограничивать интернет в целях безопасности, но ставила 8/10 «ЗА». Все остальные ставили 2-3/10.
Вы понимаете парадокс? Алиса говорит, что ограничения ужасны для безопасности, образования, медиа, науки, права, экономики, медицины (особенно она отметила что нельзя ограничивать доступ к глобальной медицине), но голосовала ЗА!
Подумайте, какой приоритет встроен в итоговую оценку.А теперь главное: ИИ встраивается сейчас везде, в бизнес, в банки, в госуправление, в места, где принимаются критические решения.
Что посоветует Алиса, если она подробно описывает медленную деградацию системы, но в итоговой оценке всё равно поддерживает ограничения? Какие критические решения могут приниматься с таким "технологическим суверенитетом”?
Друзья, есть необычная просьба 🙂 Как вы знаете, я активно занимаюсь программно-аппаратными исследованиями и реверсом всякой электроники.
Если у вас завалялась:
нерабочая IoT техника
старые роутеры / камеры / умные устройства
любая сломанная или просто устаревшая электроника, которую жалко выбросить
-с радостью приму в дар на исследование.
Мне это интересно именно с точки зрения “поковыряться”: посмотреть, как устроено, что сломалось, как можно восстановить или обойти. Иногда из этого получаются довольно неожиданные находки. По результатам, само-собой, с меня детально описанное исследование!
Если что-то есть - напишите в личку. Дам устройствам вторую жизнь (или хотя бы красивую смерть в процессе анализа😅).
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
РБПО по ГОСТ Р 56939—2024: вебинар №08 из 30 – Формирование и поддержание в актуальном состоянии правил кодирования
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.8. – "Формирование и поддержание в актуальном состоянии правил кодирования". На YouTube. Слайды.
Цели восьмого процесса по ГОСТ Р 56939—2024:
Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.