20 шагов по построению системы измерения ИБ

На днях готовил материалы для круглого стола конференции VolgaBlob Trend 2015.

На одном из слайдов презентации хотел показать шаги по построению системы измерения ИБ. Хотя это процедура в целом и описана в некоторых стандартах и "лучших" практиках, но я решил существенно пересмотреть (и детализировать) ее с учетом своего опыта по внедрению СУИБ по 27001 и, вообще, здравого смысла. Вот, что получилось.

Шаги по построению системы измерения ИБ:

1. Решить, что готовы к измерению ИБ. Редкие специалисты по ИБ готовы к измерению результатов своей деятельности. Причин для этого могу выделить несколько:

• этому не обучают в ВУЗах (обычно);
• сложно найти действительно полезные рекомендации, известные стандарты и "лучшие практики" (например, ISO 27004:2009, NIST SP 800-55 Revision 1, CIS Security Metrics v1.1.0 (2010), ITU-T X.1208, COBIT5, ITIL) не дают даже приблизительного примера перечня метрик;
• руководство обычно не просит измерять ИБ, нужна собственная инициатива;
• уже пробовали вводить систему метрик и показателей, но она не прижилась (обычно из-за сложности сбора данных и отсутствия поддержки руководства);
• высокая загруженность по другим задачам;
• низкий уровень зрелости процессов ИБ (по-хорошему, к измерениям стоит переходить при достижении стабильного 3го уровня - формализация и документирование требований и процедур);
• или что-то другое...

2.  Определить заинтересованных лиц и их ожидания. Необходимо четко понимать кому будут представляться результаты измерений. Основным потребителем будет, конечно, руководитель ИБ, но могут быть и другие, например, руководитель организации, руководитель департамента ИТ, члены комитета по ИБ, сотрудники подразделений ИТ и ИБ, служба внутреннего контроля. служба контроля качества или кто-то еще...

3. Определить перечень внутренних и внешних требований. Чаще всего таких требований не бывает, но есть исключения (например, оценка соответствия и обязательные отчеты для банков. стандарты Газпрома и пр.). Так или иначе, рекомендую проверить это заблаговременно.

4. Определить цели измерений ИБ. Да, я считаю, что к определению целей стоит подходить лишь на 4м этапе, после того, как вы уже соберете первичную информацию и ожидания заинтересованных сторон. Простыми примерами базовых целей будут: необходимость обоснования бюджетов, определение "проблемных" областей в системе ИБ для дальнейшего совершенствования, формальное выполнение требований (см.п.3).

5. Определить перечень возможных источников данных. Этого стоит определить еще до выбора метрик. Идея проста: собирать результаты измерений ИБ обычно довольно трудозатратно, и если вы не сможете автоматизировать этот процесс, то "закопаетесь" (см.п.11) и скорее всего откажетесь от измерений вообще.

6. Определить группы (домены) метрик и показателей. Это упростит в дальнейшем выбор метрик и показателей.

7. Определить перечень метрик и показателей. Как я уже говорил, хороший перечень метрик и показателей найти будет сложно, скорее всего придется придумывать свои. Кстати, если вы заметили, я разделяю понятия "метрики" (фактические / абсолютные результаты измерений. например, "количество  ноутбуков", "количество инцидентов с высоким приоритетом") и "показатели" (относительные значения, результаты действий с метриками, обычно выражены в %, например, "% инцидентов, закрытых в срок", "% АРМ, соответствующих требования по настройке СЗИ"). Мне так удобнее...

8. Определить перечень интегральных показателей. По сути, тут можно перейти от "технических" низкоуровневых метрик к верхнеуровневым. Довольно удобно бывает использовать такие неочевидные показатели как, например, "степень защищенности активов", "общий уровень ИБ", "уровень трудовой дисциплины". Значения этих интегральных показателей рассчитываются по несложным формулам из уже определенных показателей (см.п.7). Формулой чаще всего выбирается среднее арифметическое, сумма значений с выбранными коэффициентами, произведение показателей, мода или медиана значений.

9. Определитель средние значения метрик и показателей для вашей отрасли (если вы найдете такие данные). Это пригодится на следующем шаге.

10. Определить граничные значения показателей. Сами по себе результаты измерений редко являются показательными. "36 инцидентов в месяц" - это много или мало? "100% устраненных уязвимостей" это вроде хорошо, но если будет 80%, это плохо? Именно для понимания и определят допустимые границы (обычно не для метрик, а для показателей). Удобно брать 3 зон: красную ("не допустимо"), желтую ("нормально, но можно лучше"), зеленую ("все молодцы")..

11. Попробовать собрать результаты измерений. Это самое веселое! У нас есть перечень метрик, теперь попробуем их собрать.

12. Пересмотреть систему метрик и показателей. Первый раз при сборе метрик мы скорее всего с удивлением обнаружим, что многие значения собирать долго и трудно (особенно если их надо получать от других людей), некоторые данные к моменту окончания сбора уже устаревают, а некоторые не так уж и нужны. Скорее всего, от многих метрик вы откажетесь, ведь "стоимость получения результатов измерения не должно превышать их ценности"...

13. Еще раз попробовать собрать результаты измерений. В своем прошлом посте я писал про интересную идею о том, чтобы выбирать такие метрики (или автоматизировать их сбор) так, чтобы на получение результатов тратилось не более 15 минут и их можно было получать не реже, чем раз в 2 недели. Если это не получается, то вернитесь еще раз к п.11.

14. Провести анализ представленных данных. Ну, это достаточно очевидно.

15. Пересмотреть граничные значения показателей. Этот пункт идет по аналогии с п.11, велика вероятность, что вы слишком оптимистично выбрали граничные значения показателей (п.9), и их стоит пересмотреть...

16. Представить результаты заинтересованным лицам.

18. Окончательно утвердить перечень метрик и показателей, граничные и целевые значения.

19. Утвердить периодичность оценки и формат представления данных (в некоторых случаях следует показывать динамику).

20. Регулярно пересматривать и совершенствовать систему измерения ИБ.

Вот, как-то так. Схема не простая, но ее не стоит бояться. Из этого лабиринта есть выход.


Из блога Андрея Прозорова