Какво определя цената на един тест за проникване

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

Размерът на обхвата е очевидният фактор — и най-малко интересният

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

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

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

Същинската цена идва от сложността

Истинските множители са структурни — свойствата, които оскъпяват едно номинално малко приложение.

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

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

Илюстративни форми, не оценки.

  R = отделни роли      O = чувствителни операции

  вертикални проверки   ≈  R × O
  двойки роли           ≈  R × (R − 1) / 2   (изследвани в двете посоки)
  хоризонтални проверки ≈  O × обекти, за всяка граница между наематели

  R = 2   потребител, администратор
          вертикални → 2 × O      двойки → 1
  R = 6   анонимен, потребител, администратор на екип, администратор на организация, поддръжка, одитор
          вертикални → 6 × O      двойки → 15

  добавяне на една роля при R = 6:
          + O вертикални опита
          + 6 нови двойки
          + още един акаунт и набор от данни за поддръжка

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

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

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

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

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

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

Дълбочина: какво ниво на увереност купувате

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

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

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

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

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

Те не са умалени версии един на друг. Сканирането не е евтин тест за проникване, а red team не е скъп такъв; те са различни продукти с различни резултати, доказателства и режими на провал, затова сравняването на цените им означава да сравнявате несравнимото. Най-често купувачите остават разочаровани, когато купят едно стъпало, а очакват отговорите на друго. Решете на кой въпрос ви трябва отговор, после сравнявайте само сравнимото.

Достъп и среда

Колко се дава на тестера променя както цената, така и стойността, а зависимостта е обратна на това, което мнозина допускат. Black box означава минимално предварително познание: име, диапазон, URL. Grey box добавя данни за достъп за всяка роля, документация, бележки по архитектурата, спецификации на API и посочено лице за контакт. White box добавя изходен код, конфигурация и дефиниции на инфраструктурата.

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

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

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

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

Ограничения, които добавят цена, без да добавят стойност

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

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

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

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

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

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

Бавно осигуряване на достъп. Най-честото от всички — данни за достъп, пристигащи късно, с погрешни права или за погрешната среда. За разлика от останалите, то няма абсолютно никаква полза.

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

Сравняване на оферти, които не са сравними

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

Променливите, които движат усилието най-много, в приблизителен ред на въздействие:

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

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

Въпросите, които правят офертите сравними

Изпратете едни и същи въпроси на всеки доставчик и сравнете отговорите, а не предложенията. Те отличават иначе еднакви оферти.

• Кой извършва теста и какъв е опитът му? Не сертификатите на фирмата — на хората. Попитайте също дали старши тестер преглежда констатациите на всеки по-малко опитен. Доставчик, който отказва да назове ниво, ви подсказва, че такова може да липсва.
• Това ръчно тестване ли е, проверено сканиране или и двете? Инструментите имат място в добрия ангажимент; те покриват известните класове бързо и освобождават време за частите, изискващи преценка. Въпросът е каква част от усилието е човешка.
• Колко роли ще бъдат тествани и колко ще бъде наистина покрито? Поискайте отговора в роли, интерфейси и функционални области. Доставчик, който знае какво остойностява, може да каже какво ще бъде достигнато и какво не.
• Какво съдържа отчетът? Поискайте анонимизиран пример — единственият надежден начин да прецените качеството на отчитането преди предаването. Нашият е публикуван като примерния ни отчет (вижте го тук), а всеки сериозен доставчик ще има нещо равностойно.
• Включен ли е повторен тест след отстраняване? Ако да, какво покрива и в какъв срок след предаването може да бъде ползван? Ако не, колко струва — и сравнете това с офертите, които го включват.
• Ще бъдат ли констатациите демонстрирани със стъпки за възпроизвеждане? Констатация, която инженерите ви могат да възпроизведат, е и такава, която могат да поправят и после да проверят. Такава, която не могат да възпроизведат, се превръща в спор дали изобщо е реална.
• Какво се случва, ако по средата на теста бъде открито нещо критично? Искате незабавно уведомяване, а не откритие чак на етап отчет. Попитайте кой с кого се свързва, колко бързо и дали тестването се спира.
• Ще проведат ли същите хора разговор по резултатите с вашите инженери? Разговор с човека, който е намерил проблема, решава повече от писмен отчет. Ако разговорът по резултатите идва от мениджър по продажбите, голяма част от стойността остава при тестера.

Какво да дадете на тестера, за да получите точна оферта

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

• Описание на архитектурата от абзац или два: какво прави системата, кои са основните компоненти, какво с какво говори, къде се пазят данните.
• Бройки. Приложения, API и приблизително колко крайни точки, отделни потребителски роли, среди.
• Технологии. Езици, рамки, облачна платформа, механизъм за удостоверяване, всичко необичайно. Това определя кой да бъде назначен на работата.
• Дали производствената или тестовата среда е в обхвата и колко точно тестовата отразява производствената.
• Всеки фактор за съответствие и краен срок. Сертификация, изискване от клиент или договорно задължение оформя отчитането и доказателствата; крайният срок оформя подредбата.
• Известни ограничения. Замразявания на промените, прозорци за тестване, ограничаване на честотата, компоненти на трети страни, които не можете да разрешите, всичко, за което се знае, че е счупено.

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

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

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

• Автоматизирано сканиране, представено като тестване. В примерния отчет търсете констатации, които биха могли да дойдат само от инструмент: общи описания, без доказателство за въздействие, критичност, взета направо от таблица за оценяване.
• Младши тестери без преглед от старши. Поискайте посочени хора, опита им и дали старши тестер преглежда констатациите. Отказът да се обсъжда екипът сам по себе си е отговор.
• Няма повторен тест. Четете списъка с предавани документи, а не разказа. Ако повторен тест не е изброен като включен, допуснете, че не е, и остойностете такъв, преди да сравнявате.
• Отчет по шаблон без стъпки за възпроизвеждане. Личи си от примера: констатации, написани срещу общо приложение, а не вашето, и поправки, които само преповтарят класа на уязвимостта.
• Изнесено или възложено на подизпълнител изпълнение, за което не са ви казали. Попитайте къде са тестерите, кой ги наема и дали някоя част от работата се възлага на подизпълнител. Няма нищо нередно в разпределения екип; нередно е да не ви кажат.
• Обхват, тихо свит, за да се вмести в цената. Сравнете формулировката на обхвата между предложенията. Изрази като „представителна извадка“, „ключова функционалност“ или „ако времето позволява“ прехвърлят решението за покритието на доставчика, след като сте подписали.

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

Не всяко увеличение на цената купува пропорционално увеличение на стойността. Струва си да платите за:

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

Често не си струва да плащате за:

• Тестване на всичко с еднаква дълбочина. Еднаквото покритие звучи строго, но неизменно подценява системите, които имат значение. Повечето неща заслужават поглед; малко заслужават продължително внимание.
• Повтаряне на широк годишен тест, когато целенасочен би отговорил на действителния въпрос. Ако трябва да знаете дали новият процес на плащане е солиден, определете го по обхват и го тествайте както трябва, вместо да покривате отново непроменена площ.
• Сканиране, което сами бихте могли да изпълните. Сканирането за уязвимости и зависимости е част от процеса ви и трябва да върви непрекъснато. Да го купувате като еднократна годишна услуга на консултантски цени е слаба сделка и за двете страни.
• Симулация на противник, преди известните проблеми да бъдат поправени. Red teaming отговаря дали бихте открили и реагирали на проникване. Ако неудостоверен интерфейс все още е изложен, вече знаете отговора, а тестването за проникване ще ви каже повече за единица усилие. Симулацията си струва парите, щом очевидните пътища са затворени.

Как да получите стойност от теста, който купувате

Щом ангажиментът е договорен, колко ще получите от него е до голяма степен във ваши ръце. По-голямата част от пропиляното усилие в един тест е административно, а не техническо.

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

PXL включва повторен тест след отстраняване по стандарт при тестовете за проникване. Изпълняваме отново първоначалните стъпки за възпроизвеждане срещу поправения билд и записваме какво намираме, включително къде поправката е частична — защото констатация, затворена без проверка, е твърдение, докато такава, проверена срещу назован билд, е факт.