False или не false?

При расследовании инцидентов есть несколько ключевых моментов этого процесса для аналитиков, на которые в данной статье мы обратим внимание – это корректность самого расследования, верная категоризация произошедшего, а также приоритет. Грамотно расставленные приоритеты, а именно, правильно рассчитанная критичность инцидента, в значительной степени влияет на скорость принятия решений аналитиком и на эффективность его работы в целом.

SOC представляет собой набор людей и процессов, который, подобно живому существу, постоянно развивается и эволюционирует. Без этого сложно представить себе команду расследования. И понятная категоризация, в данном случае – понятная система метрик и понятий – помогает выстроить еще и те процессы, которые начинаются тогда, когда расследование завершено. Речь пойдет о подготовке к процессу lessons learned, или о пост-инциденте: в правках и тюнинге могут нуждаться плейбук, регламент, а зачастую и автоматизация – к примеру, может потребоваться донастройка источника или SIEM. И как раз чтобы знать, куда смотреть, на что обращать внимание, аналитик, проводящий подобную работу, руководствуется результатами предыдущих этапов – категоризацией инцидента в разрезе было или не было, выявлено правильно или неправильно.
От флага, полученного на этапе реагирования и расследования, может зависеть многое – как время аналитика, так и область поиска ошибки с дальнейшим ее исправлением.
Понимание, в какой области находится проблема, как с ней разбираться и как к ней подступиться, даже то, в какой системе эта проблема находится – ко всему этому можно прийти, разбирая случаи подтвержденных/не подтвержденных инцидентов и false positive сработок.

Источник: Хабрахабр