Отчет по gap-анализу
Хотелось бы сказать несколько слов по поводу отчетов по gap-анализу (сравнение текущей ситуации as-is с тем что должно быть по стандарту to-be).
В моем случае я имею один отчет по трем задачам - сравнение с ISO/IEC 27001:2005, со стандартом по информационной безопасности Банка России CTO ИББС и анализ уязвимостей систем (pentest + vulnerability scan). Собственно с этого отчета и начались наши работы - руководство осознало проблему и был разработан план работ (устранения уязвимостей и приведения в соответствие).
Проблема заключается в том, что такие отчеты обычно разрабатывают в крайне не удобном виде - нет возможности высылать разделы отчета по частям в отделы в рамках их компетенции - в план, к сожалению, суть идентифицированных проблем не помещается, да и не для этого он.
Суть моих рекомендаций, для тех кто будет такие отчеты писать или заказывать эти работы у других компаний, заключается в разбитии отчета на несколько частей со своим титульным листом (разбить физически и логически):
- отдельно выводы для руководства;
- отдельно выводы для специалистов по нормативным документам;
- отдельно выводы по системным продуктам (ЛВС, системное ПО и прочее);
- отдельно выводы по прикладным системам (желательно, чтобы каждая система описывалась в отдельном разделе);
- отдельно выводы по СУБД;
- отдельно по нарушениям законодательства (комплайнс);
- отдельно выводы по физической безопасности;
- отдельно выводы по управлению СМИБ (риски, внутренние аудиты и прочее);
- отдельно описание разделов стандарта и чего по ним не хватает, чек-листы, формы интервью, протоколы сканирования и почее.
Такая структура имеет более удобный вид представления, позволяет рассылать что нужно кому нужно и грифовать не все, а только отдельные документы (приложения).
