Безпека застосунків завжди була пріоритетним питанням у розробці, а нині тим паче. Кількість кібератак зросла чи не найбільше за останні роки. Тож спеціалісти у сфері Application Security затребувані у багатьох проєктах.
Чим же займаються AppSec-інженери та як опанувати цю професію? Розповім із власного досвіду.
Дещо про роботу AppSec-інженерів
Ці інженери відповідають за безпеку програмного забезпечення на всіх рівнях. Зазвичай AppSec-фахівці мають досвід розробки, тому розуміють процеси побудови ПЗ. Знання про те, що і як працює зсередини, а відповідно як це може зламати хакер, допомагають інженеру створити краще захищений софт.
В ІТ вирізняють Red Team і Blue Team. Перші фахівці шукають вразливості системи та її організації. Це етичні хакери, penetration-тестувальники, соціальні інженери.
Blue Team безпосередньо працює над захистом: створює firewall'и, полісі, стандарти. Фактично це Social Operation Center, який для запобігання атак моніторить системи, організацію та мережі, а під час атаки використовують інцидент-плани. Наприклад, відключають користувача, якщо проникнення відбувається через його акаунт.
Application Security можна віднести до Purple Team («пурпурної команди»), що стоїть між двома попередніми. В AppSec-інженерів є вміння і знання з обох напрямів.
У більшості проєктів Application Security-команда невелика, тому часто просто ні в кого навчатися азів професії. Для старту важливо базово знатися на процесах та ролях в ІТ-команді. Вам доведеться взаємодіяти з розробниками, архітекторами, продуктовими аналітиками, тестувальниками та багатьма іншими спеціалістами. Навички написання, читання та рев’ю коду теж будуть плюсом.
З чого складається робота в Application Security
1. Моделювання загроз та рев’ю дизайну/архітектури
Інколи можна почути думку, що ця робота починається ще з вимог, щоб зрозуміти порушення комплаєнсів. Але недоцільно долучати AppSec-ів уже на цій стадії проєкту. Фахівець має зрозуміти, як буде побудована система та які в ній потенційно вразливі місця.
Наприклад, у продукті використовуються не ті протоколи взаємодії чи неправильно організовано збереження даних про кредитні картки. Вимоги прописані недостатньо чітко, тому й реалізувати все можна по-різному. Тож лише після створення архітектури та плану розробки вдасться проаналізувати можливі загрози й «підсвітити» девелоперам порушення безпеки.
2. Створення безпечного коду
Включає в себе комплексне рев’ю коду на всіх етапах. Йдеться не стільки про перевірку як таку (хоча і вона потрібна), скільки про запровадження best practices та автоматизацію процесів розробників.
AppSec-інженери прописують полісі та гайди безпечного кодстайлу та допомагають налаштувати різноманітні інструменти автоматизації: від плагінів для IDE на машинах девелоперів до сканерів, які інтегровані в CI-процес.
3. Навчання команди практикам захисту софту
Передбачає тренінги для різних фахівців на проєкті. Програми таких зустрічей можуть бути загальними, з описом базових правил на кшталт «Не використовуйте флешки на комп’ютері» або «Не відкривайте емейли від незнайомих людей». А можуть бути й спеціалізованими: для розробників, QA, бізнес-аналітиків.
Застосовуючи шифрування даних, потрібно використовувати ті чи інші алгоритми. Багато чого залежить і від бізнес-домену. Наприклад, в американській Healthcare-індустрії важливі HIPAA-комплаєнси. AppSec має нагадати колегам: обов’язково перевірте, чи надійно захищені дані пацієнтів саме за цими державними стандартами.
4. Автентифікація, авторизація та контроль доступу
Це один із найважливіших етапів Application Security. Його важко стандартизувати, бо чи не на кожному проєкті автентифікація й авторизація реалізуються по-своєму. Ніколи не будуються стандартні моделі забезпечення рівня доступу до даних – завжди комбіновані.
Зазвичай це не є цілком вдалим рішенням, адже можуть з’явитися проблеми з перфомансом чи невідповідність бізнес-вимогам. У гіршому ж – команда знехтує безпекою. Тому AppSec-інженери мають наголошувати на ціні помилок усім стейкхолдерам: як своїм колегам, так і технічним фахівцям на боці замовника і самому клієнту.
5. Тестування безпеки
У проєктах, де немає можливості залучити тестувальників із Red Team, AppSec-фахівці проводять перевірки безпеки. Якщо ж на проєкті є пенештрейшен-тестувальники, спеціалісти з Application Security співпрацюють із ними.
Тести на проникнення здебільшого виглядають як робота з чорною/сірою скринькою. QA достеменно не знають, де виникла проблема. AppSec-інженер, розуміючи побудову системи, зможе відшукати ці вразливі місця. Тож тестувальники витратять менше часу на пошуки й відразу візьмуться за свою справу.
AppSec-інженери бачать цілісну картину проєкту і можуть допомогти розшифрувати знайдені тестувальниками помилки та навіть запропонувати рішення. Особисто для мене, наприклад, це і є найцікавішим у всій роботі AppSec: знайти прогалину в безпеці та придумати, як її «закрити».
6. Захист даних
Насамперед це методи шифрування і хешування інформації, налаштування системи зберігання ключів шифрування, способи їх передачі тощо.
AppSec-інженери мають переконатися, що всі дані, які передаються публічними каналами, надійно захищені. Вся інформація має лишатися цілісною, її ніхто не повинен перехопити, побачити й тим паче зламати або вкрасти. Для цього, зокрема, перевіряються алгоритми шифрування і протоколи передачі даних.
7. Відповідність та керування
Окреме завдання – це збереження даних. Тут важливо проаналізувати відповідність тим чи іншим стандартам. Наприклад, PCI DSS вимагає, щоб дані про банківські картки користувачів зберігалися в базі даних у зашифрованому вигляді. Це один із ключових критеріїв виконання комплаєнсу. AppSec перевіряє, що використані на проєкті підходи відповідають цим вимогам.
8. Інтеграція DevSecOps
Вразливі місця можуть бути не лише у проєкті, але й у конфігурації інфраструктури. Зазвичай це зона відповідальності DevOps-фахівців. Проте вони часто не мають вузької спеціалізації та знають лише базові аспекти безпеки. Тоді AppSec дивиться, як усе налаштовано з позиції DevSecOps. Подекуди переймає деякі задачі девопсів.
Наприклад, в одному з моїх проєктів AppSec-інженери тісно взаємодіяли з DevOps-ами. Розбиралися в наявних пайплайнах та інтегрували в CI-процес кастомний сканер. Обом командам допоміг попередній досвід розробки, і вони досить легко знайшли спільну мову.
9. Моніторинг та реагування на інциденти
За відстеження атак та реагування на них відповідає Social Operation Center. AppSec-інженери визначають кроки: як має реагувати команда, організація і продукт, коли щось трапилось. Усе прописують у стандартах полісі та інцидент-планах для різних варіантів атак.
Наприклад, юзер завжди логінився з Австрії, але раптово зайшов у систему з Австралії. Це вибивається зі звичного сценарію, тому потрібен план дій. Система за схемою мультифакторної авторизації зв’язується із користувачем за допомогою іншого каналу комунікації та перепитує: а це точно ти? Якщо відповіді немає чи вона негативна, запит автоматично блокується.
Саме тому норми Application Security слід впроваджувати від початку розробки. Реалізація такого інцидент-плану потребує заздалегідь передбачити технічну можливість блокування юзера.
Ми не можемо закрити очі на жоден із цих пунктів чи приділити їм замало уваги. Але будемо чесні: ресурсів завжди не вистачає, тому доводиться йти на компроміси. І це треба обговорювати з клієнтом.
Часто команди не встигають перевірити певний функціонал. Тут є сенс переглянути бізнес-стратегію та змінити фічу чи взагалі відмовитися від неї на певний час.
А ще, наприклад, сьогодні чимало продуктів будують навколо ШІ, який може робити в системі будь-що. Але це порушує базові стандарти Application Security. Зловмисники намагатимуться зламати такого «юзера» задля супердоступу. Тож слід переконати клієнта, що ризики від впровадження фічі перевищують профіт.
Краще йти на компроміс не в безпеці, а в можливостях. Якщо ж клієнт все одно залишає без уваги згадані небезпечні місця у застосунку, то варто винести їх у пріоритет для наступного релізу.
Що допомагає у виконанні завдань
Арсенал інструментів, методологій, фреймворків доволі широкий, та передусім варто...
Орієнтуватися на галузеві та державні стандарти
Наприклад, є визнані фреймворки американського інституту NIST та міжнародні стандарти ISO, яким повинні відповідати організація та ПЗ (наприклад, ISO 27001 чи ISO 15408). Ці документи описують, яким має бути безпечний IT-продукт.
Фахівці вивчають подібну документацію та порівнюють із тим, що бачать на проєкті. У разі розбіжностей слід звернути увагу на невідповідність стандартам, яка може завадити продукту пройти подальшу сертифікацію.
Працювати зі сканерами – статичного аналізу коду, аналізу залежностей, динамічного аналізу (коли є готовий продукт у вигляді API)
Ці інструменти імітують різні типи атак і дозволяють шукати вразливості, чим AppSec займається регулярно. Адже проєкт не стоїть на місці, фічі постійно змінюються чи додаються.
Application Security не обмежується налаштуванням і запуском інструментів. Робота з тим же статичним аналізатором коду нескладна, але для AppSec недостатньо запустити інструмент і витягнути звіт. Варто досліджувати особливості продукту, щоб прогнозувати можливі атаки в тих чи інших місцях.
Часто розробники використовують характерні системи найменування змінних, на які сканер реагує як на вразливість.
Припустимо, в назві змінної є слово password, але це не пароль. У такому випадку інженер оцінює проблему та позначає її як false positive – хибну тривогу. Сканери показують все, що здається неправильним, і видають багато нерелевантної інформації.
Опрацьовувати алерти можуть і розробники, але краще довірити це AppSec-ам. Вони відфільтрують вразливості, а девелопери зосередяться на своїх завданнях.
Як впроваджувати Application Security на проєкті
Існує кілька моделей роботи Application Security. На вибір впливають особливості проєкту. Наприклад, створення SOC-команди виправдано лише в масштабних проєктах. А для роботи з продуктами у хмарі навіть AppSec-команда часто не потрібна. Адже 99,9% комплаєнсів та перволів налаштовує хмарний провайдер. Тому побудувати все зможуть і девопси, а з боку AppSec потрібна буде лише перевірка їхньої роботи.
Зазвичай AppSec-спеціалістів можуть залучати у проєкти під такі завдання:
- Аудит – коли інженер аналізує системи та організації та надає звіт, чи все відповідає нормам безпеки. Зауважу, що жоден продукт не може та не має відповідати абсолютно всім нормативам. Їх безліч, а тому під час аудиту варто орієнтуватися на бізнес-домен та особливості конкретного проєкту.
- Консалтинг – коли разово чи на постійній основі спеціаліст допомагає командам, де немає ролі AppSec. Консультації можуть стосуватися й окремих напрямів роботи. Наприклад, потрібно налаштувати шифрування даних. Розробники не впевнені, що використовують оптимальні алгоритми. Тоді AppSec оцінює, як побудовано механізм шифрування, і за необхідності радить щось виправити.
- Інтеграція в SDLC – коли Application Security включається у життєвий цикл розробки. Особисто для мене це найцікавіше і водночас найскладніше завдання. Особливо важко це зробити, якщо проєкт вже «біжить».
Наприклад, неможливо швидко замінити небезпечний канал комунікацій. Складно модифікувати і процеси. Тести на проникнення часто проводять безпосередньо перед релізом, і завжди щось знаходять. Задля усунення вразливостей реліз відкладається. Завдання AppSec-інженера – порекомендувати команді змістити тестування на більш ранню стадію за принципом Shift Left. Через додаткові перевірки CI-процес затягується, що сповільнює темп розробки. Тому краще інтегрувати у проєкт Application Security якомога раніше. Це збереже і час, і кошти.
Як AppSec-фахівцеві організувати свою роботу
План роботи зазвичай такий:
- Комплексний аналіз. Ця оцінка допоможе розставити пріоритети у знайдених проблемах і створити екшен-план. Неможливо охопити все й одразу. Визначте критичні недоліки. Наприклад, у Healthcare інколи використовують публічні ендпойнти, де можна отримати дані про пацієнта, просто передавши ID. Ця проблема вимагає негайного вирішення. Бувають проблеми, що витікають із самих процесів. Тоді спершу фіксимо процесуальні недоліки.
- Виправлення проблем. Може стосуватися як старих частин проєкту, так і нових фіч. Виправлення можуть відбуватися паралельно за обома цими напрямами. Зазвичай вказані задачі виконуються в shadow-режимі. Тобто команда розробки в принципі не знає, що робить AppSec. Тим часом фахівець аналізує код і систему, готує звіти та передає їх техлідам, а надалі перевіряє реалізацію.
- Постійна інтеграція AppSec. Коли нагальних проблем немає, беремось інтегрувати процеси безпеки. Це варто робити на всіх етапах життєвого циклу ПЗ. План інтеграції може бути суворим або більш гнучким, коли спирається не стільки на виправлення помилок, скільки на покращення безпеки. Жодна система не може бути на 100% захищеною. Завжди є шляхи подальших покращень.
Кар’єрний розвиток AppSec-інженера
Професія AppSec передбачає виконання різних завдань різної складності, а отже й варіантів розвитку у цій сфері безліч. Можна рухатись у бік Blue Team чи Red Team.
Якщо ви вмієте проводити тести на проникнення і хочете зосередитись на цьому – ось вам ще один шлях. Можна фокусуватися на окремій технології. Наприклад, на роботі з хмарними платформами або на системах на базі штучного інтелекту.
Йдеться не про зміну професії, а про відкриття для себе нової спеціалізації. В Application Security ви зможете працювати з документацією, із кодом, з DevOps-підходами.
Для початку варто базово знатися на цьому. А далі – збагачувати практичний досвід і може навіть подумати про сертифікацію за окремим напрямом. Це дасть вам змогу як Application Security інженеру вийти на новий професійний рівень.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.
