На практике есть разные интерпретации данного термина:
Я трактую его как конкретный сценарий реализации актуальной угрозы безопасности информации.
Имея практический опыт технической реализации Use cases, хочу обратить внимание, что, увы, очень и очень часто Use case сводится к общим словам, которые, во-первых, проблематично однозначно интерпретировать, а, во-вторых, «приземлить» в конкретное ИТ и бизнес-окружение.
Вот примеры формулировок Use cases:
К любому из компонентов описания возможны вариации:
1. Administrative accounts:
- Domain Admins (администраторы домена);
- Root (супер пользователь в *nix);
- DomainIvan.Ivanov ;
- Admin_*.
2. Multiple:
- 2 раза;
- 10 раз;
- 100 раз;
- 1 000 раз.
Кто-то скажет, что я цепляюсь к словам, и что все всё понимают, но на практике именно эти детали становятся «камнем преткновения», а так называемое экспертное обоснование далеко не всегда работает. И порой приходится проводить анализ документов и особенностей осуществления видов деятельности, лежащих далеко за пределами SOC.
На мой взгляд, в данном случае можно ориентироваться на известную фразу Микеланджело Буонарроти: «Мелочи создают совершенство, а совершенство – уже не мелочь».
Для того, чтобы оценить качество и результат проектирования и реализации Use cases, я предлагаю следующие метрики:
- количество реализованных Use cases / количество спроектированных Use cases (отражает насколько качественным был дизайн);
- количество протестированных Use cases / количество всех реализованных Use cases (отражает насколько вы можете быть уверенными, что Use cases «взлетит» в нужный момент, это актуально, т.к. далеко не все Use cases можно протестировать (например, DDoS или угрозы, связанны с 0-day уязвимостями));
- количество эксплуатируемых Use cases в SOC / количество всех спроектированных Use cases (отражает насколько качественная работа проведена, т.е. отношения «выхода» и «входа»).
Успехов в рамках процессов, связанных с Use cases!
