«ГИГАНТ — Комплексные системы», российский производитель вычислительной техники, и «Газинформсервис», разработчик решений для информационной безопасности, расширяют возможности создания защищенных рабочих мест на базе отечественных технологий. Компании подтвердили совместимость рабочей станции ГИГАНТ ГКС-777 со средством доверенной загрузки SafeNode System Loader. Для бизнеса и государственных организаций это возможность выстраивать защиту рабочих мест начиная с момента включения компьютера, ещё до запуска операционной системы.

Специалисты обеих компаний провели совместные испытания SafeNode System Loader с рабочей станцией серии ГКС-777. Тестирование подтвердило корректность совместной работы оборудования и средства защиты. По его итогам выдан бессрочный сертификат совместимости.

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

SafeNode System Loader встраивается в микропрограмму UEFI BIOS и обеспечивает защиту от несанкционированного доступа на этапе загрузки компьютера до старта операционной системы. Продукт поддерживает двухфакторную аутентификацию пользователей до загрузки ОС, контроль целостности UEFI и заданных файлов, блокировку запуска нештатной операционной системы, в том числе с внешних носителей.

«Предприятия выбирают вычислительную технику на годы вперед. Для них принципиальны свобода выбора операционных систем и средств защиты, предсказуемость внедрения и возможность развивать инфраструктуру по собственному плану. Поэтому мы последовательно расширяем перечень российских решений, с которыми совместимо оборудование ГИГАНТ. Партнерство с „Газинформсервисом“ позволяет закладывать доверенную загрузку в архитектуру рабочего места и формировать проверенные конфигурации для крупных проектов в бизнесе и государственном секторе», - отметил Яков Сотников, технический директор компании «ГИГАНТ  —  Комплексные системы».

SafeNode System Loader допускает программную установку без вскрытия корпуса компьютера. При использовании сервера «Блокхост-Сеть 4» доступны централизованная установка и управление средством защиты, сбор событий аудита и их передача в систему мониторинга информационной безопасности. Эти возможности помогают администрировать защиту на большом числе рабочих мест.

«Попытка запустить компьютер с внешнего носителя не должна становиться способом обхода правил доступа к корпоративным данным. Поэтому важно проверять пользователя и целостность заданных компонентов ещё до старта операционной системы, а загрузку нештатной ОС — блокировать. Подтверждённая совместимость SafeNode System Loader с ГКС-777 дает заказчикам проверенное сочетание оборудования и средства защиты для проектов обновления рабочих мест. При использовании „Блокхост-Сеть 4“ развертыванием и настройками можно управлять централизованно. Это позволяет включать доверенную загрузку в стандарт оснащения рабочих мест и применять единые настройки защиты при дальнейшем расширении парка компьютеров», — отметил Константин Хитрово, менеджер по продукту SafeNode System Loader компании «Газинформсервис».

Рабочая станция ГИГАНТ ГКС-777 включена в реестр российской промышленной продукции Минпромторга России, а SafeNode System Loader входит в Единый реестр российского программного обеспечения.

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

Восстановление дата-центров «Яндекса» после атак и дополнительные расходы на защиту ЦОДов после сообщений об атаке на объект Сбербанка в Балаково могут усилить спрос на серверы, системы хранения данных и комплектующие. Если компаниям потребуется быстро заменить поврежденную технику, восстановить резерв мощностей или усилить защиту инфраструктурных объектов, срочные закупки добавятся к уже существующему спросу на рынке. Об этом CNews сообщили представители компании «ГИГАНТ — Комплексные системы».

Поводом для обсуждения стали сообщения об атаках на дата-центры «Яндекса» и ЦОД Сбербанка в Балаково. В случае со Сбербанком банк заявлял о штатной работе сервисов, поэтому речь не идет о подтвержденном влиянии на доступность услуг. Однако сама серия инцидентов усиливает вопрос о том, сколько операторам ЦОДов придется дополнительно вкладывать в восстановление, резервирование и физическую защиту объектов.

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

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

«Крупное восстановление инфраструктуры почти никогда не проходит как обычная плановая закупка. Если повреждены значимые мощности, оборудование нужно не просто купить, а быстро произвести, доставить, установить и ввести в эксплуатацию. Такой спрос возникает поверх уже существующих потребностей рынка. Поэтому ценовое давление, скорее всего, не будет краткосрочным: часть ресурсов, которые планировались на развитие, придется направить на восстановление, а дефицитные позиции будут дорожать сильнее всего», - отметил Сергей Семикин, генеральный директор компании «ГИГАНТ — Комплексные системы».

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

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

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

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

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

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

Академия АйТи fabricaONE.AI (акционер - ГК Softline) открыла набор на курс «Аналитик киберугроз». Курс поможет специалистам связывать данные из внешних источников с событиями внутри корпоративной инфраструктуры, оценивать актуальность угроз и преобразовывать результаты анализа в конкретные меры защиты.

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

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

Новая программа Академии АйТи охватывает полный цикл работы с данными о киберугрозах: от постановки задач, сбора и проверки информации до подготовки аналитических выводов и их применения в системе защиты. Слушатели изучат методы OSINT, особенности мониторинга теневого сегмента интернета и каналов утечек, работу с индикаторами компрометации, профилирование киберпреступных группировок и анализ тактик, техник и процедур злоумышленников.

Отдельная часть курса посвящена тому, как связать внешний и внутренний контуры аналитики. Специалисты научатся сопоставлять сведения о новых угрозах с событиями в корпоративных системах, интегрировать данные Threat Intelligence в SOC, SIEM, SOAR, EDR и XDR, формировать гипотезы для поиска скрытой активности и разрабатывать правила обнаружения угроз на основе YARA и Sigma.

«Компания может подключить источники данных о киберугрозах и внедрить современные средства защиты, но сами по себе инструменты не определят, какая информация действительно важна для ее инфраструктуры. Эту задачу решает аналитик, который проверяет источники, восстанавливает контекст, связывает внешние индикаторы с внутренними событиями и переводит результаты исследования в понятные действия для SOC, специалистов по управлению уязвимостями и руководителей. Программа построена вокруг этого полного цикла: от получения исходных данных до аналитического отчета и мер реагирования», - отметил Михаил Шепелев, куратор направления «Информационная безопасность» Академии АйТи (ГК Softline).

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

Курс также рассматривает российский нормативный и отраслевой контекст, включая требования к защите КИИ, базы данных ФСТЭК России и НКЦКИ, а также форматы обмена информацией с ГосСОПКА, НКЦКИ и ФинЦЕРТ.

Программа предназначена для аналитиков SOC, специалистов по реагированию на инциденты и информационной безопасности, а также системных и сетевых инженеров, участвующих в защите инфраструктуры. Для обучения потребуются базовые навыки администрирования Linux, понимание основ программирования на Python и ключевых принципов информационной безопасности.

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

Подробная информация о программе представлена на сайте Академии АйТи: https://academyit.ru/courses/ti/.

Переход на доверенное ПО редко упирается в поиск российского аналога. Сложнее определить, какие требования действуют именно для конкретной системы, какие решения нужно заменить уже сейчас, а какие попадут под новые правила позже. Значимый объект КИИ, ГИС, защитный контур, виртуализация и промышленное ПО подчиняются разным основаниям и срокам. Если свести их в одну миграционную программу, компания рискует начать не с того участка, заложить в архитектуру несовместимые решения и обнаружить критичные зависимости уже после закупки.Как разделить регуляторные контуры, проверить не только статус продукта, но и его место в целевой архитектуре, выстроить очередность миграции и не превратить формальное соответствие требованиям в дорогую перестройку инфраструктуры, рассказывает Дмитрий Битченков, директор департамента сопровождения конкурентных процедур компании «ГИГАНТ — Компьютерные системы», преподаватель дисциплины «Документирование в сфере закупок» РТУ МИРЭА.Реестровая запись больше не гарантирует закупочный приоритет

При закупках по Законам № 44-ФЗ и № 223-ФЗ российское ПО без отметки о соответствии требованиям доверенного ПО в предусмотренных случаях приравнивается к иностранному для целей национального режима, если в процедуре участвует доверенное решение. Поэтому проверять нужно не только наличие продукта в реестре, но и конкретную версию, актуальность реестровой записи и отметки о соответствии требованиям доверенного ПО, и сведения о совместимости и состав фактически используемой конфигурации.

Следующий риск связан с совместимостью. Для регулируемых классов ПО потребуется подтвердить работу как минимум с двумя доверенными операционными системами. С 1 сентября 2026 года требование применяется к офисному ПО.  С 1 января 2027 года требование затронет виртуализацию, облачные и распределенные вычисления, хранение данных, серверное ПО, СУБД, мониторинг и контейнеризацию, с 1 июня - прикладные и отраслевые системы, средства информационной безопасности и обработки данных, с 1 января 2028 года - промышленное ПО и системы управления процессами.

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

КИИ, ГИС, средства защиты и облака нельзя объединять в один контур

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

Указ Президента № 166 запрещает с 1 января 2025 года органам государственной власти и подпадающим под него заказчикам использовать иностранное ПО на принадлежащих им значимых объектах КИИ. Ограничение касается именно установленного указом круга организаций и значимых объектов. Его нельзя автоматически распространять на любую систему субъекта КИИ, как нельзя считать любую корпоративную информационную систему значимым объектом только из-за того, что ее остановка создаст сложности для бизнеса.

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

Отдельно необходимо рассматривать средства защиты информации. Указ Президента № 250 с 1 января 2025 года запрещает указанным в нём органам и организациям использовать средства защиты информации, странами происхождения которых являются недружественные иностранные государства, а также средства защиты, производимые организациями, находящимися под контролем таких государств. Применимость запрета к конкретной организации следует определять по её статусу и основаниям, предусмотренным Указом № 250. Это самостоятельное требование, которое нельзя откладывать до будущих этапов перехода на доверенное прикладное или инфраструктурное ПО.

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

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

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

Отдельного штрафа за «не успели перейти» может не быть, но риск остается

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

В 2025 году были увеличены штрафы по статье 13.12 КоАП за отдельные нарушения правил защиты информации. В зависимости от состава максимальный штраф для юридических лиц может достигать 100 тыс. рублей.

С 20 апреля 2026 года действует статья 13.12.2 КоАП РФ. Она предусматривает ответственность за нарушение правил эксплуатации средств хранения, обработки или передачи охраняемой компьютерной информации, содержащейся в КИИ, а также правил доступа к такой информации и соответствующим системам, сетям и средствам связи. Для должностных лиц предусмотрен штраф от 10 тыс. до 50 тыс. рублей, для юридических лиц — от 100 тыс. до 500 тыс. рублей.

Уголовная ответственность по статье 274.1 УК РФ не возникает только из-за задержки миграции. Для нее необходимы самостоятельные признаки преступления и предусмотренные законом последствия. Но это не означает, что откладывание проекта безопасно. Чем дольше в критичном контуре сохраняется неподдерживаемое или запрещенное решение, тем сложнее отделить проблему миграции от нарушения требований к эксплуатации и защите системы.

Особенно рискованно опираться на упоминаемые в проектах нормативных актов, отраслевых планах или публичных обсуждениях сроки 2028-2036 годов как на универсальную отсрочку. Любая более поздняя дата должна относиться к конкретной организации, категории объекта и нормативному основанию. Такие сроки могут быть связаны, в частности, с особо значимыми проектами, индивидуально обоснованными решениями или специальными условиями перехода, а не с общим правом субъекта КИИ отложить миграцию. Она не отменяет уже действующие ограничения Указов № 166 и № 250 и не дает права сохранить иностранное решение только потому, что его замена технически сложна.

Миграция начинается с правового периметра, а не с выбора аналога

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

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

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

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

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

Критерии пилота должны быть измеримыми. Вместо формулировки «обеспечить высокую производительность» необходимо указать допустимое время ответа, количество транзакций, объем обрабатываемых данных и поведение при пиковой нагрузке. Вместо общего требования отказоустойчивости - определить RTO, RPO, допустимый простой, сценарий переключения и порядок возврата к основной площадке. Вместо обещания совместимости - провести тест на фактических версиях операционной системы, СУБД, драйверов, средств защиты и прикладных компонентов.

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

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

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

Где проекты чаще всего ломаются

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

Вторая группа связана с неверным прочтением отдельных требований. Совместимость облачного ПО с доверенными операционными системами принимают за запрет иностранных облаков. Переход на доверенное прикладное ПО считают достаточным выполнением требований, хотя в критичном контуре продолжают использоваться иностранные СЗИ, подпадающие под Указ № 250. Дальние сроки из проектов документов воспринимают как автоматическую отсрочку, не проверяя, относятся ли они к конкретному объекту и организации.

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

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

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

Глеб Ковалев, руководитель ИТ-отдела, «ГИГАНТ — Компьютерные системы» рассказал о том, для каких организаций действительно оправдано внедрение систем выявления инсайдерских угроз, а также о том, с чего стоит начинать построение такой защиты. Он объяснил, какие технические и организационные требования нужно выполнить до внедрения DLP и UEBA, по каким критериям выбирать решение, если сравниваешь несколько продуктов, и какие показатели после запуска реально говорят о том, что система работает, а не просто сыпет уведомлениями. 

— Для каких организаций и сценариев внедрение систем выявления инсайдерских угроз сегодня действительно оправдано, а в каких случаях их использование будет избыточным?

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

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

Организациям с небольшим объемом чувствительных данных и простой инфраструктурой на первом этапе может быть достаточно базовых мер: разграничить доступ, использовать многофакторную аутентификацию и журналирование, контролировать подключаемые устройства и своевременно отзывать права при увольнении. В крупных и распределенных средах базовых мер часто оказывается недостаточно, уже не обойтись без полноценного комплекса DLP, UEBA и других специализированных средств.

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

— С чего стоит начинать построение системы защиты от инсайдерских угроз, чтобы избежать типичных ошибок на этапе внедрения?

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

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

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

— Какие технические и организационные требования необходимо выполнить до внедрения DLP, UEBA или других средств выявления инсайдерской активности?

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

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

— По каким критериям следует выбирать решение для выявления инсайдерских угроз, если компания сравнивает несколько продуктов?

Выбирать решение необходимо исходя из конкретных рисков и инфраструктуры компании. Сначала необходимо определить контролируемые среды и каналы: рабочие станции, электронную почту, веб-трафик, мессенджеры, USB-устройства, облачные хранилища, виртуальные рабочие места. Затем оцениваем качество контентного анализа, распознавания русскоязычных данных, работы со словарями, применения OCR, анализа контекста и поведенческих аномалий. Отдельно проверяем уровень ложных срабатываний. Большое количество событий не показатель эффективности, наоборот специалисты могут оказаться перегруженными и пропустить действительно опасные события.

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

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

— Какие показатели наиболее объективно отражают эффективность системы выявления инсайдерских угроз после ее внедрения?

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

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

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

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