Моделиране на заплахи: превърнете архитектурата в решения за сигурността

Моделирането на заплахи пита какво може да се обърка в конкретна система и какво трябва да направи екипът по въпроса. Неговият полезен резултат не е каталог от плашещи възможности. Той е набор от решения за дизайна и внедряването, свързани с архитектурата, със собственици и доказателства, че избраните защити работят.

За техническия директор централният въпрос е дали инженерният екип може да обясни как важните свойства на сигурността издържат на реалното поведение на системата: повторни опити, фонови задачи, привилегировани действия на поддръжката, прекъсвания при доставчици и злонамерени входни данни. Диаграмата прави тези разговори конкретни. Поддържаният модел на заплахите превръща заключенията в работа по реализацията.

Насоките на OWASP за моделиране на заплахи дават полезна основа: разберете системата, идентифицирайте заплахите, решете как да реагирате и преценете дали работата е достатъчна. Работният процес по-долу прилага този начин на мислене към инженерните решения.

Опишете системата, преди да обсъждате атаки

Започнете с ограничена функционалност, например експорт на клиентски данни, иницииране на плащания или актуализации на устройства. Моделирането на цяла платформа наведнъж често води до повърхностни наблюдения, защото никой не може да обясни всяка зависимост достатъчно подробно.

Формулирайте активите и целите за сигурност в оперативни термини. „Защита на клиентските данни“ е твърде общо. „Удостоверен потребител може да експортира само записи, принадлежащи на наемателя, за който е оторизиран“ дава на екипа свойство, което може да се тества. Други цели може да се отнасят до целостта на транзакциите, наличността на услугата, възстановяването или установяването на автора на административни действия.

Идентифицирайте потребителите, услугите, хранилищата на данни, външните зависимости, входните точки и границите на доверие. Начертайте важните потоци от данни, включително асинхронната обработка и административните пътища. Обозначете потоците с пренасяните данни, механизма за удостоверяване и контекста на оторизация, когато те влияят върху анализа.

Границата на доверие отбелязва промяна в допусканията или правомощията, а не непременно мрежов периметър. Браузър, който извиква API, пресича една граница. Споделен работен процес, действащ от името на клиент, пресича друга, дори ако и двете услуги работят в един и същ клъстер.

За приложение с много наематели покажете къде се установява идентичността на наемателя и как тя достига до проверките за оторизация, фоновите задачи и експортите. Включете идентичностите на услугите, достъпа до обектното хранилище, инструментите за поддръжка и външните обратни извиквания. В противен случай диаграмата може да описва щастливия път, като пропуска пътищата, които най-вероятно ще заобиколят изолацията.

Записвайте допусканията отделно от фактите. „Опашката не може да бъде записвана от клиенти“ се нуждае от подкрепящи доказателства за конфигурацията. Неизвестните трябва да се превръщат в задачи за проучване, а не в мълчаливо приети защити.

Изберете метод, който помага на екипа да разсъждава

Методът предоставя насочващи въпроси и структура. Той не определя кои заплахи са най-важни, не доказва, че дизайнът е сигурен, и не замества познаването на системата.

STRIDE за систематични насочващи въпроси

STRIDE разглежда шест категории. Прилагайте ги към релевантните компоненти, потоци и граници, вместо да налагате всяка категория върху всеки елемент на диаграмата.

Един сценарий може да обхваща няколко категории. Когато е уместно, поддържайте един-единствен приложим запис, вместо да създавате дублиращи се заявки, само за да удовлетворите таксономията.

Други методи за различни въпроси

PASTA (Process for Attack Simulation and Threat Analysis) предлага седемстепенен, ориентиран към риска подход, който свързва бизнес целите, техническия обхват, декомпозицията, анализа на заплахите и уязвимостите, моделирането на атаки и третирането на риска. Той е подходящ за по-задълбочен анализ, когато поведението на нападателя и бизнес последиците се нуждаят от изрично внимание.

Дърветата на атаките започват с целта на нападателя и я разлагат на алтернативни или комбинирани пътища. За „получаване на експорта на друг наемател“ алтернативите може да включват заобикаляне на оторизацията в API, объркване на контекста на наемателя в работния процес или кражба на идентификационни данни за изтегляне. Връзките И представят условия, които трябва да настъпят заедно; връзките ИЛИ представят алтернативи.

VAST (Visual, Agile, and Simple Threat modeling) набляга на мащабируемо моделиране от гледна точка както на приложенията, така и на операциите. Екипите, които го обмислят, трябва да проверят дали техните инструменти и процес на разработка могат да поддържат тези изгледи последователно.

Практичната препоръка за начало е диаграма на потоците от данни плюс STRIDE, последвана от дърво на атаките за сценария с най-сериозни последици. Повече методология е полезна само когато подобрява решенията.

Провеждайте прегледа около конкретни сценарии

Включете хората, които разбират внедряването и експлоатацията: разработчик, архитект или технически ръководител, проверяващ по сигурността и човек, запознат с поведението в производствената среда. Включете специалисти по продукта, поверителността или доставчиците, когато техните знания влияят върху обхвата.

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

Описвайте заплахите като сценарии, а не като етикети. „Проблем с оторизацията“ не е достатъчно полезно. По-силно твърдение е: „Удостоверен потребител подменя идентификатора на експорт на друг наемател; крайната точка за изтегляне проверява влизането, но не и собствеността върху обекта, и разкрива клиентски записи.“

Разграничавайте три понятия:

• Заплахата описва неблагоприятно действие или събитие, например неоторизирано получаване на експорт.
• Уязвимостта е слабост, която би могла да го направи възможно, например липсваща проверка за собственост.
• Рискът отчита вероятността и последиците от сценария в действителната среда.

Една заплаха може да си струва да бъде проучена, преди дадена уязвимост да е потвърдена. По същия начин откриването на слабост не установява, че всяка мислима атака е осъществима.

Включете злоупотребата от легитимни потребители, привилегированите вътрешни лица, грешките в конфигурацията и отказите на доставчици наред с външните атаки. Питайте какво се случва, когато зависимост изтече по време или върне неочакван отговор. Поведението „при отказ — отворено“ и непоследователните повторни опити често излизат наяве в тези дискусии.

Практически пример: конвейер за експорт с много наематели

Следващият пример е илюстративен. Да приемем, че SaaS приложение има клиент в браузъра, API, споделена база данни, опашка със задачи, работен процес за експорт и обектно хранилище. Потребителите на наемателите заявяват CSV експорти; работният процес генерира файловете, а API издава временни връзки за изтегляне. Администраторите на поддръжката имат отделен интерфейс за отстраняване на проблеми.

Целите за сигурност са изолация на наемателите, оторизирано иницииране на експорт, ограничено потребление на ресурси и установим автор на действията на поддръжката. Да приемем, че работният процес има достъп до базата данни, достатъчно широк, за да обслужва множество наематели. Това прави обработката на контекста на наемателя от негова страна централно решение, а не дребен детайл на внедряването.

Проследете правомощията през потока

В API удостовереният субект се свързва с разрешено членство в наемател. Идентификатор на наемател, подаден от браузъра, е заявка за избор, а не доказателство за оторизация. API проверява членството и правото за експорт, преди да създаде непроменим запис за задачата, съдържащ оторизирания наемател, заявителя и разрешения обхват на експорта.

Съобщението в опашката препраща към този запис. Работният процес валидира задачата и прилага достъп до данните, ограничен по наемател, при създаването на експорта. Метаданните в хранилището свързват получения обект със задачата и наемателя. Преди да издаде връзка за изтегляне, API проверява оторизацията на текущия заявител спрямо тази връзка.

Този дизайн все пак се нуждае от изрични решения относно отнемането на достъп: трябва ли потребител, който загуби членството си след заявяване на експорт, да запази достъпа до завършения файл? Екипът трябва да определи тази политика и да я прилага последователно.

Превърнете сценариите в контроли и тестове

Временните връзки въвеждат прозорец на остатъчна експозиция: притежаването на връзката може да позволява достъп до изтичането ѝ, в зависимост от механизма. Екипът трябва да реши дали това е приемливо за съответните данни или изтеглянията се нуждаят от удостоверен посредник с текущи проверки на оторизацията.

Не приключвайте модела, след като сте тествали само синхронния API. Проверете отложените задачи, повторните опити, отменените заявки, изтеклото членство, изтритите наематели и частичните откази. Например задача, която се изпълнява повторно, не бива да използва обект, свързан с друг наемател, или да публикува непълен експорт като успешен.

Полученият резултат е прегледана архитектура, регистър на заплахите, задачи по внедряването и свързани резултати от проверки. Той не е просто диаграмата.

Приоритизирайте според експозицията и последиците

Приоритизирайте правдоподобните сценарии според експозицията, въздействието, предпоставките и съществуващите защити. Разграничавайте пряко достъпен отказ на оторизацията от сценарий, който изисква няколко недоказани компрометирания. Вземете предвид засегнатите данни, прекъсването на услугата, финансовите последици, последиците за безопасността и трудността на възстановяването, когато е релевантно.

Използвайте проста последователна скала, ако тя помага на екипа, но записвайте обосновката на оценката. Числова оценка с необяснени входни данни създава фалшива точност. CVSS може да информира оценката на конкретна уязвимост; той не замества разбирането на бизнес въздействието или на архитектурен сценарий на злоупотреба.

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

Остатъчният риск трябва да има посочено лице, вземащо решението, причина, срок или повод за преглед и евентуални оперативни условия. Завършването на инженерната работа и приемането на риска са различни решения. Една заявка може да е приключена, докато съществен риск остава.

Пренесете модела в реализацията и доказателствата

За всеки съществен сценарий запишете неговия идентификатор, засегнатите компоненти, предпоставките, последиците, съществуващите защити, третирането, собственика и метода за проверка. Свържете записа с версията на архитектурата и релевантната работа по внедряването, така че проверяващите да могат да разберат кой дизайн е бил оценен.

Превърнете третиранията в критерии за приемане, които могат да се тестват. „Подобряване на контрола на достъпа“ е неясно. „Наемател A не може да заяви, проверява, отменя или изтегля експорта на наемател B чрез никоя поддържана крайна точка“ посочва поведение, което инженерният екип може да провери.

Използвайте доказателства, подходящи за твърдението:

• Прегледът на кода може да установи къде се прилага оторизацията.
• Проверката на конфигурацията може да установи правата на услугите и експозицията на хранилищата.
• Отрицателните интеграционни тестове могат да проверят границите между наематели и между нива на привилегии.
• Тестовете с натоварване и с инжектиране на откази могат да изследват наличността и поведението при отказ.
• Целенасоченото тестване за проникване може да проучи пътища на атака, които се нуждаят от независимо изследване.

Нито един отделен артефакт не доказва целия модел. Екранна снимка на настройка не доказва, че всеки работен процес я използва, а успешно преминал тест не демонстрира нетестван път. Записвайте тестовата среда, обхвата, резултатите и ограниченията.

Моделирането на заплахи допълва безопасното програмиране, оценката на зависимостите, сканирането за уязвимости и тестването за проникване. Неговият отличителен принос е архитектурното разсъждение: то може да разкрие опасно разпределение на правомощия дори когато отделните компоненти нямат известни уязвимости.

Дръжте инструментите и автоматизацията подчинени на модела

Споделена диаграма и структуриран регистър могат да подпомогнат един фокусиран първи преглед. Специализираните инструменти стават полезни, когато екипите се нуждаят от библиотеки с компоненти за многократна употреба, последователни идентификатори, сътрудничество и надеждни връзки между заплахите и записите за реализацията.

Преценете дали даден инструмент поддържа граници на доверие, персонализирани сценарии, история на версиите, записи, които могат да се експортират, собственост и препратки към доказателства. Автоматично генерираните заплахи са насоки за проучване, а не потвърдени констатации. Дългите списъци без контекст могат да скрият малкото решения, които имат значение.

Помощта от AI може да изготвя проекти на описания на сценарии, да предлага липсващи пътища или да сравнява промени спрямо по-ранен модел. Човешките проверяващи все пак трябва да валидират архитектурата, осъществимостта, покритието на мерките за смекчаване и остатъчния риск. Не допускайте поверителни диаграми и идентификационни данни в неодобрени услуги. Генерирането на модел на заплахите е различно и от откриването по време на работа; създаването на модел не установява непрекъснат мониторинг или автоматизирано отстраняване.

Преглеждайте, когато архитектурата или допусканията се променят

Актуализирайте модела при нови интеграции, промени в удостоверяването, привилегировани действия, категории данни, мрежова експозиция и големи промени в зависимостите. Инцидент или неочакван резултат от тест също може да обезсили по-ранно допускане.

Различните системи изискват различен акцент. Облачните приложения изискват внимание към правата на идентичностите и достъпа до управляващата равнина. Мобилните клиенти трябва да се третират като среди, контролирани от нападателя, а не като доверени точки за прилагане на правила. Свързаните устройства въвеждат физически достъп, цялост на актуализациите, възстановяване и потенциално последици за безопасността. Функциите, използващи AI, добавят недоверено съдържание и граници при използването на инструменти; оторизацията трябва да ограничава действията независимо от резултата на модела.

Измервайте дали важните потоци имат актуални модели, дали третиранията с висок приоритет имат доказателства за проверка, дали допусканията остават нерешени и дали приетите рискове имат просрочени прегледи. Броенето само на заплахите възнаграждава обема, а не полезния анализ. Периодично молете независим проверяващ да оспори един критичен сценарий и доказателствата за него.

Направете първия преглед достатъчно малък, за да бъде завършен

Secani може да запази работния процес около тези решения, като моделира релевантните системи и зависимости, възлага собственици и проверяващи и свързва доказателствата с изисквания, контроли и решения. Нерешените допускания се превръщат в задачи; изходните материали и човешките одобрения остават свързани с прегледа. Всички предложения, подпомогнати от AI, трябва да бъдат проверени преди одобрение.

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