Контролният списък на купувача на тест за проникване

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

Решете на кой въпрос ви трябва отговор

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

• Имаме ли известни слабости, откриваеми с инструменти? Отговаря се чрез сканиране с човешка проверка. Няма да открие нарушен контрол на достъпа между ролите, нито нещо, което изисква разбиране за какво служи приложението ви.
• Какво би открил компетентен нападател при ограничено усилие? Това, което повечето хора имат предвид под тест за проникване: методология, приложена върху договорен обхват за договорен период, следвайки каквото изглежда интересно и спирайки, когато времето свърши. Методично, но по конструкция ограничено.
• Може ли да бъде постигнато конкретно последствие? Да се достигнат клиентски записи, да се вземе административен контрол над средата, да се извърши плащане с грешен резултат. Определя се чрез цели, а не чрез покритие, затова броят на констатациите може да е малък, а резултатът — сериозен.
• Бихме ли забелязали и бихме ли могли да спрем? Упражнение срещу организацията, а не срещу актива — откриване, ескалация, реакция — което носи разходи по съгласуване, каквито един обхватен тест на приложение няма.

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

Установете какво в действителност можете да дадете на тестерите

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

Установете рано кое от следното можете да осигурите и колко време отнема всяко:

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

Ако част от това е невъзможна, това е законно ограничение. Кажете го в искането, вместо да го откривате през първата седмица, и очаквайте предложението да го отчете.

Информация за обхвата: какво да подготвите за първия разговор

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

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

Въпросите към всеки доставчик

Задайте всичките тези, задайте ги на всички и запишете отговорите един до друг. Стойността е по-малко в който и да е единичен отговор, отколкото в сравнението.

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

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

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

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

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

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

Можете ли да свържете констатациите с нашата рамка? Ако докладът ще се използва при одит по ISO 27001, SOC 2, PCI DSS, DORA или NIS2, връзките с приложимите изисквания трябва да са включени в него. Уточнете това при определянето на обхвата.

Какво ще ни кажете, че не сте имали време да тествате? Доставчик, който планира да посочи границите на покритието, разграничава „тествахме това и не открихме нищо“ от „не стигнахме до това“ — разликата между увереност и пропуск, за който не знаете.

Четене на отговорите: тревожни и добри признаци

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

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

Как да сравните офертите по еднакви критерии

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

После проверете изключенията, където най-ниската оферта обикновено се разкрива: непокрити роли, зони с удостоверяване извън обхвата, изключено API, защото е бил назован само уеб интерфейсът, изключено тестване за отказ на услуга (разумно), изключено тестване на бизнес логиката (не). Цената за ден е лош измерител; цената за ден ръчно тестване върху обхвата, който ви интересува, е използваем.

КОНТРОЛЕН СПИСЪК ЗА КУПУВАЧА НА ТЕСТ ЗА ПРОНИКВАНЕ

ПРЕДИ ДА СЕ ОБЪРНЕТЕ КЪМ КОГОТО И ДА Е
[ ] Въпросът, на който този отчет трябва да отговори
[ ] Публиката: инженери / одитор / клиент / застраховател / борд
[ ] Дълбочина: проверено сканиране / ръчно с ограничено време / водено от цели /
    симулация на противник
[ ] Рамката и контролът, които тестът трябва да докаже, ако има
[ ] Какво можем да предадем: данни за достъп, документи, спецификация на API, изходен код
[ ] Ограничения, които не можем да премахнем: прозорци, контрол на промените, забрани

ВХОДНИ ДАННИ ЗА ОБХВАТА, КОИТО ДА ДОНЕСЕТЕ
[ ] Списък с активи, групиран по обща рамка / шлюз / модел на оторизация
[ ] Матрица на ролите и правата, с посочени дубликати
[ ] Къде живее специфичната логика (пари, права, регулаторни правила)
[ ] Модел на многонаемателността и къде се налага изолацията
[ ] Нестандартно удостоверяване
[ ] Работни процеси със състояние, които трябва да бъдат достигнати преди тестване
[ ] Интеграции с трети страни и кои могат да бъдат задействани
[ ] Избор на среда + известни разлики между тестова и производствена
[ ] Препятствия на платформата: ограничения на честотата, WAF, защита от ботове, блокиране по география

ПОПИТАЙТЕ ВСЕКИ ДОСТАВЧИК
[ ] Кой тества и какви практически квалификации притежава?
[ ] Може ли да видим анонимизиран примерен отчет?
[ ] Колко дни са ръчно тестване, без отчитането?
[ ] Ще откриете ли дефекти в бизнес логиката и контрола на достъпа?
[ ] Как определяте обхвата и фиксирана ли е цената писмено?
[ ] Как се съобщават критичните констатации по време на теста?
[ ] Правила на ангажимента и условия за работа с данните?
[ ] Включен ли е повторен тест след отстраняване и при какви условия?
[ ] Можете ли да съотнесете констатациите към нашата рамка?
[ ] Какво ще ни кажете, че не сте имали време да тествате?

ПРЕДАВАНИЯТ ДОКУМЕНТ ТРЯБВА ДА СЪДЪРЖА
[ ] Резюме за ръководството, четимо без жаргон
[ ] Обхват и методология, включително какво НЕ е било тествано
[ ] За всяка констатация: критичност, компонент, доказателство, стъпки за възпроизвеждане,
    бизнес въздействие, конкретна поправка
[ ] Групиране по първопричина, не само списък от отделни случаи
[ ] План за отстраняване, подреден по действителен риск, не по суров CVSS
[ ] Съотнасяне към рамка, ако публиката го изисква
[ ] Жив разговор по резултатите с тестера, който е свършил работата

УСЛОВИЯ ЗА ПОВТОРНИЯ ТЕСТ, ПИСМЕНО
[ ] Включен без допълнителна цена
[ ] Прозорец след предаването
[ ] Всички констатации или само високи и критични?
[ ] Преиздаден отчет или подписано потвърждение?
[ ] Извършен от първоначалния тестер?
[ ] Какво се случва, ако поправката е непълна

ПРЕДИ ПЪРВИЯ ДЕН
[ ] По един работещ акаунт за всяка роля, в който човек е влязъл
[ ] Два наемателя / акаунта за всяка роля, с различими данни
[ ] Реалистични въведени данни във всеки акаунт
[ ] Адресите на източника в списъка с разрешени; WAF и ограниченията на честотата уредени
[ ] Посочено техническо лице за контакт, което може да действа, а не да предава
[ ] Договорен канал за критични констатации
[ ] Определени отговорници за отстраняването
[ ] Предварителна дата за повторния тест в календара

Какво трябва да съдържа крайният доклад

Отчетът е продуктът. Специфицирайте го в договора, вместо да се надявате на него.

Резюме за ръководството, което заявява общия риск и темите на език, по който нетехнически читател може да действа. Раздел обхват и методология, записващ какво е било тествано, как и изрично какво не — пропуските в покритието, заявени като пропуски. Констатации, всяка носеща критичност с обосновката ѝ, засегнатия компонент, доказателство, стъпки за възпроизвеждане, достатъчно точни, за да може инженерът ви да потвърди проблема без помощ, бизнес въздействие на ваш език и конкретна поправка, а не абзац от учебник. Групиране по първопричина, защото една поправка често затваря няколко констатации, а плосък списък от отделни случаи го скрива. План за отстраняване, подреден по действителен риск — критичност, съчетана със стойността на изложеното и колко достижимо е то — не по суров CVSS. Съотнасяне към рамка, където публиката го изисква. И среща за представяне на резултатите с човека, който е извършил тестването, където се отговаря на въпросите, които не сте знаели да зададете.

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

Условия за повторния тест, писмено

Повторният тест е единствената част от ангажимента, която доказва, че парите са постигнали нещо. Нетестван отчет е списък от неща, за които вярвате, че сте поправили.

Уредете шест точки, преди да подпишете. Включването, без допълнителна цена. Прозорецът — колко дълго след предаването можете да го ползвате и дали този срок е реалистичен спрямо вашия цикъл на издания. Покритието — всички констатации или само високи и критични? Повторен тест, ограничен до критичните, оставя средните постоянно непроверени. Резултатът — преиздаден отчет с констатации, отбелязани като разрешени, или отделно потвърждение, което можете да предадете на одитор или клиент. Кой го извършва: първоначалният тестер тества повторно по-бързо и разпознава поправка, която само премества проблема. И какво се случва, когато поправката е непълна — дали втори опит е покрит и дали частичното отстраняване се отчита като разрешено, ограничено или отворено, защото тези три думи означават много различни неща за един оценител.

Какво да подготвите, за да бъде тестът полезен

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

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

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

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