Контроль вразливостей в програмних додатках

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

чи Можна контролювати наявність дефектів у програмному коді?
Сьогодні все ПО, яке експлуатується в російських компаніях, можна умовно розділити на категорії:
  • Самостійна розробка ПЗ, що розробляється або силами своєї ІТ-команди, або стороннім розробником за виданим замовником технічного завдання.
  • Стандартне ПЗ, розроблене російським виробником, можливо, налаштоване і адаптоване під бізнес.
  • ПЗ, розроблене невеликим іноземним виробником.
  • ПЗ, розроблене світовим IT-гігантом і поставляється у вигляді набору готових модулів.
Дефекти в програмному забезпеченні, яке розробляється самостійно, рекомендується зменшувати і контролювати за допомогою впровадження практики розробки надійного (Security Development Lifecycle, SDL), розробленої компанією Microsoft. Однією з необхідних умов її застосування є наявність інструментальних засобів аналізу коду в циклі розробки. Так, на етапі розробки програмісти повинні використовувати інструментальне засіб статичного аналізу коду, що дозволяє виявляти уразливості безпосередньо під час написання коду. На етапі тестування, крім проведення регресійного тестування та тестування випадкових даних, рекомендується використовувати інструментальні засоби динамічного аналізу коду, що дозволяють перевіряти програмний продукт з допомогою тестів на проникнення.

На сьогоднішній день на ринку представлено кілька інструментальних систем аналізу коду, як статичного (з вихідного коду методом «білого ящика»), так і динамічного (без вихідного коду методом «чорного ящика»). Крім цього, провідні інструментальні системи аналізу коду від таких виробників, як HP і IBM, пропонують комбінований статичний і динамічний аналіз, який дозволяє відображати результати динамічного аналізу на вихідний код. Можна сказати, що в даний час найбільш ефективним інструментальним засобом аналізу коду, яке пропонує статичний, динамічний, а також гібридний аналіз у поєднанні зі зручним інтерфейсом і гарною бібліотекою правил пошуку вразливостей, є інструментальне засіб HP Fortify.

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

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

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

  • розробка рекомендацій щодо усунення виявлених вразливостей;

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

Автор статті: Катерина Трошина

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.