justify gt;
Рис. 9. Інтерфейс введення даних
На рис. 10 можна подивитися графіческеое уявлення кількісних і якісних оцінок по кожному з елементів матриці. Тут наочно показано як порівнюється заданий рівень безпеки з досягнутим.
Рис. 10. Порівняння заданого і досягнутий рівень безпеки.
Далі за допомогою інтерфейсу на рис 11. є можливість отримати уявлення про ситеме захисту в цілому. Її еффектіность наочно відображена графічно, а також розрахована у вигляді узагальнених показників рівня безпеки (кількісного і якісного)
Рис. 11. Графічекое уявлення оцінки еффетівності СЗІ.
Не варто забувати, що вимоги до СЗІ мають різну ступінь важливості, яку необхідно враховувати при розрахунках, використовуючи відповідні коефіцієнти важливості.
интерфес для введення коефіцієнтів важливості представлений на рис. 12.
Рис. 12. интерфес для введення коефіцієнтів важливості
Найпростіше оцінюється якість реалізації механізмів захисту.
Механізм не тільки повинен функціонувати, але й залишати сліди своєї діяльності, ці сліди повинні регулярно перевірятися, а результати перевірки повинні підтверджувати коректність його функціонування. Контроль доступу повинен супроводжуватися документуванням заявок на надання доступу та проведенням вибіркових звірок, управління оновленнями - вибірковою перевіркою серверів і робочих станцій, межсетевое екранування - періодичним переглядом правил фільтрації.
Всі дії щодо контролю повинні залишати документовані сліди: хто проводив таку перевірку, що він перевірив і чому прийняв рішення про коректне або некоректному функціонуванні механізму захисту. І хоча підрозділи ІТ традиційно вважають такий контроль віднімає час бюрократією, це один з найбільш цінних методів контролю, що не дає системі захисту деградувати.
У середньому періодичний контроль механізмів захисту з циклом в шість місяців в компанії з 500 чоловік забезпечує повне завантаження одного внутрішнього аудитора.
Адекватність заходів захисту звичайно оцінюється методами аналізу ризиків, описаними в стандартах серії ISO 13335. Цей підхід справедливо критикується - адже оцінка ризиків так чи інакше базується на суб'єктивній думці експерта. Тим не менш, зіставлення суб'єктивної оцінки потенційною загрозою з об'єктивним розрахунком витрат на впровадження механізму захисту - основний метод оцінки адекватності застосовуваних заходів.
Найпростіше оцінювати адекватність заходів захисту для систем, безпосередньо пов'язаних з основними бізнес-функціями компанії. Відмова мережевого комутатора в торговому залі супермаркету призведе до неможливості обслуговування покупців, тобто збиток магазину дорівнює виручці, недоотриманої за час, витрачений на усунення несправності. При цьому потрібно враховувати, що відмови мережевого обладнання порівняно рідкісні, і середній час простою одного комутатора може становити приблизно 0.1% від загального часу його експлуатації. Якщо вважати, що термін служби пристрою рівним трьом рокам, сумарні витрати на забезпечення відмовостійкості мережевої інфраструктури будуть адекватні загрозі, якщо вони не перевищать 0.1% від трирічної виручки магазину.
Зрозуміло, це дуже груба прикидка. Найчастіше оцінка ризиків в чому грунтується на суб'єктивній думці експерта, і три групи експертів можуть дати три сильно відрізняються результату.
Найскладніше оцінюється достатність заходів захисту, і тут використовується комбінація з декількох методів. Стандарти в галузі управління інформаційної безпеки, такі як ISO 27001, IT Baseline Protection Manual, Global Technology Auditing Guide або ISM3 містять досить докладні каталоги механізмів безпеки, реалізація яких забезпечує достатній захист інформаційних ресурсів більшості компаній. Однак немає ніякої гарантії, що саме ваша компанія ставиться до цієї більшості.
Спробою уніфікувати підходи до оцінки достатності механізмів захисту став прийнятий у 2001 році і постійно розвивається стандарт ISO 15408. Методика, запропонована в стандарті, припускає, що для заданих власником цілей можна підібрати набір вимог безпеки так, що їх реалізація в інформаційній системі приведе до досягнення поставлених цілей. Практика показала, що розробити за допомогою цієї методики систему вимог для скільки-небудь складної системи неможливо: формалізований у відповідності зі стандартом документ стає абсолютно нечитабельним. Зараз стандарт використовується тільки для сертифікації програмних продуктів.
Ще один підхід - розрахунок метрик, коли окремі аспекти безпеки інформаційної си...
