Журнал "Information Security/ Информационная безопасность" #2, 2025

новенькое. Например, мы в Kaspersky ICS CERT непрерывно занимаемся тем, что обнаруживаем атаки с использова- нием нового инструментария и тактик, и точечно уведомляем о возможной ком- прометации организации, которые, по нашим данным, могли стать жертвой. И мы, и наши коллеги из других подразде- лений постоянно ищем новые угрозы, нацеленные на пользователей наших продуктов, и стараемся защитить их от таких угроз. Что мы не можем сделать для вас без вашего разрешения и без вашей помощи – это оптимизировать средства защиты конкретно под вашу инфраструктуру. Например, мы не знаем, насколько легитимна установка на кон- кретный компьютер драйвера ОС, сред- ства удаленного администрирования или компонента третьеcтороннего защитного решения, уязвимого к DLL Highjacking. Во многих отраслях, включая промыш- ленные, распространена внутренняя раз- работка, при которой нужные средства автоматизации создаются непромышлен- ным способом, "из подручных материалов" (например, на основе небезопасных ути- лит или сомнительного кода с GitHub) находчивыми, но не всегда профессио- нальными разработчиками. В результате множество частных средств автоматиза- ции используют подходы и решения, пере- секающиеся с техниками злоумышлен- ников, – это сильно затрудняет разработку универсальных мер защиты от этих тех- ник, которые подошли бы всем клиентами. Зато все это можно специализировать для конкретной организации и реализо- вать в инструментарии для SOC-команды. Не думаю, что идея подключения внешних экспертов к выполнению каких-либо функций SOC несет дополнительные объ- ективные риски для организации. Понят- но, что возможны субъективные (частные) риски для ответственных лиц (например, не удастся скрыть от руководства какие- либо существенные детали, свидетель- ствующие о неправильных действиях или бездействии ответственного сотрудника, которые могут всплыть при исследовании инцидента). Что касается разделения полномочий между локальной командой и внешним подрядчиком, то оно естественным обра- зом проходит по границе экспертизы и близости к команде разработки защит- ных средств. Большинство рутинных задач по отражению известных угроз и планомерному совершенствованию мер защиты (включая и дополнительную кон- фигурацию имеющихся защитных средств, и управление уязвимостями) должно лежать на локальной команде. Внешние специалисты при этом привле- каются в качестве третьей линии под- держки – для выявления новых угроз, оркестрирования процесса реагирования на них и для доработки средств защиты. Они же, как правило, становятся источ- ником дополнительной информации об угрозах и уязвимостях на основе которой можно принимать тактические и страте- гические решения об улучшении мер защиты. Михаил Молчанов, Газинформсервис В первую очередь нужно обеспечить инженерам, эксплуатирующим и админи- стрирующим АСУ ТП, повышение квали- фикации по ИТ и ИБ, ознакомить под роспись с ЛНА по ИБ на предприятии. Затем необходимо сформировать совместные рабочие группы из специа- листов ИТ и АСУ ТП, которые станут центром компетенций для решения задач по защите АСУ ТП и обсуждения возни- кающих проблем. Для них нужно органи- зовать на постоянной основе совместные семинары для информирования об акту- альных угрозах в обеих областях, а также совместные учения по реагированию и устранению инцидентов. Немаловажной мерой является применение единых инструментов для мониторинга и управ- ления безопасностью в обеих областях. Евгений Генгринович, ИнфоТеКС Как было правильно отмечено, растет конвергенция ИТ и промышленных информационных инфраструктур, а кор- поративная культура многих компаний не меняется. Исторически она создава- лась с начала прошлого века, с появле- нием производственных конвейеров. Было логично разделить эксплуатацию по функциональным блокам, чтобы обес- печить качественный результат на выхо- де. Но с началом цифровизации и мас- совым внедрением интеллектуальных ИТ- технологий во все сферы производства, ставшее уже привычным, функциональ- ное деление стало тормозить процесс цифровизации, так как мешает специа- листам видеть "картину в целом" и пра- вильно расставлять приоритеты в экс- плуатационном процессе. На практике, надо сфокусироваться не на "устранении разрывов" – это следствие, а не причина, – а на формировании новой корпоративной культуры, которая будет предполагать, что современный инженер- технолог без знаний в области ИТ/ИБ превращается в "хромую утку" и не сможет обеспечить качественную эксплуатацию современных решений. На переходном этапе, пока большинство вузов еще не готовят подобных специалистов, решени- ем станут эксплуатационные подразделе- ния нового типа, в состав которых войдут специалисты ИТ, ИБ и технологи с фоку- сом на технологические процессы. Теперь пару слов о распространенном мифе, что объем знаний, которым должен обладать инженер-технолог, настолько велик, что нагружать его еще вопросами ИБ/ИТ невозможно. В цифровой инфра- структуре будет требоваться относительно немного описанных выше инженеров-тех- нологов, команда максимум из 4–5 человек на крупную корпорацию. Работу на местах смогут выполнять специалисты-технологи со средним специальным образованием, которые будут иметь в эксплуатации гото- вое решение, как мы пользуемся смарт- фоном, не понимая, как он устроен. За счет централизованных платформ управления и защиты данных, цифровых двойников и киберполигонов, будет воз- можность проанализировать любой отказ и устранить, используя удаленные под- ключения или "руки" специалистов-тех- нологов на местах. На следующем этапе развития технологий, таких специалистов повсеместно начнут замещать роботы. Илья Карпов, BI.ZONE У ИТ и АСУ ТП много общего. И там, и там часто используют одни и те же решения и принципы построения сетей, операционные системы и офисные акти- Как на практике устра- нять разрывы между защитой ИТ и АСУ ТП? Какие форматы взаимо- действия, распределе- ния ответственности и (или) объединения экс- пертизы могут оказаться наиболее успешными? 60 • СПЕЦПРОЕКТ