ЗМІСТ

1 ТЕМАТИКА ТА ЗМІСТ КУРСОВОГО ПРОЕКТУ

1.1 Тематика

1.2 Обсяг проекту та його зміст

2 ОФОРМЛЕННЯ ПОЯСНЮВАЛЬНОЇ ЗАПИСКИ

2.1 Загальні правила оформлення

2.2 Структура пояснювальної записки

2.3 Вміст вступної частини пояснювальної записки

2.3.1 Титульний аркуш

2.3.2 Індивідуальне завдання

2.3.3 Анотація

2.3.4 Зміст

2.4 Вміст основної частини

2.4.1 Вступ

2.4.2 Предпроектний аналіз системи захисту

2.4.3 Техноробоче проектування системи захисту

2.4.4 Впровадження системи захисту

2.5 Висновки

2.6 Список використаних джерел

2.7 Додатки

3 РОЗРОБКА І ОФОРМЛЕННЯ ГРАФІЧНОЇ ЧАСТИНИ

4 ГРАФІК ВИКОНАННЯ КУРСОВОГО ПРОЕКТУ І ПОРЯДОК ЙОГО ЗАХИСТУ

5 ОЦІНЮВАННЯ КУРСОВОГО ПРОЕКТУ

6 ВАРІАНТИ ЗАВДАНЬ

7 ЛІТЕРАТУРА

ДОДАТКИ

Додаток А  Приклад оформлення титульного аркуша

Додаток Б  Приклад рамки на першу сторінку змісту

Додаток В  Приклади рамок

Додаток Г  Приклад оформлення індивідуального завдання

Додаток Д  Приклад анотації

Додаток Е  Приклад змісту

Додаток Ж  Приклад технічного завдання

1 ТЕМАТИКА ТА ЗМІСТ КУРСОВОГО ПРОЕКТУ

1.1 Тематика

Курсовий проект (КП) – навчальний самостійній проект з дисципліни, яка містить елементи (задачі) навчального, аналітично-розрахункового та науково-дослідницького характеру.

В курсовому проекті з дисципліни «Технології створення та застосування систем захисту в кіберпросторі» студент повинен показати знання основних принципів проектування та подальшого практичного застосування систем захисту інформації та асоційованих із ними програмних засобів.

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

Тематика курсового проекту пов’язана з майбутньою спеціальністю студентів. Для програмної реалізації даного курсового проекту пропонуються розробка системи захисту інформації в кіберпросторі або асоційованою із цією тематкою програмних засобів.

Під час виконання курсового проекту студенти повинні використати всі знання, отримані ними під час вивчення дисциплін «Основи інформаційної безпеки», «Прикладана криптологія», «Захист операційних систем», «Засоби програмування», «Організаційне забезпечення інформаційної безпеки підприємства», «Інформаційно-комунікаційні системи», «Технології створення та застосування систем захисту в кіберпросторі», «Комплексні системи захисту інформації».

Зміст курсового проекту відповідає робочому плану дисципліни «Технології створення та застосування систем захисту в кіберпросторі» і повинен відображати суть теми, яка розглядається.

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

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

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

В 1 семестрі студентам пропонується виконати курсовий проект (КП - 45 годин / 1,5 кредита). Завдання на курсовий проект включає весь матеріал, який було опрацьовано під час лекційних, практичних, лабораторних та самостійних занять протягом курсу вивчення дисципліни.

1.2 Обсяг проекту та його зміст

При виконанні курсового проекту обов’язково повинні бути використані такі елементи:

- передпроектний аналіз предметної області системи;

- техноробоче проектування системи захисту;

-  тестування та оцінка ефективності системи захисту.

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

- індивідуальне завдання на курсовий проект;

- передпроектний аналіз системи захисту;

- техноробоче проектування системи захисту

- впровадження системи захисту

- висновки та перелік використаної літератури;

- додатки:

- технічне завдання;

- схема алгоритму програми;

- схема структурна засобу;

- схема алгоритму методу захисту;

- текст програми;

- програма та методика випробувань;

- керівництво користувача (оператора).

2 ОФОРМЛЕННЯ ПОЯСНЮВАЛЬНОЇ ЗАПИСКИ

2.1 Загальні правила оформлення

При оформленні пояснювальної записки (ПЗ) необхідно дотримуватись вимог до курсового проекту за ГОСТ 2.105-95. Текст пояснювальної записки повинен бути набраний на комп'ютері та роздрукований на принтері.

Обсяг. Обсяг текстової частини визначається кількістю годин СРС, які виділяються для дисципліни на курсовий проект навчальним планом (30 − 40 с.).

Шрифт і відступи.

Текст ПЗ виконується у відповідності з вимогами ГОСТ 2.105-95 одним із застосовуваних друкувальних та графічних пристроїв виведення ЕОМ з висотою букв і цифр не менше 2,5 мм, (кегль – № 14), через один інтервал (ГОСТ 2.004-88).

Текст пояснювальної записки повинен бути набраний у будь-якому текстовому редакторі шрифтом Times New Roman розміром 14 з інтервалом між рядками 1.

Текст розміщують таким чином, щоб відстань від рамки до робочого поля становила: зліва і справа – 3-5 мм; зверху і знизу – не менше 10 мм; абзац – 5 знаків (відступ 0,75 см). Відступи рамок до країв аркуша: зліва – 20 мм, решта – 5 мм. Наявність рамок у додатках, які містять графічний матеріал, є обов’язковою.

Шрифт та міжрядковий інтервал у додатках можуть бути довільними, але оформлені так, щоб можна було прочитати і зрозуміти. Відступи: зліва – 2,5 см; справа – 1 см; зверху – 1,5 см; знизу – 2.5 см.

Рамки. На першій сторінці виконується рамка показана у додатку А. Індивідуальне завдання, анотації та додатки (за винятком креслень) виконуються без рамок. Перша сторінка змісту містить рамку 180х40 показану у додатку Б. На інших сторінках ПЗ використовується рамка 180х15 показана у додатку В рис. В1. На кресленнях, що представлені у додатках (схема роботи програми, схема обміну даними, схема функціонування програми, структурна схема тощо) використовується рамка 180х40 показана у додатку В рис. В3.

Нумерація сторінок. Сторінки повинні бути пронумеровані, починаючи з третьої (зміст), у правому нижньому кутку сторінки на рамці. Нумерація додатків продовжує основну нумерацію.

Оформлення розділів і підрозділів. Структурними елементами основної частини ПЗ є розділи, підрозділи, пункти, підпункти, переліки.

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

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

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

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

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

Перед та після заголовку підрозділу пропускається один рядок.

Розділи нумерують порядковими номерами в межах всього документа (1, 2, і т.д.). Підрозділи нумерують в межах кожного розділу, пункти – в межах під­розділу і т.д. за формою (3.1, 3.2, 3.2.1, 3.2.2 і т.д.). Цифри, які вказують номер, не повинні виступати за абзац. Після номера крапку не ставлять, а пропускають один знак.

Заголовки розділів і підрозділів, пунктів і підпунктів не повинні містити знаків переносу на новий рядок. Назви розділів і підрозділів, пунктів і підпунктів не повинні мати крапки в кінці.

Допускається розміщувати текст між заголовками розділу і підрозділу, між заголовками підрозділу і пункту. Посилання в тексті на розділи виконується за формою: “...наведено в розділі 3”.

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

На всі таблиці мають бути посилання за формою “ ... в табл. 2.1” або в дужках по тексту (табл. 2.1). Посилання на раніше наведену таблицю дають зі скороченим словом ”дивись” (див. табл. 2.4) за ходом чи в кінці речення.

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

Бажано використовувати засоби автоматичної нумерації ілюстрацій.

Оформлення рисунків. Розміщують рисунки в тексті або в додатках. В тексті рисунки розміщують симетрично до тексту після першого посилання на неї або на наступній сторінці, якщо на даній вона не уміщується без повороту. На всі рисунки мають бути посилання за формою: “ ... на рис. 3.5”, або в дужках по тексту (рис. 3.6). Посилання на раніше наведений рисунок дають зі скороченням (див. рис. 1.4).

Кожен рисунок повинен мати номер і підпис, розташовані під рисунком по центру. Крапку в кінці не ставлять, знак переносу не використовують. Якщо найменування рисунка довге, то його продовжують у наступному рядку, починаючи від найменування. Приклад показано на рис. 2.1.

Між рисунком і текстом пропускають один рядок.

Нумерують рисунки в межах розділів або в межах всього документа.

Бажано використовувати засоби автоматичної нумерації рисунків.

Рисунок 2.1 – Вигляд вікна авторизації

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

При проведенні аналізу ризиків підприємства було виділено такі основні загрози:

– обхід мережевого екрану;

– DDoS атака на мережу підприємства;

– зовнішній моніторинг;

– несанкціонований доступ до інформаційних ресурсів;

– викрадення паролів.

Для подальшої деталізації використовують арабські цифри з дужкою. Наприклад,

Для забезпечення функціонування мережі виконати таке.

1) Заборонити широкомовні адреси.

2) Заборонити використання всіх портів для обміну TCP/UDP.

3) Обмежити смугу пропускання.

4) Проводити аудит вхідного та вихідного трафіку.

Оформлення формул. Між формулою і текстом пропускають один рядок. Кожну формулу записують з нового рядка, симетрично до тексту, курсивом.

Умовні літерні позначення в формулі наводять в тексті або зразу ж під формулою. Для цього після формули ставлять кому і записують пояснення до кожного символу з нового рядка в тій послідовності, в якій вони наведені у формулі, розділяючи крапкою з комою. Перший рядок повинен починатися з абзацу з слова “де” і без будь-якого знака після нього.

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

Потреба в обслуговуванні обчислюється за формулою

 

,

(2.1)

де  - коефіцієнт використання черги ;

 - кількість запитів, виконаних за час .

2.2 Структура пояснювальної записки

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

Пояснювальна записка повинна мати таку структуру:

Вступна частину, яка містить:

-  титульний аркуш;

-  індивідуальне завдання;

-  анотацію;

-  зміст.

Основна частина, яка складається з:

-  вступу;

-  основної частини;

-  висновків;

-  списку використаних джерел.

Додатки, які розміщуються після основної частини пояснювальної записки курсового проекту, обов’язковими додатками є:

-  Додаток А Технічне завдання;

-  креслення обумовлені в завданні;

-  лістинг коду програми.

2.3  Вміст вступної частини пояснювальної записки

2.3.1  Титульний аркуш

Титульний аркуш є першою сторінкою КП, яка не нумерується. Згідно з діючим стандартом титульний аркуш виконується за встановленим зразком. Зразок титульного аркушу пропонується у додатку А.

На титульному аркуші для курсових проектів подаються: тема курсового проекту; запис «Пояснювальна записка ...» із зазначенням спеціальності, умовне позначення згідно з прийнятою системою (див. далі); перераховується науковий ступінь та звання керівника. Підписи керівника та студента із зазначенням термінів обов’язкові.

Для курсових проектів доцільною є предметна система умовних позначень, яка має таку структуру:

хх-хх.ххх.ххх.хх.ххх хх

1     2       3        4     5   6

хх-хх.ххх.ххх.хх.ххх хх

1     2       3        4     5   6

де  1 (ХХ-ХХ) – числовий шифр кафедри, прийнятий у ВНТУ (08-20);

2 (ХХХ) – умовне скорочення для дисципліни (ТСЗСЗвК – Технології створення та застосування систем захисту в кіберпросторі);

3 (XXХ) – перша цифра 0, якщо це проект або 1, якщо робота, друга і третя цифри означають рік, наприклад, 16 – 2016 рік);

4 (XX) – варіант завдання на курсовий проект (наприклад, 01, 02, . . ., 99);

5 (XXХ) – перший символ – номер групи (1 або 2), наступні два символи задають номер студента за списком у журналі академічної групи;

6 (XX) – код документа (ПЗ – пояснювальна записка, ТЗ – технічне завдання, ГЧ – графічна частина).

Слід зазначити, що робота, яка подається у вигляді копії, до захисту не приймається.

2.3.2  Індивідуальне завдання

Конкретний зміст кожного КП та етапи виконання визначає керівник на підставі індивідуального завдання, затвердженого завідувачем кафедри не пізніше ніж за два тижні після початку семестру.

Керівник видає індивідуальне завдання до курсового проекту. Індивідуальне завдання в перелік змісту не вноситься та має бути другою сторінкою після титульного аркуша. Зразок індивідуального завдання до курсового проекту наведено в додатку Г.

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

В залежності від специфіки дисципліни керівник курсового проекту може пропонувати тему, яка вимагає конкретного обґрунтування та розробки індивідуального завдання. Індивідуальне завдання до курсового проекту повинно містити термін видачі, підписи керівника та студента.

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

2.3.3  Анотація

Анотація призначена для ознайомлення з текстовим документом курсового проекту. Анотація повинна коротко характеризувати мету роботи, засоби, використанні для досягнення поставленої задачі, коротку інформацію про досягнуті результати. Розмір анотації повинен становити приблизно 1/3 частину сторінки. Анотація повинна бути двома мовами українською та англійською.

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

2.3.4  Зміст

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

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

Приклад оформлення змісту можна бачити у додатку Е.

2.4  Вміст основної частини

2.4.1  Вступ

Вступ пишуть з нової пронумерованої сторінки з заголовком «ВСТУП» посередині великими літерами з більш високою насиченістю шрифту (напівжирний).

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

Вступ висвітлює:

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

-  актуальність, яка повинна подаватись в останньому абзаці вступу з метою стислого викладання суті обраної розробки.

-  галузь використання та призначення даної розробки;

-  мету та завдання.

Кількість сторінок вступу не повинна перевищувати 2 сторінки.

2.4.2  Предпроектний аналіз системи захисту

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

2.4.2.1 Системний аналіз предметної області системи захисту

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

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

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

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

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

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

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

2.4.2.2 Формулювання вимог до системи захисту

Виконайте порівняльний аналіз відомих аналогів (програм, методів, моделей, методик, підходів)  проектованої системи захисту. Виділіть переваги та недоліки.

Обґрунтуйте фактори впливу на ефективне використання  автоматизованого робочого місця (АРМ) для розв’язання комплексу задач системи захисту.  Обґрунтування виконайте по кожній із груп.

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

-  об’єм інформації за одиницю часу і його зміна в часі (протягом доби, місяця, року);

-  тип носія вхідної інформації;

-  характер вхідної інформації (співвідношення між алфавітною і цифровою інформацією й ін.).

У другу групу можна включити фактори, які залежать від характеру задач, що повинні вирішуватися на ЕОМ або ОС, і алгоритмів їхнього розв’язання. Такі фактори включають :

-  терміновість задач ;

-  допустимість затримки у видачі результатів, а також величина припустимої затримки;

-  можливість поділу задач на підзадачі, які можна вирішувати в різний час або на різних засобах (наприклад, різних ЕОМ);

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

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

До третьої групи доцільно віднести фактори, зумовлені технічними характеристиками ЕОМ і ОС. Вкажемо лише деякі з них:

-  продуктивність процесора;

-  об’єм оперативної пам'яті;

-  наявність надоперативної пам'яті і її об’єм;

-  об’єм і швидкодія зовнішньої пам'яті;

-  можливість розширення об’єму пам'яті (шляхом підключення додаткових модулів пам'яті);

-  система числення, яка використовується для введення й обробки даних;

-  форма подання даних при введенні, виведенні й обробці даних;

-  ступінь розвиненості системи команд із погляду обробки конкретних задач;

-  режими роботи (пакетні, поділу часу й ін.);

-  можливості об'єднання в багатопроцесорні і багатомашинні комплекси;

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

-  ступінь повноти автоматичного контролю виконання операцій.

У четверту групу можна включити експлуатаційні характеристики ЕОМ і ОС:

-  надійність ЕОМ і ОС і їхніх окремих пристроїв, а також пов'язані з надійністю характеристики (середній наробіток на відмовлення, корисний добовий час роботи й ін.);

-  загальна споживана потужність;

-  необхідні умови експлуатації;

-  необхідний штат обслуговуючого персоналу і його кваліфікація.

У п'ятій групі факторів доцільно виділити вартісні показники, до яких прийнято відносити наступні:

-  капітальні вкладення, тобто витрати на придбання й установку ЕОМ і ОС;

-  витрати на утримання обслуговуючого персоналу;

-  витрати на електроенергію;

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

-  витрати на допоміжні матеріали.

Визначте фактори по кожній із груп.

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

Проектні рішення по інформаційному забезпеченню будуються з погляду позамашинного і внутрішньо-машинного забезпечення і включають наступні питання:

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

- обґрунтування складу і змісту результатних масивів і вихідних документів;

- обґрунтування складу, форм представлення вихідної інформації в первинних документах і на машинних носіях;

- обґрунтування вимог до систем класифікації і кодування інформації.

У даному розділі також приділіть увагу обґрунтуванню методів організації інформаційної бази.

          Розгляньте наступні питання:

- обґрунтування вибору форми збереження даних (база даних або сукупність локальних файлів);

- обґрунтування вибору моделі логічної структури бази даних (ієрархічної, мережний, реляційної);

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

При виборі ІЗ створюваної системи найбільш важливими є наступні вузли вибору альтернативних рішень:

-  визначення доцільності використання інтегрованої бази даних;

-  вибір СУБД;

-  вибір структури автономних файлів;

-  використання діалогу.

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

Фактори вибору наступні:

1. Визначення доцільності використання інтегрованої бази даних (БД):

-  складність інформації;

-  різнорідність запитів;

-  обсяг інформації;

-  обсяг коректувань;

-  можливості ЕОМ /пам'ять, програмне забезпечення, надійність.

2.  Використання діалогу:

-  вимоги користувача;

-  різнорідність запитів;

-  об’єми інформації;

-  можливості ЕОМ;

-  надійність;

-  час реакції на запит;

-  простота роботи користувача.

3.  Вибір структури автономних файлів:

-  потрібна пам'ять;

-  час на коректування;

-  надійність;

-  час вирішення задачі.

4.  Вибір СУБД:

-  структура інформації;

-  можливості ЕОМ;

-  наявність програмного забезпечення;

-  широта програмного оточення СУБД;

-  наявність мережі ЕОМ;

-  час реакції на запит.

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

- вибір способу збору вихідної інформації на основі аналізу доцільності використання технічних засобів збору (реєстраторів, датчиків, лічильників і т.д.);

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

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

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

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

- обґрунтувати вибір відповідного інструментального засобу (мови програмування, спеціалізовані бібліотеки, СУБД, системи автоматизованого проектування, системи класу CASE і ін.) і середовища в якій передбачається використання розроблювальної ЕІС;

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

- розкрити сутність методів проектування раціональної внутрімашинної технології (наприклад, скорочення числа сортувань, використання ефективних методів пошуку інформації, процедурно-орієнтованих підходів до виділення модулів і т.д.);

- визначити функції керуючої програми;

- обґрунтувати наявні режими обробки даних (при яких обставинах буде використовуватися пакетний режим, у яких випадках діалоговий і т.д.) ;

    − виробити вимоги до оформлення екранних і друкованих форм, ергономіки програмного забезпечення.

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

На основі проведеного аналізу сформулювати вимоги до проектованої системи та відобразити у технічному завданні. Вимоги групуються у ТЗ по таким розділам та категоріям:

 «ВИМОГИ ДО СИСТЕМИ» складається з наступних підрозділів:

1) вимоги до системи в цілому;

2) вимоги до функцій (задач), що  виконується  системою;

3) вимоги до видів забезпечення.

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

 «ВИМОГИ ДО СИСТЕМИ В ЦІЛОМУ» включають:

-     вимоги до структури й функціонування системи;

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

-     показники призначення;

-     вимоги до надійності;

-     вимоги безпеки;

-     вимоги до ергономіки й технічної естетики;

-     вимоги до транспортабельності для рухливих АС;

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

-     вимоги до захисту інформації від несанкціонованого доступу;

-     вимоги по схоронності інформації при аваріях;

-     вимоги до захисту від впливу зовнішніх впливів;

-     вимоги до патентної чистоти;

-     вимоги по стандартизації й уніфікації;

-     додаткові вимоги.

„ВИМОГИ ДО ФУНКЦІЙ (ЗАДАЧ), ЩО ВИКОНУЮТЬСЯ СИСТЕМОЮ”, включають:

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

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

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

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

4) перелік і критерії відмов для кожної функції, по якій задаються вимоги по надійності.

 «ВИМОГИ ДО ВИДІВ ЗАБЕЗПЕЧЕННЯ» . Тут залежно від виду системи приводять вимоги до математичного, інформаційного, лінгвістичного, програмного, технічного, метрологічного, організаційного, методичного й інші видам забезпечення системи.

Розробіть склад і зміст робіт зі створення СЗ. Він повинен містити перелік стадій і етапів робіт зі створення системи, строки їхнього виконання, перелік виконавців робіт. Побудуйте мережевий графік та діаграму Ганта проекту.

Розробіть технічне завдання на СЗ згідно ГОСТ 19.201-78 або ГОСТ 34.602-89 або НД ТЗІ 3.7-001-99 ( у разі розробки комплексної СЗІ).

2.4.3  Техноробоче проектування системи захисту

Проект СЗ розробляється на підставі та у відповідності до ТЗ . Під час розробки проекту СЗ обґрунтовуються і приймаються проектні рішення, які дають змогу реалізувати вимоги ТЗ, забезпечити сумісність і взаємодію різних компонентів СЗ, а також різних заходів і способів захисту інформації. Проект СЗ виконується на таких стадіях: ескізний проект, технічний проект, робочий проект. Дозволяється вилучати етап “Ескізний проект ”, а також поєднувати етапи “Технічний проект ” і “Робочий проект ” в один етап “Техноробочий проект ”. Для всіх стадій розробки проекту СЗ склад документації визначається ТЗ на СЗ, види та зміст - ГОСТ 34.201-89, НД ТЗІ 2.5-004. Документація на програмні засоби виконується згідно з комплексом стандартів ЄСПД, а на технічні засоби – згідно з комплексом стандартів ЄСКД. Рекомендований обсяг підрозділу – 10-20 сторінок пояснювальної записки.

2.4.3.1 Технічне проектування системи захисту

Розробку технічного проекту можна поділити на 4 етапи (ГОСТ 34.601–90 «Автоматизированные системы. Стадии создания»,  НД ТЗІ 3.7-003 -2005 «Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі»).

1. Розробка проектних рішень по системі захистута її частинах.

2. Розробка документації на систему захисту та її частини.

3. Розробка документації на постачання засобів захисту інформації та/або технічних вимог (технічних завдань) на їх розробку.

4. Розробка завдань на проектування в суміжних частинах проекту.

Перелік документів, що створюються на стадії «Технічний проект», визначається документом ГОСТ 34.201-89. Вимоги до змісту документів технічного проекту наведені в керівному документі по стандартизації РД 50-34.698-90.

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

Здійснюються організаційно-технічні заходи щодо забезпечення послідовності розробки СЗ, архітектури, середовища розробки, випробувань, середовища функціонування та експлуатаційної документації СЗ у відповідності до заданих рівнем гарантій реалізації послуг безпеки згідно із специфікаціями НД ТЗІ 2.5-004, НД ТЗІ 2.5-007, НД ТЗІ 2.5-008, НД ТЗІ 2.5-010.

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

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

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

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

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

Організаційне забезпечення це сукупність документів, які встановлюють організаційну структуру, права і обов`язки користувачів і експлутаційного персоналу в умовах функціонування, перевірки та забезпечення працездатності ІС.

Методичне забезпечення це сукупність документів, що описують технологію функціонування СЗ, методи вибору і використання користувачами технологічних прийомів для отримання конкретних результатів при функціонуванні ІС.

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

Усю інформацію, що обробляється в СЗ, можна поділити на вхідну, проміжну та вихідну.

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

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

Математичне забезпечення це сукупність математичних  ме­тодів, моделей і алгоритмів, що використовуються в ІС.

Програмне забезпечення це сукупність програм на носіях даних і програмних документів, призначених для відладки, функціонування та перевірки працездатності СЗ.

Лінгвістичне забезпечення  це сукупність засобів і правил для формалізації природної мови, що ви­користовуються при спілкуванні користувачів і експлутаційного персоналу із СЗ.

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

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

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

-    Функціональна й організаційна структура системи:

1)  обґрунтування виділення підсистем системи захисту, їх перелік та призначення;

2)  перелік завдань, що вирішуються в кожній підсистемі, з короткою характеристикою їх змісту;

3)  схема інформаційних зв'язків між підсистемами і між завданнями в рамках кожної підсистеми.

-    Постановка завдань і алгоритми вирішення:

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

2)   математична модель задачі (структурна і розгорнута форма подання);

3)   вхідна оперативна інформація (характеристика показників, діапазон зміни, форми подання);

4)   нормативно-довідкова інформація (НДІ) (зміст і форми подання);

5)   інформація, що зберігається для зв'язку з іншими завданнями;

6)   інформація, що накопичується для наступних варіантів розв'язання задачі;

7)   інформація щодо внесення змін (система внесення змін і перелік інформації, яка піддається змінам);

8)   алгоритм вирішення задачі (послідовність етапів розрахунку, схема, розрахункові формули);

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

-    Організація інформаційної бази:

1)   джерела надходження інформації та способи її передачі;

2)   сукупність показників, що використовуються в системі;

3)   склад документів, терміни і періодичність їх надходження;

4)   основні проектні рішення по організації фонду НДІ;

5)   склад НДІ, включаючи перелік реквізитів, їх визначення, діапазон зміни і перелік документів НДІ;

6)   перелік масивів НДІ, їх обсяг, порядок і частота коригування інформації;

7)   структура фонду НДІ з описом зв'язку між його елементами; вимоги до технології створення і ведення фонду;

8)   методи зберігання, пошуку, внесення змін і контролю;

9)   визначення обсягів і потоків інформації НДІ;

10)   контрольний приклад по внесенню змін до НДІ;

11)   пропозиції щодо уніфікації документації.

-    Система математичного забезпечення:

1)   обґрунтування структури математичного забезпечення;

2)   обґрунтування вибору системи програмування;

3)   перелік стандартних програм.

-    Принцип побудови комплексу технічних засобів:

1)  опис і обґрунтування схеми технологічного процесу обробки даних;

2)  обґрунтування і вибір структури комплексу технічних засобів і його функціональних груп;

3)  обґрунтування вимог до розробки нестандартного обладнання;

4)  комплекс заходів щодо забезпечення надійності функціонування технічних засобів.

-    Заходи з підготовки об'єкта до впровадження системи:

1)   перелік організаційних заходів щодо вдосконалення бізнес-процесів;

2)   перелік робіт з впровадження системи, які необхідно виконати на стадії робочого проектування, із зазначенням термінів і відповідальних осіб.

2.4.3.2 Робоче проектування системи захисту

На етапі “Робочий проект” (НД ТЗІ 3.7-003 -2005) або «Робоча документація» (ГОСТ 34.601–90)  ведуться роботи щодо практичної реалізації положень, закладених в проекті. Робоча документація розробляється на основі затверджених технічного завдання і технічного проекту і затвердженню не підлягає.

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

Основні роботи на етапі робочого проектування:

1. Розробка робочої документації на систему та її частини.

2. Розробка чи адаптація системи.

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

Можна виділити такі роботи:

1) прийняття рішень щодо організації розробки робочої документації;

2) розробка загальносистемних проектних рішень;

3) розробка проектної документації з видів забезпечення;

4) оформлення, погодження, затвердження в установленому порядку.

Роботи з інформаційного забезпечення:

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

2) перевірка інформаційно-логічної структури бази даних;

3) розробка інструкції для створення і ведення бази даних.

Роботи з організаційного забезпечення:

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

2) розробка технологічного процесу обробки даних, який складається з технологічного процесу отримання і обробки даних. Розробка керівництва користувача.

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

У ході розробки робочої документації замовник:

1) забезпечує приймання до дослідної експлуатації;

2) завершує під методичним керівництвом розробника формування інформаційної бази і організовує її експлуатацію;

3) передає на вимогу розробника дані, необхідні для перевірки задач на контрольних приладах;

4) організовує приймання програм, надаючи розробникові магнітні носії та машинний час;

5) виконує основні організаційно-технічні заходи з підготовки підприємства до введення системи в дію.

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

Склад і структура проектної документації на стадіях «Технічний проект» і «Робоча документація» визначаються ГОСТ 34.201–89 «Виды, комплектность и обозначение документов при создании автоматизированных систем», РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов», ГОСТ 19.101-77 «Виды программ и программных документов»

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

Загальносистемні рішення:

1. Формуляр.

2. Паспорт.

3. Загальний опис системи.

4. Програма і методика випробувань.

5. Відомість тримачів оригіналів.

6. Відомість експлуатаційних документів.

7. Проектна оцінка надійності системи.

8. Локальний кошторис.

Технічне забезпечення:

1. Специфікація обладнання.

2. Відомість потреб у матеріалах.

3. Інструкція з експлуатації КТЗ.

4. Схема структурна КТЗ.

5. Схема поділу системи.

Організаційне забезпечення:

1. Методика (технологія) автоматизованого проектування.

2. Технологічні інструкції.

3. Керівництво користувача.

4. Опис технологічного процесу обробки даних.

Інформаційне забезпечення:

1. Каталог бази даних.

2. Відомість машинних носіїв інформації.

3. Склад вхідних даних (повідомлень).

4. Масив вхідних даних.

5. Креслення форм документів (відеокадрів).

6. Інструкція з формування і ведення бази даних (набору даних).

У ПЗ до КП представте та прокоментуйте основні програмні коди проектованої системи захисту. Розробіть документ «Текст програми» згідно ГОСТ 19.401-78 та представте його у додатках до ПЗ. Наведіть основні принципові аспекти щодо використання проектованої системи із використанням відповідних екранних форм та коментарів до них. Розробіть документ «Керівництво оператора» згідно ГОСТ 19.505-79 або «Керівництво користувача» згідно РД 50-34.698-90 та представте його у додатках до ПЗ.

2.4.4  Впровадження системи захисту

На етапі введення СЗ в дію виконуються такі роботи:

−    підготовка СЗ до введення в дію;

−    навчання користувачів;

−    комплектування СЗ;

−    будівельно-монтажні роботи;

−    пусконалагоджувальні роботи;

−    попередні випробування;

−    дослідна експлуатація;

−    приймальні випробовування (державна експертиза).

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

Рекомендований обсяг підрозділу – 10-15 сторінок пояснювальної записки.

2.4.4.1 Проведення випробувань системи захисту

Метою випробувань є перевірка працездатності СЗ та визначення можливості прийняття її у дослідну експлуатацію. Під час випробувань перевіряються працездатність СЗ та відповідність її вимогам ТЗ. Випробування проводяться згідно з програмою та методиками випробувань. Програму й методики випробувань готує розробник СЗ, а узгоджує замовник. Програма та методики випробувань, протоколи випробувань розробляються та оформлюються згідно з вимогами ГОСТ 19.301-79  або РД 50-34.698.

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

У разі отримання  негативних результатів виконання тестів вкажіть на можливі причини їх отримання та виконайте налагодження системи із повторним тестуванням до отримання бажаного позитивного результату.

Розробіть документ «Програма та методика випробовувань» згідно ГОСТ 19.301-79 або РД-50-34.698-90  та представте його у ПЗ до ПК.

2.4.4.2 Оцінка ефективності системи захисту

Оцінку ефективності системи захисту можна виконати за економічними, технічними та соціальними показниками.

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

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

Відобразіть соціальний ефект від розробки системи захисту, якщо таке передбачалося у ТЗ.

Можете запропонувати із відповідним обґрунтуванням власні показники оцінки ефективності системи захисту інформації.

Проведіть порівняльний аналіз функціоналу та вартісних показників вашої системи з аналогічними.

2.5 Висновки

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

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

2.6 Список використаних джерел

Список містить перелік літературних джерел, на які повинні бути обов’язкові посилання в тексті пояснювальної записки. Література (книги, статті, патенти, журнали) в загальний список записується в порядку посилання на неї в тексті. В даному переліку дається оформлений відповідно до вимог ДСТУ ГОСТ 7.1:2006 «Бібліографічний запис. Бібліографічний опис. Загальні вимоги та правила складання», перелік літературних джерел, які було використано в процесі виконання проекту, і на яку є посилання в тексті пояснювальної записки. Кожне джерело повинно бути вказано разом з видавництвом, роком видання, кількістю сторінок. Літературу записують мовою оригіналу. В списку кожне джерело записують з абзацу, нумерують арабськими цифрами, починаючи з одиниці.

Якщо у списку використаних джерел є посилання на Інтернет-сторінки, слід наводити і їх.

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

2.7 Додатки

Обов’язковим додатком є технічне завдання (Додаток А). Технічне завдання розробляється студентом самостійно на основі індивідуального завдання протягом 2-х перших тижнів триместру. Зразок технічного завдання наведено у додатку Ж. Також обов’язковими додатками є текст програми, керівництво користувача, програма і методика випробувань.

Інші додатки повинні містити матеріал, який не увійшов в основні розділи пояснювальної записки: лістинг програм, підпрограм та функцій, результати тестування програми у вигляді образів екранів, таблиць, графіків, креслення, які займають більш ніж аркуш формату А4.

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

Кожен додаток необхідно починати з нової сторінки, вказуючи зверху посередині рядка слово “Додаток” і через пропуск – його позначення. Додатки позначають послідовно великими українськими буквами, за винятком букв Г, Є, З, І, Ї, Й, О, Ч, Ь, наприклад, Додаток А, Додаток Б і т.д. Якщо додатків більше ніж букв, то продовжують позначати арабськими цифрами. Дозволяється позначати додатки латинськими буквами, за винятком букв I і O.

Кожен додаток повинен мати тематичний (змістовний) заголовок, який записують посередині рядка малими літерами .

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

Всі додатки включають у зміст, вказуючи номер, заголовок і сторінки, з яких вони починаються.

Приклад оформлення додатків можна переглянути у додатках до даних методичних вказівок.

3 РОЗРОБКА І ОФОРМЛЕННЯ ГРАФІЧНОЇ ЧАСТИНИ

Як результат виконання курсового проекту є розробка графічної частини, яка демонструє основні результати виконаної розробки.

В курсовому проекті обов’язковими є два креслення:

1. Схема роботи системи захисту

2. Схема структурна системи захисту

Креслення друкуються на аркушах формату А4 з рамками 40х180 мм, як показано у додатку В.2. Графічна частина прикріпляється до пояснювальної записки, але не є її складовою частиною.

Графічна частина має окрему нумерацію та підписи у рамках.

4 ГРАФІК ВИКОНАННЯ КУРСОВОГО ПРОЕКТУ І ПОРЯДОК ЙОГО ЗАХИСТУ

Рекомендується такий графік виконання курсового проекту (табл. 4.1), який враховує самостійну роботу студентів під час 10-го триместру (16 тижнів).

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

5 ОЦІНЮВАННЯ КУРСОВОГО ПРОЕКТУ

Оцінюється курсовий проект членами комісії після її захисту студентом у балах і за національною шкалою оцінок. Загальна кількість балів включає (табл. 5.1) оцінки змісту роботи (до 34 балів), оформлення (до 20 балів), графічної частини (до 20 балів) та захисту (до 26 балів).

При оцінюванні курсової роботи за кредитно-модульною системою враховуються

- кваліфікаційний рівень (фаховість, дотримання стандартів) підготовки захисту ІКС;

- обґрунтування актуальності теми, на яку підготовлено курсовий проект;

- відповідність назв і змісту структурних елементів пояснювальної записки цілям, завданням та особливостям побудови систем захисту ІКС;

- грамотність викладу змісту пояснювальної записки, відповідність її вимогам щодо оформлення робіт;

- вміння студента представляти результати курсового проектування.

Підготовка курсового проекту – сумарно 100 балів, у тому числі:

Якість розробки проекту – 34 бали:

- фахова вмотивованість рішень – 10 бали;

- логічність і послідовність рішень – 10 балів;

- обґрунтованість та оптимальність обраних рішень – 10 балів;

- дотримання стандартів побудови систем захисту – 4 бали.

Зміст пояснювальної записки – 20 балів:

- відповідність структурних розділів визначеній тематиці та вимогам до даного типу робіт: вступ; основна частина; висновки; додатки – 10 балів.

- відповідність оформлення ПЗ стандартам –5 балів;

- наявність посилань та списку використаних джерел – 3 бали;

- дотримання граматичних і стилістичних правил – 2 бали.

Зміст графічної частини – 20 балів:

- відповідність графічної частини завданню – 8 балів;

- відповідність графічної частини тексту пояснювальної записки –7 балів;

- відповідність графічної частини стандартам –5 балів.

Захист курсового проекту – 26 балів:

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

- відповіді на запитання (чіткість формулювання та відповідність запитанню) – 13 балів.

Для переведення суми балів в оцінку за національною шкалою використовуємо шкалу оцінювання (таблиця 5.2).

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

6    ВАРІАНТИ ЗАВДАНЬ

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

Типові варіанти для виконання КП:

1.  Проектування програмного засобу для обфускації.

2.  Проектування системи захисту від SQL-ін'єкцій.

3.  Проектування програмного засобу для захисту даних в ОС Android.

4.  Проектування програмного засобу для виявлення прихованих процесів в ОС Windows.

5.  Проектування програмного засобу для захисту виконуваних файлів за допомогою цифрового підпису.

6.  Проектування системи виявлення DDOS атак на основі самоорганізаційних карт Кохонена.

7.  Проектування програмного засобу для аналізу ШПЗ в ОС Android.

8.  Проектування засобу для захисту баз даних в ОС Android.

9.  Проектування засобу захисту від DDoS-атак.

10.  Проектування системи захисту файлів на платформі UWP.

11.  Проектування системи захисту від НСД до програмного забезпечення з прив'язкою до мережевих параметрів.

12.  Проектування оцінки ризиків інформаційної безпеки на основі методу ієрархії.

13.  Проектування СППР при виборі програмно-технічних засобів захисту ві загроз ІБ підприємства.

14.  Проектування системи захисту WEB-ресурсів.

15.  Проектування системи стеганографічного захисту.

16.  Проектування системи захисту від DOS атак на основі багатошарового персептрона.

17.  Проектування системи захисту від несанкціонованого доступу.

18.  Проектування програмного засобу методом хешування.

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

20.  Проектування програмного засобу методом шифрування Цезаря.

21.  Проектування системи захисту мовної інформації в каналах зв'язку.

22.  Проектування програмного захисту методом цифрових водяних знаків.

23.  Проектування системи захисту від аналізу дампа пам'яті в ОС Windows.

24.  Проектування системи виявлення аномалій на основі нейромереж.

25.  Проектування засобу для шифрування файлів на основі еліптичних кривих з використанням прив'язки.

26.  Проектування системи захисту програмного забезпечення з прив'язкою до флеш-носія.

27.  Проектування системи захисту з прив'язкою до апаратного забезпечення комп'ютера.

28.  Проектування системи захисту даних на основі стеганографічних методів.

29.  Проектування системи біометричної автентифікації.

30.  Проектування системи виявлення прихованої інформації методом стеганоаналізу.

31.  Проектування системи захисту від DDOS-атак.

32.  Проектування системи захисту з прив'язкою до місцевості.

33.  Проектування засобу для авторизації на основі стеганографії.

34.  Проектування системи для автентифікації за допомогою блокового шифру.

35.  Проектування системи для автентифікації за допомогою симетричного шифру.

7    ЛІТЕРАТУРА

1.  ГОСТ 19.201-78. Единая система программной документации. Техническое задание.  Требования к содержанию и оформлению. -   Чинний від 1980-01-01. ­– М.: Издательство стандартов, 1978.

2.  ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы.Техническое задание на создание автоматизированной системы. – На заміну ГОСТ 24.201-85.  - Чинний від 1990-01-01. ­– М.: Издательство стандартов, 1989.

3.  ГОСТ 34.601–90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. - Чинний від 1992-01-01. ­– М.: Издательство стандартов, 1990.

4.  НД ТЗІ 3.7-003 -2005 «Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі»

5.  ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы.  Виды, комплектность, обозначения документов при создании автоматизированных систем. - Чинний від 1990-01-01. ­– М.: Издательство стандартов, 1989.

6.  РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы .  Автоматизированные системы. Требования к содержанию документов.  – На заміну ГОСТ 24.104-85 в частині розд. 3. -  Чинний від 1992-01-01. ­– М.: Издательство стандартов, 1990.

7.  ДСТУ 3396.0-96  Захист інформації. Технічний захист інформації. Основні положення. - Чинний від   01-01-1997. – Київ: Держстандарт України, 1996. 

8.  ДСТУ 3396.1-96 Захист інформації. Технічний захист інформації. Порядок проведення робіт. - Чинний від   01-01-1997. – Київ: Держстандарт України, 1996. 

9.  ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення. - Чинний від   01-01-1998. – Київ: Держстандарт України, 1997. 

10. ДСТУ 2226-93 Автоматизовані системи. Терміни та визначення. - Чинний від   01-01-1994. – Київ: Держстандарт України, 1994.

11. ДБН А.2.2-2-96 Проектування. Технічний захист інформації. Загальні вимоги до організації проектування та проектної документації для будівництва. Затверджені наказом Держкоммістобудування України від 02.09.96 р. № 156.

12. НД ТЗІ 2.1-001-2001 Створення комплексів технічного захисту інформації. Атестація комплексів. Основні положення. Затверджено наказом ДСТСЗІ СБ України від 09.02.2001 № 2.

13. НД ТЗІ 2.5-004-99 Критерії оцінки захищеності інформації в комп’ютерних системах від несанкціонованого доступу. Затверджено наказом ДСТСЗІ СБ України від 28.04.1999 № 22.

14. НД ТЗІ 2.5-005-99 Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу. Затверджено наказом ДСТСЗІ СБ України від 28.04.1999 № 22.

15. НД ТЗІ 3.6-001-2000 Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу. Затверджено наказом ДСТСЗІ СБ України від 20.12.2000 № 60.

16. НД ТЗІ 2.5-008-2002 Вимоги із захисту конфіденційної інформації від несанкціонованого доступу під час оброблення в автоматизованих системах класу 2. Затверджено наказом ДСТСЗІ СБ України від 13.12.2002 № 84.

17. НД ТЗІ 2.5-010-2003 Вимоги до захисту інформації WEB - сторінки від несанкціонованого доступу. Затверджено наказом ДСТСЗІ СБ України від 02.04.2003 № 33.

18. НД ТЗІ 3.6-001-2000 Технічний захист інформації. Комп'ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу. Затверджено наказом ДСТСЗІ СБ України від 20.12.2000 р. № 60.

19. НД ТЗІ 3.7-001-99 Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі. Затверджено наказом ДСТСЗІ СБ України від 28.04.99 р. №22.

20. НД ТЗІ 3.7-003-2005. Про порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі.

21. ГОСТ 19.101-77. Единая система программной документации. Виды программ и программных документов.  -   Чинний від 1980-01-01. ­– М.: Издательство стандартов, 1977.

22. ГОСТ 19.401-78. Единая система программной документации. Текст программы. Требования к содержанию и оформлению.  -   Чинний від 1980-01-01. ­– М.: Издательство стандартов, 1977.

23. ГОСТ 19.505-79. Единая система программной документации. Руководство оператора. Требования к содержанию и оформлению .  -   Чинний від 1980-01-01. ­– М.: Издательство стандартов, 1979.

24. ГОСТ 19.301-79. Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению .  -   Чинний від 1981-01-01. ­– М.: Издательство стандартов, 1979.

25. Матвійко А.В. Управління ІТ-проектами. - Львів: Новий світ-200, 2011. - 550 с.

26. Джалота Панкаж. Управление программным проектом на практике. Software Project Management in Practice. - М.: Лори, 2012. - 224 с.

27. Мазур И.И., Шапиро В.Д. Управление проектами. - М.: Омега-Л, 2004. - 664 с.

28. Арчибальд Р.Д. Управление высокотехнологичными программами и проектами / Пер. с анг. Мамонтова Е.В.; под ред. Баженова А.Д., Арсеньева О.А. - М.: ДМК Пресс, 2004.- 463 с  

29. Верба В. А., Загородніх О. А. Проектний аналіз: Підручник. — К.: КНЕУ, 2000. — 322 с.  

30. Кантор Марри. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. - м.: Вильямс, 2002. – 176 с.

31. &Домарев В.В. "Безопасность информационных технологий. Методология создания систем защиты" – К.: ООО "ТИД "ДС", 2002 – 688 с.

32. Домарєв В.В., Швець В.А., Шестакова В.В. Організаційне забезпечення захисту інформації з обмеженим доступом. Навчальний посібник. – К.: НАУ, 2006. – 108 с.

33. Завгородний В.И. Комплексная защита информации в компьютерных системах – М.: Логос; 2001. – 264 с

34. Гвоздева Т.В. Проектирование информационных систем: учеб. пособие / Т.В. Гвоздева, Б.А. Баллод. – Ростов н/Д: Феникс, 2009. –508 с.

35. Душин В.К. Теоретические основы информационных процессов и систем: Учебник / В.К. Душин. – М.: Издательско-торговая корпорация «Дашков и К^о», 2006. – 348 с.

36. Богуш  В.М.,  Довидьков  О.А.,  Кривуца  В.Г. Основи  захищених інформаційних технологій. –К.: ДУІКТ, 2013 -454 с.

37. Грушо  А.А.,  Тимонина  Е.Е.  Теоретические основы защиты информации.–М.: 3-е выд., перер. Изд-во агентства ''BHV'', 2013.–192 с.

38. Зегжда  Д.П.,  Ивашко  А.М.  Основы  безопасности  информационных систем. –М.: Горячая линия-Телеком,2000. –452 с.

39. Теоретические основы компьютерной безопасности: Учебное пособие для вузов / П.Н.Девянин, О.О.Михальский, Д.И.Правиков и др. –М.:Радио и связь, 2010. –192 с.

40. Проектування інформаційних систем : посібник / Пономаренко В. С., ред. - К. : Академія, 2012. - 488 с.

41. Береза А. М. Основи створення інформаційних систем : навч. посіб. / А. М. Береза. - 4-е вид., перероб. і доп. - К. : КНЕУ, 2011. - 214 с.

42. Вендров А.М. Современные технологии анализа и проектирования информационных систем (Электронный ресурс)// Центр Информационных Технологий: Режим доступа: WWW.CITMGU.RU.

43. Грэхем И. Объектно-ориентированные методы. Принципы и практика.–М.: Вильямс, 2004.–880 с.

44. Козленко Л. Проектирование информационных систем. Ч.1. Этапы разработки проекта: стратегия и анализ // КомпьютерПресс, №9, 2001.

45. Международные стандарты, поддерживающие жизненный цикл программных средств.– М.: Экономика, 1996.

46. Моделирование бизнеса и архитектура информационной системы/ О. Полукеев, Д. Коваль// СУБД, №4, 1995.

47. Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем.- М., 1996.

48. Позин Б.А. Современные средства программной инженерии для создания открытых прикладных информационных систем// Системы управления базами данных, №1, 1995.

49. Проектирование программно-технологических комплексов интегрированных адаптирующихся информационных систем / М.В. Кузнецов, С.В. Моздор, А.А. Полтев, А.В. Хомутов //Нормативные и метод. материалы. Сер. Организация информационной деятельности.–М.: ВИМИ, 1989.–Вып.4 (23).–77 с.

50. Державна служба спецзв’язку і захисту інформації України. − Режим доступу до ресурсу: http://www.dstszi.gov.ua/dstszi/control/uk/index.

51. Закон України «Про інформацію» : за станом на 1 січня 2013 р. / Верховна Рада України. — Офіц. вид. — Режим доступу до ресурсу: http://zakon.rada.gov.ua/cgi-bin/laws/main.cgi?nreg=2657-12

52. Закон України «Про захист інформації в інформаційно-телекомунікацій­них системах» : за станом на 1 січня 2013 р. / Верховна Рада України. — Офіц. вид. — Режим доступу до ресурсу: http://zakon.rada.gov.ua/cgi-bin/laws/main.cgi?nreg=80%2F94-%E2%F0.

53. Портал безпека [Електронний ресурс]. – Режим доступу : URL : www.bezpeka.com - Назва з екрану.

54. Издание о высоких технологиях CNews [Електронний ресурс]. – Режим доступу : URL : www.cnews.ru - Назва з екрану.

55. Указ Президента України «Про положення про технічний захист інформації в Україні»  − Режим доступу до ресурсу: http://zakon4.rada.gov.ua/laws/show/1229/99.

Чунарьова А.В. Чунарьов А.В. Комплексний підхід при створенні захищених інформаційних мереж. [Електронний ресурс]. – Режим доступу до журналу: http://www.rusnauka.com/8_NND_2011/Informatica/ 4_81260.doc.htm.

57. Роз’яснення щодо змісту та порядку виконання робіт зі створення комплексної системи захисту інформації та одержання Атестату відповідності. − Режим доступу до ресурсу: http://www.sbu.gov.ua

58. Офіційний сайт книги Гребеннікова В.В. «Історія криптології&секретного зв’язку» . − Режим доступу до ресурсу: http://cryptohistory.ru

ДОДАТКИ

Додаток А
 Приклад оформлення титульного аркуша    pdf

Додаток Б 
Приклад рамки на першу сторінку змісту    pdf

Додаток В 
Приклади рамок   pdf

Додаток Г
Приклад оформлення індивідуального завдання pdf

Додаток Д
Приклад анотації

АНОТАЦІЯ

УДК 004.056

Комаров А. О. «Засіб для підвищення ефективності захисту файлів». Курсовий проект. – Вінниця: ВНТУ, 2016. – 28 с.

Українською мовою. Рисунків – 10, таблиць – 1, бібліографій – 17.

Даний курсовий проект присвячений розробці системи захисту файлів в операційних системах сімейства Windows, методами захисту є шифрування файлів, та контроль цілісності за допомогою порівняння геш-значень файлів. У проекті проведено аналіз відомих рішень для захисту файлів, розроблено проект систему для забезпечення захисту файлів. Обґрунтовано вибір використовуваних засобів. Реалізовано систему захисту з використанням популярних алгоритмів.

ABSTRACT

Andrii Komarov “System for protection user files” Course project. - Vinnytsia: VNTU, 2015. – 28 p.

In Ukrainian. Figures – 10, tables – 1, bibliographies – 17.

This course project dedicated to the development of a secure tool for protection user files. Method of protecting is a decoding and changes control. The project analyzed the information resources of medical institutions, developed safety program. Implemented  methods based on OS Windows using the best algorithms.

Додаток Е
Приклад змісту pdf

Додаток Ж
Приклад технічного завдання pdf

1 Назва та область використання

Засіб для підвищення ефективності захисту файлів. Область використання: Автоматизовані робочі місця з ОС сімейства Windows з підвищеними вимогами до захисту файлів.

2 Основа для розробки        

Розробка виконується на основі індивідуального завдання, затвердженого протоколом засідання кафедри захисту інформації №1 від 11.09.16.

3 Мета та призначення розробки

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

4 Джерела розробки

4.1. Використання Захисника Windows [Електронний ресурс]. – Режим доступу: URL http://windows.microsoft.com/uk-ua/windows/using-defender#1TC=windows-7 – Назва з екрану.

4.2. Огляд засобу BitLocker Drive Encryption  [Електронний ресурс]. – Режим доступу: URL http://windows.microsoft.com/uk-ua/windows-vista/bitlocker-drive-encryption-overview – Назва з екрану

4.3. Що таке файлова система із шифруванням (EFS)? [Електронний ресурс]. – Режим доступу: URL http://windows.microsoft.com /uk-ua/windows/what-is-encrypting-file-system#1TC=windows-7 – Назва з екрану.

4.4. Прозрачное шифрование: преимущества и недостатки  [Електронний ресурс]. – Режим доступу: URL http://habrahabr.ru/company/ cybersafe/blog/251041 – Назва з екрану

4.5. Russian Password Crackers: самые быстрые программы для взлома паролей EFS/NTFS [Електронний ресурс]. – Режим доступу: URL http://www.password-crackers.ru/category_147/ – Назва з екрану

4.6. Хогдал Дж. Анализ и діагностика компьютерных сетей./ Дж. Хогдал – К. : Компьютерная литература, 2010 – 120с.

4.7. Столлингс В. Основы защиты сетей. Приложения и стандарты/ Network Security Essentials. Applications and Standards. — М.: «Вильямс», 2002. — С. 432.

5 Вимоги до захисту інформації

У даному підрозділі потрібно представити усі ключові вимоги до системи захисту, які обґрунтовані в підпункті 1.2 ПЗ до КП.

5.1. Реалізацію вказаного функціонального профілю буде здійснювати застосована система захисту інформації, яка повинна реалізувати наступні основні функції:

– ідентифікацію та автентифікацію користувачів ПК під час запуску системи;

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

– гарантоване видалення конфіденційної інформації шляхом затирання змісту файлів при їх видаленні;

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

– контроль цілісності вибраних файлів;

– реєстрацію в спеціальних журнальних файлах таких подій, що мають відношення до безпеки, як:

– вхід в систему та вихід користувача;

– реєстрацію спроб несанкціонованих подій з інформацією з обмеженим доступом;

– доступ до інформації з обмеженим доступом;

– відновлення функціонування засобу захисту після збоїв;

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

5.2  Вимоги до модулю шифрування.

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

Підсистема шифрування повинна забезпечувати:

– шифрування та розшифрування змісту файлів;

– шифрування та розшифрування назви файлів та каталогів;

– автоматичну перевірку ключа на стійкість;

– виводити помилки, які можуть виникнути в процесі шифрування.

5.3  Вимоги до модулю контролю цілісності.

   Необхідно реалізувати модуль контролю цілісності за рахунок зберігання геш-значення файлів, обчисленого з використанням таких алгоритмів, як Keccak, SHA2, або власна функція, що дозволяє розпаралелення обчислень. Модуль має реалізовувати:

– контроль цілісності змісту файлів.

– складання списку файлів, цілісність яких була порушена;

– можливість відновлення попередньої версії файлу;

– виводити помилки, які можуть виникнути в процесі обчислень.

5.4  Вимоги до модулю автентифікації.

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

  Підсистема автентифікації повинна забезпечувати:

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

– виводити помилки, які можуть виникнути в процесі автентифікації користувача.

5.5 Операційна система користувачів – Windows 7;

6 Вимоги до документації

6.1 Програмна документація повинна бути оформлена згідно ГОСТ 19.105-78 «Общие требования к программным документам».

6.2 Документ «Текст програми» ГОСТ 19.401-78.

6.3 Документ «Керівництво користувача» згідно РД 50-34.698-90

6.4 Документ «Програма та методики випробувань» згідно ГОСТ 19.301-79  або РД 50-34.698

7 Стадії та етапи розробки

8 Порядок контролю та прийому

До приймання курсового проекту представляється :

– ПЗ до курсового проекту;

– робоча система для реалізації захисту;

– графічні матеріали.

Початок розробки:   08.09.2016.

Крайній термін виконання курсового проекту: 06.01.2017.

Розробив студент групи 1БС-16м  ____________  Іванов І.І.