Послуга генерування ключа

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

Послуга реєстрування ключа

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

Уповноважений реєстрації веде реєстр ключів та зберігає відповідну інформацію з належним рівнем захистом. В додатку Б подані інформаційні об’єкти управління ключовими даними.

Уповноважений з реєстрації ключів здійснює операції реєстрування і зняття з реєстрації.

Послуга формування сертифіката відкритого ключа

Послуга формування сертифіката відкритого ключа засвідчує зв'язок відкритого ключа з суб'єктом і забезпечується уповноваженим на сертифікацію. Після одержання запиту на сертифікацію відкритого ключа, уповноважений на сертифікацію створює сертифікат відкритого ключа. Сертифікати відкритих ключів описані більш детально в ISO/IEC 11770-3.

Послуга розподілення ключа

Розподілення ключа – це множина процедур для надійного забезпечення уповноважених суб'єктів інформаційними об'єктами управління ключовими даними (відповідно до прикладу в додатку Б). Особливим випадком розподілення ключів є передача ключа, внаслідок чого ключова інформація встановлюється між суб'єктами, які використовують послуги центру передавання ключів (відповідно до 6.2). ISO/IEC 11770-2 пропонує різні протоколи встановлення ключів між суб'єктами. ISO/ІEC 11770-3 визначає протоколи встановлення таємних ключів і протоколи пересилання таємних і відкритих ключів.

Послуга інсталювання ключів

Послуга інсталювання ключів завжди необхідна перед використанням ключів. Інсталювання ключів означає введення ключів всередину засобу управління ключовими даними із захистом від розкриття.

Послуга зберігання ключів

Послуга зберігання ключів забезпечує безпечне зберігання ключів, призначених для поточного використання, використання у найближчій час або для резервування. Зазвичай, корисно забезпечувати фізично відокремлене зберігання ключів.

Приклад

Це забезпечує конфіденційність та цілісність ключової інформації або цілісність відкритих ключів.

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

- фізичний захист (а саме: зберігання ключа всередині тривких до пошкоджень пристроїв або на зовнішніх носіях, таких, як дискета або картка з пам'яттю);

- шифрування з використанням ключів, які самі фізично захищені;

- захист доступу до них за допомогою паролів або персонального ідентифікаційного номера (ПІН).

Для всієї ключової інформації будь яка спроба компроментації має бути виявленою.

Вироблення ключів

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

Послуга архівування ключів

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

Послуга скасування ключів

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

Примітка. Деякі додатки цієї послуги використовують термін «видалення ключа».

Послуга зняття з реєстрації ключів

Послуга зняття з реєстрації ключів забезпечується уповноваженим з реєстрації ключів і практично усуває зв’язок ключа з суб’єктом. Вона є частиною послуги скасування ключів (відповідно до 5.1.11). Під час зняття з реєстрації суб’єкт взаємодіє з уповноваженим з реєстрації.

Послуга знищування ключів

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

Знищування таких ключів може вимагати додаткових адміністративних заходів.

Примітка. За необхідності деякі ключі можуть зберігатися поза електронним пристроєм або системою. Знищування таких ключів вимагає додаткових адміністративних заходів.

6.1.4 Послуги підтримки в частині управління ключами.

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

Послуги засобів (апаратури, устаткування) управління ключами

Послуги управління ключами можуть припускати використання й інших послуг, які пов'язані з забезпеченням безпеки. До таких послуг відносяться:

- управління доступом – ця послуга може використовуватися для забезпечення того, щоб ресурси системи управління ключами були доступні тільки для авторизованих суб'єктів і авторизованим способом;

- аудит – спостереження за діями, пов'язаними із захистом, які виникають у системі управління ключами. Журнали аудита допомагають у виявленні ризиків безпеки та витоків інформації;

- автентифікація – ця послуга має використовуватися для підтвердження того, що суб'єкт (об’єкт) є авторизованим членом домена безпеки;

- криптографічні послуги – ці послуги мають використовуватися службами управління ключами для забезпечення їх цілісності, конфіденційності, доступності, автентифікації та неспростовності;

- послуга фіксування часу – ці послуги необхідні для генерування змінних часових параметрів, таких як терміни дії, позначки часу й т.д.

Послуги, що орієнтовані на користувача

Криптографічні системи та пристрої можуть вимагати застосування інших послуг, необхідних для адекватної функціональності, напр., послуги реєстрації абонента. Реалізація цих послуг має специфічний характер і виходить за рамки цієї частини стандарту ДСТУ ISO/IEC 11770.

6.1.5 Концептуальні моделі розподілення ключових даних

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

Розподілення ключів між суб'єктами, що взаємодіють

На взаємодію суб'єктів впливають характер зв'язку між суб’єктами, ступінь довіри між ними та криптографічні перетворення, що використовуються.

Існують комунікації між суб'єктами А і В, які бажають обмінятися інформацією з використанням криптографічного захисту. Ці комунікаційні лінії показано на рисунку 6.1.3. Взагалі, розподілення ключа має здійснюватися через безпечний канал, який логічно відрізняється від каналу передачі.

Рисунок 6.1.3 - Прямий зв’язок між двома суб’єктами

Випадками безпосередньої взаємодії суб’єктів є узгодження ключів, контроль ключів та підтвердження ключів. Більш детально цей випадок розглядається в другій частині (ДСТУ ISO/IEC 11770-2, Інформаційні технології – Методи захисту – Управління ключовими даними – Протоколи, що ґрунтуються на симетричних криптографічних перетворюваннях) та в третій частині стандарту (ДСТУ ISO/IEC 11770-3, Інформаційні технології – Методи захисту – Управління ключовими даними – Протоколи, що ґрунтуються на асиметричних криптографічних перетворюваннях).

Розподілення ключів в межах одного домена

Наступна модель заснована на концепції організації домена безпеки під загальним керуванням уповноваженим з безпеки у відповідності до міжнародного стандарту ISO/IEC 10181.

Уповноважений з безпеки може надавати послуги управління ключовими даними (ключами), наприклад послуги передачі ключів. За умови використання суб'єктами асиметричних методів для безпечного обміну інформацією можливі такі випадки:

- для забезпечення цілісності даних або автентифікації джерела даних одержувач потребує відповідного сертифіката відкритого ключа відправника;

- для забезпечення конфіденційності відправник потребує чинного сертифіката відкритого ключа одержувача;

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

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

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

У разі використання симетричних криптоперетворень між двома такими суб’єктами генерування ключів розпочинається одним із таких способів:

1) генеруванням ключа одним із суб'єктів і відсиланням його до центру передавання ключів (ЦПК);

2) запитом одного із суб'єктів до (ЦРК) стосовно генерування
ключа для подальшого розподілення,

Якщо генерування ключів виконується одним із суб'єктів, безпечне розподілення ключа може виконуватися ЦПК як показано на рисунку 6.1.4 Цифри зображують кроки обміну. ЦПК одержує зашифрований ключ від суб'єкта А (1), розшифровує його і повторно зашифровує його з використанням ключа, розподіленого між ним та суб'єктом В. Потім він може або переслати зашифрований ключ суб'єкту В (2), або відправити його назад суб'єкту А (3), який перешле його суб'єкту В (4).

(1) (3) (2)

(4)

Рисунок 6.1.4 – Центр передавання ключів

Якщо генерування ключів здійснюється третьою довірчою стороною, то існують два варіанти подальшого розподілення ключа суб’єктам, що взаємодіють. Ці випадки проілюстровані на рисунку 6.1.4 та на рисунку 6.1.5. Рисунок 6.1.4 ілюструє випадок, для якого центр розподілення ключів спроможний безпечно зв'язуватися з обома суб'єктами. У цьому випадку, як тільки у відповідності до запиту одного з суб’єктів буде згенерований ключ, центр розподілення ключів несе відповідальність за безпечне розподілення ключа обом суб’єктам. Для цього випадку (1) це зображення запиту розподіленого ключа, а (2а) і (2б) - розподілення ключа суб’єктам, що взаємодіють.

(1) (2а) (2б)

Рисунок 6.1.5 - Концептуальна модель центру розподілення ключів

Якщо тільки суб'єкт А формує запит розподілення таємного ключа між суб'єктами А і В, то уповноважений може діяти двома різними шляхами. Якщо він може безпечно зв'язатися з обома суб'єктами, він може розподілити таємний ключ обом суб'єктам, як це зазначено вище. Якщо уповноважений може зв'язатися тільки з суб'єктом А, то суб'єкт А відповідає за розподілення ключа суб'єкту В. Рисунок 6.4 зображує цей спосіб розподілення ключа. Тут (1) зображує запит розподіленого ключа, а (2) - його розподілення суб'єкту А, (3) зображує пересилання ключа від А до В.

(1) (2)

(3)

Рисунок 6.1.6 - Розподілення ключа пересиланням ключа від суб'єкта А до суб'єкта В

6.1.6 Розподілення ключів між доменами

Ця модель включає два суб'єкти А і В, що належать двом різним доменам безпеки, які можуть застосувати принаймні одне криптографічне перетворення (симетричне чи асиметричне). Кожний домен безпеки має свого власного уповноваженого з безпеки: одного, якому довіряє А, другого, якому довіряє В. Якщо А і В або довіряють один одному, або кожний довіряє уповноваженому з безпеки іншого домена, то ключі розподіляються відповідно до 6.1.4 або 6.1.5.

Розрізнюються два випадки встановлення ключа між А і В:

- одержання сертифіката відкритого ключа В;

- встановлення розподіленого таємного ключа між А і В.

Між цими компонентами можливі різні ключові відносини, що відображають сутність довіри між компонентами.

У випадку використання суб'єктами для обміну інформацією асиметричних криптоперетворень і відсутності доступу до загальної послуги довідників, яка надає сертифікати відкритих ключів, кожний суб'єкт має зв'язуватися зі своїм відповідним уповноваженим для одержання сертифіката відкритого ключа партнера (відповідно до рисунка 6.5 (1)). Уповноважені А і В обмінюються сертифікатами відкритих ключів суб'єктів А і В (2) і пересилають їх до А і В (3). Після цього А і В можуть безпосередньо здійснювати безпечний зв'язок (4).

Протилежним підходом до обміну сертифікатами відкритих ключів є перехресна сертифікація (відповідно до додатка Г).

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

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

		Домен А		Домен Б

Рисунок 6.1.7 – Розподілення ключів між двома доменами

Інколи УБ, А і В не мають ані взаємних довірчих відносин, ані безпосередніх шляхів зв'язку. В цьому випадку вони повинні залучити УБ X, якому вони обоє довіряють, як це показано на рисунку 6.6 (стрілки (2а) і (2б)). УБ X може згенерувати ключ і розподілити його уповноваженим суб'єктів А і В (рисунок 6.6, стрілки (За) і (3б)). Або УБ X може переслати одержаний таємний ключ, або сертифікат відкритого ключа (2а) від УБ суб'єкта А до УБ суб'єкта В (3б). УБ повинні потім переслати одержаний ключ їхнім відповідним суб'єктам (відповідно до рисунку 6.6, (4а) і (4б)), які потім можуть безпечно обмінюватися інформацію (5). Можливо, для встановлення ланцюга довіри необхідно буде провести пошук УБ, які б відповідали вимогам.

Рисунок 6.6 - Ланцюг довіри між органами

6.1.7 Спеціальні постачальники послуг

Деякі послуги, яких потребує система управління ключовими даними, можуть бути надані зовнішнім постачальником послуг. Такі послуги можуть надавати:

- центр реєстрації ключа або уповноважений з сертифікації;

- центр розподілення ключів, згідно з 1SO/IEC 8732;

- центр пересилання ключів, згідно з ISO/IEC 8732.

Додаток А

В таблице А1 представлены примеры реализации угроз в системе, вследствии которых был насен значительный финансовый ущерб различным организациям. В результате НСД к информационной системе злоумышленником, организации потерпели ущерб.

Таблица А1 – Финансовый ущерб, нанесенный различным организациям [6]

Дата	Организация	Описание
Апрель 2006 г.	Lockheed Martin	Три инсайдера из Lockheed Martin украли результаты проекта по разработке тренировочной системы для пилотов ВВС США и план действий компаний в борьбе за контракт Пентагона стоимостью $ 1 млрд. Все эти сведения были переданы конкуренту — подразделению Link Simulation and Training компании L-3 Соттитсаиопа. Вся интеллектуальная собственность утекла из Lockheed Martin через банальные USB-флэшки и пишущие CD/DVD-приводы
Май 2006 г.	Министерство по делам ветеранов США	Инсайдер из Министерства по делам ветеранов США унес домой ноутбук с персональными данными 26,5 млн бывших военных. Этот компьютер был украден из дома в результате ограбления. Все ветераны США оказались под угрозой кражи личности, так как приватные данные не были зашифрованы. Потенциальные убытки вследствие утечки оцениваются в $30 млрд
Июнь 2006 г.	USB Paine Webber	Системный администратор финансовой компании ЦВ8 USB Paine Webber запрограммировал «логическую бомбу», которая вывела из строя более двух третей корпоративной сети. На восстановление работы потребовалось более $3 млн и несколько недель простоя

Продолжение таблицы 2.1

Июнь 2006 г.	KDDI	Инсайдеры из второго по величине японского оператора сотовой связи — KDDI — украли базу приватных данных клиентов («слили» на компакт-диски и ШВ-флэшки). С помощью своих сообщников они шантажировали КХЮ1, угрожая раскрыть факт утечки перед собранием акционеров. Инсайдеры требовали $90 тыс., но благодаря умелым действиям токийской полиции оказались за решеткой
Июль 2006 г	HSBC	Инсайдер в индийском са11-центре крупнейшего британского банка HSBC выкрал конфиденциальную информацию о счетах британских клиентов и передал ее подельникам в Соединенном Королевстве. В результате около 20 британских клиентов Н8ВС лишились почти $500 тыс. Убытки же самого банка составили несколько миллионов
Август 2006 г	Российские банки, занимающиеся потребительским кредитованием	В середине августа в Интернете прошла рассылка с предложением купить БД заемщиков, бравших кредиты на приобретение товаров в торговых сетях. Каждая запись базы содержит ФИО заемщика, его адрес, название торговой сети, размер и срок кредита, объем просрочки и т. д. За всю базу, которая содержит более 700 тыс. записей, продавцы запросили 90 тыс. рублей. Подозрение в утечке пало на инсайдеров в нескольких российских банках, занимающихся потребительским кредитованием

Продолжение таблицы 2.1

Август 2006 г.	Банк «Первое ОВК» (поглощен Росбанком в 2005 г.)	На прилавках Митинского радиорынка появился диск «Банковский черный список физлиц: Москва и Московская область». За 900 рублей продавцы предлагали относительно небольшую базу данных примерно 3 тыс. неблагонадежных клиентов банка «Первое ОВК». Подозрение в утечке пало на инсайдеров — бывших сотрудников банка «Первое ОВК», которые «слили» данные именно в процессе поглощения компании Росбанком
Сентябрь 2006 г.	МЦС (Мобильная Цифровая Связь), владелец марки Уе1сот	В продаже появилась база данных более 2 млн абонентов белорусского сотового оператора Уе1сот. Компания обвинила в утечке партнерский банк, которому база была передана для проверки правильности указанных реквизитов при оплате услуг связи. Фирма МЦС даже собралась подать на банк в суд, хотя белорусские журналисты отмечают, что приватные базы абонентов Уе1сот появляются в продаже регулярно
Октябрь 2006 г.	Citibank (сингапурский филиал)	Инсайдер — руководитель местного отделения Prevate Binking в Citibank — перешел на работу в банк-конкурент ЦВ8, прихватив конфиденциальные данные всех наиболее состоятельных клиентов. Естественно, через некоторое время ЦВ8 начал переманивать клиентов Citibank. Однако самое интересное в том, что утечка произошла самым банальным способом — по электронной почте
Июнь 2006 г.	США	В результате взлома серверов компании CardSystems Solutions 200 тысяч номер кредиток были похищены и скомпрометированы 40 миллионов кредитных карт MasterCard, Visa и American Express.

Продолжение таблицы 2.1

Октябрь 2006 г	Acme Tele Power	Инсайдеры из индийского телекома Acme Tele Power украли результаты инновационных разработок и передали их фирме-конкуренту Lamda Private Limited. По оценкам Ernst & Young прямые финансовые убытки Асmе составили $166 млн. Любопытно, что интеллектуальная собственность «утекла» самым обычным способом — по электронной почте. Теперь компания Acme Tele Power собирается вообще перенести свой бизнес из Индии в Австралию
2007 г.	Россия	Компании PricewaterhouseCoopers (PwC), российский рынок лидирует по количеству внутренних экономических преступлений. Более половины (59%) отечественных компаний хотя бы раз столкнулись с инсайдерами за последние два года. В половине случаев мошенниками оказывались топ-менеджеры, а средний ущерб от одного инсайдера составил 12,8 млн долларов.
Июнь 2007г.	США	Хакеры взломали базу данных одного из управлений Пентагона и обнаруженную там улику фактов зверств американских военнослужащих в Ираке и Афганистане.выложили в Интернете на всеобщее обозрение. Она вызвала волну возмущения даже у самих американцев.
Январь 2007 г.	США	Самой крупной утечкой на сегодняшний день является потеря персональных данных, произошедшая в результате взлома сайтов американо-британской торговой компании TJX, о которой было сообщено в январе 2007 года: тогда было по данным компании скомпрометировано 45 миллионов кредитных карт (по другим данным значительно больше), а убытки компании, по некоторым оценкам составили порядка 1 миллиарда долларов.

Продолжение таблицы 2.1

Август 2008 г.	Канада	Неизвестные злоумышленники взломали систему безопасности CardSystems Solutions и установили вредоносное ПО, которое позволило мошенникам получить необходимые данные. Как выяснилось, утечка информации произошла главным образом из-за грубейших нарушений правил безопасности.В результате взлома злоумышленники умыкнули 263 тысяч записей CardSystems Solutions, что примерно составляет 239 тысячам банковских счетов. 68 тысяч людей получили сообщения с просьбой срочно проверить состояние своих счетов. После такой «катастрофы» компания не могла остаться в бизнесе.
Февраль 2008 г.	Британия	На стоянке нашли флэшку с именами и паролями для правительственной компьютерной системы. Утерянная карта памяти позволяла любому, кто ее найдёт, получить доступ к личной информации 12 миллионов человек.
Март 2009 г.	США	Компания CheckFree вынуждена оповещать об утечке 5 миллионов своих клиентов и оплачивать им финансовый мониторинг. Злоумышленники, подменив данные DNS, смогли перенаправить посетителей на подложный веб-сайт и в течение 9 часов получали данные о банковских картах и транзакциях.
Январь 2010 г.	США	Monster.com, один из наиболее популярных интернет-ресурсов для работодателей и соискателей.Нелегальный доступ к базе данных ресурса Monster.com позволил злоумышленникам украсть огромное количество личной информации, среди которой - сведения об именах и датах рождения, телефонные номера, адреса электронной почты, пароли и так далее.В этой связи представители Monster.com посоветовали своим пользователям незамедлительно изменить пароли для доступа к сайту и быть готовыми к возможному получению писем от фишеров.

В таблице 2.2 приведены мотивы осуществления НСД, за уровнем квалификации и осведомленности относительно AC, за показателем возможностей использования средств и методов преодоления системы защиты, по времени действия. В графе "Уровень угроз" в таблице приведен в виде относительного упорядочивания оценки возможных убытков, которые может причинить нарушитель при осуществлении НСД. Уровень убытков характеризуется следующими категориями: 1 - незначительные, 2 – значительные, но в большенстве случаев допустимые, 3 - средние, 4 - очень значительные [7].

Таблица 2.2 – Спецификация модели нарушителя по совершонным нарушениям

Обозначение	Мотив нарушения	Уровень угрозы
М1	Безответственность
М2	Самоутверждение
М3	Полезный интерес
М4	Профессиональные обязанности

Дата добавления: 2014-01-11