Как написать лучший отчет о пентесте

Все рекомен­дации будут касать­ся обыч­ного пен­теста, а не отче­та учас­тни­ков прог­раммы bug bounty.

Работа начинается с заявки

Раз­работ­ка отче­та о пен­тесте начина­ется одновре­мен­но с самим пен­тестом. Тес­тируя сис­темы, про­веряя свои гипоте­зы, мы уже собира­ем огромное количес­тво информа­ции. Неваж­но, каким инс­тру­мен­том ты поль­зуешь­ся — рекомен­дуемым во всех учеб­ных пособи­ях CherryTree, OneNote или Dradis, который отлично под­ходит для сов­мес­тной работы боль­шой коман­ды, — в любом слу­чае к кон­цу пен­теста он дол­жен напол­нить­ся боль­шой базой из скрин­шотов, час­тей логов, резуль­татами работы раз­личных команд и про­чим.

Ес­ли не сде­лать это­го еще на эта­пе про­веде­ния тес­та, тебе прос­то нечем будет напол­нять отчет. Зво­нить заказ­чику через неделю пос­ле завер­шения тес­та и про­сить запус­тить один из скрип­тов, что­бы сде­лать скрин­шоты, — вряд ли хорошая идея. Таким обра­зом, осно­ва хороше­го отче­та зак­ладыва­ется еще в про­цес­се тес­тирова­ния.

Структура отчета

От­чет мож­но раз­делить на два боль­ших бло­ка (не счи­тая всту­питель­ной час­ти и при­ложе­ний). Пер­вая часть — общее опи­сание про­делан­ной работы. Его луч­ше делать мак­сималь­но доход­чивым и не исполь­зовать слож­ную тер­миноло­гию, что­бы понять написан­ное мог человек, не име­ющий спе­циаль­ной под­готов­ки. Как пра­вило, эта часть пред­назна­чена для руково­дите­ля ком­пании‑заказ­чика, поэто­му она дол­жна давать общее пред­став­ление о про­делан­ной работе.

Вто­рая часть — это текст для тех­ничес­ких спе­циалис­тов, где при­водит­ся вся необ­ходимая информа­ция о най­ден­ных уяз­вимос­тях, а так­же о том, как их мож­но вос­про­извести. В иде­але дол­жны быть даны рекомен­дации и о том, как их устра­нить.

От­чет име­ет прос­тую струк­туру, одна­ко каж­дая из его час­тей обя­затель­на и име­ет свое пред­назна­чение. Ниже при­веде­на рекомен­дуемая нами схе­ма отче­та.

1 Всту­питель­ная часть
1.1 Клас­сифика­тор най­ден­ных уяз­вимос­тей
2. Общее опи­сание про­делан­ной работы
3. Тех­ничес­кий отчет
4. Рекомен­дации по устра­нению уяз­вимос­тей

Да­лее мы опи­шем тре­бова­ния к каж­дой из час­тей отче­та.

Вступительная часть

Во всту­питель­ной час­ти сто­ит ука­зать фак­ты, которые были извес­тны и тебе, и заказ­чику еще до начала работ. К ним отно­сят­ся: дата про­веде­ния пен­теста, методи­ка, которая при­меня­лась (очень крат­ко, не сто­ит перепи­сывать весь NIST 800-115 и руководс­тво OWASP), основные эта­пы тес­тирова­ния, перечень сис­тем для тес­тирова­ния и исклю­чения из объ­ема работ, перечень узлов, а так­же методи­ки, которые ты и твои кол­леги обя­зуетесь не при­менять, нап­ример соци­аль­ную инже­нерию или ата­ки на отказ в обслу­жива­нии. Об этом важ­но упо­мянуть в этой час­ти.

Классификатор уязвимостей

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

В зак­лючении всту­питель­ной час­ти мож­но опи­сать осо­бен­ности, о которых на эта­пе тех­нико‑ком­мерчес­кого пред­ложения ты не догова­ривал­ся с заказ­чиком, одна­ко которые ста­ли акту­аль­ными на эта­пе тес­тирова­ния. Нап­ример, заказ­чик поп­росил обра­тить осо­бое вни­мание на какой‑то новый сер­вис, который появил­ся за неделю до начала тес­тирова­ния, или, наобо­рот, в пос­ледний момент поп­росил исклю­чить из иссле­дова­ния веб‑при­ложе­ние, уяз­вимос­ти в котором наш­ли сво­ими силами бук­валь­но за день до начала работ и которое собира­ются капиталь­но дорабо­тать преж­де, чем вновь показы­вать поль­зовате­лям.

Общее описание проделанной работы

Этот раз­дел дол­жен содер­жать зна­чимую для руково­дите­лей ком­пании‑заказ­чика информа­цию о про­делан­ной работе и ее резуль­татах. Глав­ные тре­бова­ния, предъ­явля­емые к нему, — понят­ность и крат­кость. Сам отчет может рас­тянуть­ся на десят­ки, если не сот­ни стра­ниц. Руково­дитель не всег­да готов читать докумен­тацию такого объ­ема, и зачас­тую в этом нет необ­ходимос­ти. Глав­ное — понять кри­тичес­ки важ­ные резуль­таты для при­нятия даль­нейших решений. Наша задача в этом раз­деле — зав­ладеть вни­мани­ем читате­ля с любым уров­нем под­готов­ки, опи­сать общую ситу­ацию и сооб­щить о наибо­лее зна­чимых выводах.

Технический отчет

Это самый объ­емный раз­дел, и пред­назна­чен он в пер­вую оче­редь для тех­ничес­ких спе­циалис­тов. В нем мы, как инже­неры, объ­ясня­ем дру­гим тех­ничес­ким спе­циалис­там, что мы наш­ли при тес­тирова­нии и чем это может гро­зить.

В сво­ей работе мы пред­почита­ем сос­тавлять отчет в виде кар­точек по най­ден­ным уяз­вимос­тям. Такая кар­точка сос­тоит из сле­дующих раз­делов:

1. Крат­кое опи­сание най­ден­ного. Прос­то и дос­тупно опи­сыва­ем, что уда­лось най­ти, что прив­лекло наше вни­мание.
2. Уро­вень рис­ка. Прос­тавля­ем бал­лы по той шка­ле, о которой говори­лось ранее.
3. Ука­зание мес­тонахож­дения в сис­теме. Ука­зыва­ем IP-адрес, DNS-имя или что‑то, что однознач­но иден­тифици­рует сис­тему.
4. Опи­сание инс­тру­мен­тария. Это необя­затель­ный пункт, но он может очень помочь инже­нерам со сто­роны заказ­чика, ког­да они решат вос­про­извести твои дей­ствия.
5. Ссыл­ка на опи­сание уяз­вимос­ти. Что­бы чрез­мерно не уве­личи­вать раз­меры отче­та, рекомен­дуем сде­лать внеш­ние ссыл­ки на опи­сания уяз­вимос­тей из откры­тых баз зна­ний. Выб­рать мож­но любую, которая подой­дет под твои пот­ребнос­ти, нап­ример cve.mitre.org, cvedetails.com, snyk.io или rapid7.com.
6. Скрин­шоты и дру­гие под­твержде­ния. Скрин­шоты нуж­но добав­лять толь­ко при усло­вии, что они наг­лядно что‑то объ­ясня­ют.
7. Ре­комен­дации, как испра­вить уяз­вимость. В этом раз­деле нуж­но при­вес­ти рекомен­дации про­изво­дите­ля уяз­вимого прог­рам­мно­го обес­печения или свои собс­твен­ные. В любом слу­чае ответс­твен­ность за устра­нение уяз­вимос­тей лежит на заказ­чике и толь­ко ему решать, как они будут устра­нены и будут ли.

При­мер опи­сан­ной кар­точки — на рисун­ке.

Не забудь вклю­чить в тех­ничес­кий отчет и опре­деле­ние всех исполь­зуемых тер­минов и рас­шифров­ку аббре­виатур.

Заключение

В написа­нии отче­тов нет ничего слож­ного. Осо­бен­но ког­да перед гла­зами есть мно­го при­меров и понима­ние того, что в ито­ге дол­жно получить­ся. «Страх чис­того лис­та» про­ходит доволь­но быс­тро.

Все реаль­ные слож­ности дол­жны воз­никать толь­ко в про­цес­се тес­тирова­ния, поэто­му всег­да нуж­но оста­вать­ся про­фес­сиона­лом, быть в кон­такте с заказ­чиком и знать гра­ницы пен­теста. А если не уве­рен — не стес­нять­ся задавать воп­росы.

Тех­ничес­кий отчет, сос­тавлен­ный в соот­ветс­твии со все­ми перечис­ленны­ми рекомен­даци­ями, ста­нет руководс­твом, которое поможет сде­лать инфраструк­туру ком­пании безопас­нее.