Захист від закладок при розробці програм

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

• використання сучасних технологій програмування;

• наявність автоматизованої системи розробки;

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

• представлення готових програм на мовах високого рівня;

• наявність трансляторів для виявлення закладок.

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

Такий поділ підвищує надійність програмування, так як доступ до внутрішніх даних можливий тільки за допомогою процедур, перерахованих в модулі опису. Це дозволяє визначати більшу частину помилок в обробці абстрактного типу даних на етапі компіляції, а не на етапі виконання. Аналіз програмних засобів на наявність> закладок полегшується, так як допустимі дії з абстракт-; ними даними задаються в модулі опису, а не в тілі процедур. Одним з центральних понять ООП є поняття «клас». За допомогою цього поняття здійснюється зв'язування певного типу даних з набором процедур і функцій, які можуть маніпулювати з цим типом даних. Перевага ООП полягає також у наданні можливості модифікації функціонування, додавання нових властивостей або знищення непотрібних елементів, не змінюючи того, що вже написано і налагоджено. Користувачеві досить визначити об'єкти, що належать вже створеним класам і посилати їм повідомлення. При цьому контроль безпеки програмного продукту зводиться до аналізу модулів опису класів. Якщо клас з бібліотеки класів не задовольняє розробника, то він може створити клас, похідний від базового, зробити в ньому необхідні зміни і працювати з об'єктами отриманого похідного класу. Якщо дані і методи базового класу не повинні бути доступні в похідних класах, то їх слід описати як внутрішні. Концепція ООП змушує розробників програмних продуктів ретельно продумувати структуру даних класу і набір методів (процедур), які необхідні для обробки цих даних. Отримувані програми є безліч легко читаються, самодокументіруемих модулів описів класів і безліч модулів реалізації тел методів. Таке уявлення програм спрощує їх семантичний аналіз і контроль на наявність в них закладок.

Автоматизована система розробки програмних засобів. Автоматизована система створюється на базі локальної обчислювальної мережі (ЛОМ). До складу ЛВС входять робочі станції програмістів і сервер адміністратора [19]. Програмісти мають повний доступ тільки до інформації своєї ЕОМ і доступ до ЕОМ інших програмістів в режимі читання. З робочого місця адміністратора можливий доступ в режимі читання до будь-який ЕОМ розробників. База даних алгоритмів розроблюваного програмного засобу перебуває на "сервері адміністратора і включає в себе архів затверджених організацією-розробником і контролюючою організацією алгоритмів програмного засобу у вигляді блок-схем, описи на псевдокоді для їх контролю адміністратором. На сервері адміністратора розташовується база даних лістингів програм розробляється програмного засобу, включає в себе архів затверджених організацією розробником і контролюючою організацією програм для їх контролю адміністратором з застосуванням програм порівняння лістингів та пошуку змінених і доданих ділянок програм. Програми контролю версій лістингів програм і порівняння виконуваних модулів повинні бути розроблені організацією, не пов'язаною ні з організацією-розробником, ні з контролюючою організацією і повинні контролювати програми будь-якого призначення. Контроль за безпекою розробки може здійснюватися таким чином. Адміністратор відповідно до свого графіка без повідомлення розробників зчитує в бази даних листинги програм і виконувані модулі. За допомогою програм порівняння адміністратор виявляє й аналізує зміни, які внесені розробником, порівняно з останнім контролем. У міру розробки виконуваних модулів у базі адміністратора накопичуються готові до здачі замовнику еталонні зразки виконуваних модулів, збереження яких контролюється адміністратором. Застосування такої організації робіт дозволяє адміністратору виявляти закладки та ненавмисні помилки на всіх стадіях розробки програмного засобу. Адміністратор не може сам впровадити закладку, так як у нього немає права на модифікацію програм, що розробляються програмістами.

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

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

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

3. Необхідно підтримувати взаємозамінність програмних модулів моделі і реальної системи.

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

Контрольно-випробувальний стенд може містити такі модулі (рис. 9): • модель системи, яка складається з моделей програмних модулів і програмних модулів реальної системи;

• модуль конфігурації моделі системи,

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

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

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

ММ -модель програмного модуля; МС - програмний модуль реальної системи

Рис.9. Структурна схема контрольно-випробувального стенду

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

• модуль аналізу результатів тестування.

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

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