PXLSecurity LTD., София, България Офанзивна сигурност от 2014[email protected]
Ръководство за купувачаМетодологияТестване за проникване

Колко време отнема един тест за проникване?

От PXLSec4 октомври 2026 г.13 мин. четенеОбновено:

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

Време за тестване спрямо календарно време

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какво означава това за вас

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

Какво контролирате вие

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

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

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

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

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

Последователността, етап по етап

Всеки етап има входни данни, които изисква, нещо, което вие трябва да направите, и нещо, което го блокира. Формата има по-голямо значение от което и да е число.

Последователност на етапите и зависимости. Подредбата не предполага продължителности.

  определяне на обхват
    вие осигурявате: списък с активи, роли, цели, ограничения
    блокира се от:   липса на вътрешно решение за въпроса
        →
  правила на ангажимента
    вие осигурявате: прозорци, изключения, лица за ескалация
    блокира се от:   нерешено съгласие от хостинг на трета страна
        →
  договаряне и разрешение
    вие осигурявате: подписващ, писмено разрешение за тестване
    блокира се от:   правен преглед, съмнение за собствеността на активи
        →
  осигуряване на достъп  ──►  начална среща
    вие осигурявате: по един акаунт за роля, въведени данни, списък с разрешени
    блокира се от:   погрешни права, погрешна среда, късна доставка
        →
  тестване
    вие осигурявате: лице за контакт, което може да действа, стабилна среда
    блокира се от:   прекъсвания, тесни прозорци, одобрения на части
        →
  отчитане  ──►  разговор по резултатите
    вие осигурявате: участници, които могат да вземат решения
    блокира се от:   нищо от ваша страна
        →
  отстраняване
    вие осигурявате: инженерен капацитет, внедряване
    ограничено от:   ВАШИЯ цикъл на издания  <— обичайното дълго звено
        →
  повторен тест
    вие осигурявате: внедрени поправки там, където тестерът може да ги достигне
    блокира се от:   частични поправки, поправки само в клон
        →
  писмо за приключване
    блокира се от:   констатации, все още отворени или приети без решение

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

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

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

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

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

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

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

Планиране назад от краен срок

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

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

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

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

Какво означава това за вас

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

Когато по-бързият тест е погрешният отговор

Понякога календарът наистина няма да се помести и единственият лост е самият тест. Има два начина един тест да бъде скъсен и те не са равностойни.

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

Свиването на дълбочината означава да бъде тестван същият обхват, по-малко задълбочено. Нищо не е изключено на хартия, което е точно проблемът: покритието вече е неравномерно по начини, които документът не разкрива. Онова, което се губи, е конкретно и предвидимо. Матрицата на контрола на достъпа се прави чрез извадка, вместо да бъде обходена, а именно там обикновено живеят сериозните констатации. Бизнес логиката остава нетествана, защото разбирането ѝ е скъпата част и затова първото, което отпада. Навързаните констатации изчезват: проблемът, който има значение само защото се комбинира с друг, се отчита изолирано или изобщо не, защото никой не е имал време да опита комбинацията. Проверката изтънява, така че повече констатации пристигат като „възможни“, вместо демонстрирани. А отчетът започва да описва изхода на инструмент, а не поведение на нападател.

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

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

Работите по краен срок?

Кажете ни датата, до която ви трябват доказателства, и ще планираме ангажимента назад от нея.

Заявете предложение