Безпека починаючи з ранніх етапів розробки: реалізація аналізу вихідного коду в циклі розробки IBM Rational Software Development Lifecycle

Важливість раннього тестування безпеки


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


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


Відповідно до останнього звіту Gartner:

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

Рішення від Ounce Labs “аналізує вихідний код додатка, забезпечуючи найбільш повний і точний аналіз вразливих місць докладання і їх відносних пріоритетів, надаючи розробникам рекомендації по виправленню і дозволяючи команді розробників ефективно уникати слабких місць у вихідному коді. Рішення Ounce 5 має сертифікат Ready for Rational і може інтегруватися з рішеннями з управління змінами IBM Rational ClearQuest і IBM Rational ClearCase, а також з рішенням IBM Rational Application Developer.


Ounce 5 і RUP


Рішення від Ounce Labs “аналізує вихідний код додатка, забезпечуючи найбільш повний і точний аналіз вразливих місць докладання і їх відносних пріоритетів, надаючи розробникам рекомендації по виправленню і дозволяючи команді розробників ефективно уникати слабких місць у вихідному коді. Рішення Ounce 5 має сертифікат Ready for Rational і може інтегруватися з рішеннями з управління змінами IBM Rational ClearQuest і IBM Rational ClearCase, а також з рішенням IBM Rational Application Developer.


Rational Software Development Lifecycle – це інфраструктура процесів і засобів автоматизації відповідно до методології RUP. RUP – це гнучка типова інфраструктура процесів, що включає чотири фази: розробка концепції (Inception), проектування (Elaboration), реалізація (Construction) і передача в експлуатацію (Transition). Рішення Ounce для аналізу вихідного коду головним чином застосовне на етапах кодування, збірки і передачі в експлуатацію. На рис. 1 показано місце, займане рішенням Ounce 5 в рамках методології RUP.


Shows Ounce code analysis is applied most heavily during Construction phase

Рис. 1: Рішення Ounce 5 в світлі методології RUP


Фаза прийняття основних рішень


У контексті забезпечення безпеки необхідно враховувати такі питання, як управління доступом і авторизація, належне обслуговування відповідальних даних, правильне використання даних і ресурсів зберігання, застосування шифрування. Деякі вимоги до безпеки не є функціональними вимогами, наприклад, тип застосовуваної системи шифрування. З іншого боку, багато вимог до безпеки в більшій мірою орієнтовані на конкретне застосування і вимагають визначення головного сценарію (наприклад, вхід користувача в систему шляхом введення імені і пароля), а також завдання альтернативних варіантів дії (Наприклад, авторизований користувач вводить невірний пароль) і дій у виняткових ситуаціях (наприклад, хакер намагається фальсифікувати процес входу в систему). Без визначення як функціональних, так і нефункціональних вимог і відповідного вбудовування їх в програмне забезпечення можуть виникати помилки програмування і конструктивні недоліки, що ставлять під загрозу важливу інформацію і операції. Вимоги до безпеки повинні враховуватися так само, як і будь-які інші вимоги, а раз так, то у них повинні бути пріоритети і сфери застосування, і ними слід управляти в загальному контексті моделей використання і функціональних вимог, застосовуючи для цього рішення IBM Rational RequisitePro ®


Рішення Ounce 5 автоматизує процеси тестування на безпеку і виявляє проблеми, пов’язані з недодержанням вимог безпеки, включаючи основні проблеми, порушення політик і конструктивні недоліки. Як показано на рис. 2, до основних проблем відносяться помилки реалізації, такі як переповнення буферу, ситуації конкуренції між ресурсами, перевірка вводу / виводу. До порушень політик і до конструктивних недоліків відносяться слабкості, пов’язані з криптографією, мережевими взаємодіями, контролем доступу, проникненням зловмисного коду, обробкою помилок, реєстрацією і т. д.


Chart showing terms grouped under basic findings and policy violations

Рис. 2: Основні проблеми, порушення політик, конструктивні недоліки


Отже, по завершенні етапу прийняття основних рішень повинні бути вирішені наступні питання, пов’язані з безпекою:



Етап детального опрацювання та вдосконалення


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


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


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


Ось декілька прикладів:



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



Етап побудови рішення


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


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


Нижче представлена ​​процедура щоденної збірки і показано, як Ounce 5 інтегрується з рішенням IBM Rational:



  1. Вихідний код сканується на регулярній основі (див. рис.3): Using IBM Rational Build Forge ®, дозволяє планувати і контролювати процеси складання. Build Forge дає можливість фахівцеві, відповідальному за випуск, визначати й автоматизувати конкретні процеси збірки рішення. Ounce 5 надає інтерфейс командного рядка, який дозволяє автоматично аналізувати вихідний код на безпеку в процесі складання системи. По завершенні аналізу результати стають доступними для фахівця з безпеки, який оцінює їх значимість.

Shows 4-step sequence from security scan back to development team

Рис. 3: Сканування вихідного коду як частина регулярного процесу складання.



  1. Спеціаліст з безпеки оцінює результати і дає вказівки по розробці (див. рис. 4): У великих організаціях фахівець з безпеки зазвичай зосереджений виключно на питаннях забезпечення безпеки при розробці ПЗ. У невеликих групах розробників учасники часто займаються декількома сферами діяльності, та функції фахівця з безпеки може брати на себе провідний розробник, глибоко розуміє проблеми безпеки. У будь-якому випадку фахівець з безпеки використовує продукт Ounce 5 Security Analyst для оцінки результатів аналізу. Ounce 5 надає базові можливості, що дозволяють оптимізувати процес оцінки. Наприклад, таблиця вразливих місць дозволяє швидко виявляти слабкості і негайно вживати відповідні дії. Спеціаліст з безпеки за допомогою засобів інтеграції Ounce 5 і ClearQuest доводить проблеми до розробників. З метою підвищення ефективності проблеми можуть бути згруповані в пакет і передані в ClearQuest всі разом. Окремі записи ClearQuest при цьому генеруються автоматично.

Screen from Ounce Security Analyst tool

Рис. 4: Надання результатів за допомогою Security Analyst



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

Shows integration of Ounce software and ClearQuest

Рис. 5: Інтеграція Ounce 5 і ClearQuest


Конкретний номер запису в ClearQuest також фіксується Ounce 5 Security Analyst. Після того, як ClearQuest вказав розробнику на проблему, вона вирішується в контексті всього проекту і враховується як показник при оцінці процесу розробки і загальної працездатності ПЗ.



  1. Розробник усуває проблеми з безпекою (див. рис. 6): При використанні середовища розробки (IDE) IBM Rational Application Developer в поєднанні з плагіном Ounce 5 Developer Plug-in розробнику не потрібно виходити з IDE для виконання дій по усуненню слабостей. Розробник має всю інформацію про пріоритет проблеми в списку, наданому ClearQuest. Вибравши проблему, яку слід усунути, розробник відкриває в Ounce 5 вікно, в якому виділена рядок коду, що є слабким місцем з точки зору безпеки. Крім того, він отримує вказівки по суті слабкості, а також рекомендації з оптимальної методики дій з прикладами “поганого” і “хорошого” коду. Усунувши проблему, розробник може виконати локальне сканування, щоб перевірити виправлену версію і з’ясувати, чи не виникло нових проблем. Коли розробник завершить процес виправлення, код перевіряється ClearCase і готується до тестової збірки, після чого цикл починається спочатку.

Shows how Ounce 5 addresses security issues

Рис. 6: Усунення проблем з безпекою за допомогою Ounce 5


Ми отримуємо подвійне перевагу від інтеграції засобів аналізу вихідного коду Ounce 5 в Rational Application Developer і регулярного виконання сканування. Насамперед, природно, знижується ризик появи проломів у системі безпеки. По-друге, що важливо на перспективу, ростуть навички розроблювачів, які з меншою ймовірністю будуть створювати уразливості в коді, оскільки їм відомі найкращі методики написання коду завдяки вказівкам, видаваним Ounce 5. Робочі групи неминуче будуть робити менше помилок при майбутніх розробках ПЗ. Щоб сприяти впровадженню більш безпечних методик програмування, в плагіні Ounce 5 Developer Plug-In передбачено безкоштовне і багаторазове використання рекомендацій щодо усунення слабкостей. Отже, після завершення етапу побудови повинні бути вирішені наступні завдання в області забезпечення безпеки:



Передача в експлуатацію


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


Ключовим моментом цього приемосдаточной тестування є, зрозуміло, тестування на безпеку. У цей момент має бути проведено тестування на подолання захисту (за допомогою, наприклад, IBM Watchfire ® AppScan) щоб виявити можливі слабкості в системі захисту при функціонуванні в робітничому середовищі. Аналізу вихідного коду за допомогою Ounce 5 є хорошим доповненням до тестування на подолання захисту, оскільки Ounce 5 здатний виявляти вразливі місця і вказувати на них у коді, тоді як тест на подолання захистів просто вказує слабкості, виявлені при виконанні атак. Ступінь суворості аудиту системи безпеки та приймально-здавальних випробувань, проведених для конкретного додатка, залежать від застосовних норм (наприклад, PCI) і стандартів. Ounce 5 надає звіти SmartAudit (див. рис. 7) для забезпечення дотримання нормативних вимог. Звіт SmartAudit надає “табель успішності” додатка і в повній мірі розкриває конструктивні недоліки і помилки програмування.


Screen shows security report

Рис. 7: Ounce 5 SmartAudit забезпечує дотримання нормативних вимог і стандартів.


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


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


Dashboard shows vulnerability for different applications

Рис. 8: Портфель засобів управління Ounce 5


Отже, на етапі передачі повинні бути вирішені наступні завдання:



Висновок


Підвищена увага до безпеки програмного забезпечення перед обличчям все більш масованих атак і необхідністю дотримання нормативних вимог накладає на групу розробників додаткові обов’язки по захисту ПЗ. Реалізація рішення аналізу вихідного коду Ounce 5 на платформі Rational Software Delivery Platform (відповідно до методології RUP) забезпечує як рамкову інфраструктуру процесів, так і засоби автоматизації, що спрощують роботу і проясняють роль кожного учасника команди в задачі забезпечення безпеки ПО. На всіх етапах, від прийняття основних рішень до передачі готового продукту в експлуатацію, є основні цілі, яких потрібно добиватися. Підсумковий результат двоякий – розроблене ПЗ відповідає стандартам безпеки, і одночасно скорочуються витрати на виправлення помилок, виявлених в ході експлуатації ПЗ.


Фази RUP, ключові цілі щодо забезпечення безпеки ПО і основні інструменти, необхідні для автоматизації на кожному з етапів, представлені в табл. 1.


ТАБЛИЦЯ 1: Етапи RUP, ключові цілі та інструменти автоматизації






















Фаза RUP Цілі, які потрібно досягти після закінчення етапу Інструмент автоматизації
Етап розробки концепції

  • Чітке розуміння стандартів і норм, що впливають на розробку ПЗ
  • Загальні вимоги безпеки усвідомлені, зафіксовані і мають пріоритети відповідно до завдань бізнесу
  • Якщо це вже відомо на даному етапі, мають бути виявлені (з присвоєнням пріоритетів) важливі архітектурні вимоги до безпеки, недотримання яких загрожує графіком виконання проекту
IBM Rational RequisitePro
Етап проектування

  • Завершити розробку варіантів використання засобів забезпечення безпеки та вимог
  • Визначити план проекту та ітерації для етапу побудови рішення, забезпечити перевірку вимог до безпеки при виконанні ітерацій
  • Включити плани тестування на безпеку Ounce 5 в загальну стратегію тестування, як в якості майбутніх цільових завдань ітерацій, так і у вигляді поточних цілей.
  • Якщо потрібно, налаштувати Ounce 5 під конкретні політики
IBM Rational RequisitePro
IBM Rational ClearQuest TestManager
Ounce Security Analyst
Етап реалізації

  • Повністю реалізована безпечна архітектура
  • Всі вимоги до безпеки перевірені в процесі ітераційного побудови рішення
  • Автоматизовані перевірки вихідного коду забезпечують відсутність слабкостей, зумовлених застосуванням “поганих” методик програмування
  • Розробники повинні бути краще інформовані про методики безпечного написання коду
IBM Rational ClearQuest
IBM Rational Application Developer
Ounce Security Analyst
Ounce Developer Plug-In
Етап передачі в експлуатацію

  • Повне проведення приймально-здавальних випробувань перед розгортанням
  • Підготовка до безперервним удосконаленням і організація супроводу
  • Управління ризиками для програми в контексті всього портфеля розгорнутих додатків
IBM Rational ClearQuest
Ounce Security Analyst
Ounce Portfolio Manager

Примітки


1 B. Boehm and V. Basili, “Software Defect Reduction Top 10 List.” IEEE Computer, January 2001.


2 “Implement Source Code Security Scanning Tools to Improve Application Security,” Amrit Williams, Gartner, April 4, 2006.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*