Понятие Инцидента

Все задачи ИБ так или иначе сводятся к управлению инцидентами, поэтому понятие инцидента - принципиальный вопрос, на который нужно знать четкий ответ, прежде чем предпринимать какие-либо мероприятия по обеспечению ИБ на предприятии. Если обратиться к ГОСТР 59709 - 2022 "Защита информации. УПРАВЛЕНИЕ КОМПЬЮТЕРНЫМИ ИНЦИДЕНТАМИ. Термины и определения", то в нем можно встретить следующее определение инцидента, ставшее классическим, которое обычно все и имеют в виду, говоря об инцидентах ИБ:

Непредвиденное или нежелательное событие (группа событий) ИБ, которое привело (могут привести) к нарушению функционирования информационного ресурса или возникновению угроз безопасности информации или нарушению требований по защите информации

Для понимания этого определения нам потребуются еще определение информационного ресурса:

Информационные системы, информационно-телекоммуникационные сети и автоматизированные системы управления.

А также события ИБ:

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

Вроде, все как будто понятно, но, вместе с тем, определения имеют ряд сложностей в интерпретации, попробуем в них поразбираться.

Начнем с события ИБ, - "это состояние информационной системы (ИС), указывающее на нарушение", т.е. с точки зрения нашей классификации - это алерт. Однако фраза: "ситуацию, которая может быть значимой для безопасности" позволяет полагать, что это и сырое событие телеметрии, поскольку любое событие из любых логов ИС, безусловно, может быть значимым для ИБ. Наверно, на каком-то уровне абстрации, действительно, между событием и алертом разницы нет, так как алерт можно считать совокупностью событий, обогащенной дополнительным контекстом (как-то предобработанным событием), - надо просто для себя запомнить, что любое - первичное ли событие из логов ИС, или мета-событие\алерт из SIEM - все с точки зрения ГОСТ считаются "событиями ИБ".

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

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

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

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

Важнейший продукт Управления инцидентами - мероприятия, улучшения к нашей СУИБ, - это та самая обратная связь в демингообразном цикле бесконечного улучшения. Как мы выше разобрались, мероприятия могут быть как с возможностью нашего влияния, так и неподвластные нам. Поэтому будут инциденты как те, в отношении которых мы можем что-то поделать, так и те, которые мы можем только зарегистрировать, и, может, посокрушаться над ними, так как мероприятия по ним будут либо неэффективны и бесполезны, либо отсутствовать вовсе. Ну чтобы было понятно, приведем примеры. Допустим, у меня есть периметровый МЭ, который постоянно подвергается сканированию (допустим, просто отправка SYN по портам) из подсетей, например, провайдеров, предоставляющих Интернет для населения. Или, я пришел в публичный Wi-fi в кафе, и ко мне сразу пощемились с MS17-010... Что я могу сделать еще по этим инцидентам, с учетом того, что у меня уже есть сетевой периметр (и на десктопе тоже), защищающий от подобного рода сценариев? А если по этому инциденту нечего поделать, имеет ли смысл регистрировать такой инцидент? Зачем учитывать то, с чем мы далее ничего не делаем? Мы же не хотим делать работу ради работы. Допустим, даже есть сценарии когда мы стремимся подметить тенденцию и оформить некоторую проблему в рамках нашего процесса Управления проблемами, например, заметить, что у нас очень часты вот такие "инциденты", с которыми мы ничего не делаем. Возможно, для внутреннего корпоративного SOC это будет иметь смысл, именно как для входных данных для Управления проблемами.

Еще один очень важный момент: если "инцидент" не создает дополнительных рисков ИБ, то это точно не инцидент. В приведенном выше примере со сканированием дополнительные риски создаются, но они компенсированы техническими контролями - системами защиты сетевого периметра, а остаточный риск принят как допустимый, поэтому сканирование внешнего МЭ в общем случае не инцидент. Во втором случае с попытками эксплуатации CVE-2017-014* в кафе - не инцидент, так как с этим ничего нельзя поделать. Аналогичный сценарий, но в корпоративной сети, уже будет инцидентом - рассылающий эксплоит хост можно найти и полечить, а также расследовать, как он был скопрометирован. Инцидент, по которому есть что поделать, будем называть actionable.

В связи с обозначенным отсутствием необходиомости учета "инцидентов" за рамками наших способностей по разрешению\реагированию, я бы предложил наши возможности по управлению инцидента интегрировать непосредственно в техническое определение инцидента, и в рамках процесса Управления инцидентами в SOC считать инцидентом только то стечение обстоятельств, на которое существует эффективная реакция, хотя бы потенциальная (т.е. допустим, в данный момент времени у нас нет каких-то технических решений, но в принципе они есть), т.е. инцидент всегда обязательно actionable.

Описанный подход ограничения термина инцидента только тем, на что можно влиять, не выдерживает критики с позиции корпоративного SOC, поскольку не всегда в рамках процесса Управления инцидентами можно оценить потенциальную степень влияния корпоративных ИТ и ИБ на снижение риска, релевантного инциденту (сложно написал, поэтому скажу проще: группа мониторинга может ошибаться, решив, что на инцидент нельзя предложить реакцию == он не actionable, или для принятия решения о существовании реакции требуется проект\исследование). Например, группа мониторинга, принимающая решение инцидент\не инцидент может не быть в курсе стретегических планов ИТ об изменениях ИТ-инфраструктуры, скажем, переходе на гибридное облако, с соответствующими изменениям СУИБ. И даже больше, нормальная практика SOC - в спорных ситуациях, когда не понятно регистрировать инцидент или нет, всегда лучше зарегистрировать, так как ложное срабатывание всяко лучше, чем пропуск.

Для поставщиков услуг SOC/MDR подобное сужение понятие инцидент до исключительно actionable - хороший и правильные выход, так как, с одной стороны, он не ограничивается жестко предопределенными сценариями на которые реагирует SOC (я такие варианты встречал в практике SOC Consulting), а с другой стороны такой подход позволяет SOC сфокусироваться на наиболее значимых, с точки зрения возможностей SOC и знаний об инфраструктуре заказчика, инцидентах, исключая публикацию слабо полезных инцидентов (типа, попыток брута системы удаленного доступа из Интернет, при наличие 2FA с использованием, например, SecureID), позволяет иметь возможность всегда предоставить рекомендации по управлению инцидентом (едва ли заказчик будет рад, получив инцидент с которым не указано, да и вообще не понятно, что делать).

Мы очень много вопросов коснулись в этой статье, поэтому в заключение изложенного потока сознания тезисно остановимся на основных моментах:

1. Понятие инцидента - принципиально, это важнейший вопрос по которому необходимо синхронизоваться SOC и потребителю его услуг.
2. Определение по ISO ГОСТ непротиворечиво, его можно взять за основу, но для практического использования его следует уточнять и конкретизировать.
3. Если инцидент впоследствии не создает рисков ИБ, то это не инцидент - этот критерий применим к любой модели операционной безопасности.
4. Большое значение имеет контекст: одна и та же ситуация в зависимости от условий может считаться инцидентом, а может таковым и не являться.
5. Для поставщика услуг SOC/MDR разумно основным критерием инцидента считать наличие эффективных и результативных мероприятий по управлению им, т.е. инцидент только тогда инцидент, когда он actionable.