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

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

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

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

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

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

Въпросите, които отличават доставчиците

Задайте ги писмено и сравнете отговорите, не брошурите.

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

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

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

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

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

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

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

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

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

Преглед на офертата

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

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

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

Сертификатите и какво доказват и не доказват

Сертификатите са полезни и рутинно им се разчита прекомерно. Практическите — OSCP, OSWE, OSEP, наборът OSCE³, регистрираните и сертифицирани изпити за тестери на CREST и техните еквиваленти — се печелят на изпити с ограничено време и практическа работа срещу живи цели. Издържаният изпит е доказателство, че даден човек би могъл, в даден ден, да върши определен клас работа без помощ, което е повече, отколкото казва сертификат с избор от отговори.

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

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

За да сме ясни за собствената си позиция: инженерите на PXL притежават индивидуални практически сертификати, включително OSCE³, OSWE, OSEP, CRTO и CREST CRT. Не притежаваме акредитация на ниво фирма по никаква схема и не твърдим, че притежаваме. Ако правилата ви за доставки изискват акредитиран доставчик, ние не отговаряме на условията, затова го кажете рано, вместо да го откриете на етап договор. Преценете вместо това това, което акредитацията замества: посочените хора, проверимата им работа и документ, който можете да прочетете предварително.

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

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

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

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

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

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

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

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

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

Тревожни признаци

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

Въпроси към избраните кандидати

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

1. Кой ще извърши този тест, колко дълго всеки е тествал системи като нашите и кой преглежда констатациите им преди издаването?
2. Каква част от усилието е ръчна, за какво се използват инструментите и как се валидират констатациите?
3. Колко различни роли ще бъдат задействани и тества ли се хоризонталният контрол на достъпа наред с вертикалния?
4. Ще се покрие ли цялото приложение или извадка и как ще ни бъде съобщено какво не е било достигнато?
5. Може ли да прочетем цял анонимизиран отчет, преди да решим?
6. Ще включва ли всяка констатация стъпки за възпроизвеждане, използвания акаунт и записани доказателства?
7. Включен ли е повторен тест в тази цена? Кои констатации покрива, в какъв прозорец и какъв документ получаваме?
8. Ако намерите нещо критично по средата на теста, с кого се свързвате, колко бързо и какво следва?
9. Включен ли е технически разговор по резултатите с тестерите и могат ли разработчиците ни да ги питат по време на отстраняването?
10. Къде се съхраняват данните ни, кой може да ги достига, кога се унищожават и възлага ли се някоя част от този ангажимент на подизпълнител?
11. Ще подпишете ли нашето NDA и споразумение за обработка на данни, преди да споделим подробности за обхвата?
12. Какво е извън обхвата, какво допускате за нашата среда и какво се случва, ако приложението се окаже по-голямо от определеното?
13. Можете ли да опишете една констатация от минал ангажимент, която скенер не би могъл да произведе?
14. Какво би ви накарало да ни кажете, че този ангажимент е грешното нещо за купуване?

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

След като изберете

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

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

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

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

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

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

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