Бележка
Достъпът до тази страница изисква удостоверяване. Можете да опитате да влезете или да промените директориите.
Достъпът до тази страница изисква удостоверяване. Можете да опитате да промените директориите.
Отнася се за тази Power Platform препоръка за контролен списък за добре архитектурирана сигурност:
| SE:09 | Създайте цялостен режим на тестване, който съчетава подходи за предотвратяване на проблеми със сигурността, валидиране на внедрявания за предотвратяване на заплахи и тестване на механизми за откриване на заплахи. |
|---|
Строгото тестване е в основата на добрия дизайн на сигурността. Тестването е тактическа форма на валидиране, за да се гарантира, че контролите работят по предназначение. Тестването също е проактивен начин за откриване на уязвимости в системата.
Установете строгост на тестване чрез ритъм и проверка от различни гледни точки. Трябва да включите гледни точки отвътре навън, които тестват платформата и инфраструктурата, и външни оценки, които тестват системата като външен нападател.
Това ръководство предоставя препоръки за тестване на състоянието на защитата на вашето работно натоварване. Внедрете тези методи за тестване, за да подобрите устойчивостта на вашето работно натоварване на атаки и да поддържате поверителност, цялост и наличност на ресурси.
Дефиниции
| Термин | Дефиниция |
|---|---|
| Тестване на сигурността на приложенията (AST) | Техника за жизнения цикъл на разработката на защитата на Microsoft (SDL), която използва методологии за тестване на бяла кутия и черна кутия за проверка за уязвимости в защитата в кода. |
| Тестване на черна кутия | Методология за тестване, която валидира външно видимото поведение на приложението без познаване на вътрешността на системата. |
| Син отбор | Отбор, който се защитава от атаките на червения отбор във военно упражнение. |
| Тест за проникване | Методология за тестване, която използва етични хакерски техники за валидиране на защитата на системата. |
| Червен отбор | Екип, който играе ролята на противник и се опитва да хакне системата във военно учение. |
| Жизнен цикъл на разработката на сигурността (SDL) | Набор от практики, предоставени от Microsoft, които поддържат изисквания за осигуряване на защитата и съответствието. |
| Жизнен цикъл на разработката на софтуер (SDLC) | Многоетапен, систематичен процес за разработване на софтуерни системи. |
| Тестване на бяла кутия | Методология за тестване, при която структурата на кода е известна на практикуващия. |
Ключови стратегии за проектиране
Тестването е стратегия, която не подлежи на договаряне, особено по отношение на сигурността. Тя ви позволява проактивно да откривате и решавате проблеми със защитата, преди да могат да бъдат използвани, и да проверявате дали контролите за сигурност, които сте внедрили, функционират както е проектирано.
Обхватът на тестването трябва да включва приложението, инфраструктурата и автоматизираните и човешките процеси.
Бележка
В тези насоки се прави разлика между тестване и реакция при инциденти. Въпреки че тестването е механизъм за откриване, който в идеалния случай коригира проблеми преди производството, то не трябва да се бърка с отстраняването или разследването, което се извършва като част от реакцията при инциденти. Аспектът на възстановяването от инциденти със сигурността е описан в Препоръки за реакция при инциденти със сигурността.
Участвайте в планирането на тестовете. Екипът за работно натоварване може да не проектира тестовите случаи. Тази задача често е централизирана в предприятието или се изпълнява от външни експерти по сигурността. Екипът за работно натоварване трябва да участва в този процес на проектиране, за да се гарантира, че гаранциите за сигурност се интегрират с функционалността на приложението.
Мислете като нападател. Проектирайте тестовите си случаи с предположението, че системата е била атакувана. По този начин можете да разкриете потенциалните уязвимости и съответно да приоритизирате тестовете.
Провеждайте тестове по структуриран начин и с повтарящ се процес. Изградете строгостта си на тестване около ритъма, видовете тестове, движещите фактори и очакваните резултати.
Използвайте правилния инструмент за работата. Използвайте инструменти, които са конфигурирани да работят с работното натоварване. Ако нямате инструмент, купете инструмента. Не го изграждайте. Инструментите за сигурност са тясно специализирани и изграждането на собствен инструмент може да доведе до рискове. Възползвайте се от експертизата и инструментите, предлагани от централните екипи на SecOps или чрез външни средства, ако екипът за работно натоварване няма този опит.
Настройте отделни среди. Тестовете могат да бъдат класифицирани като разрушителни или неразрушителни. Безразрушителните тестове не са инвазивни. Те показват, че има проблем, но не променят функционалността, за да отстранят проблема. Разрушителните тестове са инвазивни и могат да увредят функционалността чрез изтриване на данни от база данни.
Тестването в производствена среда ви дава най-добрата информация, но причинява най-много смущения. Склонни сте да правите само безразрушителни тестове в производствена среда. Тестването в непроизводствени среди обикновено е по-малко разрушително, но може да не представи точно конфигурацията на производствената среда по начини, които са важни за сигурността.
Можете да създадете изолиран клонинг на вашата производствена среда, като използвате функцията закопиране на среда. Ако имате настроени тръбопроводи за внедряване, можете също да разположите решенията си в специална среда за тестване.
Винаги оценявайте резултатите от теста. Тестването е напразно усилие, ако резултатите не се използват за приоритизиране на действията и извършване на подобрения нагоре по веригата. Документирайте указанията за защита, включително най-добрите практики, които откривате. Документацията, която улавя резултатите и плановете за отстраняване, обучава екипа за различните начини, по които нападателите могат да се опитат да пробият сигурността. Провеждайте редовно обучение по защита за разработчици, администратори и тестери.
Когато разработвате плановете си за изпитване, помислете за следните въпроси:
- Колко често очаквате да се провежда тестът и как се отразява на околната среда?
- Какви са различните типове тестове, които трябва да изпълните?
Колко често очаквате да се провеждат тестовете?
Тествайте работното натоварване редовно, за да се уверите, че промените не създават рискове за защитата и че няма регресии. Екипът също така трябва да е готов да отговори на проверки на организационната сигурност, които могат да бъдат извършени по всяко време. Има и тестове, които можете да изпълните в отговор на инцидент със сигурността. Следващите раздели предоставят препоръки за честотата на тестовете.
Рутинни тестове
Рутинните тестове се провеждат с редовен ритъм, като част от вашите стандартни оперативни процедури и за да отговарят на изискванията за съответствие. Различните тестове могат да се изпълняват с различен ритъм, но ключът е, че те се провеждат периодично и по график.
Трябва да интегрирате тези тестове във вашия SDLC, защото те осигуряват задълбочена защита на всеки етап. Разнообразете тестовия пакет, за да проверите гаранциите за самоличност, съхранение и предаване на данни и комуникационни канали. Провеждайте едни и същи тестове в различни моменти от жизнения цикъл, за да сте сигурни, че няма никакви регресии. Рутинните тестове помагат да се установи първоначален еталон. Това обаче е само отправна точка. Когато откривате нови проблеми в същите точки от жизнения цикъл, добавяте нови тестови случаи. Тестовете също се подобряват с повторението.
На всеки етап тези тестове трябва да проверяват кода, който е добавен или премахнат, или настройките за конфигурация, които са се променили, за да се открие въздействието на тези промени върху защитата. Трябва да подобрите ефикасността на тестовете с автоматизация, балансирана с партньорски проверки.
Помислете за изпълнение на тестове за защита като част от автоматизиран конвейер или планирано тестово изпълнение. Колкото по-рано откриете проблеми със защитата, толкова по-лесно е да намерите кода или промяната в конфигурацията, която ги причинява.
Не разчитайте само на автоматизирани тестове. Използвайте ръчно тестване, за да откриете уязвимости, които само човешкият опит може да открие. Ръчното тестване е добро за изследователски случаи на употреба и намиране на неизвестни рискове.
Импровизирани тестове
Импровизираните тестове осигуряват валидиране на защитата на сигурността във времето. Предупрежденията за защитата, които могат да повлияят на работното натоварване по това време, задействат тези тестове. Организационните мандати може да изискват мислене за пауза и тестване, за да се провери ефективността на отбранителните стратегии, ако тревогата ескалира до извънредна ситуация.
Ползата от импровизираните тестове е готовността за реален инцидент. Тези тестове могат да бъдат принудителна функция за извършване на потребителски тестове за приемане (UAT).
Екипът по защитата може да провери всички работни натоварвания и да изпълни тези тестове, ако е необходимо. Като собственик на работно натоварване трябва да улеснявате и да си сътрудничите с екипите по сигурността. Договорете достатъчно време за изпълнение с екипите по сигурността, за да можете да се подготвите. Признайте и съобщете на вашия екип и заинтересованите страни, че тези смущения са необходими.
В други случаи може да се наложи да изпълните тестове и да докладвате състоянието на защитата на системата срещу потенциалната заплаха.
Компромис: Тъй като импровизираните тестове са разрушителни събития, очаквайте да преразгледате приоритетите на задачите, което може да забави друга планирана работа.
Риск: Има риск от неизвестното. Импровизираните тестове могат да бъдат еднократни усилия без установени процеси или инструменти. Но преобладаващият риск е потенциалното прекъсване на ритъма на бизнеса. Трябва да оцените тези рискове спрямо ползите.
Тестове за инциденти със сигурността
Има тестове, които откриват причината за инцидент със сигурността при източника му. Тези пропуски в сигурността трябва да бъдат отстранени, за да се гарантира, че инцидентът няма да се повтори.
Инцидентите също подобряват тестовите случаи с течение на времето, като разкриват съществуващите пропуски. Екипът трябва да приложи уроците, научени от инцидента, и рутинно да включва подобрения.
Какви са различните видове тестове?
Тестовете могат да бъдат категоризирани по технология и по методологии за тестване. Комбинирайте тези категории и подходи в рамките на тези категории, за да получите пълно покритие.
Чрез добавяне на множество тестове и видове тестове можете да разкриете:
- Пропуски в контролите за сигурност или компенсиращите контроли.
- Неправилни конфигурации.
- Пропуски в наблюдаемостта и методите за откриване.
Доброто упражнение за моделиране на заплахи може да посочи ключови области, за да се гарантира покритието и честотата на тестовете. За препоръки относно моделирането на заплахи вижте Препоръки за осигуряване на жизнения цикъл на разработката.
Повечето тестове, описани в тези раздели, могат да се изпълняват като рутинни тестове. Повторяемостта обаче може да доведе до разходи в някои случаи и да причини смущения. Обмислете внимателно тези компромиси.
Тестове, които валидират технологичния стек
Ето няколко примера за видове тестове и техните приоритетни области. Този списък не е изчерпателен. Тествайте целия стек, включително стека на приложенията, предния край, задния край, API, базите данни и всички външни интеграции.
- Сигурност на данните: Тествайте ефективността на криптирането на данните и контрола на достъпа, за да сте сигурни, че данните са правилно защитени от неоторизиран достъп и подправяне.
- Мрежа и свързаност: Тествайте защитните си стени, за да се уверите, че позволяват само очакван, разрешен и безопасен трафик към работното натоварване.
- Приложение: Тествайте изходния код чрез техники за тестване на сигурността на приложенията (AST), за да сте сигурни, че следвате практики за защитено кодиране и да уловите грешки по време на изпълнение, като повреда на паметта и проблеми с привилегиите.
- Самоличност: Преценете дали присвояването на роли и условните проверки работят по предназначение.
Методология на изпитване
Има много гледни точки за методологиите за тестване. Препоръчваме тестове, които позволяват лов на заплахи чрез симулиране на атаки от реалния свят. Те могат да идентифицират потенциални участници в заплахата, техните техники и експлойти, които представляват заплаха за работното натоварване. Направете атаките възможно най-реалистични. Използвайте всички потенциални вектори на заплахи, които идентифицирате по време на моделирането на заплахите.
Ето някои предимства на тестването чрез атаки в реалния свят:
- Когато направите тези атаки част от рутинно тестване, вие използвате перспектива отвън-навътре, за да проверите натоварването и да се уверите, че защитата може да издържи на атака.
- Въз основа на научените уроци екипът надгражда своите знания и ниво на умения. Екипът подобрява ситуационната осведоменост и може да прецени готовността си да реагира на инциденти.
Някои примери за симулирани тестове включват тестване на черна кутия и бяла кутия, тестове за проникване и упражнения за военни игри.
Тестване на черна кутия и бяла кутия
Тези типове тестове предлагат две различни гледни точки. При тестовете на черната кутия вътрешните части на системата не се виждат. При тестовете с бяла кутия тестерът има добро разбиране на приложението и дори има достъп до код, регистрационни файлове, топология на ресурсите и конфигурации за провеждане на експеримента.
Тестове, които симулират атаки чрез тестване за проникване
Експертите по сигурността, които не са част от ИТ или приложните екипи на организацията, провеждат тестове за проникване или тестване на проникването. Те гледат на системата по начина, по който злонамерените участници обхващат повърхността на атаката. Тяхната цел е да намерят пропуски в сигурността чрез събиране на информация, анализиране на уязвимости и отчитане на резултатите.
Практикуващите може да се нуждаят от достъп до чувствителни данни в цялата организация. Спазвайте правилата за ангажиране, за да сте сигурни, че достъпът не се използва неправомерно. Вижте ресурсите, изброени в Свързана информация.
Тестове, които симулират атаки чрез военни упражнения
В тази методология на симулирани атаки има два екипа:
- Червеният отбор е противникът, който се опитва да моделира атаки от реалния свят. Ако те са успешни, откривате пропуски във вашия дизайн за сигурност и оценявате радиуса на взрива на техните пробиви.
- Синият отбор е екипът, който се защитава от атаките. Те тестват способността си да откриват, реагират и отстраняват атаките. Те валидират защитите, които са внедрени, за да защитят ресурсите на работното натоварване.
Ако се провеждат като рутинни тестове, ученията за военни игри могат да осигурят постоянна видимост и сигурност, че вашите защити работят както е проектирано. Упражненията за военни игри могат потенциално да тестват различни нива в рамките на вашите работни натоварвания.
Популярен избор за симулиране на реалистични сценарии за атака е обучението за симулация на Microsoft Defender for Office 365 Attack.
За повече информация вижте Прозрения и отчети за обучение за симулация на атака.
За информация относно настройката на червения и синия отбор вижте 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 за облака предлага сканиране на уязвимости за различни технологични области. За повече информация вижте Разрешаване на сканиране на уязвимости с Microsoft Defender Vulnerability Management.
Практиката на DevSecOps интегрира тестването на сигурността като част от мисленето за непрекъснато и непрекъснато подобрение. Упражненията за военни игри са често срещана практика, която е интегрирана в ритъма на бизнеса в Microsoft. За повече информация вижте Защита в DevOps (DevSecOps).
Azure DevOps поддържа инструменти на трети страни, които могат да бъдат автоматизирани като част от тръбопроводите за непрекъсната интеграция/непрекъснато внедряване (CI/CD). За повече информация вижте Активиране на DevSecOps с Azure и GitHub.
Свързана информация
Най-новите тестове за проникване и оценки на сигурността могат да бъдат намерени на Microsoft Service Trust Portal.
Microsoft извършва обширно тестване на облачните услуги на Microsoft. Това тестване включва тестване за проникване с резултати, публикувани на портала за доверие на услугата за вашата организация. Вашата организация може да извърши свой собствен тест за проникване на Microsoft Power Platform услуги и Microsoft Dynamics 365. Всички тестове за проникване трябва да следват правилата за ангажиране на тестовете за проникване в облака на Microsoft. Важно е да запомните, че в много случаи облакът на Microsoft използва споделена инфраструктура, за да хоства вашите активи и активи, принадлежащи на други клиенти. Трябва да ограничите всички тестове за проникване до вашите активи и да избегнете нежелани последици за другите клиенти около вас.
Следвайте правилата за ангажиране, за да сте сигурни, че достъпът не се използва неправилно. Научете повече за планирането и изпълнението на симулирани атаки:
Можете да симулирате атаки за отказ на услуга (DoS) в Azure. Не забравяйте да следвате правилата, изложени в тестването на симулация на Azure DDoS защита.
Контролен списък за сигурност
Вижте пълния набор от препоръки.