5. Класифікація криптоалгоритмів.

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

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

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

Основною схемою класифікації всіх криптоалгоритмів є наступна:

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

Симетричні криптоалгоритми.

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

Асиметричні криптоалгоритми.

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

6. Основні положення по розробці программного забезпечення.

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

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

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

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