Професія AppSec: чим займається фахівець і навіщо потрібен у часи війни

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Привіт! Я — Богдан Нікітченко, в минулому .NET developer, а вже близько року Application Security Engineer в IT-команді NIX.

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

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

Чому зростає значення Application Security

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

Яскравий приклад — історія одного з найбільших витоків даних XXI століття у другому за величиною в США банківському холдингу Capital One. У 2019 році один хакер зламав файрвол цього банку та вкрав із серверів AWS фінансові дані понад 100 млн користувачів. Причому компанія дізналася про це лише за кілька місяців. Скандал, що вибухнув через провал безпеки, призвів Capital One до величезних репутаційних втрат і $80 млн штрафу. Атака на сервери стала можливою через помилку в конфігурації файрвола та неправильну видачу привілеїв користувача. Через це зловмисник і отримав доступ до незашифрованих даних зі сховища.

Згідно з дослідженнями PurpleSec, 2020 року щодня відбувалося 30 тис кібератак. Під час пандемії COVID-19 їхня кількість зросла на 600%. Сучасний бізнес дедалі більше використовує у своїй діяльності програмне забезпечення. Саме воно є вразливим до хакерських нападів. ПЗ керує даними і приймає «розумні» рішення, тож користь бізнесу від нього очевидна. У цьому ж і кіберзлочинці вбачають користь. Тому захист даних — це мастхев для будь-якої сучасної компанії.

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

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

Які завдання вирішує AppSec

Що чекає бізнес від AppSec’а? Насамперед запобігання потенційним атакам. Фахівці в області AppSec сканують і тестують програми, шукають у них вразливості та підбирають різні способи, як запобігти цим «діркам» в безпеці чи викорінити їх. Для цього спеціалісти проводять статичні та динамічні тестування. Про них детальніше розповім далі. Також AppSec відповідають за збереження чутливої інформації. Таким чином користувачі не отримають дані, доступ до яких їм закритий.

До того ж наявність Application Security відділу в проєкті або продукті підвищує довіру клієнтів до бізнесу, показує серйозний підхід до розробки. Тож раджу слідувати фреймворку Secure Software Development Life Cycle — коли безпека від самого початку проєкту інтегрується в застосунок і підтримується ще до реалізації основного рішення.

Гарною аналогією інженера Application Security є співробітник відділу безпеки в аеропорту. Коли ви кудись збираєтесь полетіти, то проходите низку перевірок. Спочатку оглядають ваші документи, потім просять пройти через металошукач, після чого рентгеном просвічують багаж. А ще вас може обнюхати спеціальний собака та оглянути офіцер, що називається, вручну. Так і в розробці застосунку буде багато різних перевірок. Завдання AppSec — знати вразливі місця продукту, наголошувати на його захисті та створювати додаткові рівні безпеки, які допоможуть уникнути кібератак.

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

Робота AppSec-інженера складається з багатьох етапів. Один із найважливіших — тестування вихідного коду. Для цього існує кілька флоу. Наприклад, якщо команда Application Security від початку була у проєкті та стежила за безпекою розробки, то вся інфраструктура вже налаштована. Проте найчастіше AppSec команда з’являється на більш пізньому етапі розробки. Тоді таке тестування дає реально видимий результат. Хоча тут немає нічого надприродного — просто потрібно вбудувати перевірки у CI/CD проєктів і налаштувати автоматичні програми для тестів.

Найбільш вживані види тестування: статичне — із тестом коду за принципом «білої скриньки» та динамічне. Для статичного, наприклад, можна використовувати Snyk та Checkmarx, а для динамічного — SonarQube. У кожного з інструментів свої особливості.

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

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

А от прямий Code Review AppSec-спеціалістами проводиться рідко. Зазвичай під час перевірки певних компонентів, пов’язаних із критично важливими елементами. Це може бути, наприклад, флоу авторизації або шифрування даних. Переважно цей процес виконується, коли AppSec-команда приєднується до проєкту пізніше. В такому випадку можливі неточності, виявлені на тому етапі, коли за безпекою особливо й не стежили. Тому в Application Security команді важливо мати фахівців із девелоперським досвідом. Вони зможуть розібрати іноді досить заплутаний код та проаналізувати правильність реалізації критично важливих компонентів.

Моделювання загроз

Наступне важливе завдання Application Security інженера — Threat Modeling. Це процес виявлення найбільш небезпечних потенційних загроз для застосунку та їх точкового усунення. Для цього будуються спеціальні діаграми — Threat Model, приклад якої наведено на ілюстрації.

В основі лежить Data Flow Diagram. Ми розглядаємо як перетікають дані між компонентами продукту і що це за дані. Компоненти розташовуються в рамках меж довіри — Trust boundary. Це може бути локальна машина користувача, внутрішня мережа, хмарна структура, зовнішнє мережне підключення тощо. Інженер бачить, де знаходиться компонент, якими даними він оперує і які передає іншим компонентам. Після цього вказуються Sensitivity Data та виявляються можливі вектори атаки. На противагу їм визначаються способи, як контролювати проблему чи уникнути її. Далі проводиться перевірка чи всі компоненти захищені від вказаних вразливостей. У наведеному прикладі від загроз позбуваються шляхом використання TLS з’єднання між користувачем та веб-застосунком, а паролі хешуються.

Зазвичай діаграму Threat Modeling AppSec розробляє разом з архітектором проєкту. Вони можуть сісти і зробити все швидко, але це можливо лише для таких простих випадків, як наведено у прикладі. У великих проєктах для побудови діаграми можуть знадобитися кілька консультацій з архітекторами і розробниками. Адже на початку багато деталей можуть бути невідомими або не зовсім зрозумілими. Фахівець у галузі безпеки не є постійним розробником у продукті, тому не завжди може розібратися, як усе влаштовано насправді.

Що повинен знати та вміти AppSec

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

Зазвичай AppSec-команда в одному продукті поділяється на проєкти, і в кожному з них є один інженер. Він вивчає архітектуру і постійно має бути на зв’язку з розробниками. У межах «свого» проєкту він цілком автономний спеціаліст. Однак зі зростанням Application Security команди з’являється розподіл і за напрямками роботи. Хтось заглиблюється у питання криптографії, хтось зосереджується на авторизації. Одні налаштовують інструменти, які були інтегровані у продукт для тестування source-коду, інші — більше практикуються у Penetration Testing. Усі ці інженери повинні розуміти базу. З часом у команді хоча б одна людина починає копати окрему тему вглиб. Це і є особисто для кожного фахівця вектор його професійного росту.

Ще один масив знань, яким варто оволодіти — Penetration Testing. Адже неможливо щось захищати, якщо ти не знаєш, як мислить хакер, як працюють атаки в реальності, які інструменти можуть використовуватися для злому системи. PenTest зазвичай вивчається у межах спеціальних платформ, де ви в ролі хакерів шукаєте слабкі місця в спеціально піднятій та імітований під реальне життя системі. Знайшовши «дірки», намагаєтеся заекспойтити вразливість і знайти шлях підвищення до адмінських привілеїв на атакованій машині. Особисто для мене як для екс-розробника іноді важко працювати лише в теоретичній площині. А PenTest є чудовим способом застосувати знання на практиці.

З чого краще розпочати свій шлях AppSec-інженера? Найперше — вивчити основу криптографії та флоу авторизації та аутентифікації. Також необхідно мати непогану базу знань про мережі. Про ключові вразливості можна дізнатись зі списку OWASP TOP 10. Причому не просто прочитати, а, як-то кажуть, «помацати» руками ці вразливості. Взяти ті ж ін’єкції: розібратися, як вони створюються на практиці, які є слабкі місця та як можна захистити проєкт.

Чимало «наших» галузей чудово знають інші IT-фахівці. Та вони використовують ці знання у питаннях практичності рішення, зручності його реалізації, ефективності продукту тощо. У свою чергу AppSec спеціалісти дивляться на ті ж самі речі з боку підвищення безпеки продукту. Тому теорію вони одразу вивчають під певним кутом. Тільки так перехід у сферу Application Security дозволить вам стати справді висококласним інженером.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

На рахунок статичного та динамічного тестування коду. SonarQube дозволяє робити тільки статичний аналіз коду (SAST). З останніми апдейтами він все краще і краще знаходить потенційні вразливості в коді, якусь чутливу інформацию, але все ж SonarQube я розглядаю більше як Quality Gate(з можливістю додати security вразливості та хотспоти), чим інструмент який допоможе знайти вразливості в коді. Більш якісніше допоможе Coverity/Polaris, Snyk та Checkmarx. Якщо говоримо про динамічний аналіз(DAST), то динамічне тестування передбачає запуск коду. З рішень які можуть допомгти з тестування це Acunetix, Netsparker, Qualys, з опен сорсу є OWASP ZAP.

На рахунок навичок і можливості розібратися з вразливостями зі списку OWASP TOP 10 і не тільки рекомендую проходити безкоштовні лаби від Web Security Academy. Там ви не тільки отримаєте гарно структуровані теоретичні знання, а також зможете отримати досвід знаходження та базового експлотування на практиці. Лаби розгортаються в вашому браузері і дуже легко тренуватися. Ну і якщо ви плануєте будувати кар’юру в Application Security то знання клаудів будуть дуже суттєвою перевогаю та можливістю працювати з різного рода проектами.

Цікаво, як оцінюють продуктивність AppSec інженерів? У девелоперів кількість зроблених завдань, у тестувальників кількість написаних тестів чи знайдених дефектів. А що у вас?

Checkmarx потрібен для перевірки вихідного кода на наявність відомих вразливостей.

Яких, наприклад?
Як для мене, стаття була б цікавішою, якби ви навели приклади з вашої практики — як ви знайшли (або не знайшли) проблему з безпекою. І як ви її виправили.

Дякую за статтю. Але не зовсім зрозумів, чому вас із девелопменту перевели до Application Security? Це ж не як покарання?

Підписатись на коментарі