19. Моделювання загроз.

Термін "моделювання загроз" має безліч значень. Для відповіді на питання "що таке моделювання загроз"? я скористаюся дескриптивним підходом і опишу, як може використовуватися цей термін, замість того, щоб намагатися підібрати для нього одне строге визначення. Отже, розглянемо найбільш поширені значення: термін " загроза" використовується для позначення як зловмисників, тобто людей, що атакують систему, так і ризиків, тобто тих небажаних подій, які можуть статися. Моделювання загроз може відноситися як до методики встановлення вимог до системи("яка прийнята Вами модель загроз"?), так і до методики конструкторського аналізу("дозвольте поглянути на Ваш аналіз моделі загроз"?). Крім того, моделювання загроз може будуватися на розгляді ресурсів, зловмисників або програмного забезпечення. Моделювання загроз, орієнтоване на ресурси, часто включає різні рівні оцінки, апроксимації або ранжирування ризиків. Моделювання загроз з акцентом на зловмисниках іноді включає ранжирування ризиків або оцінку ресурсів, можливостей і мотивацій(виконання таких оцінок представляє украй складне завдання для розробників пакетів програм широкого застосування, оскільки різноманітність варіантів використання тягне і різноманітність загроз, пов'язаних з кожним конкретним застосуванням). Кожен підхід до моделювання загроз має свої сильні і слабкі сторони, на яких я при необхідності зупинятимуся, пояснюючи деякі інші аспекти або описуючи отриманий досвід. Крім того, про моделювання загроз можна говорити стосовно аналізу програмних продуктів, організаційних мереж, систем або навіть промислових секторів. Моделювання протоколів часто виконується з використанням різноманітних формальних методів, іноді званих моделями мережевих загроз. Термін "моделювання мережевих загроз" також використовується при аналізі розгорнутої мережі. Нарешті, моделювання загроз може виконуватися експертами по безпеці з подальшою передачею результатів інженерам, спільно експертами і інженерами або одними інженерами без участі експертів. Фахівці з безпеки можуть засумніватися в цінності останнього підходу. Проте, існує, принаймні, дві причини, по яких варто проводити моделювання загроз без експертів. По-перше, експерти можуть бути просто відсутніми в організації по фінансових або іншим причинам. По-друге, залучення до процесу моделювання людей, які розроблятимуть систему, але які не є фахівцями з безпеки, дозволяє їм відчути свою причетність до захисту системи і набути розуміння моделі безпеки. Моделювання загроз включає безліч різних процедур по виявленню вимог до безпеки системи і по аналізу різних схем захисту. Не існує одного " кращого" або " правильнішого" методу моделювання загроз, навпаки, необхідно поєднувати і комбінувати різні альтернативи для того, щоб досягти явно заданих або прихованих цілей.

Сучасна методологія SDL . Сучасна методологія моделювання загроз в SDL є процесом, що складається з чотирьох етапів, розроблений для того, щоб скоротити об'єм експертних оцінок безпеки, які потрібні інженерам для побудови моделі загроз і упевненості в тому, що усі серйозні загрози дійсно були визначені. Цілями цієї процедури є підвищення рівня безпеки розробок, документування подій, пов'язаних із захистом продуктів, і навчання працівників питанням захисту системи в процесі розробки. Метод включає чотири основні етапи: побудову діаграм, перерахування загроз, зниження ризиків і перевірку.

Моделювання загроз як tabula rasa. Багато фахівців, маючи своє уявлення про те, як повинне виглядати моделювання загроз(термін, що має, як я вже відмітив в розділі 1.1, безліч значень), утілили ці представлення у своїх методологіях і доповненнях до існуючих методів. Найчастіше такі доповнення створюються без урахування і усвідомлення того, які витрати знадобляться на їх впровадження, які приношувані ними вигоди і витрати. Приклад - впровадження методики оцінки ризиків DREAD. Для деяких систем ця методика працює, але при моделюванні загроз з акцентом на програмному забезпеченні методика DREAD починає вводити числові змінні, не задаючи їх області визначення, що призводить до небезпеки прийняти оцінку ризиків за алгоритмічну, тоді як вона такий не являється. Проте, SDL- моделювання загроз в Microsoft явно потребує методики управління рисками, і тому DREAD була впроваджена.

Кількісна оцінка моделей загроз. Сьогодні нами створюється величезна кількість моделей загроз. Існує декілька тривіальних параметрів, які ми МОЖЕМО виміряти кількісно(число елементів, різні заходи повноти і словесного наповнення). Набагато складнішими є питання про те, які параметри ми ПОВИННІ вимірювати і ЧОМУ. Які властивості моделі загроз найточніше показують, чи досягнуті поставлені нами цілі аналізу, забезпечення безпеки і навчання? Говорячи інакше, які параметри системи відповідають певній меті і як вони з цими цілями пов'язані? Які витрати знадобляться для виміру таких параметрів? (Невеликий приклад: в одну з наших груп по обговоренню проблем забезпечення безпеки поступив електронний лист з питанням про те, як розв'язати певну проблему. Декілька чоловік відповіло на нього; після короткого обговорення група вибрала один із запропонованих варіантів. Навряд чи якесь з цих рішень було коли-небудь формальне описано і зафіксовано. Зроблений вибір повністю виправдав себе: ми змогли з невеликими витратами підвищити рівень безпеки. Таким чином, документування рішень, що повторюються, не має особливого сенсу.) Чи існує можливість проаналізувати модель і визначити вірогідність, з якою вона повторюється? Які ще підходи до виміру параметрів можуть бути корисні для розробників і фахівців, що займаються ухваленням рішень?