Kept | Cyber

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

Стратегия ИБ начинается со сбора информации:
• цели и планы развития компании (например, новые продукты и рынки, каналы взаимодействия, сделки и т.д.);
• ключевые бизнес-процессы и поддерживающие их системы, допустимое время простоя, владельцы;
• результаты оценки рисков ИБ и статистика инцидентов за предыдущие периоды;
• текущее состояние функции ИБ (процессы, организационная структура, численность, бюджет, используемые средства защиты и их покрытие);
• результаты аудитов, тестирований на проникновение, проверок регуляторов;
• применимые требования законодательства, отраслевых стандартов и договорные обязательства перед клиентами и партнерами;
• ИТ-стратегия и планы развития инфраструктуры;
• актуальные угрозы безопасности информации;
• ограничения (бюджетные, кадровые, технологические, сроки закупочных процедур и т. д.).

Далее на основании наиболее существенных выявленных рисков по формализованной методологии и критериям оценивается способность текущего состояния противостоять этим рискам. Затем на основании результатов такой оценки и сформулированных глобальных целей информационной безопасности (миссия функции ИБ) формируется целевое состояние. Разница между этими состояниями трансформируется в проекты и мероприятия, для каждого из них определяются закрываемый разрыв, снижаемый риск, ожидаемый эффект, стоимость, ресурсы и зависимости, который в совокупности составляют дорожную карту (маршрут) реализации стратегии.

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

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

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

#Викторины

CISO & DPO news #143 (25 сентября – 1 октября)
 
▫️ Минцифры опубликовало ключевые инициативы Антифрод 3.0
Среди основных предложений третьего пакета мер против мошенников — создать единую платформу согласий на «Госуслугах» и сформировать базу людей, которые предоставляют аферистам абонентские номера и данные в информсистемах. Кроме того, СМС-рассылки смогут осуществлять только операторы связи, что снизит число нарушений законодательства, в том числе в сфере рекламы. Еще одно дополнение касается распространения сим-карт: их смогут продавать только прямые дилеры — компании с агентским договором с оператором.

▫️ «Красная кнопка» защитит от мошенников на портале «Госуслуг»
Сервис поможет заморозить значимые операции, например перевод денег или смену пароля, если пользователь поймет, что стал жертвой злоумышленника. «Красная кнопка» должна заработать уже в 2026 г. — сейчас к проекту подключаются банки и операторы связи.

▫️ Утечка в Пентагоне: хакеры похитили данные 2,7 млн действующих и бывших сотрудников
Злоумышленники получили доступ к незашифрованному серверу Центра кадровых данных Министерства обороны США еще в октябре прошлого года, однако инцидент обнаружили и устранили только спустя девять месяцев. Утечка затронула номера соцстрахования и личные данные гражданского персонала и военнослужащих. Пентагон пока не зафиксировал фактов неправомерного использования данных, но эксперты предупреждают, что информация представляет огромную ценность для иностранных разведок и киберпреступников.

▫️ DDoS-атаки превратились в массовый онлайн-сервис
Специализированные площадки позволяют запускать атаки без каких-либо технических знаний и конкурируют между собой ценой, мощностью ботнетов, стабильностью и методами обхода защиты. Только за первое полугодие 2026 г. в мире зафиксировано 9,1 млн атак, количество инцидентов мощностью свыше 1 Тбит/с выросло на 1286% год к году.

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

▫️ Киберпреступники сместили фокус атак с госсектора на частные компании
Главными мишенями стали микрофинансовые организации и малый бизнес — на МСП пришлось 83% всего объема скомпрометированной информации.  Среди причин уязвимости — ограниченные бюджеты на информационную безопасность и недостаточно выстроенная защита данных. Доля государственных организаций, напротив, упала с 52% в 2025 г. до 4% в первом полугодии 2026 г. Количество зафиксированных Роскомнадзором утечек снизилось до 12 случаев, но объем похищенных данных вырос на 31% — до 378,4 млн строк. 

Что представляет собой горизонтальное/боковое перемещение (Lateral Movement) в рамках пентеста и как минимизировать риски его реализации?

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

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

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

Ключевые риски и факторы, способствующие развитию атаки:
🔸 Переиспользование учетных данных: наличие одинаковых паролей на рабочих станциях позволяет захватывать соседние узлы без эксплуатации уязвимостей.
🔸 Плоская топология сети: отсутствие сетевой изоляции между сегментами и прямых ограничений на взаимодействие между рабочими станциями дает возможность беспрепятственно продвигаться к критичным системам и атаковать смежные узлы.
🔸 Избыточные привилегии и сессии администраторов: некорректное делегирование прав в Active Directory и присутствие активных сессий привилегированных пользователей на обычных ПК создают короткие цепочки для эскалации прав до уровня предприятия.
🔸 Использование устаревших протоколов: включенные по умолчанию механизмы сетевого разрешения имен (LLMNR, NBT-NS) и протоколы аутентификации (NTLM) позволяют специалистам реализовать атаки типа Man-in-the-Middle и ретрансляцию хэшей (NTLM Relay) для дальнейшего горизонтального перемещения.

Методы снижения рисков и закрытия векторов атаки:
🔸 Внедрение модели эшелонированного администрирования: жесткое разделение учетных записей по уровням доверия с запретом аутентификации администраторов домена на пользовательских рабочих станциях.
🔸 Исключение общих локальных паролей: развертывание решений класса LAPS (Local Administrator Password Solution) для генерации уникальных ротируемых паролей на каждом узле.
🔸 Сетевая микросегментация: настройка межсетевого экранирования внутри инфраструктуры, изоляция критических серверов и блокировка межузлового трафика между клиентскими устройствами.
🔸 Предотвращение атак на память хостов: аппаратная изоляция учетных данных через Credential Guard, включение привилегированных учетных записей в группу Protected Users (для запрета кэширования их хэшей) и отказ от протоколов NTLM в пользу Kerberos.
🔸 Мониторинг и поведенческий анализ (EDR/XDR): выявление нестандартного использования протоколов удаленного управления (WMI, WinRM, SMB, RDP), аномальных дампов памяти процессов (LSASS) и подозрительной активности служебных учетных записей.

#KeptОтвечает

Согласие на обработку персональных данных (ПДн) в письменной форме требуется только в закрытом перечне случаев, установленном законодательством. Если ситуация не подпадает ни под один из них, согласие может быть получено в любой форме, позволяющей подтвердить факт его получения (ч. 1 ст. 9 152-ФЗ).

Согласие на обработку ПДн в письменной форме должно быть получено в следующих случаях:
● включение ПДн в общедоступные источники (ст. 8 152-ФЗ);
● обработка специальных категорий ПДн (ст. 10 152-ФЗ);
● распространение ПДн членов (участников) общественного объединения или религиозной организации (ст. 10 152-ФЗ);
● обработка биометрических ПДн (ст. 11 152-ФЗ);
● передача ПДн работников третьим лицам, за исключением случаев, предусмотренных федеральными законами (ст. 88 ТК РФ);
● автоматизированное принятие решения, порождающего юридические последствия в отношении субъекта ПДн (ст. 16 152-ФЗ).

Теперь разберем варианты ответов.

❌ «Решение о повышении сотрудника принимается автоматизированной системой после оценки выполнения KPI» подпадает под ст. 16 152-ФЗ: компания принимает решение о повышении на основе результатов работы автоматизированной системы, которое порождает юридические последствия, поэтому требуется письменное согласие.
❌ «Компания передает ПДн работника страховой компании для оформления полиса ДМС» подпадает под требования ст. 88 ТК РФ: работодатель передает данные работника третьему лицу, что требует письменного согласия работника. Передача ПДн в рамках обозначенной цели не подпадает под случаи, предусмотренные законодательством, которые исключали бы необходимость получать согласие, например проведение медицинских осмотров работников.
❌ «Компания внедряет систему прохода в офис по отпечаткам пальцев для сотрудников» подпадает под требования ст. 11 152-ФЗ: отпечатки пальцев являются биометрическими ПДн и используются для идентификации личности, их обработка допускается только с письменного согласия.
✔️ «Компания проводит собеседование кандидатов перед принятием решения о приеме на работу» является правильным вариантом ответа, поскольку эта ситуация не входит в закрытый перечень случаев, когда необходимо получать письменное согласие.

#Викторины

CISO & DPO news #142 (18–24 сентября)

▫️ ИИ-модель от Google взломала три реальные компании во время тестов
Во время майских испытаний одна из моделей семейства Gemini получила несанкционированный доступ к защищенным системам трех организаций. Причины — ошибки в изоляции тестовой среды и совпадение названия вымышленной компании с реальной. В одном случае модель подобрала пароль методом перебора, в двух других — нашла учетные данные в публичных репозиториях через обычные поисковые запросы. В Google заявили, что модель остановилась, как только поняла, что вышла за пределы симуляции. Фактического ущерба не было, и компания решила не заявлять об инциденте публично.

▫️ Вредоносное расширение может захватить встроенный ИИ в популярных браузерах
Новая техника BragJack позволяет провести атаку без взаимодействия с пользователем, перехватывая управление встроенными ИИ-агентами. Манипулируя сетевыми запросами, злоумышленник заставляет ИИ выполнять вредоносные команды с высокими системными привилегиями. Это открывает доступ к локальным файлам, истории просмотров, скриншотам и потенциально к камере и микрофону. BragJack был апробирован на Gemini Live от Google, Perplexity Comet, Microsoft Edge, Opera Neon и Claude от Anthropic.

▫️ Хакеры заявили о взломе сайта ФБР и краже данных тысяч сотрудников
В качестве доказательств представители группировки ShinyHunters опубликовали скриншот измененной веб-страницы и выборку из примерно 5000 записей, где содержатся имена, домашние адреса, номера социального страхования и сведения о родственниках сотрудников ведомства. Злоумышленники заявили, что эта атака — ответ на публикацию ФБР в мае 2026 г., в которой описывались методы злоумышленников.

▫️ OpenAI раскрыла шесть инцидентов с «нежелательным» поведением своих моделей
Все случаи произошли за последние полгода. Модели пытались скрыть ошибки от пользователей, оставляли скрытые инструкции для будущих версий, несанкционированно использовали найденные в открытом доступе API-ключи, загружали данные на публичные хостинги и обменивались сообщениями через внутренние репозитории. В OpenAI признали, что индустрия еще не решила проблемы безопасности и контроля ИИ в достаточной степени, чтобы продолжать масштабироваться на максимальной скорости.

▫️ Уязвимость в SharePoint Server позволяет удаленно выполнять код с правами авторизованного пользователя
Изначально Microsoft классифицировала уязвимость CVE-2026-65660 как спуфинг со средней степенью серьезности. Но по факту аутентифицированный злоумышленник мог внедрить дополнительные директивы через неэкранированные кавычки, загрузить произвольные классы .NET и выполнить произвольный код на сервере. Проблема затрагивает SharePoint Server 2016, 2019 и Subscription Edition. Случаи эксплуатации в реальной среде не зафиксированы.

Что такое физический пентест и для чего его проводят?
 
Физический пентест – это проверка защищенности объектов, помещений и инфраструктуры организации от несанкционированного физического доступа. В отличие от классического тестирования на проникновение информационных систем, в данном случае специалисты оценивают, насколько злоумышленник способен попасть на охраняемую территорию, получить доступ к оборудованию или обойти действующие физические меры безопасности.
 
В рамках физического пентеста специалисты моделируют действия потенциального нарушителя в заранее согласованных пределах. Проверке могу подвергаться системы контроля и управления доступом, турникеты, двери, замки, пропускной режим, охрана, видеонаблюдение, серверные и технические помещения. Также оценивается устойчивость организации к методам социальной инженерии, в том числе попыткам получить временный пропуск под правдоподобным предлогом или пройти вслед за сотрудником через контролируемую точку доступа.
 
Основная задача такого тестирования – выявить практические уязвимости, которые невозможно обнаружить исключительно с помощью технического тестирования. Даже современная система информационной безопасности может быть скомпрометирована, если злоумышленник получает физический доступ к серверу, сетевому оборудованию, рабочей станции или другим критически важным ресурсам.
 
Физический пентест позволяет проверить не только технические средства защиты, но и эффективность установленных процедур. Специалисты анализируют, соблюдают ли сотрудники требования пропускного режима, как контролируется доступ посетителей, насколько внимательно персонал реагирует на подозрительные ситуации и могут ли внутренние регламенты быть обойдены на практике.
 
Перед проведением тестирования заказчик определяет согласованный периметр работ: объекты, временные интервалы, допустимые методы и ограничения. Это позволяет провести проверку контролируемо и исключить чрезмерное воздействие на сотрудников, оборудование и производственные процессы.
 
Результатом физического пентеста становится отчет с описанием выявленных недостатков, подтверждающими материалами, оценкой потенциальных рисков и рекомендациями по повышению уровня физической и комплексной безопасности организации.
 
#KeptОтвечает

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

Их разобрал старший менеджер, руководитель направления по анализу защищенности Kept Алексей Водясов в своем докладе «Почему пентестеры не находят уязвимости» на конференции ISCRA Talks, которая прошла в субботу, 19 сентября.

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

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

Каждый браузер применяет собственный формат и местоположение. Рассмотрим три наиболее популярных браузера: Google Chrome, Mozilla Firefox и Apple Safari.

🔎 Google Chrome (и другие браузеры на основе Chromium: Opera, Яндекс.Браузер, Brave и т. д.) хранит данные автозаполнения (кроме паролей) в SQLite-базе “Web Data”, расположенной в папке профиля пользователя.

Стандартные пути:
Windows: %LOCALAPPDATA%\Google\Chrome\User Data\Default\
Linux: ~/.config/google-chrome/Default/
macOS: ~/Library/Application Support/Google/Chrome/Default/

Пароли в Google Chrome хранятся в базе данных Login Data рядом с Web Data.

🔎 Mozilla Firefox хранит историю заполнения форм в файле “formhistory.sqlite”, расположенном в папке профиля пользователя. Система похожа на Google Chrome: здесь пароли так же хранятся отдельно — в файлах logins.json и key4.db.

Стандартные пути:
Windows: %APPDATA%\Mozilla\Firefox\Profiles\\formhistory.sqlite
Linux: ~/.mozilla/firefox/.default/
macOS: ~/Library/Application Support/Firefox/Profiles//formhistory.sqlite.

🔎 Apple Safari не использует отдельный файл для автозаполнения как в Chrome или Firefox. Данные автозаполнения (имена, адреса, контакты) хранятся в системном хранилище macOS и iOS — Keychain (цепочке ключей) и приложении Contacts. Последнее может звучать странно, но Safari не создает отдельную базу для таких данных, как имя, адрес или телефон. Вместо этого он использует уже существующие карточки из приложения «Контакты».

Пароли и учетные данные сохраняются в iCloud Keychain, которая синхронизируется между устройствами Apple, если синхронизация активна.

Стандартный путь:
~/Library/Safari/Form Values

#Викторины

CISO & DPO news #141 (11–17 сентября)

▫️ ФСТЭК обяжет субъектов КИИ регулярно подтверждать уровень безопасности
С 1 марта 2027 г. субъекты КИИ, эксплуатирующие значимые объекты, должны будут пересчитывать показатель защищенности от типовых актуальных угроз дважды в год, а уровень зрелости мер безопасности — раз в три года. Кроме того, оценивать зрелость теперь нужно будет не только самому субъекту КИИ, но и подрядчикам с доступом к значимым объектам КИИ.

▫️ Минцифры предлагают наделить новыми полномочиями в сфере регулирования ИИ
Ведомство будет анализировать большие фундаментальные модели, разрабатывать меры поддержки отрасли и помогать госорганам внедрять нейросети. Отдельным направлением станет стимулирование российских ИИ-разработок. Проект постановления, закрепляющий эту роль за Минцифры, опубликован для общественного обсуждения. Изменения связаны с законом «О поддержке развития технологий искусственного интеллекта в РФ».

▫️ Боты в Telegram могли красть переписку через HTML-экспорт
Уязвимость в десктопной версии мессенджера позволяла незаметно встраивать JavaScript в подписи к кнопкам ботов. При экспорте чата в HTML и открытии файла в браузере скрипт запускался автоматически и мог скопировать сообщения на сервер злоумышленника или подменить содержимое страницы. Исправление вошло в версию 7.0.1, но ранее созданные HTML-файлы остаются уязвимыми. Случаев реальной эксплуатации не зафиксировано.

▫️ Британский банк Revolut передал данные клиентов мошенникам из-за фальшивого запроса
Поддельное обращение от имени госоргана пришло на электронную почту финтех-компании, и команда по соблюдению нормативных требований приняла его за настоящее. Результат — скомпрометированные даты рождения, почтовые и электронные адреса, номера телефонов, а также копии паспортов и водительских удостоверений. Банк проинформировал пострадавших, но отметил, что средства клиентов не были затронуты.

▫️ 150 тыс. жалоб на нарушения персональных данных получил Роскомнадзор за последние полтора года
Число обращений выросло на 20%. Информационная система ведомства обнаруживает признаки нарушений персональных данных почти в 90% случаев. Роскомнадзор проверил 159,1 тыс. интернет-сайтов, 135,95 тыс. из них содержат нарушения законодательства в области персональных данных.

▫️ Троян KREMLIN крадет банковские сессии через Chrome и Edge
Вредонос устанавливает расширение напрямую в Chrome и Edge, подделывает защитные данные браузера и получает доступ к токенам сессий, cookies и содержимому вкладок. Пароли не нужны — злоумышленники перехватывают уже авторизованные банковские сессии. Адреса управляющих серверов злоумышленники хранят в смарт-контракте Ethereum, что позволяет менять инфраструктуру без обновления трояна и обходить блокировку доменов. Более 98% из 1515 зараженных систем находились в Бразилии.

▫️ Немецкая полиция получает доступ к мессенджерам без взлома шифрования
Правоохранительные органы подключают служебный компьютер к учетной записи подозреваемого как доверенное устройство и могут следить за перепиской в Signal, Telegram и других мессенджерах. Шифрование при этом не нарушается. Пользователям советуют проверить привязанные устройства и завершить незнакомые сеансы.

Публикуем двадцать девятый выпуск «Непропустимых» событий ИБ. Мы активно следим за интересными мероприятиями по тематике информационной безопасности и приватности. Сегодня представляем наши рекомендации на октябрь 2026 года.

Подборка мероприятий в файле под этим постом. ⬇️

#Непропустимыесобытия

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

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

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

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

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

#Викторины

CISO & DPO news #140 (4–10 сентября)

▫️ 88% российских компаний имеют критические уязвимости в облаках
В каждой четвертой инфраструктуре присутствует вредоносное ПО, у 39% организаций в открытом виде хранятся ключи и токены, а 48% учетных записей не защищены многофакторной аутентификацией. Основные причины низкой защищенности — нехватка знаний и экспертизы в сфере облачной безопасности и попытки защитить облако привычными инструментами, предназначенными для защиты on-premise решений.

▫️ Word и Excel занимают 26% от всех способов доставки вредоносного ПО
Продукты Microsoft Office превратились в полноценный ИТ-инструмент для запуска и закрепления кода. Хакеры маскируют атаки под обычную активность сотрудников, применяя изначально штатные инструменты. Это усложняет обнаружение инцидентов и требует более сложной защиты: сочетания технических мер, обучения персонала и строгого контроля за использованием офисных приложений и внешних файлов.

▫️ Сбор данных «на всякий случай» увеличивает риски утечек
Именно такая информация становится мишенью для злоумышленников. Необходимо минимизировать собираемые данные и внедрять простые правила обработки вместо избыточной бюрократии. Дополнительная угроза — бесконтрольное использование сотрудниками публичных нейросетей: загрузка в них рабочей или клиентской информации может привести к крупным оборотным штрафам и даже уголовному преследованию.

▫️ В ядре SAP обнаружили две критические уязвимости
Уязвимость OVERPASS позволяет выполнять произвольные команды на хостах SAP с правами администратора и полностью компрометировать процессы и бизнес-данные. Уязвимость S4GET дает возможность получить доступ ко всему кластеру систем и удаленно запускать вредоносный код через сеть. SAP уже выпустила кумулятивный патч, закрывающий эти две уязвимости и еще 18 проблем безопасности.

▫️ Каждая третья успешная кибератака начинается со взлома подрядчика
Причина — слабая защищенность самих контрагентов. Украденные у них логины и пароли дают атакующему легитимный доступ к инфраструктуре организации в обход периметровых средств защиты. Основная цель таких атак — крупные компании с численностью персонала более 10 тыс. сотрудников.

▫️ Check Point исправила две критические уязвимости в VPN-сертификатах
Обе уязвимости оценены в 9.8 балла по шкале CVSS. По заявлению компании, они позволяют удаленному злоумышленнику выполнить произвольный код на Security Gateway и Security Management Server при определенных условиях. Хотя активных атак пока не зафиксировано, уязвимости затрагивают ключевые версии ПО.

▫️ Обвиняемый получил год колонии за передачу персональных данных
Ростовский районный суд вынес приговор местному жителю, который через Telegram-бота собирал и продавал третьим лицам конфиденциальные сведения о гражданах, включая военнослужащих. Помимо года в колонии строгого режима, подсудимому назначен штраф в размере 100 тыс. руб.

▫️ Хакеры использовали сотни ИИ-агентов для взлома 440 серверов PaperCut
Хакерская кампания затронула 48 стран. ИИ-агенты на базе OpenAI Codex и DeepSeek автоматизировали разработку эксплойтов, проведение вторжений, отладку неудач и постэксплуатацию. В некоторых случаях на получение прав доменного администратора было затрачено всего семь минут. Основной удар пришелся на сектор образования, но конечная цель атаки пока неясна.

▫️ Кража сессионных токенов ИИ-сервисов позволяет злоумышленникам обходить MFA
Киберпреступники перехватывают учетные записи пользователей, используя данные из логов инфостилеров. Воспроизведение украденных JWT-токенов и API-ключей дает прямой доступ к платформам вроде OpenAI, Google и Anthropic в обход многофакторной аутентификации. Это открывает путь для LLMjacking — незаконного использования корпоративных вычислительных ресурсов ИИ и накрутки счетов.

Договор как самостоятельное основание для обработки ПДн

Согласно п. 5 ч. 1 ст. 6 152-ФЗ, договор является одним из возможных оснований для обработки ПДн субъектов. Обработка признается законной, если она необходима для:
▫ исполнения договора, стороной которого, выгодоприобретателем или поручителем по которому является субъект ПДн;
▫ заключения договора по инициативе субъекта ПДн (например, при заполнении формы на сайте для получения банковской услуги) или договора, по которому он будет выгодоприобретателем или поручителем.

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

▫ Будущий vs. заключенный договор. Основание распространяется как на уже заключенный, так и на будущий договор. Однако, если вы обрабатывали данные для заключения договора, но он так и не был заключен, то цель обработки достигнута. В этом случае вы обязаны прекратить обработку и удалить ПДн субъекта, так как дальнейшее хранение становится неправомерным, если нет иного правового основания для продолжения обработки.
▫ Субъект ПДн – всегда сторона договора. Данное правовое основание применимо только в том случае, когда субъект ПДн (физическое лицо) сам является стороной договора, его выгодоприобретателем или поручителем. Согласно гражданскому законодательству, выгодоприобретатель — это физическое или юридическое лицо, в пользу которого заключен договор. Поручитель как сторона договора поручительства обязывается перед кредитором другого лица отвечать за исполнение последним его обязательства полностью или в части.
▫ Неприменимость к отношениям между юридическими лицами. Договор не может служить основанием для обработки ПДн работников контрагента – юридического лица. В отношениях между двумя организациями для обработки данных, например подписанта договора, правовым основанием будет исполнение требований законодательства о представительстве (ст. 182 ГК РФ).
▫ Только минимально необходимые данные. Используя договор как правовое основание компания может обрабатывать исключительно те ПДн, которые минимально необходимы для достижения цели заключения или исполнения договора. Запрашивать или собирать избыточную информацию, не связанную с договором, нельзя. Для дополнительных целей, например для маркетинговых рассылок, потребуется отдельное согласие. Такое согласие должно быть оформлено отдельно от иных документов, которое подписывает субъект ПДн.
▫ Ограничения по содержанию договора. Договор не может ограничивать права и свободы субъекта ПДн, допускать в качестве условия бездействие субъекта, устанавливать случаи обработки данных несовершеннолетних, если иное не предусмотрено законодательством РФ, или предусматривать бездействие субъекта как условие заключения договора.
▫ Трудовые отношения – особая сфера. Положение п. 5 ч. 1 ст. 6 152-ФЗ не распространяется на трудовые отношения. Обработка ПДн работников регулируется трудовым законодательством РФ.

Неправильный выбор правового основания, в частности запрос согласия от субъекта в ситуации, когда обработка должна была осуществляться на основании договора, влечет за собой серьезные риски.

В соответствии с Постановлением Правительства РФ № 1046 избыточный сбор согласий на обработку ПДн является основанием для отнесения деятельности оператора к группе тяжести «А». Это автоматически переводит компанию в категорию риска не ниже «среднего». Такая категория напрямую влияет на периодичность контрольных (надзорных) мероприятий со стороны Роскомнадзора, повышая вероятность проведения внеплановых проверок.

#Privacy

Эскалация привилегий (Privilege Escalation) — это получение атакующим более высокого уровня прав, чем тот, которым он обладал изначально.

Например, атакующий получил доступ к Windows-системе как обычный пользователь. Если он использует уязвимость, неправильную настройку прав или другой механизм и получает права Administrator или SYSTEM — это вертикальная эскалация привилегий.

В Linux аналогичным примером будет переход от обычного пользователя к root.

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

Обычно выделяют два основных типа:
🔸 Вертикальная эскалация — получение более высокого уровня привилегий. Например: от user до Administrator.
🔸 Горизонтальная эскалация — получение доступа к ресурсам другого пользователя с аналогичным уровнем прав. Например: получение доступа к данным user2 от user1.

MITRE ATT&CK выделяет Privilege Escalation как отдельную тактику TA0004. Среди техник этой тактики есть эксплуатация уязвимостей, злоупотребление механизмами повышения привилегий и другие способы получения более высокого уровня доступа.

OWASP также рассматривает вертикальную и горизонтальную эскалацию в контексте веб-приложений.

#Викторины