Впроваджуємо DevSecOps-підходи. Як бути «незламним» під час хакерських атак

Вітаю! Мене звати Андрій, я — DevOps Chapter Lead у компанії Newfire Global Partners. Працюю в IT вже понад 10 років, починав я свою кар’єру в IT як Developer і через деякий час перейшов у напрямок DevOps.

Чи можете ви згадати випадок, коли ламали вашу пошту, Фейсбук, OLX, Біткоїн-гаманець або інший особистий акаунт? Насправді, злам може статися з кожним із нас.

Мій обліковий запис на OLX зламали десь два роки тому, і помітив я це, тільки коли від мого імені були опубліковані фейкові оголошення.

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

  1. Сфера охорони здоров’я.
  2. Енергетика.
  3. Фінансовий сектор.

В цій статті ми з вами подивимось, з чого складається DevSecOps, зробимо огляд DevSecOps-інструментів у Azure, дізнаємось, що таке Shift-left стратегія, та як вона може зберегти час при розробці програмного забезпечення.

Також розберемо підходи з впровадження вищезгаданих інструментів та практики без спротиву з боку команди.

Отже чим DevSecOps може допомогти, коли мова йде про комп’ютерну безпеку?

DevSecOps — це вже тренд, який за останні роки тільки наростає, але якщо подивитись глибше, то DevSecOps можна назвати філософією інтеграції інструментів, практик та культури (без неї ніяк) безпеки в процес DevOps. Тобто передумовою впровадження DevSecOps є саме DevOps.

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

Починати впровадження DevSecOps-культури потрібно з навчання команди, перш ніж імплементувати інструменти безпеки у SDLC. І найкраще про це розповідає наступна історія.

Історія трапилась декілька років тому в одній із попередніх компаній, де я працював у той час. Одного ранку фінансовий директор, яку звали Кейт, отримала листа від CEO компанії, якого звали Джон, з проханням надіслати $50 000 на рахунок клієнта. Це було схоже на звичайне прохання СЕО. Добре, що Джон сидів поряд, і Кейт вирішила запитати його, наскільки терміново потрібно надіслати цю суму.

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

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

У вас, можливо, виникло запитання, а як же хакери проникли у систему компанії та відправили лист від імені CEO компанії? Все дуже просто! Кількома тижнями раніше офіс-менеджеру компанії Мішель прийшов фішинговий лист нібито від «СЕО» з проханням залогінитись через посилання в корпоративну пошту і відправити звіт.

Після цього хакери отримали доступ до корпоративної пошти офіс-менеджера, змогли створити фейковий обліковий запис CEO, з якого і відправили лист з проханням надіслати $50 000 на рахунок клієнта.

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

Хоча надалі атаки і траплялись, але зламів системи більше не відбувалось.

Перш за все DevSecOps-культура має з’явитися в кожному з нас, і лише після цього можемо думати про DevSecOps-інструменти.

Так поступово ми почнемо знайомство із DevSecOps-інструментами. Їх можна умовно поділити на чотири категорії:

  1. Інструменти, що використовуються під час дизайну системи та на локальній машині.
  2. Інструменти, які інтегруються в процес Сontinuous Integration (CI).
  3. Інструменти, які інтегруються в процес Continuous Delivery (СD).
  4. Інструменти, які застосовуються у Production.

Всі DevSecOps-інструменти, які зображені на малюнку, є дуже важливими, але в цій статті ми зупинимось більш детально тільки на деяких з них.

Перед тим, як почнемо розглядати DevSecOps-інструменти, розберемо, що ж таке shift-left стратегія. Цей термін виник ще на початку 2000-х, і належить до практики розробки програмного забезпечення, в якій команди зосереджуються на якості і фокусуються на запобіганні проблем замість їх виявлення.

До останніх років тестування безпеки проводилося в кінці циклу розробки після тестування програми. На цьому етапі спеціалісти з IT-безпеки виконують різні типи аналізу та тестування безпеки, такі, як статичний аналіз і динамічний аналіз.

На сьогодні концепція тестування безпеки програмного забезпечення змінилась і shift-left стратегія наклалась на DevSecOps, тепер нам необхідно перевіряти наш код, інфраструктуру та архітектуру на вразливості вже на ранніх етапах розробки програмного забезпечення.

Перейдімо тепер до DevSecOps-інструментів.

Категорія Design/Development

Microsoft Threat Modeling Tool — важливий елемент shift-left стратегії. Він допомагає перевіряти релізи, рішення, а також рівень безпеки під час кожного етапу розробки програмного забезпечення. Раніше цей інструмент використовували лише під час тестування, а тепер ще й під час дизайну архітектури програмного забезпечення.

Перед тим, як розгортати інфраструктуру та програмний продукт в Azure, необхідно намалювати свою архітектуру в Microsoft Threat Modeling Tool і змоделювати потенційні загрози. Дуже важливо знати наперед, які вразливості і загрози існують, та як їх нейтралізувати у Azure-сервісах.

Категорія Сontinuous Integration (CI)

Перший інструмент з категорії CI, який використовується для статичного аналізу коду, це SonarQube. SonarQube вимірює якість програмного коду згідно з сімома показниками якості програмного забезпечення, які розробники називають Seven Axes of Quality:

  1. Потенційні помилки.
  2. Стиль програмування.
  3. Тести.
  4. Повторення ділянок коду.
  5. Коментарі.
  6. Архітектура та проєктування.
  7. Складність.

Під час впровадження цього інструменту особливу увагу потрібно звернути на налаштування правил аналізу, щоб уникнути так званих false-positive результатів статичного аналізу. Наприклад: з дефолтними налаштуваннями SonarQube буде сигналізувати про помилку, якщо в коді є змінна з назвою password. Якщо таких false-positive результатів статичного аналізу буде багато, то з часом на SonarQube просто не будуть звертати увагу.

Другий інструмент, який використовується для пошуку вразливостей у залежних пакетах, це GitHub dependency graph. GitHub dependency graph — простий, безкоштовний і дуже корисний інструмент, що допомагає виявити уразливості у сторонніх open-source пакетах, які використовуються у вашій програмі. За замовчуванням, GitHub dependency graph не активний, але ви його можете увімкнути у налаштуваннях репозиторію. Зручно, що він сам створює Pull Requests у вашому репозиторії, якщо знаходить уразливості у сторонніх open-source, які ви використовуєте, і вам потрібно лише натиснути кнопку «Merge pull request».

Третій інструмент — Trivy — це простий та функціональний сканер вразливостей докер-контейнерів. Він допомагає виявляти вразливість пакетів операційної системи (Alpine, RHEL, CentOS, Ubuntu та інших), а також залежності пакетів (npm, yarn та інших). Працює так само з Infrastructure as Code (IaC) файлами Terraform. Trivy дуже легко може бути інтегрований в будь-який інструмент Сontinuous Integration.

Категорія Continuous Delivery (CD)

Під час цього етапу важливо звернути увагу на Azure-інфрактрустуру. В цьому нам допоможуть Tfsec та Azure Policy Compliance. Tfsec — поширений інструмент для перевірки Terraform-коду, для виявлення потенційних проблем безпеки. Запобігає зберіганню паролів, токенів та інших конфіденційних даних у системі контролю версій (GitHub, GitLab та інших).

Azure Policy Compliance — корисний інструмент, який допомагає дотримуватись організаційних стандартів шляхом налаштування політик для Azure Subscription. Наприклад, можна дозволити Azure сервісам працювати тільки по HTTPS, заборонити створення Azure-ресурсів, які не планується використовуватися, заборонити змінювати налаштування Azure-ресурсів та багато іншого.

Категорія Production

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

OWASP також дозволяє автоматизувати процес тестування вразливостей за допомогою інструменту OWASP Zed Attack Proxy, що вміє симулювати найбільш поширені атаки на сервіси і допомагає виявити найнебезпечніші типи загроз з можливістю надсилання звіту.

Також цей інструмент легко інтегрується в процес Continuous Delivery, наприклад, коли сервіс вже задеплоєний в Staging/UAT середовище і потрібно провести ключові тести на вразливості. Всі OWASP-інструменти є безкоштовними й допомагають спільноті розробників з усього світу попередити інциденти та вразливості.

Отже, ми розібрали DevSecOps інструменти, які інтегруються у SDLC-процес і допомагають підвищити загальну ІТ-безпеку. Але які ще інструменти Azure можуть допомогти в підтримці рівня безпеки на проєкті?

Якщо вам необхідно просканувати поточний стан проєкту без зайвих витрат часу, ви можете це зробити у Azure Security Center.

Azure Security Center показує основні наявні загрози, які можуть нести загрозу для програмного забезпечення в налаштуваннях Azure-ресурсів, та пропонує зміни з детальним описом про саму вразливість та кроки, які потрібно зробити, щоб її уникнути.

Наприклад, Azure Security Center дає поради використовувати HTTPS замість HTTP у всіх Azure ресурсах, не відкривати SSH порти в мережу Інтернет у віртуальних машинах. Насправді таких рекомендацій досить багато і щоб не заплутатись, цей елемент автоматично сортує веб-сервіси, файлові сервіси тощо.

Підсумок

Наостанок хочу додати — враховуйте такі важливі показники, що стосуються безпеки системи у Production:

  1. Баги та вразливості, що виявили наші інструменти.
  2. Кількість проблем та їх рівень.
  3. Звіти з безпеки (баги за певний проміжок часу).
  4. Метрики, логи та події, які з’являються в Production.

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

Безпека — це не просто інформація — це спосіб мислення! Тому always think before you click ;)

Використані матеріали:

owasp.org/...​ity-testing-guide/stable

azsk.azurewebsites.net

docs.sonarqube.org/latest

azure.microsoft.com/...​s/#solution-architectures

media.webteam.puppet.com/...​rcleci-splunk_sml-1-1.pdf

docs.microsoft.com/...​ling-tool-getting-started

github.com/tfsec/tfsec

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному5
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
To: [email protected]
Subject: Test DMARC
From: "newfireglobal.com" <[email protected]>
X-Priority: 3 (Normal)
Importance: Normal
Errors-To: [email protected]
Reply-To: [email protected]
Content-Type: text/plain; charset=utf-8
Message-Id: <[email protected]>
Date: Wed, 22 Dec 2021 00:30:01 +0100 (CET)

give me $50000
Зміг з вашого домену відправити собі листа. Навіть в Spam не потрапило. Не налаштували DMARC

Дякую за ваш коментар і знахідку. Обов’язково закриємо цю діру в безпеці.

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

Тільки ця людина — це девопс, який провтикав налаштувати антиспам і перевірку на іп логіна в пошту

.

Не побачив нічого про створення політик безпеки, dmz, логування

Microsoft Threat Modeling Tool

Оце наче те, але ніфіга не зрозуміло, як картинка відноситься до випадку з 50к

.

Стаття почалась з правильного посилу — безпека це процес навчання персоналу правильним правилам поведінки, а продовжилась, як огляд інструментів від одного вендора
Може варто було зосередитись на одному інструменті і описати як їм користуватись
Чи зробити статтю як вводну і розповісти теорії і байки про Мітника (без називання конкретних продуктів)

В даному кейсі антиспам та перевірка на геолокацію іп логіна була включена, а ось 2-х факторна аутентифікація ні.

Політики безпеки, логування, та багато інших практик та інструментів планую більш детально описати в наступній статті.

Фокус у статті робиться на різні DevSecOps-інструменти, в тому числі Azure, я про це пишу на початку статті.

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