Журнал "Information Security/ Информационная безопасность" #3, 2024

Цели пентеста на стороне заказчика Некоторые компании создают свои внутренние команды для проведения тестов на проникновение, или команды red team, но большинство покупают услу- ги по проведению пентестов у внешних подрядчиков. Оба варианта подразумевают прове- дение имитации атаки с максимальным покрытием на информационные системы заказчика, чтобы определить уровень защиты компании, а также имеющиеся уязвимости. Обычно для этих целей пре- доставляется максимальная свобода действий "белому" пентестеру, так как нет какого-то определенного "кодекса" хакера, который будет ограничивать выбранные векторы атаки. Но мы знаем, что любая команда все равно ограничена в ресурсах и вынуждена применять инструментарий, который с профессио- нальной точки зрения способен дать нужный эффект наиболее оперативно. Сложности ручного пентеста На рынке информационной безопас- ности за несколько десятков лет, по мере его развития, появилось много разных компаний и специалистов, кото- рые вполне успешно и профессионально оказывают услуги по проведению тестов на проникновение. Но, как обычно, есть нюансы: у собственных специалистов компании может быть высокая загрузка, не до конца отлаженные внутренние рабочие процессы и т.д., а при обраще- нии ко внешним исполнителям нельзя до конца быть уверенными в квалифи- кации команды, кроме того есть обяза- тельные циклы согласования ПЗ, КП, ТЗ, договора, закупки, приемки работ и прочие действия. Это все требует боль- шого количества времени, из-за чего пентест возможно выполнить не чаще 1–2 раз за год. Продолжая мысль о внешних специалистах: они могут полу- чить (и наверняка получат) чувствитель- ную информацию, нежелательную для распространения, неаккуратное обра- щение с которой (или злой умысел) могут привести к утечке и неблагопри- ятным последствиям для заказчика. Еще одной проблемой является то, что заказчик перед выполнением работ не имеет представления о методах и техниках, которые будет применять внешняя команда пентестеров, и не может влиять на набор таких методов. В результате в итоговом отчете о про- веденном пентесте заказчик может и не увидеть описание части методик, кото- рые, например, не привели к получению какого-либо результата при выполнении работ. А эта информация является важ- ной, потому что показывает заказчику, от каких методов та часть его инфра- структуры, в которой проводились рабо- ты, защищена, и, соответственно, не позволяет ему самому проверить эти же методы в других частях инфраструк- туры. В силу различных ограничений не все технические средства и методики доступ- ны для реализации на стороне пенте- стеров, что вынуждает команду исполь- зовать наиболее вероятные с точки зре- ния успешной реализации инструменты для проведения успешной атаки. Но все желаемые и вероятные варианты реа- лизовать не получится. В лучшем случае это будет десятая часть из всех возмож- ных, а успешная реализация взлома часто приводит к тому, что остальные варианты уже не рассматриваются. Потенциальный злоумышленник не имеет большого количества ограничений и может успешно провести атаку с нескольких векторов, непроверенные способы ее исполнения останутся за скобками. Сроки и ограничения по трудозатратам приводят к тому, что проверками в рам- ках теста покрывается только часть инфраструктуры. Даже на первичном этапе внутреннего сканирования затра- гивается обычно только небольшая часть машин, а дальше атака в рамках теста распространяется только по некоторому участку инфраструктуры. Ни одна коман- да не сможет покрыть тестами большую часть машин в крупной сети, в которой может насчитываться несколько тысяч или даже десятков тысяч узлов. Один из вариантов выхода из этой ситуации – заказывать работы, которые включают в себя выполнение тестов одновременно в разных сегментах сети. Но такие рабо- ты будут стоить значительно дороже. После окончания теста на проникно- вение исполнитель готовит отчет с опи- санием выявленных уязвимостей и несо- ответствий, а заказчик запускает про- цесс исправления выявленных недостат- ков. Но как проверить потом, что дей- ствительно ВСЕ недостатки исправлены? В большинстве случаев такие проверки откладываются до следующего запла- нированного теста. И во многих случаях выясняется, что не все было корректно исправлено. К сожалению, оперативно проверить качество устранения недо- статков практически невозможно. В результате – оценка защищенности только раз в полгода или год, по ограни- ченному набору векторов атак и только для части инфраструктуры. Индивидуальный подход или стандартные практики? На практике многие действия зло- умышленников хорошо изучены и в основе своей не сильно меняются, поэто- му пентестеры знают множество вариа- ций стандартных сценариев проведения атаки на объект и, исходя из своей практики, делают проверку устойчивости компании именно к данным типам взло- ма. Пишутся и исполняются рутинные пошаговые скрипты для исполнения дей- ствий возможного нарушителя, прове- ряются известные методики проникно- 60 • ТЕХНОЛОГИИ Зачем автоматизировать пентест есты на проникновение стали неотъемлемой частью работ по оценке защищенности информационных систем. Многие компании осознают, что такой тест является одним из наиболее действенных способов проверить инфраструктуру и подготовиться к возможным киберугрозам. Т Максим Пятаков, заместитель генерального директора/сооснователь CtrlHack Виктор Сердюк, генеральный директор АО “ДиалогНаука” Фото: CtrlHack Фото: ДиалогНаука