В преддверии SOC-форума, решил высказаться по сабжу.
Тема инцидент-менеджмента на мой взгляд одна из тех, которая должна быть в приоритетах практически любой службы информационной безопасности. В современном мире неприкасаемых не осталось, жертвами внешних или внутренних злоумышленников становятся самые разнообразные компании, включая тех, которые сами занимаются разработкой программного обеспечения или оказанием услуг в области информационной безопасности.
Есть несколько моментов, которые являются, на мой взгляд, ключевыми факторами, влияющими на успех или провал при реализации деятельности по управлению инцидентами ИБ.
Определиться что является инцидентом. Ресурсов никому никогда не хватает, пытаться все подряд называть инцидентом и реагировать - путь в никуда. Хотя большинство начинают именно с этого, сперва пытаются собирать и фиксировать все, пытаться реагировать на каждый чих, но сразу же приходит понимание того, что нужно как-то сужать фокус. Т.е движение идет от большего к меньшему, в то время как более правильный путь это движение от меньшего к большему. Уж лучше сразу целенаправленно уменьшить перечень событий, которые должны быть отнесены к инцидентам ИБ и обеспечить их корректную обработку. Далее, настроив процесс, постепенно его масштабировать и расширять на менее критичные события.
Понятная цепочка обработки инцидентов. Обработка инцидентов - это конвейер, каждый инцидент должен быть обработан по заранее согласованной схеме, которая должна быть отработана практически до автоматизма.
Готовые планы реагирования. "Время дорого" - вот главный девиз эффективного инцидент-менеджмента. Действовать надо быстро и слаженно. Здесь очень хорошо помогают готовые планы реагирования на инциденты, привязанные к типовым ситуациям: вирусное заражение, DDOS, отключение питания и проч. Понятно что если вдруг возникнет нештатная ситуация, для которой нет плана реагирования, придется импровизировать уже на ходу, но это не отменяет того, что для типовых ситуаций удастся сберечь массу ресурсов, времени и нервов.
Согласованный порядок сбора и фиксации информации по инцидентам. Инцидент нужно не только как можно скорее закрыть, устранив возможные последствия, но еще и зафиксировать набор различных сведений, которые должны помочь впоследствии провести расследование, применить меры дисциплинарного воздействия, выявить системные проблемы, накопить статистику для различных целей, в том числе для оценки рисков. Если это не реализовано, то процесс реагирования на инциденты превращается в вечный и неэффективный бой.
Тайминг. Время, время, время... Самая главная метрика эффективности процесса реагирования на инциденты ИБ - время отработки инцидента. Причем эта одна из самых простых метрик, с точки зрения ее определения. Если данные по обнаружению инцидента и данные по закрытию инцидента где-то зафиксированы, то определить среднее время обработки инцидентов не составит большого труда. За счет работы над тем, что я описал выше и рядом других моментов необходимо добиваться снижения данного показателя до необходимого для компании уровня.
Как видите все вышеперечисленное не про технические системы. SIEMы, IDSы, и проч. всего лишь инструменты, которые должны помочь реализовать стоящие перед группой реагирования на инциденты ИБ задачи и помочь с тем что я описал. К сожалению плохие, непродуманные внедрения порой становятся главным препятствием на пути к нормальному инцидент-менеджменту.
P.S. На SOC-форуме я буду вместе с моими коллегами представлять проект R-Vision. Подходите, буду рад пообщаться.
P.P.S. Что касается инструментов, то на следующий день после SOC-форума буду проводить вебинар с демонстрацией новых возможностей R·Vision SGRC по управлению инцидентами ИБ. Регистрация тут - https://rvision.pro/?post_type=event&p=1219
Facebook
==> Связаться со мной <==
