Собесы в пентест

Пора разобрать самую популярную тему, связанную с менеджментом, а именно - собесы. Собеседование кандидата является очень стрессовым событием как для собеседуемого, так и для менеджера. Важно уметь заинтересовать друг друга и не упасть в грязь лицом. “Что же происходит на таких собесах? Как подготовиться? Как себя вести на собеседованиях? Что спрашивать?” - все эти постоянно возникают в голове всех участников собеседований. Что ж, давайте разберем по частям написанное.

Первое, о чем стоит помнить: если вы дошли до этапа технического общения, то можете смело радоваться, ведь тест на адекватность вы уже прошли🙂 Тем не менее, нанимающие менеджеры хотят сперва как можно лучше узнать кандидата: его опыт, мотивацию, что побудило менять работу, в каких сферах он хочет развиваться. Часто просят рассказать какой-то факт с прошлого, которым вы гордитесь. Часто ожидают услышать какой-то интересный чейн атак, поиск 0-day уязвимостей, может методов защиты от каких-то баг - тут все зависит от вашего бэкграунда.

После первого знакомства начинаются уже технические вопросы. Тут все зависит от ваших грейдов. Для удобства я разделю людей на 2 группы: стажер/джун/мидл и мидл/ сеньор. Может возникнуть резонный вопрос, а почему так? На мой взгляд, первая категория похожа и зависит от глубины знаний и опыта. Во второй категории появляются уже навыки тимлида либо ну очень глубокое погружение.

Стажер/Джун/Мидл

На стартовые позиции приходит много кандидатов, ведь бытует уверенность, что стажером может стать кто угодно, ведь на работе научат всему. Я считаю, что это утверждение в корне неверно. Кандидат на начальные позиции в пентесте должен понимать теоретическую базу, понимать смысл уязвимостей и иметь какой-никакой практический опыт эксплуатации, например, решение лабораторных работ или же участие в CTF соревнованиях.

Так что же стоит спрашивать по теории у данной категории? Я предпочитаю проводить проверку по следующим темам:

• понимание работы основных протоколов какие атаки на них возможны
• знание различных особенностей и векторов атак на различное ПО. Например, чем опасен доступ от рута в PostgreSQL или что делать, если видим redis без авторизации.
• какие атаки(не веб) в принципе есть? Например, что такое брут или спуфинг.

Ну и, конечно же, куда без проверок на веб. Здесь спрашивают различные баги клиента(xss/csrf) и сервера (rce/sqli) и так далее. Довольно сложно как-то конкретно сказать, что и на какую должность кандидат обязан знать, но по глубине ответа в целом понятен уровень специалиста. Например, на вопрос о способах вытаскивания данных из php файла через ххе начинающий вспомнит только 1 способ (допустим, использование php фильтров), а вот мидл уже должен уметь это делать, при условии, что фильтры выключены. Поскольку веб - основа практически любого проекта (даже мобилки, по факту, это веб, просто с другим клиентом), то глубокие познания данной тематики будут иметь решающую роль при собесе на любую позицию.

Мидл/Сеньор

При собеседовании кандидатов на данные позиции процесс идет куда сложнее. Как правило, нет смысла спрашивать какую-либо теоретическую основу, так как кандидаты, очевидно, это знают. На мой взгляд, есть два подхода к собеседованию скилловых ребят: задавать очень глубокие вопросы по механике работы уязвимостей/средств защиты(и способов их обхода)/ред тиму либо же проводить кейс-интервью. Последний метод позволяет оценить, как кандидат мыслит, понимает ли архитектуру и принципы взаимодействия различных компонентов. Хорошим примером кейса может служить, например, следующая задача “У нас есть функциональность загрузки картинки по урлу. Какие ты видишь риски, как бы ты защитился от них? В том числе и архитектурно”. Хороший специалист будет рассуждать о том, какие есть баги веба, что делать, если было пробитие, и, конечно, о методах защиты такой функциональности. Еще неплохо бы оценить софт скиллы, так как люди на таких позициях часто будут менторами на проектах для своих менее опытных коллег, поэтому стоит понимать, способен такой человек быть учителем или все же джунов стоит ставить с другими людьми.

Важно помнить, что люди на таких герйдах часто специализируются на чем-то одном, например, на тестировании Active Directory. В таких случаях необходимо четко понимать, нужны ли вам узкая специализация кандидата. Допустим, что у вас нет AD (если вы в инхаусе) или же нет проектов, где нужны такие компетенции (если вы в консалтинге), поэтому зачем вам такой специалист, если вы не сможете удовлетворить его потребности? Да, он может быть очень крутым и в других областях, но такой человек быстро выгорит и уйдет в другую компанию, чтобы делать интересные ему проекты.

Меня не взяли, я плохой специалист?

Ответ простой: не факт:) Часто бывают ситуации, когда компания не может позволить себе ваши финансовые ожидания, или же им не нужны ваши компетенции на текущий момент. Конечно, бывают ситуации, когда вы сами виноваты в своем провале: оказались не готовы к вопросам, переоценили свои силы, не смогли ответить на каверзные вопросы. Самое главное - не расстраиваться и не отчаиваться. Вы всегда можете подготовиться получше и попробовать еще раз, если не в эту компанию, так в другую. Помните, мест, где нужны специалисты по иб полно и вы всегда сможете найти то, что подойдет вам.