Все, кто пытается отстроить сервисы мониторинга событий безопасности рано или поздно приходят к вопросу необходимости классификации инцидентов. Здесь, как и в случае с отчетностью следует использовать подход "по цели", а уже понимание целей позволит определить критерии классификации.
1. По критичности/важности/приоритету/потенциальному ущербу, иногда сюда же замешивают "влияние". Цель здесь - приоритезация усилий по реагированию: наиболее приоритетные - в первую очередь, наименее - можно отложить. Обычно в этом случае для определения критичности используется какая-то матрица в виде (Количество затронутых пользователей) х (Критичность подразделений для предприятия, либо грейд/позиция этих людей).
2. По типу инцидента/сути инцидента. Здесь цель - организовать правильную маршрутизацию, чтобы информация об инциденте с минимальным количеством хопов попала сразу в правильную группу реагирования. Обычно здесь используются типы, как-то коррелирующие с имеющимися группам эксплуатации. Например, DOS-атаки надо как-то совместно решать сетевикам с ISP, проблему спама могут адресовать почтовые админы и админы антиспам-фильтров (если это другие люди), проблемы на Интернет-сайте предприятия разумно направить сразу админам сайта, вирусы на рабочих станциях пользователя - в поддержку рабочих мест, чтобы они вытащили сэмпл, передали админу антивируса, который направит его в поддержку, получит экстру и всех сразу вылечит. Если кто-то сливает данные на флешки/в Интернет - разумно аккуратно переговорить с его линейным руководителем, чтобы уточнить возможную бизнес-потребность такого поведения. Если кто-то сканирует сеть, надо выяснить кто это: если админ - уточнить что он делает, если пользователь - исследовать удаленно насколько это возможно, если не все понятно - направить туда поддержку рабочих мест. Полезно в ходе расследования уточнять является атака специализированной "под вас" или "просто залетело" - это также следует учитывать в классификации. .... подобные "если, то" можно продолжать бесконечно, ибо мы одарены безграничной фантазией, поэтому надо смотреть по месту.
3. По вектору атаки. Может переплетаться с "По типу инцидента" (если погуглить, то большинство из того, что выпадет в результат будет содержать слитые эти типы категорий вместе - это тоже нормально и тоже определяется вашей целью). Достигаемая здесь цель - контроль эффективности используемых систем безопасности. Если, например, у меня большинство подтвержденных взломов прошло через Интернет-прокси - надо что-то в нем менять; если большинство прилетело по почте, то надо поднастроить почтовый шлюз. Может, при просмотре статистики инцидентов будет установлено, что почти все занесли со съемных носителей, то надо поставить какую-нибудь контролировалку флешек, а может, даже и запретить копировать с них исполняемые файлы; ну а если стало известно что все наши проблемы из-за того, что пользователи не задумываясь о последствиях сливают важную информацию направо и налево, то имеет смысл заняться повышением осведомленности.
4. По источнику обнаружения. Возможно, предыдущий тип классификации вам не нужен, но есть потребность оценивать эффективность используемых систем обнаружения (имеется в виду не только IDS), тогда полезно в инциденте указывать каким образом он был обнаружен. Это позволит понимать во-первых насколько существующие системы здорово выполняют свою работу (может, их надо заменить на другие или получше подконфигурировать), во-вторых, понять в какие места еще что было бы полезно поставить, чтобы обнаруживать инциденты быстрее/дешевле.
5. ....
Атака может быть комбинацией: сначала пользователя заспамили, затем зафишили, затем drive-by, затем зловред, и понеслась... - в этом случае для более удобного анализа я бы регистрировал несколько связанных инцидентов, но опять же обязательно иметь понимание как информация об этих инцидентах будет обрабатываться и какой результат хочется получить из операционной отчетности.
Может показаться, что иметь много категорий - это хорошо, так как это покажет ситуацию в разных перспективах, но надо помнить, что множество параметров затрудняет процесс регистрации, снижает операционную эффективность процесса, чего мы всегда стремимся избегать, поэтому здесь функционал впрок тоже не нужен - любая категоризация обязательно должна под собой иметь цель.
Для облегчения первичной регистрации часть работ по классификации можно отнести на период уже после отработки инцидента: классификацию, влияющую на маршрутизацию инцидента и оперативность реагирования - делать в первую очередь, классификацию, позволяющую анализировать тренды и поддерживать какие-либо стратегические/тактические решения - можно делать уже после, в рамках Lessons learned, может, даже, специально обученными для этого людьми :)
Как видите преследуемые классификацией цели сугубо индивидуальны, сильно зависят от среды, как следствие, индивидуален и подход к классификации, поэтому универсального подхода не придумать, но, надеюсь, накидать идей/мыслей у меня получилось.
1. По критичности/важности/приоритету/потенциальному ущербу, иногда сюда же замешивают "влияние". Цель здесь - приоритезация усилий по реагированию: наиболее приоритетные - в первую очередь, наименее - можно отложить. Обычно в этом случае для определения критичности используется какая-то матрица в виде (Количество затронутых пользователей) х (Критичность подразделений для предприятия, либо грейд/позиция этих людей).
2. По типу инцидента/сути инцидента. Здесь цель - организовать правильную маршрутизацию, чтобы информация об инциденте с минимальным количеством хопов попала сразу в правильную группу реагирования. Обычно здесь используются типы, как-то коррелирующие с имеющимися группам эксплуатации. Например, DOS-атаки надо как-то совместно решать сетевикам с ISP, проблему спама могут адресовать почтовые админы и админы антиспам-фильтров (если это другие люди), проблемы на Интернет-сайте предприятия разумно направить сразу админам сайта, вирусы на рабочих станциях пользователя - в поддержку рабочих мест, чтобы они вытащили сэмпл, передали админу антивируса, который направит его в поддержку, получит экстру и всех сразу вылечит. Если кто-то сливает данные на флешки/в Интернет - разумно аккуратно переговорить с его линейным руководителем, чтобы уточнить возможную бизнес-потребность такого поведения. Если кто-то сканирует сеть, надо выяснить кто это: если админ - уточнить что он делает, если пользователь - исследовать удаленно насколько это возможно, если не все понятно - направить туда поддержку рабочих мест. Полезно в ходе расследования уточнять является атака специализированной "под вас" или "просто залетело" - это также следует учитывать в классификации. .... подобные "если, то" можно продолжать бесконечно, ибо мы одарены безграничной фантазией, поэтому надо смотреть по месту.
3. По вектору атаки. Может переплетаться с "По типу инцидента" (если погуглить, то большинство из того, что выпадет в результат будет содержать слитые эти типы категорий вместе - это тоже нормально и тоже определяется вашей целью). Достигаемая здесь цель - контроль эффективности используемых систем безопасности. Если, например, у меня большинство подтвержденных взломов прошло через Интернет-прокси - надо что-то в нем менять; если большинство прилетело по почте, то надо поднастроить почтовый шлюз. Может, при просмотре статистики инцидентов будет установлено, что почти все занесли со съемных носителей, то надо поставить какую-нибудь контролировалку флешек, а может, даже и запретить копировать с них исполняемые файлы; ну а если стало известно что все наши проблемы из-за того, что пользователи не задумываясь о последствиях сливают важную информацию направо и налево, то имеет смысл заняться повышением осведомленности.
4. По источнику обнаружения. Возможно, предыдущий тип классификации вам не нужен, но есть потребность оценивать эффективность используемых систем обнаружения (имеется в виду не только IDS), тогда полезно в инциденте указывать каким образом он был обнаружен. Это позволит понимать во-первых насколько существующие системы здорово выполняют свою работу (может, их надо заменить на другие или получше подконфигурировать), во-вторых, понять в какие места еще что было бы полезно поставить, чтобы обнаруживать инциденты быстрее/дешевле.
5. ....
Атака может быть комбинацией: сначала пользователя заспамили, затем зафишили, затем drive-by, затем зловред, и понеслась... - в этом случае для более удобного анализа я бы регистрировал несколько связанных инцидентов, но опять же обязательно иметь понимание как информация об этих инцидентах будет обрабатываться и какой результат хочется получить из операционной отчетности.
Может показаться, что иметь много категорий - это хорошо, так как это покажет ситуацию в разных перспективах, но надо помнить, что множество параметров затрудняет процесс регистрации, снижает операционную эффективность процесса, чего мы всегда стремимся избегать, поэтому здесь функционал впрок тоже не нужен - любая категоризация обязательно должна под собой иметь цель.
Для облегчения первичной регистрации часть работ по классификации можно отнести на период уже после отработки инцидента: классификацию, влияющую на маршрутизацию инцидента и оперативность реагирования - делать в первую очередь, классификацию, позволяющую анализировать тренды и поддерживать какие-либо стратегические/тактические решения - можно делать уже после, в рамках Lessons learned, может, даже, специально обученными для этого людьми :)
Как видите преследуемые классификацией цели сугубо индивидуальны, сильно зависят от среды, как следствие, индивидуален и подход к классификации, поэтому универсального подхода не придумать, но, надеюсь, накидать идей/мыслей у меня получилось.
No comments:
Post a Comment