Рекомендації щодо тестування безпеки

Стосується цієї Power Platform рекомендації щодо контрольного списку Well-Architected Security:

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

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

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

Визначення

Ключові стратегії дизайну

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

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

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

Думай як нападник. Проектуйте свої тест-кейси з припущенням, що система зазнала атаки. Таким чином, ви зможете виявити потенційні вразливості та відповідно визначити пріоритети тестів.

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

Використовуйте правильний інструмент для роботи. Використовуйте інструменти, які налаштовані на роботу з робочим навантаженням. Якщо у вас немає інструменту, купіть його. Не будуйте його. Інструменти безпеки є вузькоспеціалізованими, і створення власного інструменту може спричинити ризики. Скористайтеся перевагами досвіду та інструментів, пропонованих центральними командами SecOps, або зовнішніми засобами, якщо команда робочого навантаження не має такого досвіду.

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

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

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

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

Коли ви розробляєте свої плани тестування, подумайте про такі питання:

• Як часто ви очікуєте проведення тесту та як це впливає на ваше оточення?
• Які типи тестів ви повинні проводити?

Як часто ви очікуєте проведення тестів?

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

Рутинні тести

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

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

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

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

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

Імпровізовані тести

Імпровізовані тести забезпечують точкову перевірку захисту безпеки. Сповіщення системи безпеки, які можуть вплинути на робоче навантаження в цей час, ініціюють ці тести. Організаційні мандати можуть вимагати мислення «пауза і тестування», щоб перевірити ефективність оборонних стратегій, якщо тривога переросте в надзвичайну ситуацію.

Користь імпровізованих тестів полягає в готовності до реального інциденту. Ці тести можуть бути функцією примусу для проведення приймального тестування користувача (UAT).

Команда безпеки може провести аудит усіх робочих навантажень і провести ці тести за потреби. Як власник робочого навантаження, ви повинні сприяти командам безпеки та співпрацювати з ними. Домовтеся про достатній час виконання з командами безпеки, щоб ви могли підготуватися. Визнайте та повідомте своїй команді та зацікавленим сторонам, що ці збої необхідні.

В інших випадках вам може знадобитися провести тести та повідомити про стан безпеки системи від потенційної загрози.

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

Ризик: Існує ризик невідомого. Імпровізовані тести можуть бути одноразовими зусиллями без налагоджених процесів чи інструментів. Але переважаючим ризиком є потенційне переривання ритму бізнесу. Вам потрібно оцінити ці ризики щодо переваг.

Тести на інциденти безпеки

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

Інциденти також з часом покращують тестові випадки, виявляючи існуючі прогалини. Команда повинна застосовувати уроки, отримані з інциденту, і регулярно впроваджувати вдосконалення.

Які існують типи тестів?

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

Додавши кілька тестів і типів тестів, ви можете виявити:

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

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

Більшість тестів, описаних у цих розділах, можна виконувати як звичайні тести. Однак повторюваність може спричинити витрати в деяких випадках і спричинити збої. Уважно обміркуйте ці компроміси.

Тести, які перевіряють стек технологій

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

• Безпека даних: перевірте ефективність шифрування даних і контролю доступу, щоб переконатися, що дані належним чином захищені від несанкціонованого доступу та несанкціонованого втручання.
• Мережа та підключення: перевірте свої брандмауери, щоб переконатися, що вони дозволяють лише очікуваний, дозволений і безпечний трафік для робочого навантаження.
• Застосування: перевірте вихідний код за допомогою методів тестування безпеки додатків (AST), щоб переконатися, що ви дотримуєтеся безпечних методів кодування та виявити помилки під час виконання, такі як пошкодження пам’яті та проблеми з привілеями.
• Ідентифікація: оцініть, чи призначення ролей і умовні перевірки працюють належним чином.

Методологія тестування

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

Ось деякі переваги тестування за допомогою реальних атак:

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

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

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

Тестування «чорного ящика» та «білого ящика»

Ці типи тестів пропонують дві різні перспективи. У тестах «чорного ящика» внутрішні компоненти системи не видно. У тестах white-box тестувальник добре розуміє додаток і навіть має доступ до коду, логів, топології ресурсів і конфігурацій для проведення експерименту.

Ризик: Різниця між двома типами полягає в авансовій вартості. Тестування в білому ящику може бути дорогим з точки зору часу, необхідного для розуміння системи. У деяких випадках тестування білого ящика вимагає придбання спеціалізованих інструментів. Тестування «чорного ящика» не потребує часу на посилення, але воно може бути не таким ефективним. Можливо, вам доведеться докласти додаткових зусиль, щоб виявити проблеми. Це компроміс між інвестиціями в часі.

Тести, що імітують атаки за допомогою тестування на проникнення

Експерти з безпеки, які не входять до складу ІТ-команд або команд додатків організації, проводять тестування на проникнення або пентестінг. Вони дивляться на систему таким чином, як зловмисники масштабують поверхню атаки. Їхня мета — знайти прогалини в безпеці шляхом збору інформації, аналізу вразливостей і звітування про результати.

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

Ризик: Перевірка на проникнення може вплинути на середовище виконання та порушити доступність для звичайного трафіку.

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

Тести, що імітують атаки за допомогою вправ на військову гру

У цій методиці імітації атак виділяють дві команди:

• Червона команда – це супротивник, який намагається моделювати реальні атаки. Якщо вони успішні, ви знаходите прогалини у своїй конструкції безпеки та оцінюєте радіус стримування їх порушень.
• Синя команда – це команда з навантаженням, яка обороняється від атак. Вони перевіряють свою здатність виявляти, реагувати та усувати атаки. Вони перевіряють захисні механізми, які були впроваджені для захисту ресурсів робочого навантаження.

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

Популярним вибором для моделювання реалістичних сценаріїв атак є тренування Office 365 з симуляції Microsoft Defender forAttack.

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

Для отримання інформації про налаштування червоної та синьої команд дивіться Microsoft Cloud Red Teaming.

Power Platform Сприяння

Microsoft Рішення Sentinel дозволяє Microsoft Power Platform клієнтам виявляти різні підозрілі дії, такі як:

• Power Apps Виконання з несанкціонованих географічних місць
• Знищення підозрілих даних Power Apps
• Масове видалення Power Apps
• Фішингові атаки, здійснені через Power Apps
• Power Automate Потоки активності за рахунок співробітників, що звільняються
• Microsoft Power Platform конектори, додані до середовища
• Оновлення або видалення Microsoft Power Platform політик захисту від втрати даних

Для отримання додаткової інформації дивіться Microsoft Рішення Sentinel для Microsoft Power Platform огляду.

Документацію продукту дивіться в розділі Можливості полювання в Microsoft Sentinel.

Microsoft Defender for Cloud пропонує сканування вразливостей для різних технологічних областей. Для отримання додаткової інформації дивіться Увімкнення сканування вразливостей за допомогою Microsoft Керування вразливостями Defender.

Практика DevSecOps інтегрує тестування безпеки як частину мислення постійного вдосконалення. Вправи з військової гри – поширена практика, яка інтегрована в ритм бізнесу на Microsoft. Для отримання додаткової інформації дивіться статтю Безпека в DevOps (DevSecOps).

Azure DevOps підтримує сторонні інструменти, які можна автоматизувати в рамках конвеєрів безперервної інтеграції/безперервного розгортання (CI/CD). Для отримання додаткової інформації дивіться Увімкнення DevSecOps за допомогою Azure та GitHub.

Пов’язані відомості

Останні тести на проникнення та оцінки безпеки можна переглянути на порталі надійності служб Microsoft.

Microsoft проводить всебічне тестування хмарних сервісів Microsoft. Це тестування включає тестування на проникнення, результати якого публікуються на Порталі довіри до служби для вашої організації. Ваша організація може провести власний тест на проникнення на Microsoft Power Platform сервіси 365 Microsoft Dynamics . Усі тести на проникнення повинні відповідати Microsoft правилам тестування на проникнення в хмару. Важливо пам’ятати, що в багатьох випадках хмара Microsoft використовує спільну інфраструктуру для розміщення ваших активів та активів, що належать іншим клієнтам. Ви повинні обмежити всі тести на проникнення до своїх активів і уникнути непередбачених наслідків для інших клієнтів навколо вас.

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

• Правила проведення тестування на проникнення
• Тестування на проникнення

Ви можете імітувати атаки типу «відмова в обслуговуванні» (DoS) у розділі Azure. Обов’язково дотримуйтесь політик, викладених у Azure тестуванні симуляції захисту від DDoS-атак.

Контрольний список безпеки

Зверніться до повного зведення рекомендацій.