Пентест как проект с высокой ценой ошибки
За время своей работы я видела десятки пентестов, которые технически были выполнены просто безупречно: обнаружены критические уязвимости, подготовлен полноценный технический отчет, выданы исчерпывающие рекомендации по повышению уровня безопасности компании. Но почему-то все равно оставались вопросы и недовольство как со стороны команды, так и со стороны заказчика.
Зачастую проблема заключалась не в технической экспертизе, а в управлении. Именно поэтому я хотела бы поговорить о пентестах не как о технической услуге, а как о проектах с высокой ценой ошибки.
Чтобы говорить предметно, зафиксируем контекст. Пентест – это практически всегда работа с живой инфраструктурой, с боевыми системами. Это реальные бизнес-процессы, реальные сервисы, реальные пользователи. В таких проектах, как правило, присутствует много различных стейкхолдеров, у которых могут различаться конечные цели проводимого пентеста. Могут существовать различные организационные, технические и регуляторные ограничения.
В отличие от других ИТ-проектов, проекты по пентестам отличаются тем, что здесь ошибка может проявиться довольно быстро и сразу – в виде простоя, инцидента или просто неприятного разговора с заказчиком. Поэтому относиться к ним формально не стоит. В проектах по пентестам цена ошибки действительно достаточно велика.
Те, кто работает с подобными проектами, наверняка сталкивались с ситуациями, когда возникали вопросы или звучали фразы: «А мы думали, вы этот сервис трогать не будете. А у нас здесь что-то упало и что-то не работает».
В такие моменты, как правило, начинают искать виноватых: инструменты, подрядчиков, людей. Но если копнуть глубже, выясняется, что не было зафиксированных договоренностей, отсутствовало управление проектом, и каждый участник происходящего трактовал свои задачи по-своему.
Рассмотрим, на каких этапах проектов по пентестам возникают ключевые проблемы и как с ними можно работать.
Блок 1. Правильная инициация
Зачастую проекты по пентестам начинаются с довольно размытых целей и совершенно не зафиксированных границ работ. По факту же они должны начинаться с понимания и определения того, зачем мы проводим тестирование, каковы допустимые границы наших действий, какие риски приемлемы и чего мы должны однозначно избежать.
Если на старте проекта этот разговор не состоится, то это неизбежно приведет к различным проблемам в коммуникации и ошибкам в управлении проектом.
Скоуп работ, или границы проведения работ, – это не формальность и не ограничение свободы команды проекта. Это действительно некий предохранитель, который позволяет зафиксировать границы допустимых действий, задать понятные ожидания для команды и снизить риски для бизнеса.
В моей практике большинство больших проблем или конфликтных ситуаций при проведении пентестов было связано именно с размытыми границами работ. Если зафиксировать их на старте, это позволит избежать различных проблем в будущем.
Еще один критически важный момент – приемлемые риски. О них важно договориться заранее: когда мы должны остановить работы, кто должен принять это решение, каков порядок действий при инцидентах, кого и в каком формате необходимо проинформировать. Обсуждать все эти вопросы уже после инцидента абсолютно бессмысленно, бесполезно, а иногда даже болезненно.
Поэтому успех или провал пентеста может быть определен еще до его начала. Но важно понимать, что даже зафиксированные цели и четко определенный скоуп проекта – не гарантия того, что все пройдет так, как нужно.
Далее начинается этап непосредственной реализации проекта, когда весь набор договоренностей, сформированный на старте, перерастает в живой проект. Возникают вопросы: кто будет принимать решения, кто будет согласовывать изменения, и кто будет отвечать за все происходящее в проекте?
Блок 2. Роли и ответственность
Пентест – это межфункциональный проект. В него могут быть вовлечены различные подразделения и службы заказчика – даже больше, чем может показаться на старте.
Помимо команды пентестеров, в проекте могут участвовать ИБ- и ИТ-подразделения, службы эксплуатации, представители бизнеса-заказчика и сами сотрудники, если речь идет о тестировании методами социальной инженерии.
Здесь критически важно определить и распределить роли и зоны ответственности, чтобы ликвидировать хаос и дать людям понимание того, что они сохраняют контроль над ситуацией, а проект остается управляемым.
Нужно определить, кто принимает различные решения, кто организует и выдает доступы, кто будет согласовывать изменения и отвечать за эскалацию в случае возникновения инцидентов.
В условиях такого межфункционального взаимодействия нельзя не отметить коммуникации, которые тоже становятся точкой риска. Чтобы нивелировать различные проблемные ситуации, необходимо определить единый канал связи для всех участников проекта, критичность событий, форматы экстренных уведомлений, SLA на реакцию и контакты ответственных лиц. Важно заранее понимать, какие события означают, что действительно произошел инцидент, а какие не требуют дополнительного внимания.
Без четкого распределения ролей и зон ответственности пентест становится хаотичным. Если же все эти моменты проговорены, согласованы и зафиксированы, пентест становится инструментом, позволяющим сохранять управляемость проекта, особенно в условиях повышенных рисков.
Блок 3. Риски и изменения
Пентест по своей природе связан с повышенным уровнем неопределенности. Риски могут быть связаны с нарушением бизнес-процессов, выходом за пределы границ работ или различными репутационными последствиями.
Часть рисков действительно можно определить на старте проекта, постараться их проанализировать и выработать различные стратегии того, как их избежать или снизить степень их влияния. Но полностью исключить риски не удастся, потому что большая часть из них проявляется уже в процессе проведения работ.
Почему так происходит? В процессе тестирования могут обнаруживаться новые векторы атак и точки входа, могут уточняться границы инфраструктуры. Могут меняться приоритеты заказчика или вводиться новые ограничения.
Все эти изменения – не отклонение от нормы, а рабочая действительность большого, сложного, многофункционального проекта. Ее нужно принимать во внимание и уметь с ней работать.
Для управления подобными изменениями потребуется понятный для всех механизм их фиксации. Нужно оценивать влияние изменений на риски проекта, сроки и договоренности. Необходимо определить понятный порядок действий, механизм эскалации или информирования ответственных лиц, а также порядок корректировки планов работ и согласования изменений.
Когда процедура становится прозрачной для всех участников и всех сторон, удается сохранять управляемость проекта даже в условиях некоторого хаоса или в ситуациях, когда все идет не по плану.
Риски и изменения в пентесте неизбежны. Задача менеджера или проектного менеджера – не ликвидировать их полностью, а сделать прогнозируемыми и контролируемыми.
Блок 4. Ограничения и особенности Заказчика
Еще один важный момент, который многие недооценивают, – ограничения и особенности самого заказчика. Это не помеха, а входные условия для рабочей группы проекта.
У заказчика могут существовать различные технические, регуляторные или организационные ограничения. Их нельзя игнорировать, их нужно интегрировать в проект.
Для начала эти требования необходимо определить и зафиксировать на старте, а затем учитывать в плане-графике активностей. Нужно проверить реализуемость этих требований и понять, насколько команда способна удовлетворить пожелания заказчика. Необходимо отслеживать и адаптировать технические методологии с учетом ограничений проекта.
Важно понимать, что это данные, с которыми нужно иметь дело. Их необходимо принять как факт, зафиксировать на старте проекта и учитывать в планах работ.
Я как практик всегда ратую за то, что теория – это хорошо. Можно пройти множество обучений, курсов и так далее. Но мне всегда интересно, как все это работает на практике, поскольку я в том числе руковожу проектами по пентестам, включая зарубежные проекты.
Поэтому далее речь пойдет о реальных кейсах, с которыми мне приходилось сталкиваться в ходе своей деятельности. Нас будут интересовать не технические детали и подробности, а риски, которые реализовались, решения, которые были приняты или, наоборот, не были приняты, и последствия этих решений.
Блок 5. Реальные кейсы
Кейс 1. Бигтех. Сбой в коммуникации
Первый кейс связан с проведением пентеста в большой высокотехнологичной компании с довольно высокой скоростью внутренних бизнес-процессов.
Мы провели внутреннее совещание совместно с командой заказчика и командой пентестеров, выполнявших работы. Договорились, что в случае обнаружения критических уязвимостей команда должна немедленно и оперативно проинформировать заказчика через согласованный канал связи.
Так и произошло: команда обнаружила критическую уязвимость, но почему-то решила провести дополнительную перепроверку и подготовить доказательную базу.
Решение довольно сомнительное, хотя в какой-то степени логичное, потому что команда хотела перепроверить себя и обезопасить. Но с точки зрения заказчика была нарушена договоренность об оперативном информировании о выявленной уязвимости.
В результате технически команда сработала на отлично. Мы вроде бы сделали свою работу прекрасно, но по факту заказчик остался недоволен, и мы получили большую негативную обратную связь, потому что нарушили договоренность и тем самым подорвали его доверие.
Этот кейс – хороший пример того, что скорость коммуникации и соблюдение всех правил, которые были согласованы и зафиксированы на старте проекта, гораздо важнее формулировок и технических деталей, когда речь идет о соблюдении понятных для всех договоренностей.
Кейс 2. Промышленное предприятие (ТЭЦ). Кризис доверия в момент инцидента
Второй кейс связан с проведением пентеста на промышленном объекте, на котором присутствовали элементы энергетической инфраструктуры. Все работы проводились в согласованные окна и в рамках строго ограниченного перечня работ. И остановилась турбина.
Ситуация была довольно критической и серьезной: высокое давление, высокий уровень ответственности. Тут же собрали оперативное совещание и начали проводить расследование, потому что первая гипотеза заключалась в том, что причиной остановки турбины стали действия пентестеров.
Но поскольку все работы велись строго в согласованном скоупе, проводилось логирование и была определена понятная схема реагирования, довольно быстро удалось выяснить, что действия пентестеров здесь ни при чем и остановка турбины никак не связана с проводимым пентестом.
При работе с критической инфраструктурой важно не только ничего не сломать со стороны заказчика, но и защищать пентест управленческой рамкой – так же, как и бизнес от пентеста. Как показывает практика, случаи бывают разные.
Кейс 3. Финтех. Управляемое расширение скоупа
Третий кейс связан с компанией из сферы финтеха, в которой мы проводили пентест. В процессе работ выяснилось, что существует потенциальная критическая уязвимость за пределами скоупа проекта.
Те, кто имеет дело с проектами такого рода, знают, что пентестеры – довольно увлекающиеся люди. Их сложно остановить, когда они хотят посмотреть шире, глубже или куда-то еще залезть.
Здесь был великий соблазн пойти дальше и не согласовывать расширение работ с заказчиком. Но конкретно в этом случае мы все-таки подготовили доказательную базу, представили ее заказчику, подсветили потенциальные риски, и заказчик согласовал расширение скоупа.
В результате мы действительно обнаружили критическую уязвимость. Это хороший пример того, как мы принесли реальную пользу бизнесу заказчика, сохранили его лояльность и доверие и показали высокий уровень оказываемых услуг.
В то же время у меня есть абсолютно противоположный пример, когда расширение скоупа работ не было согласовано с представителями бизнеса-заказчика. Мы обнаружили критическую уязвимость и, счастливые и довольные, побежали рассказывать заказчику о том, какие мы молодцы. Но заказчик остался недоволен.
Ресурсы, на которых мы обнаружили уязвимость, не входили в перечень работ, согласованный и установленный на старте проекта. Для заказчика это означало несоблюдение наших договоренностей.
Поэтому нужно понимать, что инициатива возможна и действительно может принести ценность и пользу бизнесу, но только в том случае, если она проходит через понятную для всех процедуру согласования изменений.
Кейс 4. Госучреждение. Адаптация к регуляторным ограничениям
Последний кейс связан с проведением пентеста в государственном учреждении, где в процессе работ был введен временный мораторий на проведение некоторых активностей.
Мы не стали прекращать все работы в полном объеме. Вместо этого организовали оперативное обсуждение видов активности, которые могли продолжить, и тех работ, на проведение которых в тот момент у нас не было полномочий. После этого мы полностью скорректировали план-график работ.
В результате мы смогли сохранить договорные сроки и лояльность заказчика, потому что пошли ему навстречу и учли особенности, возникшие в процессе проведения работ.
Это хороший пример того, как гибкость позволяет быстро адаптироваться к изменениям и интегрировать их в проект.
Резюме
Все эти кейсы объединяет не общая отрасль – компании относятся к совершенно разным сферам. Не масштаб инфраструктуры – он тоже различается от случая к случаю. И не уровень технической сложности проводимых работ. Во всех этих кейсах решающим фактором в критические моменты стало именно управление.
Это хороший стресс-тест, позволяющий понять, насколько зрелыми являются управленческие процессы в компании, оценить способность соблюдать договоренности и управлять проектом, особенно когда цена ошибки слишком велика.
Завершить статью хочется такой мыслью: пентест без катастроф выполним. Наша миссия выполнима, но только в том случае, если пентест не просто проводят, а им действительно управляют.
Если вынести из статьи одну вещь, то это будет чек-лист здорового пентеста – не безрискового, не идеального, а управляемого.
Это пентест, в котором определены и четко зафиксированы цели работ, а все участники проекта понимают, зачем проводится тестирование. Понятны границы допустимого и недопустимого. Зафиксированы и определены роли и зоны ответственности всех участников проекта. Формализованы и выстроены рабочие коммуникации. Риски проработаны на старте проекта, а изменения согласуются в процессе управления проектом.
Тогда пентест может стать действительно хорошим инструментом для повышения эффективности, зрелости и качества внутренних процессов компании.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт