Информация TI обычно представляют собой feeds (потоки данных) или IoC (индикаторы компрометации для выявления конкретной malware или хакерского инструментария). Они содержат следующие характеристики:
Сетевые индикаторы (IP-адреса, URL, доменные имена), нацеленные на выявление взаимодействия злоумышленника с сетью интернет для upload «полезной» нагрузки на зараженный хост, компрометации данных через фишинг или связи бота с центром управления для передачи хоста под контроль злоумышленника. Если мы говорим о действительно изолированном сегменте, такие соединения по умолчанию будут неуспешны, и злоумышленники не получат контроль над потенциально зараженной машиной. Тем не менее, фиксация таких попыток и выявление пусть и не активированной, «шальной» вредоносной утилиты в критичном сегменте производства тоже очень важна.
Индикаторы хостового уровня (MD5-сумма процесса, его название, изменяемые при установке/запуске ветки реестра и т.д.), нацеленные на выявление признаков активности злоумышленника на сервере/рабочей станции в процессе запуска/закрепления вредоносной утилиты. Опять же, при общей полезности информации в зрелом сегменте АСУ ТП шансов запуститься у такого рода утилиты немного. Антивирусное ПО, адаптированное под технологические процессы, как правило, функционирует даже не в режиме работы сигнатур, а в режиме whitelisting, по умолчанию вычищая все подозрительное, что оно встречает на подконтрольных ему хостах. И точно так же – важно фиксировать запуск «странных» утилит на хостах сегмента АСУ ТП. В данном случае TI используется как инструмент атрибуции вектора атаки и злоумышленника.
В итоге для атак, направленных на АСУ ТП, гораздо больший вес приобретает крайне редкая на рынке TI информация о TTP, тактиках и подходах злоумышленников к атаке, которая позволит соответствующим образом адаптировать защитные механизмы и подходы к мониторингу и выявлению угроз в сегменте.
Эти и многие другие нюансы заставляют очень серьезно и вдумчиво подходить к процессу построения такого SOC или выбору подрядчика, а также всерьез задуматься о стратегии формирования SOC OT. Должен ли он пересекаться с SOC IT или функционировать отдельно от него, возможно ли какое-то взаимообогащение и синергия в процессах, командах и решаемых задачах.