Вообще идея корпоративного архиватора в том, чтобы закрепить практику безопасной передачи корпоративных данных доверенным адресатам за пределами компании (которым, кстати, для распаковки архива понадобится передать заодно и пароль). Если пользователь отправляет архив с данными легитимно в рамках рабочих задач, логично, что у работодателя к этим данным будет доступ.
DLP-система в любом случае увидит пересылку файла, то есть инцидент – отловит.
Автоматического анализа файлов на предмет наличия вложенных структур (например, поиска ZIP-сигнатуры внутри файла после неформатного преамбула) в момент отправки нет, но система позволяет:
- фиксировать пользовательские действия (создание архива, последующее редактирование файлов, использование сторонних утилит для склейки и т.д.) через агенты мониторинга активности;
- выявлять подозрительные цепочки операций (например: создание запароленного архива → запись в него конфиденциальных данных → модификация файла с помощью скрипта или бинарной утилиты);
- применять проактивные политики, например, блокировать отправку любых файлов с неизвестными или нестандартными расширениями/сигнатурами, либо требовать дополнительного согласования при передаче таких объектов.
Таким образом, у заказчика есть все возможности снизить риски, что утечка произойдет такими «обходными путями»: комбинация контроля поведения, анализа процессов и ограничений на передачу данных. Дальше – дело техники.
В 2025 году вышел приказ ФСБ об утверждении требований к криптозащите данных в ИС госсектора. Здесь мы опираемся на его выпуск и напоминаем, как может на практике работать сочетание криптографических и некриптографических СЗИ :)
Пользуйтесь на здоровье - рады стараться! :) Еще раз в квартал собираем в блоге обновления ИБ-нормативки, там тоже расписываем, как выполнить. Может, будет полезно.
Привет, на связи Марта. Спасибо за вопрос! Отвечу по пунктам.
Да, у нас есть своя служба ИБ, которая контролирует всех сотрудников – в том числе нас, ИБ-аналитиков.
Контроль обеспечивают те же системы: DLP, DCAP, профайлинг. Они стоят, опять же, на всех ПК, и наших тоже. То есть и на нас можно применять все доступные возможности: от блокировок, чтобы нельзя было ничего выгрузить с рабочего компа (например, из той же DLP – нашей или клиентов), до полного мониторинга действий вообще, в т.ч. вне системы.
Логируется вся работа с софтом: как мы просматриваем перехват, как конфигурируем агенты, настраиваем политики безопасности или блокировки и т.д. Плюс у нас в DLP и остальных системах ролевая модель доступа, т.е. «рядовым» ИБ-аналитикам можно подрезать права в системе. Запретить менять настройки, например, или просматривать часть перехвата по выбранным пользователям. Полный доступ у начИБ, он же распределяет роли и полномочия. Как контролировать начИБ – решает уже руководство. Например, топы могут сами смотреть за ним и определять его полномочия в той же DLP.
Вопрос, действительно, во многом риторический – но могу порассуждать. Если ИБ-аналитики и вообще служба ИБ пользуются полным доверием руководства, это может стать тонким местом. Если у «контролеров тоже есть контролеры» – рисков меньше.
Немного не так. "Мы будем собирать конфиденциальные данные в админке. Она не индексируется поисковиками, а креды есть только у нас. Поэтому все будет хорошо! "
Но, как оказалось, заходить в админку и не нужно. Из-за серии ошибок одна из папок "торчала наружу" и индексировалась поисковиками.
Проблема актуальна не только для России, в других странах тоже далеко не все компании горят желанием рассказывать о собственных промахах. Например, по данным исследования среди западных фирм, 72% компаний, столкнувшихся с утечкой, предпочли об этом не рассказывать. Согласно другому опросу, IT- и ИБ-специалисты из США часто получают прямые указания от руководства – не раскрывать информацию об утечках, даже когда это формально необходимо. Причем в США с этим столкнулись 71% специалистов, для сравнения, во Франции – 27%. Но общий вектор развития на Западе всё же в сторону раскрытия информации об утечках. Компанию могут оштрафовать на крупную сумму, если выяснится, что она намеренно предоставила общественности неполные или неточные сведения об инциденте.
Да, в ситуации, которую вы описали, было бы странно не заметить смены пароля. Но если сотрудник, например, находится в отпуске, то и не заметит, что его учеткой пользуется кто-то другой. Поэтому мы за то, чтобы отслеживать подобную активность.
И в РФ такого хватает. Многие учетки месяцами висят активными после ухода сотрудников, а есть дублирующиеся учетки с паролем, который создан 3 года назад. Затем и нужна SIEM-система.
Вообще идея корпоративного архиватора в том, чтобы закрепить практику безопасной передачи корпоративных данных доверенным адресатам за пределами компании (которым, кстати, для распаковки архива понадобится передать заодно и пароль). Если пользователь отправляет архив с данными легитимно в рамках рабочих задач, логично, что у работодателя к этим данным будет доступ.
DLP-система в любом случае увидит пересылку файла, то есть инцидент – отловит.
Автоматического анализа файлов на предмет наличия вложенных структур (например, поиска ZIP-сигнатуры внутри файла после неформатного преамбула) в момент отправки нет, но система позволяет:
- фиксировать пользовательские действия (создание архива, последующее редактирование файлов, использование сторонних утилит для склейки и т.д.) через агенты мониторинга активности;
- выявлять подозрительные цепочки операций (например: создание запароленного архива → запись в него конфиденциальных данных → модификация файла с помощью скрипта или бинарной утилиты);
- применять проактивные политики, например, блокировать отправку любых файлов с неизвестными или нестандартными расширениями/сигнатурами, либо требовать дополнительного согласования при передаче таких объектов.
Таким образом, у заказчика есть все возможности снизить риски, что утечка произойдет такими «обходными путями»: комбинация контроля поведения, анализа процессов и ограничений на передачу данных. Дальше – дело техники.
Никому нельзя верить :)
В 2025 году вышел приказ ФСБ об утверждении требований к криптозащите данных в ИС госсектора. Здесь мы опираемся на его выпуск и напоминаем, как может на практике работать сочетание криптографических и некриптографических СЗИ :)
Довольно распространенная ситуация, к сожалению. Вероятно, первый громкий кейс поменяет дело.
Пользуйтесь на здоровье - рады стараться! :)
Еще раз в квартал собираем в блоге обновления ИБ-нормативки, там тоже расписываем, как выполнить. Может, будет полезно.
Привет, на связи Марта.
Спасибо за вопрос! Отвечу по пунктам.
Да, у нас есть своя служба ИБ, которая контролирует всех сотрудников – в том числе нас, ИБ-аналитиков.
Контроль обеспечивают те же системы: DLP, DCAP, профайлинг. Они стоят, опять же, на всех ПК, и наших тоже. То есть и на нас можно применять все доступные возможности: от блокировок, чтобы нельзя было ничего выгрузить с рабочего компа (например, из той же DLP – нашей или клиентов), до полного мониторинга действий вообще, в т.ч. вне системы.
Логируется вся работа с софтом: как мы просматриваем перехват, как конфигурируем агенты, настраиваем политики безопасности или блокировки и т.д. Плюс у нас в DLP и остальных системах ролевая модель доступа, т.е. «рядовым» ИБ-аналитикам можно подрезать права в системе. Запретить менять настройки, например, или просматривать часть перехвата по выбранным пользователям. Полный доступ у начИБ, он же распределяет роли и полномочия. Как контролировать начИБ – решает уже руководство. Например, топы могут сами смотреть за ним и определять его полномочия в той же DLP.
Вопрос, действительно, во многом риторический – но могу порассуждать. Если ИБ-аналитики и вообще служба ИБ пользуются полным доверием руководства, это может стать тонким местом. Если у «контролеров тоже есть контролеры» – рисков меньше.
Речь шла о миллионе. Поправили, спасибо!
Мы привели только самые типовые требования, встречающиеся регулярно. Конечно, в каждой отдельно взятой вакансии специфики больше.
А какие мастхэв-навыки включили бы вы?
Ваша правда! Опечатались - поправили, спасибо.
Немного не так. "Мы будем собирать конфиденциальные данные в админке. Она не индексируется поисковиками, а креды есть только у нас. Поэтому все будет хорошо! "
Но, как оказалось, заходить в админку и не нужно. Из-за серии ошибок одна из папок "торчала наружу" и индексировалась поисковиками.
В инциденте Сдэка пока мало подробностей. Причем большая часть из них - комментарии злоумышленников. Мы бы не стали верить им на слово.
Если выяснится что-то интересное, обязательно добавим в следующий выпуск.
Ваша правда, поправили, спасибо.
Список правил можно посмотреть по ссылке. Еще наш системный аналитик проводил вебинар, на котором рассказывал о предустановленных правилах, рекомендуем к просмотру https://youtu.be/wGMSO912Vkk?si=5I7Hb5yPyUjzN4Dk
Спасибо за обратную связь. До встречи на конференции!
Проблема актуальна не только для России, в других странах тоже далеко не все компании горят желанием рассказывать о собственных промахах. Например, по данным исследования среди западных фирм, 72% компаний, столкнувшихся с утечкой, предпочли об этом не рассказывать. Согласно другому опросу, IT- и ИБ-специалисты из США часто получают прямые указания от руководства – не раскрывать информацию об утечках, даже когда это формально необходимо. Причем в США с этим столкнулись 71% специалистов, для сравнения, во Франции – 27%.
Но общий вектор развития на Западе всё же в сторону раскрытия информации об утечках. Компанию могут оштрафовать на крупную сумму, если выяснится, что она намеренно предоставила общественности неполные или неточные сведения об инциденте.
Спасибо за обратную связь!
Да, в ситуации, которую вы описали, было бы странно не заметить смены пароля. Но если сотрудник, например, находится в отпуске, то и не заметит, что его учеткой пользуется кто-то другой. Поэтому мы за то, чтобы отслеживать подобную активность.
И в РФ такого хватает. Многие учетки месяцами висят активными после ухода сотрудников, а есть дублирующиеся учетки с паролем, который создан 3 года назад. Затем и нужна SIEM-система.
Да :)