Критичность инцидента зависит от критичности активов, затронутых инцидентом. В эпоху тотальной автоматизации хотелось бы, чтобы алерты автоматически размечались, что они происходят на критичном сервере, а для этого список критичных серверов надо точно знать в любой момент времени.
Мы помним, что наша цель - защита бизнес-процессов (БП), а защита конкретных серверов - следствие. Поэтому на предприятии имеется карта БП с указанием критичности, а для каждого БП - список информационных систем (ИС), его автоматизирующих, а для ИС уже список серверов\хостов в составе ИС. Просто перечисление критичных серверов для указания его в конфигах автоматики, повышающей приоритет алерта, - тупиковый вариант, поскольку список хостов в составе ИС может вполне себе бодро меняться, а если БП и ИС - много, то такие изменения постоянны, поэтому контролировать список критичных серверов невозможно. Решение здесь очень простое - стандартизация имен хостов, чтобы в имени присутствовал признак защищаемого БП (или хотя бы ИС, что тоже, как правило, меняется нечасто - новые ИС появляются в рамках проектной деятельности ИТ, а, следовательно, в рамках этого же проекта можно заложить работы по обновлению списка критичных ИС). Имея в составе имени сервера суффикс\префикс защищаемого БП\ИС, критичность сервера можно определять непосредственно из имени актива. Тогда наша автоматика, повышающая критичность алерта от критичности сервера будет просто небольшим списком регулярок, а не огромным списком конкретных имен критичных серверов, который устаревает в течение пары недель.
После того, как реализовали описанный выше "quick win", можно пойти дальше - коррелировать релевантность ущерба для сервера. Расскажу просто и грубо, исключительно для целей быстрого объяснения, на практике же классификация может быть довольно развесистая. Для каждого БП мы имеем карту угроз - чего боимся, применительно к этой ИС: для такой-то ИС, нам критична только конфиденциальность, а для такой-то ИС - только доступность. Похожее упражнение надо сделать и для правил обнаружения: такой-то ханат\детект обнаруживает угрозу конфиденциальности, а вот этот - угорозу доступности, а вот этот - пока не ясно что, укажим, что все. На практике последних будет большинство, но относительно узкоспециализированных, применительно к ИС с теми же значимыми угрозами, также требуется повышать приоритет. Проще говоря, логика выглядит так: обнаружено действие, влияющее на конфиденциальность, применительно к ИС, для которой критична тоже конфиденциальность - поднимаем приоритет алерта.
Замечу, что обогащать детекты релевантностью угрозы не менее полезно, чем разметка по ATT&CK, а может, и более, а по трудоемкости сравнимо. При этом мы добиваемся немного большей фокусировки: один и тот же детект, применительно к разным ИС будет подниматья с разным приоритетом\критичностью, а если мы будем риск потенциального ущерба ИС обкладывать точечными, узкими детектами, то это позволит в момент детекта лучше подсветить контекст происходящего (не только то, какая техника используется атакующим в соответствии с классификацией MITRE)
Мы поговорили про имена хостов, но аналогичный подход со стандартизацией именования и настроек правил на маски имен применим и к учетным записям, например, инциденты с участием администраторов домена тоже могут иметь автоматически повышаемый приоритет.
