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

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

Структурата на доклада

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

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

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

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

Четене на резюмето за ръководството като нетехнически читател

Ако четете резюмето, за да вземете решение, а не да поправяте нещо, искате четири неща и нито едно от тях не е число.

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

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

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

Какво се е променило от последния път. При повторен ангажимент сравнението има по-голямо значение от абсолютната картина. Появяват ли се същите първопричини отново в нов код? Това е констатация за процеса и няма да е в таблицата с констатациите.

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

Какво означават оценките на критичността и защо CVSS е информативен, а не решаващ

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

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

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

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

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

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

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

Разликата между тест за проникване и сканиране с титулна страница се вижда в самите констатации. Минете през вписванията и питайте какво е демонстрирал авторът; действителната констатация има четири свойства.

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

Още три признака. Констатациите само по версия — „компонент X е на версия Y, засегнат от CVE-Z“ — са кандидати, не заключения: текстовете на версиите често са погрешни, обратно пренесените кръпки са чести, а уязвимият път може да не е достижим във вашата конфигурация. Законни като наблюдение за обновяване; не доказателство за използваемост, освен ако тестерът не го е потвърдил, а добрият отчет разграничава двете. Преувеличаване на критичността на точки за добра практика: липсваща заглавка или бисквитка без флаг си заслужава да бъде отчетена, но отчетена като висока е запълване. И записаните опровержения, силен положителен сигнал — „опитахме да заобиколим филтъра за клиентски организации по тези три маршрута; всички бяха наложени правилно“ е увереност и показва, че тестерът е знаел какво да опита.

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

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

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

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

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

Работете в този ред.

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

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

Трето, заемете се с веригите. Установете всеки многостъпков път, прекъснете най-евтиното звено незабавно, после поправете останалите звена по нормален график.

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

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

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

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

ПРЕДИ КОНСТАТАЦИИТЕ
[ ] Какво е било в обхвата, актив по актив
[ ] Какъв достъп е имал тестерът (роли, данни за достъп, източник, документи)
[ ] Какво според отчета НЕ е било тествано или не е било достигнато
[ ] Среда: производствена или тестова, и разликите
[ ] Темите, назовани в резюмето за ръководството
[ ] Най-лошият реалистичен изход, заявен в едно изречение
[ ] При повторен тест: кои първопричини са се появили отново

ЗА ВСЯКА КОНСТАТАЦИЯ ПРОВЕРЕТЕ
[ ] Специфична за нашата система: крайна точка, параметър, роля, обект
[ ] Демонстрира резултат, не само задействане
[ ] Въздействие, написано на нашия език, не „може да доведе до разкриване“
[ ] Поправката е приложима: какво да се промени и къде
[ ] Доказателството е пълно: цяла заявка и отговор, не изрязка
[ ] Проследимо: кой акаунт, роля и наемател е действал
[ ] Повторяемо: номерирани стъпки от обявено начално състояние
[ ] Констатациите за контрол на достъпа показват, че контролът Е ТРЯБВАЛО да блокира
[ ] Само по версия? Третирано като кандидат, не като заключение
[ ] Критичността обоснована от правата и действието, не от класа

ПРЕПОДРЕДЕТЕ СПОРЕД КОНТЕКСТА
[ ] Стойността на това, което всяка констатация излага
[ ] Достижимост: обърнато към интернет / с удостоверяване / привилегировано
[ ] Способност за навързване: кои ниски са звена в сериозен път
[ ] Веригите установени, с най-евтиното звено за прекъсване

ПОДРЕДЕТЕ РАБОТАТА
[ ] Пътищата до компрометиране на акаунт или данни първо
[ ] Ограничаване в същата седмица, където пълната поправка е бавна (записано като такова)
[ ] Групиране по първопричина, преди да бъде планирано каквото и да е
[ ] Прекъсване на най-евтиното звено във всяка верига
[ ] Групиране на останалите констатации по отговорник и внедряване
[ ] Приетите рискове записани, с отговорник и дата за преглед
[ ] Задачи в нормалната инженерна система, с номера на констатациите

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

ПАЗЕТЕ ЗАЕДНО ЗА ОДИТ И КЛИЕНТИ
[ ] Отчета
[ ] Потвърждението от повторния тест
[ ] Решенията за приемане на риск, с дати и отговорници
[ ] Бележката какво не е било тествано

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

Повторният тест превръща отчета в промяна на позицията ви по сигурността. Докато той не се случи, имате списък от неща, за които вярвате, че сте поправили.

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

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

Въпроси за разговора по резултатите

Разговорът по резултатите е мястото, където получавате това, което не се вписва в документ.

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

Последните три рядко се задават, а „коя констатация е най-вероятно да поправим погрешно“ в частност спестява един провален повторен тест.

Използване на отчета с одитор или клиент

Запазете отчета: вашият одитор и проверяващите сигурността на клиентите ви ще го поискат, а двете страни го четат различно от вашите инженери.

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

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

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

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