Отчет по gap-анализу

Хотелось бы сказать несколько слов по поводу отчетов по gap-анализу (сравнение текущей ситуации as-is с тем что должно быть по стандарту to-be).

В моем случае я имею один отчет по трем задачам - сравнение с ISO/IEC 27001:2005, со стандартом по информационной безопасности Банка России CTO ИББС и анализ уязвимостей систем (pentest + vulnerability scan). Собственно с этого отчета и начались наши работы - руководство осознало проблему и был разработан план работ (устранения уязвимостей и приведения в соответствие).

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

Суть моих рекомендаций, для тех кто будет такие отчеты писать или заказывать эти работы у других компаний, заключается в разбитии отчета на несколько частей со своим титульным листом (разбить физически и логически):

• отдельно выводы для руководства;
• отдельно выводы для специалистов по нормативным документам;
• отдельно выводы по системным продуктам (ЛВС, системное ПО  и прочее);
• отдельно выводы по прикладным системам (желательно, чтобы каждая система описывалась в отдельном разделе);
• отдельно выводы по СУБД;
• отдельно по нарушениям законодательства (комплайнс);
• отдельно выводы по физической безопасности;
• отдельно выводы по управлению СМИБ (риски, внутренние аудиты и прочее);
• отдельно описание разделов стандарта и чего по ним не хватает, чек-листы, формы интервью, протоколы сканирования и почее.

Такая структура имеет более удобный вид представления, позволяет рассылать что нужно кому нужно и грифовать не все, а только отдельные документы (приложения).

05-05-2009  | Permalink |