Сигурност още от началото на разработката: моделиране на заплахите, което инженерите наистина използват

„Shift left“ се превърна в лозунг, а като повечето лозунги изгуби смисъла си. Направено лошо, моделирането на заплахите е един ден рисуване на диаграми, които се подреждат в папка и се забравят. Направено добре, то е най-евтината дейност по сигурността, която можете да провеждате: съсредоточен разговор, който улавя дефекти в проектирането, преди да бъдат изградени, когато поправката им струва почти нищо.

Защо проектирането превъзхожда откриването

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

Лек модел, който инженерите използват

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

1. Какво изграждаме? Проста диаграма на компонентите, потоците от данни и границите на доверие. Къде данните преминават от „по-малко доверено“ към „по-доверено“?
2. Какво може да се обърка? Обходете всяка граница на доверие и всеки поток от данни. Представяне за друг, подправяне, разкриване на информация, повишаване на права — кой би могъл да злоупотреби с това и как?
3. Какво ще направим по въпроса? За всяка действителна заплаха — ограничаване или приет риск. Конкретно, с отговорник, проследявано.
4. Направихме ли го? Проверете, че ограниченията са влезли в сила — в идеалния случай чрез тест, а не по предположение.

Как моделът да остане полезен

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

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

Откъде да започнете, ако никога не сте го правили

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

Случаи на злоупотреба наред със случаите на употреба

Ето най-лесния начин моделирането на заплахите да се задържи: за всяка потребителска история напишете по една история на злоупотреба. „Като нападател искам да прочета фактурата на друг клиент.“ „Като нападател искам да одобря собственото си възстановяване на сума.“ Това превръща абстрактното „какво може да се обърка“ в конкретни, тестваеми твърдения и се вписва директно в начина, по който екипите вече планират работата — без нужда от нов ритуал.

STRIDE, приложен за всеки елемент (не за цялото приложение)

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

• Процесите са изложени на всичките шест: представяне за друг, подправяне, отказ от авторство, разкриване на информация, отказ на услуга, повишаване на права.
• Потоците от данни се отнасят до подправяне, разкриване на информация и отказ на услуга — съобщение в пренос не може да повиши собствените си права.
• Хранилищата за данни поемат подправяне, разкриване на информация, отказ на услуга и отказ от авторство там, където хранилището е журнал.
• Външните субекти (потребители, услуги на трети страни) се отнасят до представяне за друг и отказ от авторство.

Това превръща неясната тревога в ограничен контролен списък. За крайна точка, издаваща токени, питате: може ли извикващият да бъде подменен (слабо удостоверяване), токенът да бъде подправен (неподписани твърдения), издаването да бъде отречено (без одитен запис), ключът за подписване да бъде разкрит? Всяко „да, и нищо не го спира“ е констатация с назовано ограничение, не притеснение.

Диаграми на потоците от данни и границите на доверие, направени правилно

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

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

[ Браузър ] --(1) HTTPS--> | ГД:мрежа | --> [ API шлюз ]
                                                      |
                            | ГД:удостоверяване/права |     v
                                                [ Услуга за поръчки ] --(2)--> [( БД с поръчки )]
                                                      |
                            | ГД:трета страна |        v
                                              [ Доставчик на плащания ]

Всеки номериран поток, който прекосява граница, е ред във вашето преминаване по STRIDE. Ако поток никога не прекосява граница, обикновено там не отива времето ви.

Дървета на атаките и честно подреждане на риска

Щом имате заплахи, трябва да приоритизирате — и точно тук числовото оценяване тихо се проваля. Дърветата на атаките приоритизират, като правят пътя на противника явен: поставете целта в корена и я разложете на подцели с И/ИЛИ, докато достигнете конкретни действия с цена. Най-евтиният пълен път — най-слабото ИЛИ разклонение — е това, което нападателят действително избира, и точно то се поправя първо.

ЦЕЛ: прочитане на поръчките на друг наемател
 ИЛИ-- използване на липсваща проверка за наемател по идентификатор на поръчка   [евтино, отдалечено]
 ИЛИ-- получаване на валиден токен за друг наемател
      И-- намиране на токен в клиентски журнали
      И-- възпроизвеждане преди изтичане                  [изисква локален достъп]

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

Моделиране на заплахите като код и обвързване с тестове

Модел, който живее в презентация, умира при първата промяна в проектирането. Дръжте го в хранилището за код до кода, който описва — диаграма на потоците от данни като код и списък със заплахи във версиониран текстов файл — така че да се сравнява при преглед и от заявка за сливане, която добавя нов поток от данни, да се очаква да го обнови. Това е „моделиране на заплахите като код“: артефактите са обикновен текст, преглеждат се като код, а CI проверка може да отбележи модел, недокоснат от N издания, или нова външна крайна точка без съответстващо вписване.

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