К сожалению, большинство коллег, с которыми мне приходилось общаться, считают отчетность ненужной рутиной и, тем более, не рассматривают ее как тактический инструмент совершенствования своей СУИБ. Такое отношение порождает неверный подход к изобретению отчетности: в лучшем случае - это демонстрация выполненных работ, типа "вот как я много всего сделал", в худшем - это просто демонстрация чего-угодно, "чтобы только отстали". Это неправильно, так как выходные данные моего operations-а являются входными данными для моей СУИБ, а транспортом этих данных является не что иное как отчетность! Ну и как же это сделать?
Прежде всего надо определиться с целями, я люблю использовать термин "отчетность по цели", тогда в общем виде построение "отчетности по цели" будет выглядеть так:
Мутновато, поэтому поясню на примере. Например, у меня есть куча систем мониторинга безопасности и целью отчетности я ставлю - выработка плана развития моих технических средств обеспечения ИБ. Под "планом развития" будем понимать модернизацию/модификацию существующих и/или внедрение новых СЗИ. Имея такую цель попробуем определить метрики: 1) по каждому инциденту определять с использованием какой системы он был а) обнаружен, б) расследован, в) локализован и т.п.; 2) по каждому инциденту определять какие системы должны были, но ничего не сделали (false negatives); 3) особо следует отразить ложные срабатывания (false positives); 4) крайне полезно раскладывать инциденты по векторам атак, например: 1) внешняя почта, 2) внешний веб, 3) съемные носители, 4) подключаемая в сеть некорпоративная техника, 5) ошибки групп эксплуатации при реализации изменений, и т.п.
Получив все эти данные самое время подумать над п.3 нашего общего плана построения "отчетности по цели" - как отобразить эти метрики наиболее наглядным образом (это и будет наша отчетность!). Имея распределение инцидентов по векторам атак, а по каждому инциденту перечень систем безопасности (инструментов) с помощью которых мы управляли инцидентом, получаем распределение систем по векторам с подтверждением их эффективности, поскольку инцидент подтверждает эффективность системы безопасности. Ну, скажем, у нас стоит какая-то система мониторинга и защиты внешней почты, однако, при работе ни с одним инцидентом прилетевшим по почте она не использовалась - с этим надо что-то делать. Или у нас стоит дорогущая система контентной фильтрации, однако все внешние взломы через Веб мы фиксировали уже по успешным отстукам ботов на свои C&C по логам внутренней IDS - свидетельствует что все либо ходят мимо нашего прокси, либо он настроен некорректно...
В целом, полагаю, идея понятна - можно придумать бесконечное количество перспектив, но цель отчетности должна быть - мотивация к действию, помощь в выборе направления этих действий..., отчетность должна помогать предсказывать будущее, а не констатировать прошлое.
Прежде всего надо определиться с целями, я люблю использовать термин "отчетность по цели", тогда в общем виде построение "отчетности по цели" будет выглядеть так:
- определяем цели;
- определяем метрики, т.е. как понять степень достижения целей;
- понимаем как можно отобразить недостатки, т.е. причины неполного достижения целей.
Мутновато, поэтому поясню на примере. Например, у меня есть куча систем мониторинга безопасности и целью отчетности я ставлю - выработка плана развития моих технических средств обеспечения ИБ. Под "планом развития" будем понимать модернизацию/модификацию существующих и/или внедрение новых СЗИ. Имея такую цель попробуем определить метрики: 1) по каждому инциденту определять с использованием какой системы он был а) обнаружен, б) расследован, в) локализован и т.п.; 2) по каждому инциденту определять какие системы должны были, но ничего не сделали (false negatives); 3) особо следует отразить ложные срабатывания (false positives); 4) крайне полезно раскладывать инциденты по векторам атак, например: 1) внешняя почта, 2) внешний веб, 3) съемные носители, 4) подключаемая в сеть некорпоративная техника, 5) ошибки групп эксплуатации при реализации изменений, и т.п.
Получив все эти данные самое время подумать над п.3 нашего общего плана построения "отчетности по цели" - как отобразить эти метрики наиболее наглядным образом (это и будет наша отчетность!). Имея распределение инцидентов по векторам атак, а по каждому инциденту перечень систем безопасности (инструментов) с помощью которых мы управляли инцидентом, получаем распределение систем по векторам с подтверждением их эффективности, поскольку инцидент подтверждает эффективность системы безопасности. Ну, скажем, у нас стоит какая-то система мониторинга и защиты внешней почты, однако, при работе ни с одним инцидентом прилетевшим по почте она не использовалась - с этим надо что-то делать. Или у нас стоит дорогущая система контентной фильтрации, однако все внешние взломы через Веб мы фиксировали уже по успешным отстукам ботов на свои C&C по логам внутренней IDS - свидетельствует что все либо ходят мимо нашего прокси, либо он настроен некорректно...
В целом, полагаю, идея понятна - можно придумать бесконечное количество перспектив, но цель отчетности должна быть - мотивация к действию, помощь в выборе направления этих действий..., отчетность должна помогать предсказывать будущее, а не констатировать прошлое.
No comments:
Post a Comment