Досвід моделювання погроз на Microsoft

Анотація. У даній статті описані десять років роботи Microsoft по створенню програмних продуктів і служб для моделювання загроз. Розглянуто сучасну методологія моделювання, що використовується в циклі розробки програмного забезпечення Security Development Lifecycle. Ця методологія являє собою практичний підхід, який можуть застосовувати і неексперти. Цей підхід заснований на побудові діаграм потоків даних і методі перерахування "загрози на елемент". Стаття описує той досвід, який буде корисний і при використанні інших методик аналізу безпеки. Наприкінці роботи наводяться можливі теми для подальших наукових досліджень.


1 Введення


Компанія Microsoft використовує різні методології моделювання загроз з 1999 року. Ці методи допомагали знаходити помилки в захисті програмних продуктів і були об'єднані в Security Development Lifecycle (SDL) – набір процедур, застосовуваний до всіх розробкам Microsoft, що передбачає роботу з високим рівнем загроз безпеки та конфіденційності. Microsoft і зараз продовжує розвивати і удосконалювати наявні інструменти, методології та процедури з урахуванням накопиченого досвіду. Дана стаття покликана розповісти про історію створення SDL-методів моделювання загроз і про уроки, засвоєних у процесі їх розробки (Які можуть виявитися корисними і за межами Microsoft), описати використовувані сьогодні підходи і поділитися темами, що представляють, як ми сподіваємося, інтерес для наукових дослідників.


Автор є власником прав на засоби моделювання загроз у SDL, включаючи процеси, інструменти та методи навчання. Так як дана стаття написана одним автором, однина буде використовуватися в ній для вираження власних суджень і особистої думки автора, а множинне – для опису поглядів, з великою ймовірністю підтримуваних всій нашою організацією. Наприклад, це стосується наступного розділу – я впевнений, що в Microsoft не існує єдиної думки з приводу вибору між дескриптивної і прескриптивний лінгвістики.


1.1 Що я маю на увазі під моделюванням загроз


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


Крім того, про моделювання погроз можна говорити стосовно до аналізу програмних продуктів, організаційних мереж, систем або навіть промислових секторів (див., наприклад, [9]). Моделювання протоколів часто виконується з використанням різноманітних формальних методів, іноді званих моделями мережевих погроз. Термін "моделювання мережевих погроз" також використовується при аналізі розгорнутої мережі.


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


1.2 Оцінка методологій


При оцінці будь-якої методології важливо вирішити, з чим її порівнювати. Зрозуміло, будь-яке рішення може бути легко розкритиковане щодо деякого ідеального уявлення про те "що треба було б зробити, не було у нас ніяких обмежень "." Що потрібно зробити? "- дуже важливе питання для дослідників, і ми повністю підтримуємо вивчення таких питань. Однак існують і інші питання, які особливо важливо піднімати на конференціях, які збирають разом вчених і фахівців-практиків: "що зазвичай робиться?" і "що перешкоджає впровадженню нових методів?". А головним у цьому сенсі стає питання "як необхідно удосконалити існуючі процедури і скільки це буде коштувати? ". Під вартістю тут маються на увазі витрати на впровадження (навчання, установку, програмне забезпечення) і подальший розвиток проекту. Основними цілями моделювання загроз для нас є підвищення рівня захищеності продуктів, що випускаються, документування результатів аналізу (як з метою перевірки, так і для повторного використання) і навчання працівників проведення непрямого аналізу безпеки, навіть якщо вони не повинні безпосередньо вирішувати задачі моделювання загроз.


2 Трохи історії


Процес моделювання загроз був вперше описаний в Microsoft як методологія в 1999 році у внутрішньому документі "Threats to our software" ("Загрози нашим програмним продуктам"), складеному Джейсоном Гармс (Jason Garms), Прерітом Гарг (Praerit Garg) і Майклом Говардом (Michael Howard). Треба сказати, що до цього в Microsoft вже займалися моделюванням загроз, однак саме в зазначеній роботі відповідна методологія була формалізована (я використовую тут термін "формалізований" в значенні "наведений до форми (як випливає з назви) міркувань" [8], а не в сенсі математичної формалізації, необхідної для доведення теорем. Таким чином, формальна методологія містить набір повторюваних і документально зафіксованих етапів з певними вхідними і вихідними даними), а моделювання загроз розглянуто як конструкторська робота з теоретичної точки зору. Пізніше в Microsoft були опубліковані наступні роботи:

– Writing Secure Code (Написання безпечного коду), Ховард (Howard) і Ле Бланк (LeBlanc), 2001;
– Writing Secure Code (Написання безпечного коду), Ховард (Howard) і Ле Бланк (LeBlanc), 2-е видання 2002;
– Threat Modeling (Моделювання загроз), Свідерський (Swiderski) і Снайдер (Snyder), 2004;
– Security Development Lifecycle (Цикл розробки безпечного програмного забезпечення), Ховард і Ліпнер (Lipner), 2006.


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


3 Сучасна методологія SDL


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


3.1 Побудова діаграм


Зазвичай ми користуємося системою діаграм, запозиченої з методології побудови діаграм потоків даних (Data Flow Diagram, DFD), додаючи до неї "кордону довіри". Як виявилось, такі DFD-елементи як "Процес", "сховище даних", "потік даних" і "зовнішній елемент" відмінно працюють в якості засобів добування інформації і можуть використовуватися при проведенні аналізу. Опис цих елементів наведено у таблиці 1. Крім того, ми додали елемент "кордону довіри", зображуваний у вигляді пунктирної лінії або прямокутника, який показує, що елементи, розташовані по різні сторони від цієї межі, функціонують на різних рівнях привілеїв. Первісне рішення про використання DFD було засновано на двох чинниках. По-перше, стандарт DFD простий для розуміння, і, по-друге, він орієнтований саме на розгляд даних. Величезна кількість атак тим або іншим чином використовують потоки даних, що проходять через систему, а значить, DFD дозволяє розглядати як раз найважливішу сторону питання. Досвід 7-8 років застосування DFD-підходу до побудови діаграм показав його надійність та ефективність. Інші методології, пропоновані для замети DFD-підходу, повинні продемонструвати помітні переваги перед DFD, щоб ми могли розглядати їх в якості альтернативи.





























Назва


Зовнішній елемент


Процес


Потік даних


Сховище даних


Графічне зображення


коло


прямокутник


стрілка


паралельні лінії


Визначення


Об'єкти, що не перебувають під нашим контролем


Програмний код


Як інформація передається між елементами


Стаціонарні дані


Приклади


Люди, інші системи, web-сайти


exe-файли, збирання, COM-компоненти


Виклики функцій


Файли, бази даних, реєстраційні ключі


Таблиця 1. DFD-елементи


Зазвичай DFD-діаграма містить від 10 до 150 елементів (не включаючи кордонів довіри і текстових пояснень). Основну складність у діаграму вносять кордону довіри і той ступінь деталізації, яка необхідна для опису процесів, що відбуваються при переході об'єктів через ці межі. Для багатьох систем ми будуємо діаграми за висхідним принципом, і тому є дві причини. По-перше, в Microsoft часто організовують групи, що складаються з розробників, випробувачів і керівників проектів, які займаються тільки виділеним для цієї групи питанням чи питаннями. Тому видається природним і логічним поділити роботу з моделювання загроз між цими групами так, щоб кожна команда становила модель загроз для своєї частини проекту. Друга причина полягає в тому, що мова SDL вимагає наявності моделей загроз для "Всіх нових блоків і продукту в цілому". Я торкнувся цього питання для того, щоб показати, як одна конкретна формулювання в будь-якому описі може призвести до зовсім несподіваних наслідків.


3.2 Перерахування загроз


Початок. Більшість ініціатив з моделювання загроз, що виникали в Microsoft і в інших компаніях, були засновані, включаючи ранні процедури SDL, на проведенні "мозкових штурмів" або використанні інших неформальних підходів до перерахування варіантів. Мозкові штурми можуть бути корисні при участі в них експертів, але навіть у цьому випадку зберігаються проблеми повноти та повторюваності. Ми усвідомили необхідність у створенні інструменту, який дозволяє отримувати більш строгі і зрозумілі рекомендації. Метод, який ми використовуємо сьогодні, бере свій початок з неопублікованого аналізу CVE і MSRC, проведеного Шоном Хенань (Shawn Hernan) і Майклом Говардом (Michael Howard).


Сучасна методологія. У нашому сьогоднішньому методології використовуються діаграми, побудовані по методиці, яку ми називаємо "загрози STRIDE на елемент" (STRIDE – Spoofing of user identity (підміна ідентифікатора користувача), Tampering (втручання), Repudiation (Відмова), Information disclosure (Розголошення даних), Denial of Service (Відмова в обслуговуванні), Elevation of privilege (Підвищення привілеїв) – система класифікації загроз), що дозволяє отримувати інструкції для неекспертов і досягати високої повторюваності. Ця методика грунтується на наступному спостереженні: загрози програмного забезпечення, якими ми займаємося, можна об'єднати в кластери. Принцип методики базується на тому, що кожному типу DFD-елементів відповідають певні класи загрози (див. таблицю 2).














































Підміна


Несанкціонований доступ до комп'ютера


Відмова від факту отримання або відправлення повідомлення


Розкриття інформації


Відмова в обслуговуванні


Підвищення привілеїв


Зовнішній елемент


x



x





Процес


x


x


x


x


x


x


Сховище даних



x


?


x


x



Потік даних



x



x


x



Таблиця 2. Розподіл "загрози STRIDE на елемент"


Що стосується сховищ даних (тобто журналів), ми ще займаємося вивченням проблем відмов від повідомлень і атак на сховища даних з метою видалення журналів. В існуючих на даний момент інструментах ми використовуємо набір питань для конкретизації та роз'яснення цих загроз.


Аналіз. Я не претендую на універсальність описаного методу перерахування. Він орієнтований на ті проблеми, якими займаються в Microsoft; інші організації можуть розширити або замінити його. Наприклад, "розголошення інформації зовнішнім об'єктом ", здавалося б, добре підходить для опису певного підмножини загроз конфіденційності. Однак інші компанії, що спеціалізуються на програмах Web 2.0, можуть замінити список загроз своїм, складеним у відповідності з їх оточенням.


У наших сучасних інструментах ми розміщуємо керівництво по тому, як кожна з перерахованих загроз проявляється по відношенню до елементів різних типів. Очевидно, що необхідна розробка більш докладного керівництва. Наприклад, можливості та методи боротьби з несанкціонованим доступом до комп'ютерів сильно розрізняються при роботі з HTTP GET-запитами, локальними викликами процедур Windows LPC і Unix-каналами.


3.3 Зниження ризиків


На семінарах і в роботах з SDL-моделювання загроз обговорюються чотири підходи до зниження ризиків, а саме (у порядку зростання перевагу): перепроектування; використання стандартних методів зниження ризиків, таких як списки управління доступом (Access Control List, ACL); використання (з обережністю) унікальних методів; робота з ризиками відповідно до політиків безпеки.


З точки зору інженера-практика, співвіднесення моделі з практичними етапами вирішення проблеми дуже важливо. По-перше, метою моделювання є підвищення безпеки системи, а зв'язування виявленої проблеми з методом її вирішення спрощує це завдання. По-друге, тут існує й психологічний аспект. Інженер, поінформоване про існування проблеми, але не отримав її точного визначення або оцінки, в більшості випадків просто розгубиться (Знайдуться і такі інженери, які з ентузіазмом приймуть цей виклик. Однак досвід показує, що прості і очевидні методи в сфері інформаційної безпеки рідко спрацьовують, тому справа, швидше за все, все одно закінчиться розчаруванням. (Психологічні аспекти будуть розглянуті більш детально в розділі 4.5).).


3.4 Перевірка


Ми використовуємо ряд евристичних методів для перевірки моделей загроз, включаючи графових аналіз діаграм, перевірку відповідності підсумкових діаграм кінцевому програмного коду, перевірку того, що були перераховані всі STRIDE-загрози елементам, що вся модель загроз була переглянута, і що для кожної загрози був знайдений спосіб зниження ризиків. Ми також прагнемо до того, щоб мати можливість зіставляти моделі з програмним кодом, написаному на різних мовах програмування (більш докладно див 5.1).


3.5 Аналіз методології


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


Один з наших рецензентів попросив довести, що "наведені підходи є вірними". Проте я не стверджую, що це так. Я стверджую, що ці підходи можуть бути корисні при вирішенні труднощів, з якими ми стикаємося, і про які я говорив вище. Враховуючи багатозначність терміна "моделювання загроз" і різноманітність вирішуваних процесами завдань, я не думаю, що можна говорити про правильних або неправильних підходах; підходи можуть бути тільки більш корисними-менш корисними.


4 Виявлені проблеми і накопичений досвід


4.1 Моделювання загроз як tabula rasa


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


4.2 Складність


Багато фахівців, що займаються моделюванням загроз, не проходили відповідне навчання, а просто дізналися про те, що потрібно робити, від інших. Я був дуже здивований, побачивши одного разу цілий відділ комп'ютерної безпеки, всі співробітники якого добре розбиралися в методиках моделювання загроз і володіли професійною лексикою, при цьому жодного разу не відвідавши будь-якої семінар. У Microsoft існує безліч курсів з безпеки, інструментів і методик, однак варто відзначити, що більшість інженерів відвідали максимум 2 години семінарських занять за останні кілька років.


Метод, наведений в описі SDL, включає 9 етапів. Деякі інші методи містять до 11 етапів. Складність етапів сильно розрізняється і варіюється від "описати сценарії використання" до "визначити типи загроз ". І якщо перше завдання більшість інженерів має виконати, то друге, швидше за все, виявиться не під силу неекспертам, та й серед експертів викличе суттєві розбіжності. Описи методологій рясніють спеціальними термінами, що ще більше ускладнює їх розуміння.


Розробникам методологій слід уважніше й дбайливіше ставитися до запитів користувачів і ретельно оцінювати кожен етап або елемент.


4.3 Життєвість


Моделювання загроз може здатися сильно відірваним від реальної розробки програмного забезпечення. Складається таке відчуття, що влучний вислів "YAGNI" (Вам це ніколи не знадобитися, "You Ain" t Gonna Need It ") було створено спеціально для цього виду діяльності. Використання ряду підходів дозволило інтегрувати моделювання загроз в процес розробки програмних продуктів (сюди відноситься, наприклад, робота з погрозами як з помилками в програмному коді та подання заходів боротьби з ними у вигляді функціональних особливостей системи). Розробники відмінно розуміють, що таке помилки і функціональні особливості, і компанії знають, як з ними працювати. Крім того, ми закликаємо проводити дискусії у відділах з безпеки, задаючи просте питання "можна поглянути на Вашу модель загроз?". Це спонукає Вас і Ваших колег розробляти дійсно хороші моделі (У більшості випадків підходи, подібні Microsoft SDL, застосовувані до різних методологій розробки, можуть здатися відірваними від життя. Однак це взагалі властиво області моделювання загроз).


Існує ще два аспекти, обидва пов'язані з людським чинником, на яких я хотів би зупинитися окремо. Перший – це уявлення людей в моделі загроз, і другий – це проблеми проектування, викликані людським фактором, що виникають при розробці методів, процедур і інструментів моделювання систем безпеки.


4.4 Люди в моделі загроз


Представлення людей в моделях загроз розглядалося вже не одним дослідником. Еллісон (Ellison) у роботі [3] доводить, що дійсно повний опис мережевих протоколів саме по собі включає облік і комп'ютерів, і людей. Неефективне уявлення людей в моделі приводить до таких проблем, як фішинг, коли поєднання трьох рівнів слабкою аутентифікації відриває двері для шахраїв (тут три рівня – Це неадекватні схеми аутентифікації електронних адрес, web-сайтів і користувачів). Моделювання користувачів представляє собою вкрай складну задачу, однак якщо це завдання не вирішується, то неминуче виникають серйозні проблеми з безпекою системи. Питання про те, як допомогти інженерам ефективно вирішувати це завдання, залишається відкритим; наприклад, він розглядається в роботі Кренора (Cranor) [7].


4.5 Люди як користувачі систем моделювання засобів захисту


Інженери, що розробляють засоби для таких же інженерів, зазвичай не турбуються про зручність використання цих коштів. Між тим, питань розробки користувальницького інтерфейсу, взаємодії між людиною і машиною і іншим подібним темам присвячено безліч робіт, і я підозрюю, що розробники систем чудово з ними знайомі. Я б хотів розглянути три аспекти, які мають велике значення при створенні систем моделювання засобів захисту, призначених для використання широким колом фахівців. Перший полягає в необхідності чітко визначити, на користувачів якого рівня розрахована Ваша система. Традиційна рекомендація "мислите як зловмисник" для більшості людей позбавлена будь-якого сенсу (Більш того, багато людей неохоче зізнавалися в тому, що насправді не розуміють, що означає "мислити як зловмисник". Зазвичай ця рада подавався так, як ніби "мислити як зловмисник" – це найприродніший і просте заняття на світі. Тому усвідомлення того, наскільки важлива Ваша модель користувача, так само необхідно, як і перевірка того, що Ваша модель дійсна застосована).


Друга проблема полягає в необхідності створення строгих і доступних вказівок щодо інтеграції методології моделювання засобів захисту у процесі розробки. Інструкції з інтеграції можуть здаватися розробнику абсолютно ясними, і при цьому бути абсолютно незрозумілими людині, в перший раз вивчає дану систему. Чіткі вказівки щодо того, як інтегрувати модель у швидко протікає процес розробки або в процес, побудований за типом "водоспаду", допоможуть подолати цей бар'єр. Наприклад, корисно приводити пояснення того, які вихідні сигнали можуть свідчити про помилки, а які лише відображають передбачені функціональні особливості системи. Іншими словами, моделюванням засобів захисту займається широке коло людей, і всі вони мають різні навички, досвід і цілі. Створюйте різнопланові інструменти для вирішення питань безпеки і розглядайте проблему з різних сторін (включаючи позицію інженерів і фірм, в яких вони працюють).


Нарешті, третє питання може здатися очевидним, але він, тим не менш, заслуговує розгляду з точки зору перспектив використання. Процедури, які може виконати будь-яка освічена і досвідчений інженер, завжди будуть використовуватися більше, ніж ті, які вимагають від фахівця виняткових здібностей і навичок. Простота використання і зрозуміла документація дуже важливі, однак їм часто приділяється мало уваги, навіть у роботах, заявлених як "практичні".


5 Питання, пропоновані нами для досліджень


Описані вище методології менше спираються на математичне обгрунтування, ніж багато хто з тих, що пропонуються на наукових конференціях. Як я підкреслив, цей підхід приносить свої вигоди і витрати. Ми хотіли б, щоб виробники програмного забезпечення та фахівці з моделювання більше співпрацювали один з одним. Саме тому я спробував описати тут наші мотивації та основні проблеми, виникли при прийнятті нами певних рішень. Я сподіваюся, що та частина наукового співтовариства, яка працює і над прикладними завданнями, знайде серед цих проблем теми, цікаві для дослідження. На шляху розвитку наших процедур та інструментарію варто ще безліч практичних проблем, деякі з яких я вже згадував. Ще три питання з тих, що можуть бути цікавими для вчених-дослідників, я опишу нижче.


5.1 Відповідність моделей і програмного коду


Запропонована нами проста модель має безліч переваг. У той же час модель – це ще не програмний код, і тут нам хотілося б мати можливість працювати за двома сценаріями. Перший – коли у нас вже є тіло програми, але для нього не створена ні модель загроз, ні діаграма потоків даних DFD (така ситуація може виникнути, наприклад, після придбання програмного продукту). Ми б хотіли мати можливість швидко створювати моделі, використовуючи вихідний код, і тим самим прискорювати процес моделювання загроз. Другий варіант виникає, коли ми маємо і моделі загроз, і програмний код, і хочемо порівняти їх один з одним. Чи відображає модель всі межі довіри і точки входу, наявні в коді? Чи містить вихідний код зв'язку, важливі для моделювання, але відсутні в моделі?


Деяка робота з вирішення цих питань вже була пророблена [1]; в ній використовувалися моделі Reflexion Models для напівавтоматичного генерування моделей на основі програмного коду і порівняння їх з користувацькими моделями. Проте ще багато потрібно зробити для того, щоб перейти до повністю автоматичного отримання моделей з вихідного коду. Зокрема, величезна частка існуючих програм написана на мовах C і C + +, а ці мови є дуже важкими для моделювання та аналізу. Втім, отримані переваги могли б окупити всі витрати.


5.2 Введення в моделі контролю даних


Одне з найпоширеніших правил у забезпеченні безпеки звучить так: "приймайте тільки ті дані, які явно дозволені". Мається на увазі, що інженер знає, що під цим мається на увазі, і зможе відкинути всі інші вхідні повідомлення. В окремих випадках це дійсно вірно; велика частина даних, що надходять у систему, вже були перевірені і занесені до списку надійних джерел або отримали відповідну позначку, наприклад "дійсну IP-пакет" або "дозволене POP3-повідомлення". Однак такі дані не є надійними взагалі, вони вважаються допустимими лише для деяких цілей. Процес визначення списку таких цілей може бути простим для невеликих завдань, але його важко представити в загальному вигляді. Було б дуже зручно мати можливість користуватися спеціальними мовами для опису таких цілей, а також інструментами, які використовують подібну інформацію для підвищення ефективності програмування та / або аналізу моделі засобів захисту.


5.3 Кількісна оцінка моделей загроз


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


6 Подяки


Я б хотів подякувати рецензентів Шона Хернана (Shawn Hernan), Стівена Ліпнер (Steven Lipner), Дж. Д. Мейєра (JD Meier) і Гленна Пітвея (Glenn Pittaway) за цінні зауваження з чернеток моєї роботи, а також своїх численних колег (перелічити всіх поіменно тут просто неможливо) за пізнавальні розмови про питання моделювання загроз.


7 Висновок


У цій статті коротко описана історія розвитку моделювання загроз в Microsoft. Наведено деякі деталі сучасної стану питання, а також накопичений нами досвід. Крім того, запропоновано декілька важливих тем для подальших досліджень, які, як ми сподіваємося, можуть зацікавити членів наукового співтовариства.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*