Сканирането за уязвимости не е тест за проникване

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

Какво всъщност прави скенерът

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

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

Какво добавя тестът за проникване

Тестът за проникване е човек — умел — който се опитва да проникне във вашите системи така, както би го направил нападател. Изходът на скенера може да е входни данни за тази работа, но стойността е в това, което прави само човек:

• Дефекти в бизнес логиката. Натрупване на кодове за отстъпка, прескачане на стъпка за плащане, повишаване на роля. Нищо не е технически „счупено“, така че никой скенер не го отбелязва — но то източва приходи или излага данни.
• Дефекти в контрола на достъпа. Класическото „смени идентификатора в URL и виж чужди данни“. Скенерите рядко разполагат с контекста с удостоверяване, за да ги намерят; те са сред най-честите сериозни дефекти, които отчитаме.
• Навързване. Действителните атаки комбинират малки проблеми. Изтичане на информация с ниска критичност плюс слаб процес за нулиране се превръща в завладяване на акаунт. Скенерът изброява две незначителни констатации; тестерът ви показва пробива.
• Доказателство и приоритизиране. Тестерът демонстрира действително въздействие и ви казва какво да поправите първо. Сканирането ви предава стотици констатации, много от които фалшиви положителни, без никакво усещане коя от тях ще провали седмицата ви.

Как да разберете кое от двете купувате

Етикетът на офертата не ви казва. Тези въпроси — да:

• „Кой извършва тестването и какви квалификации има?“ Действителният тест се прави от посочени по име старши хора с практически сертификати, а не се възлага на инструмент.
• „Може ли да видя анонимизиран примерен отчет?“ Търсете стъпки за възпроизвеждане, навързани констатации и бизнес въздействие — не просто таблица с критичност, взета от скенер.
• „Ще откриете ли проблеми в бизнес логиката и контрола на достъпа?“ Ако отговорът е неясен, купувате сканиране.
• „Включен ли е повторен тест?“ Хората застават зад констатациите си и проверяват поправките. Инструментът може само да сканира отново.
• „Колко дни ръчно тестване?“ Действителният ангажимент се измерва в дни на тестер, не в това колко бързо завършва едно сканиране.

Нужни са ви и двете

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

За какво е полезно сканирането

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

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

Тест от тридесет секунди за всеки отчет

Отворете всеки отчет, който ви е бил предаден, и потърсете три неща. Включва ли някоя констатация стъпките за възпроизвеждането ѝ? Има ли поне една констатация, която навързва два проблема заедно или използва бизнес логиката, а не известен CVE? И има ли повторен тест? Ако отговорът на всичките три е не, държите сканиране с титулна страница — както и да го е нарекла фактурата.

Капанът на съответствието

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

Икономиката на фалшивите положителни резултати при сканирането

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

Този шум има твърда цена. Всеки фалшив положителен резултат изразходва време на анализатор и, по-лошо, учи инженерите ви да отхвърлят инструмента. Списък от 900 „критични“ проблема, който е 85 процента шум, не бива триажиран — той бива игнориран, а трите действителни критични проблема в него умират от пренебрежение. Опасността на един скенер рядко е това, което пропуска; тя е изтощението, което произвежда.

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

SAST, DAST, SCA и IAST: предназначение и ограничения

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

• SAST чете изходния код, без да го изпълнява. Той е силен при дефектите от тип проследяване на недоверени данни — инжектиране, твърдо кодирани тайни, несигурна десериализация — и може да посочи точния ред. Той е сляп за конфигурацията по време на работа, за това дали уязвим път всъщност е достижим, и за всичко, което съществува само след като кодът е внедрен и свързан с действителните зависимости. Той е и надежден източник на фалшиви положителни резултати именно защото не вижда достижимостта.
• DAST атакува работещото приложение отвън. Той вижда какво вижда външен нападател и улавя действителни неправилни конфигурации, които SAST не може. Той е сляп за пътища в кода, които никога не достига — несвързани крайни точки, състояния зад сложни работни процеси — и рядко разбира бизнес смисъла, така че не може да каже, че отговор 200 крие провал на оторизацията.
• SCA описва компонентите от трети страни и с отворен код спрямо потоци с известни уязвимости. Той е съществен за хигиената на веригата на доставки и за лицензния риск. Той е сляп за това дали уязвимата функция изобщо бива извикана, затова само SCA произвежда огромни, предимно теоретични списъци със задачи.
• IAST инструментира приложението по време на функционално или DAST тестване, съотнасяйки потока от данни по време на работа с кода. Той намалява рязко фалшивите положителни резултати и подобрява увереността за достижимостта. Той е сляп за всичко, което вашият тестов трафик никога не задейства — покритието му е толкова добро, колкото тестовият набор, който го задвижва.

Всички тези инструменти имат едно и също ограничение: нито един не разсъждава за намерението. Те не знаят, че клиентът не бива да одобрява собственото си възстановяване на сума, или че две констатации с ниска критичност се комбинират в завладяване на акаунт. Това разсъждение е ръчният слой и той е задължителен.

Сканиране с и без удостоверяване: защо покритието не е дълбочина

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

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

Показателите и въпросите, които купувачът трябва да изисква

Маркетинговият език крие разликата между сканиране и тест. Числата — не. Преди да подпишете, накарайте предложението да се обвърже с конкретики, по които по-късно можете да го държите отговорно.

• Дни на тестер, не „един тест“. Попитайте колко консултантски дни ръчно усилие са заделени, отделно от времето за изпълнение на инструментите. Голямо приложение, остойностено за ден и половина, е сканиране с титулна страница.
• Назована методология и покритие. Кой стандарт — OWASP WSTG, ниво по ASVS, PTES — и кои категории са в и извън обхвата? Тест, който мълчаливо пропуска контрола на достъпа или бизнес логиката, трябва да го посочи.
• Съотношение ръчно към автоматизирано. Каква част от усилието е с ръце на клавиатурата спрямо задвижваното от инструменти? Очаквайте честно съотношение, не „напълно автоматизирано с експертен преглед“.
• Условия за повторния тест. Включен ли е повторен тест за потвърждаване на поправките на отстранените констатации, в какъв срок и на каква цена? Констатация, за която не можете да докажете, че е поправена, е констатация, която все още притежавате.
• Стандарт за доказателствата. Ще носи ли всяка констатация възпроизводим proof of concept и конкретно изявление за бизнес въздействието, или само етикет за критичност, взет от таблица по CVSS?
• Кой върши работата. Посочени по име тестери и техните квалификации, а не само лого и общ екип.

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

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

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

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