Можливо, сьогодні на думку спадає — чи можуть фахівці з кібербезпеки (cyber security) спокійно спати? — Насправді, це не завжди так. Однак завдяки підходу Shift Left Security можна допомогти фахівцям з кібербезпеки бути проактивними та систематичними, підтримуючи безпеку на всіх етапах життєвого циклу розробки, як додатків, так і інфраструктури.
Як це можливо? (це трохи нагадує термін, який використовують деякі інфлюенсери з Індонезії, хех 😁)
У середині 2010-х років виникло нове розуміння — тестування безпеки систем часто проводиться в кінці, що створює великі труднощі, оскільки це стикається з динамікою змін, і в результаті часто виникає ситуація, коли "замітають під килим" проблеми замість того, щоб виправити важливі питання, що потребують тривалого часу.
Наприклад, проведення VAPT (vulnerability assessment penetration testing) після того, як додаток вже go-live і став доступним публіці.
Зазвичай ці тести надходять з різних джерел, найкраще, коли це зумовлено awareness організації щодо безпеки, вимогами регуляторів (зазвичай для високорегульованих галузей, таких як банківський сектор) або lesson learned з інцидентів.
Я пам'ятаю, як кажуть — "Краще запобігти, ніж лікувати"
Shift Left Security став справжнім game-changer, оскільки він є антиподом до цього підходу — процес змушує відкотити деякі етапи, що дозволяє інтегрувати тестування безпеки в цикл розробки, починаючи з фази SIT до Production.
“No more silos between Software Engineers, Platform Engineers, and Cybersecurity Teams” Можливо, це висловлення найкраще відображає те, що ця синергія призведе до покращення якості систем, що розробляються.
“Як овочі без солі” — мабуть, це буде не так смачно, якщо не згадати про одну з революційних концепцій, а саме DevOps.
Тим часом, Shift Left є терміном, що описує поведінку концепції DevOps.
Швидкий розвиток технологій, більше чи менше, кожні 10 років призводить до появи нових технологій, які масово використовуються людьми (наприклад,
Соціальні медіа, послуги Cloud та інше — всі прагнуть стати найкращими, тому багато бізнесів зараз орієнтовані на цифрові технології, такі як бізнеси з цифровими гаманцями та онлайн-кредитами, конкуренція в яких стає все більш red ocean, а потім ще й пандемія COVID-19, через яку чимало компаній змушені були швидко переходити до цифровізації своїх продуктів і послуг. І, звісно, підтримка урядів, які виокремлюють це поняття через термін індустрія 4.0. — На мою думку, бізнес і tech завжди будуть намагатися перегоняти одне одного, удосконалюючи свої стратегії та створюючи магніт, щоб “їхні товари стали популярними, а їхні магазини ніколи не залишались без відвідувачів”.
Фахівці з tech, на мою думку, не можуть більше використовувати старі концепції або методології, що здаються "повільними", з недостатньою автоматизацією процесів. І є феномен силосів, коли розробка змушена "чекати" на platform & cyber security, і навпаки — бюрократичні й затягнуті процеси.
Концепція, запропонована Ларрі Смітом (1984) про System Development Life Cycle, стане філософією DevOps у майбутньому.
Однак, turning point стався в 2016 році, коли Gene Kim, Patrick Debois, John Willis та Jez Humble випустили книгу під назвою DevOps Handbook, ці чотири особи стали піонерами технологічної революції.
До того ж, ідея концепції DevSecOps також була висунута в цій книзі, хоча пізніше саме Snyk (компанія з кібербезпеки з логотипом собаки породи доберман) стала популяризатором цього терміну на ринку.
Сьогодні такі технологічні гіганти, як Google, Amazon, Netflix, вже впровадили концепцію DevOps у свої процеси розробки — Перевагами цього є ефективність та швидкість development, інтеграція між вимірами development та deployment в єдиному pipeline CI/CD, автоматизований процес, який збагачує дисципліну/процес SDLC (Software Development Life-Cycle) — Це означає, що концептуальна основа та робоча структура можуть йти в ногу з індустрією, орієнтованою на цифровізацію.
Однак, концепція, що фокусується на швидкості та інтеграції, також приносить з собою ризики для безпеки, які, якщо їх не вирішувати, можуть мати серйозні наслідки — Я не кажу, що це є антиподом, але DevSecOps (Jargon, Shift Left Security) забезпечує наявність завдання з безпеки, яке активно присутнє в середині циклу SDLC, що адаптує DevOps.
– Але фахівці з Cyber Security "обов'язково" повинні спочатку озброїти свій pipeline CI/CD.
Я підкреслюю, що є 5 критичних елементів системи додатка, які потрібно перевірити на відсутність вразливостей, а саме:
- Source Code
- Hardcoded Credential
- Library Dependency
- Binary
- Optional, Mobile
Ось “засоби” Cyber Security, які потрібно інтегрувати в workflow pipeline CI/CD:
- Static Application Security Testing (SAST) — це "зброя", яка дозволяє ідентифікувати вразливості, баги, hardcoded credential, а також здатна виявляти “плутанину” в коді та дублікати рядків, які можуть сповільнювати обробку і роботу додатка. Метод SAST передбачає скринінг A-Z для source code під час фази build, що представлена активністю Pull Request (PR) — ця фаза є частиною Continuous Integration, а метод тестування SAST має характеристику White-Box.
Ідеальна практика для тестування SAST проводиться в середовищі SIT. - Software Composition Analysis (SCA) — це друга "зброя", яка може виявляти вразливості в бібліотеках або сторонніх dependencies, що інтегруються в source code — SCA є частиною інструментів безпеки, пов'язаних з Cyber Supply Chain Risk — Неможливо заперечити, що використання сторонніх SDK/Library завжди є необхідним, навіть якщо ризики існують, такі як проникнення malicious code з боку третьої сторони і вразливості. Наприклад, Software Engineer із досвідом роботи з Java, яка є базою для open-source, здебільшого використовує SDK/Library з Maven dependency.
- Dynamic Application Security Testing (DAST) — це інструмент, який тестує на рівні deployment у вигляді програми, що виконується в server. Методологія базується на blackbox, що дозволяє додатку відчувати, ніби його неодноразово проходять через pentest.
Зосереджено на поведінці додатка, коли він вже взаємодіє з операційною системою, наприклад, коли він використовує network protocol, обробляє logic, обробляє request тощо. DAST гарантує, що в додатку (як frontend, так і backend) не буде вразливостей, таким чином, забезпечуючи відсутність вразливостей, які могли б залишитись непоміченими на фазі, коли додаток ще був у вигляді source code. — Best practice застосовується в середовищі UAT. - Mobile Application Security Testing (MAST),_ враховуючи поширення цифровізації та численні випуски версій mobile додатків багатьма компаніями, цей інструмент можна врахувати в pipeline CI/CD. Тестування зосереджено на перевірці дизайну архітектури та тестуванні POV user journey, щоб виявити логічні помилки, поведінку додатка, яка може призвести до вразливостей і так далі — Це важливо, оскільки mobile додатки складаються з кількох API, кожен з яких має свої функції та поведінку.
Крім того, MAST включає перевірку, чи може mobile додаток бути tempered/маніпульований, здійснено reverse engineer, перехоплено за допомогою MITM та інші потенційні загрози. На мою думку, це важливо впровадити, хоча Mobile відноситься до frontend, оскільки деякі фахівці з cyber security вважають, що захист frontend має бути effortless, а для мене це зовсім не так. Моя проста аналогія: mobile — це інтелектуальна власність компанії, схожа на дитинча черепахи, яке пірнає в океан, де загрози непередбачувані, і ніхто не знає, яка саме техніка та методи будуть використані.
So, Very Important thing-на, всі ці інструменти повинні мати quality gate з treshold допустимості, відповідно до industry best practice, регуляцій, success story або відповідно до appetite компанії (обережно з зоною комфорту 😁). Завдяки treshold quality gate, code, що має вразливості, буде відхилений в pipeline CI/CD, і не зможе перейти до наступного етапу, тому code має бути виправлений перш ніж продовжити.
Припустимо, що вразливості з ризиком “Low” все ще дозволяються для passing, але для Medium-to-High вони будуть reject.
Отже, якщо всі “алюцсиста” інструменти вже добре налаштовані та інтегровані в pipeline CI/CD, то все одно варто уникати зони комфорту — тому що насправді “найкращий дар” полягає в тому, що все працює автоматично, без необхідності “постійно” контролювати. Адже ці інструменти зменшать всі можливі ризики вразливостей.
Але, регулярний огляд все ж рекомендується для забезпечення актуальності конфігурацій.
Тепер питання, яка марка продукту є рекомендованою? Для мене, читачі повинні мати можливість порівнювати та досліджувати, однак, для мене, незалежно від технології, якщо вона добре підтримується, добре налаштована та добре задокументована, це і є той самий black belt! 😁
З моєї точки зору, поєднання Shift Left Security та DevOps є ефективним рецептом для подолання викликів цифровізації, яка, знову ж таки, вимагає від компаній вести боротьбу в стилі Blitzkrieg — Вразливості, що завдають збитків споживачам, матимуть непрямий негативний вплив на репутацію компанії, і, додатково, з розповсюдженням користувачів соціальних мереж по всьому світу, будь-який емоційний відгук може мати значення вже сьогодні.
Перекладено з: Shift Left Security, Proteksi Revolusioner Pada SDLC!