Открытыми остаются конкретные практические вопросы, влияющие на эффективность работы отдела ИБ АСУ ТП. Например, как автоматизированно получать актуальную информацию об активах, как сократить время на анализ инцидентов, мониторинг сетевого трафика и логов СЗИ и так далее. Об этом и пойдет речь на сегодняшнем мероприятии.
В сегодняшнем мероприятии участвуют Мария Зализняк, продуктовый менеджер InfoWatch ARMA и Равиль Зулькарнаев, руководитель отдела защиты информации InfoWatch ARMA.
Сегодня речь пойдет о автоматизации работы сотрудников ИБ АСУТП. Чтобы понять, что же конкретно нужно автоматизировать, посмотрим чем заполнены дни, недели и месяцы сотрудников ИБ сейчас.
В разных компаниях это может быть по-разному. Но основные блоки представлены на слайде. И на первом месте блок работы с документацией. Документацией непосредственно категорирования объектов критической инфраструктуры, написания, редактирования организационно-распорядительной документации или любые другие отчеты, которые требуются регулятором. Но, если говорить про другие виды отчетов, которые формируются на ежедневной систематической основе в защищенной сети, это, будут журналы инцидентов, куда включены статусы по их расследованию, которые предоставляются для внутреннего использования. Но для того, чтобы составить эти отчеты, нужно сначала выявить инциденты, отреагировать на них, с возможным выездом на конечные точки для того, чтобы локализовать их. Блок расследования инцидентов по безопасности в некоторых компаниях отдан на аутсортинг, у кого-то на СБ, кто-то сам расследует при помощи своих сотрудников ИБ.
Здесь представлен блок, который сложно автоматизировать - это контроль подрядчиков. Туда входят такие задачи, как составление технического задания, участие в рабочих группах по внедрению СЗИ, приемка по ПМИ и составление актов по разногласиям и т.п.
Но, после того, как СЗИ нам поставлены, их требуется развернуть, настроить, установить политики безопасности под требования вашей конкретной организации и в дальнейшем - эксплуатировать.
И закрывающим блоком здесь является инвентаризация оборудования АСУТП. Тут мы не указали такие задачи и процессы, как инструктаж сотрудников при приеме на работу, выдача персональных учетных записей для оборудования и др.
Но, если говорить о перспективах дальнейшей автоматизации, давайте посмотрим, что на данный момент уже автоматизировано с применением и внедрением SIEM-систем. До того, как SIEM -системы были внедрены, основной работой сотрудников ИБ АСУТП было проведение ТО СЗИ разного уровня сложностей на разных участках. Туда входили такие задачи, как снятие логов с систем защиты трансформации, обновление правил, проверка USB-устройств и какие-то дополнительные работы, которые производились ежедневно на разных участках с разным уровнем сложности. И только после этого сотрудники приступали к анализу логов, регистрации инцидентов, реагированию на эти инциденты самостоятельно либо с привлечением сторонних служб таких, как СБ, например, или каких-то других. И после этого приходилось составлять документацию.
И вот внедрили новую систему. Логи собираются автоматически, формируются инциденты, и кажется, вот она, долгожданная автоматизация наступила. Но с приходом SIEM у нас появились дополнительные задачи. Нам нужно внедрить SIEM-систему, настроить ее, обновить, развернуть политики безопасности. Все эти дополнительные задачи ложатся на плечи сотрудников ИБ. Но от работы с документацией нас ничто не спасает.
Следующей волной автоматизации будет переход на XDR, что даст расширенную возможность обнаружения инцидентов и автоматическое реагирование на них. А некоторые системы позволят даже упростить инвентаризацию самого оборудования.
Так ради чего же сотрудники ИБ каждый день совершают такие подвиги? Даже с хорошо настроенной SIEM системой они тратят большое количество времени на сами задачи. Во-первых, они вынуждены это делать ради выполнения требований регуляторов, и во-вторых, ради обеспечения кибербезопасности вверенных объектов. Эти два пункта нельзя, конечно, рассматривать порознь. Потому что они оба направлены на решение общей задачи: сохранение в рабочем состоянии объекты критической инфраструктуры и АСУТП в частности.
Почему же нужно автоматизировать работу отделов ИБ АСУТП? Для этого есть две причины. Первая состоит в том, что постоянно увеличиваются требования регуляторов ИБ. До вступления в силу ФЗ N187 у сотрудников итак было большое количество задач.
А после вступления в силу этого закона задачи дополнились категорированием объектов, внесением изменений в уже откатегорированные объекты, контроль подрядчиков, внедрение, настройка, эксплуатация. Все это дополнительным грузом легло на плечи сотрудников ИБ. Что-то из этого можно автоматизировать, но не все. А второй причиной, объясняющей, почему нужно автоматизировать рабочие процессы сотрудников ИБ является кадровый голод.
Еще в 2017 году аналитики дали прогноз о том, что к 2022 году в направлении безопасности будет дефицит кадров в размере 1,8 млн человек. Это должно стать катализатором для того, чтобы передавать софт внешним подрядчикам, и при выборе СЗИ акцент будет делаться на автоматическом реагировании на инциденты и сама экспертиза будет в руках системных интеграторов. Это мы сейчас как раз и наблюдаем. Но, несмотря на кадровый голод, кибербезопасность необходимо обеспечивать, нас от этого никто не избавит. Это можно делать решениями разных вендоров.
Мы подходим к обеспечению кибербезопасности Infowatch ARMA с помощью трех компонентов. Они представлены на слайде. Это, во-первых, Industrial Firewall - межсетевой экран нового поколения, который позволяет обеспечивать защиту АСУТП на сетевом уровне. Во-вторых, это решения по защите рабочих станций Infowatch ARMA - Industrial Endpoint. И, в-третьих, централизованная система управления Infowatch ARMA - Management Console. Как вы знаете, мы закрывает до 90% технических требований приказа 239. Со второго квартала эта доля увеличивается, потому что мы выпускаем на рынок Industrial Endpoint с антивирусом. С помощью наших продуктов можно выполнять эшелонированную защиту и автоматизировать работу сотрудников ИБ.
Что же делать, если у вас внедрены СЗИ разных вендоров, недостает людей для того, чтобы управлять всем этим зоопарком, не выделяются бюджеты на наем новых сотрудников, а регуляторы постоянно требуют дополнительные отчеты? В этом нам на помощь приходят решения класса XDR, которые позволяют не только обнаруживать сами инциденты, но и дополнительно автоматически реагировать на них и давать расширенный анализ сети и конечных точек.
Решения класса XDR позволяют получить не тысячи инцидентов, а всего несколько. В каждом инциденте связанные события выстраиваются в цепочку атак, и некоторые также позволяют управлять средствами защиты из одной точки. Но, как мы знаем, не все они одинаково полезны. И, порой, автоматическое реагирование на инцидент, которое обосновано в корпоративной сети, совсем неприемлемо для промышленной, либо приемлемо, но с какими-то оговорками. Ведь мы знаем, что часто ущерб от инцидента может быть значительно ниже, нежели ущерб от остановки производственного процесса для того, чтобы этот инцидент был устранен.
Именно поэтому мы хотим представить наш подход к промышленному XDR, который позволяет управлять всеми системами защиты Infowatch ARMA из одной точки, управлять инцидентами безопасности и расследованиями. Доступно автоматизированное реагирование на инциденты, это не автоматическое реагирование, но автоматически будут проходить только те действия, которые вы, как эксперт, разрешите проводить по определенным инцидентам. И, конечно же, визуализация информационных потоков, которые проходят в вашей сети. Именно с помощью нашей системы сотрудники ИБ АСУТП могут сократить время на выполнение ежедневных задач.
Мы уже выяснили, какие задачи стоят перед сотрудниками ИБ АСУТП, и попробуем понять, как мы можем помочь им их решать. Начнем с задачи по установке, редактированию и настройке политик ИБ, которые призваны сократить ложные срабатывания и то количество инцидентов, которое поступает сотрудникам ИБ.
Как мы подойдем к этой задаче? Во-первых, нам нужно обеспечить замкнутую защищенную среду, в которой действия злоумышленника будут ограничены. И в этом нам помогут продукты Industrial Firewall и Industrial Endpoint. Industrial Firewall позволяет нам ограничивать информационные потоки внутри сети, что актуально для АСУТП.
А с помощью Industrial Endpoint мы сможем контролировать целостность самих файлов, запуск приложений по белому списку и отслеживать подключенные носители. После того, как мы обеспечили замкнутую защищенную среду, мы подключаем наш СЗИ к единой консоли управления. Хочу заметить, что подключение одного источника занимает примерно одну минуту. И, после того, как мы подключили все источники, мы можем начать настраивать политики безопасности из одной точки.
Например, мы можем настроить одну эталонную конфигурацию Endpoint по всем ее функциям, и далее по нажатию одной кнопки раскатить ее на все подключенные системы защиты этого типа с тем, чтобы все конфигурации совпадали. Также мы можем обновить из единой консоли антивирусные базы, также по нажатию одной кнопки на всех Endpoint. И, что касается Firewall, мы можем также обновить конфигурации и обновить правила soft для всех Firewall нашей сети, подключенных к единой консоли управления.
Мы подключили наши источники событий, которые потекли, и встроенные правила корреляции начинают работать и генерировать инциденты. Вы можете сами создавать и редактировать правила корреляции под свои задачи, но основную экспертизу система Infowatch ARMA поставляет «из коробки». В рамках правил корреляции вы можете сами формировать те действия, которые можно будет совершать в автоматическом режиме для конкретного инцидента. Это такие действия, как создание правил межсетевого экрана и отправка их на конкретные, либо на все межсетивики, запуск исполняемых файлов и другие варианты, доступные в интерфейсе. В рамках правил корреляции вы можете оставлять рекомендации и последствия, которые оказывает данный инцидент на дальнейшую работу. Эти рекомендации и последствия поступают сотрудникам ИБ, которые дальше локализуют и расследуют этот инцидент. Кстати, если нам пришло событие безопасности от Endpoint, то мы можем в рамках правил корреляции создать правила для межсетевика, отправить его, и ограничить дальнейшее распространение вредоноса в другие сети и на другие рабочие станции.
В рамках первого кейса мы обсудили возможность автоматизации политик ИБ и затронули часть управления самими СЗИ из одной точки. Давайте посмотрим на следующий кейс. Это реагирование на инциденты ИБ. Туда входит анализ журналов, локализация самих инцидентов с возможным выездом на конечные рабочие станции и отправка (либо нет) событий. Во-первых, не нужно постоянно анализировать журналы событий самостоятельно, потому что с помощью базовых правил корреляции инциденты создаются автоматически.
И сотрудникам ИБ приходят уведомления в интерфейс. Но, если вам нужна дополнительная информация, то вы можете сформировать точечный расширенный поисковой запрос и отправить его в базу данных. И после этого анализировать только те события, которые вас интересуют.
Что же происходит после того, как наши события скоррелированы в инциденты? Разумеется, наше реагирование на них. На слайде представлен пример автоматического реагирования на атаку, где информация о проникновении хакера в сеть поступает на консоль. На консоли формируется правило межсетевого экрана, и это правило распространяется на все межсетевики сети для блокировки этой атаки. И до промышленного сегмента эта атака не доходит.
Ну, и при необходимости, вы можете отправлять инциденты автоматически, получать от них комментарии, всячески общаться, и в дальнейшем получать бюллетени о новых обнаруженных уязвимостях.
Следующая задача, которая стояла перед сотрудниками ИБ, это выявление самих инцидентов. Как уже говорилось выше, с помощью правил корреляции автоматически формируются инциденты и приходят оповещения сотрудникам ИБ в интерфейсе, для каждого инцидента проставляется важность. Сотрудник может отфильтровать инциденты, которые на него заведены по важности и начать локализацию, либо расследование самых важных из них.
В саму карточку инцидента попадают все, связанные с ним инциденты безопасности, а также рекомендации по дальнейшей работе и, разумеется, последствия, к которым этот инцидент может привести. Инцидент может быть назначен на какого-то конкретного сотрудника, либо решить его самостоятельно. Кроме того, что инциденты можно анализировать в рамках журнала инцидентов, на нашей статистической карте вы можете увидеть те активы, на которых проходили инциденты. Они обычно у нас на карте подсвечиваются красным.
Но, если вам нужна полная картина того, как выглядит ваша сеть на данный момент, у нас есть карта сетевых взаимодействий, на которой вы сможете увидеть все активы и то, по каким протоколам они друг с другом взаимодействуют. Если же в рамках расследования вам нужно увидеть состояние сети в определенный момент, то можно с помощью фильтра выбрать нужный диапазон даты и времени и увидеть состояние карты в нужный вам конкретный момент.
И последний кейс, последняя задача, которую мы предлагаем вам рассмотреть сегодня, это работа с документацией. В ближайшей перспективе у нас появится коммерческое релиз-решение, которое позволит оптимизировать работу отдела ИБ в части категорирования объектов критической инфраструктуры, контроль мероприятий по соответствию требований регуляторов и другой функционал, который важен в процессах категорирования.
25__21_20.jpg