Пентесты

Руслан Рахметов, Security Vision

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

Если такой инцидент произойдет достаточно быстро и в нерабочее время, то у хакеров будут высоки шансы на успех. Данный пример достаточно наглядный, но не самый пугающий: есть примеры, когда вредоносным ПО были заражены прошивки различных устройств, подключенных к корпоративной сети, которые в определенный момент начинали выполнять деструктивные действия или предоставляли атакующим доступ в сеть - в подобной ситуации установить причину инцидента становится значительно сложнее. Учитывая вышесказанное, в ИБ-сообществе сформировался принцип "Assumed Breach", который означает «Считайте, что вас уже взломали» - это означает, что никто не может и не должен быть на 100% уверен в безопасности защищаемой инфраструктуры, и всегда следует допускать наличие спящей угрозы, которую только предстоит выявить.

С учетом высказанного, при построении СУИБ важно переходить от реактивной, пост-инцидентной кибербезопасности, когда на инцидент реагируют только после наступления последствий, к проактивному выявлению инцидентов в целях поиска и устранения скрытых киберугроз. Такой переход можно начать с помощью внедрения процессов аналитики киберугроз (англ. Cyber Threat Intelligence) - проактивного поиска вредоносных или подозрительных действий в информационной инфраструктуре, которые не удалось выявить стандартными способами. Аналитика киберугроз, или киберразведка, базируется на анализе индикаторов компрометации (сокращенно IoC, от Indicator of Compromise) - объектов или артефактов, наличие которых с высокой долей вероятности может свидетельствовать о готовящейся, совершающейся или уже осуществленной компьютерной атаке. Классическими примерами IoC будут IP-адреса, домены, URL, значения хэш-сумм – однако, все эти признаки легко модифицируются атакующими для каждой новой атаки, поэтому они достаточно быстро устаревают и не всегда надежны.

Еще один способ работы с данными киберразведки - это анализ индикаторов атак (сокращенно IoA, от Indicator of Attack), которые представляют из себя последовательность действий и шагов, а также набор тактик, техник и процедур атакующих (сокращенно TTPs, от Tactics, Techniques, Procedures). Примеры IoA: запуск утилит и команд в определенной последовательности, необычное поведение учетных записей (создание, включение в высокопривилегированные группы с последующим удалением), изменение характера сетевой активности устройств (резкий рост ICMP или DNS трафика, например). Однако, для наиболее качественного выявления скрытых киберинцидентов следует внедрять процесс непрерывного поиска киберугроз (англ. Cyber Threat Hunting) - т.е. поиска угроз внутри сети с анализом потенциальных признаков заражений, поиском следов активности киберпреступных групп, поиском признаков заражений, анализом сообщений на профильных ИБ-ресурсах и в киберпреступной среде (на форумах, в соцсетях и мессенджерах).

При проведении поиска киберугроз (т.е. процесса Threat Hunting) аналитики формируют определенные гипотезы - предположения о вероятной вредоносной активности, действиях атакующих, вероятных артефактах, индикаторах компрометации и индикаторах атак, которые следует искать в инфраструктуре. Иными словами, поиск киберугроз - это целенаправленное выполнение разработанного плана по выявлению скрытой вредоносной активности и действий атакующих в инфраструктуре. При этом процесс Threat Hunting должен проводиться непрерывно, в соответствии с разработанными гипотезами и планами обнаружения скрытых угроз - это значит, что поиск киберугроз не может иметь хаотичный или спорадический характер, когда ИБ-аналитики лишь время от времени проверяют, нет ли в зафиксированных ранее событиях ИБ признаков каких-то незамеченных киберинцидентов.

При внедрении процесса поиска киберугроз в компании важно разработать политику Threat Hunting, в которую следует включить правила разработки и документирования гипотез (например, на основе регулярного анализа обновлений матрицы MITRE ATT&CK ответственный формирует вероятные новые способы атак и релевантные TTPs атакующих, которые будут проверяться), порядок формирования плана поиска признаков не обнаруженных иными способами атак, плана выполнения действий при успешном подтверждении разработанной гипотезы, способы улучшения процесса поиска киберугроз при завершении очередной проверки гипотезы, способы передачи полученных знаний и предложений по повышению уровня защищенности компании заинтересованным лицам. В документе также следует перечислить необходимые ресурсы (персонал, инструменты, инфраструктура) для выполнения процесса поиска киберугроз, определить ожидаемые результаты и формы отчетности, способы передачи обнаруженных угроз команде реагирования, закрепить полномочия ответственных и исполнителей, а затем согласовать разработанную политику у руководителя структурного подразделения. Важно иметь в виду, что поиск киберугроз не может заменить общий процесс управления киберинцидентами, однако может послужить хорошим к нему дополнением, давая возможность закрыть «белые пятна» при выявлении инцидентов ИБ. Кроме того, для успешной реализации процесса Threat Hunting требуется глубокое понимание бизнес-процессов компании для достоверного обнаружения аномалий и отклонений в нормальном поведении систем и пользователей, взаимодействие с ИТ и ИБ-департаментом или SOC-центром для обмена знаниями, опытом, инструментами и полученной информацией, а также проведение регулярного анализа обработанных инцидентов ИБ, релевантных данных киберразведки, информации из матрицы MITRE ATT&CK и других источников об актуальных TTPs хакеров. В заключении отметим, что процесс поиска киберугроз является достаточно сложным и дорогостоящим и может оправдать вложения в него и принести существенную пользу тем компаниям, у которых высока зрелость других процессов ИБ - в противном случае больше пользы принесут инвестиции в повышение базового уровня киберзащищенности компании.

Одним из таких базовых, фундаментальных процессов кибербезопасности является проведение аудитов ИБ. Аудит ИБ - это проверка состояния элементов системы управления информационной безопасностью в компании. Фактически, аудит ИБ - это анализ того, насколько реальное состояния кибербезопасности соответствует внутренним нормативным документам по ИБ и лучшим практикам, стандартам, законодательным требованиям в области защиты информации. Аудит ИБ может быть внутренним и внешним: внутренний аудит проводится силами департамента ИБ самостоятельно, представляя из себя по сути самопроверку, а внешний аудит проводится силами подрядной организации, которая в определенных случаях должна обладать соответствующей лицензией российских регуляторов. Аудит ИБ на соответствие внутренним нормативным документам в области кибербезопасности может проводиться с определенной согласованной периодичностью, а также внепланово - например, по решению руководителя компании или внутренней контрольно-ревизионной службы, при расследовании крупного киберинцидента, при назначении нового руководителя ИБ-функции.

При проведении аудитов важно определиться с нормативным обеспечением - это может быть политика компании в области проведения аудитов ИБ, в которой прописаны цели, порядок проведения аудита, роли и обязанности ответственных, формы отчетности, методы устранения выявленных недостатков и способы обработки полученных результатов для улучшения СУИБ в компании. Важно проводить плановые внутренние аудиты по сформированному плану, в котором могут быть прописаны основные аспекты работ: проверка основных внутренних нормативных документов по ИБ (политики, регламенты, инструкции), проверка реализации задокументированных положений на практике (настройки и результаты работы СЗИ, инфраструктурных компонентов), анализ отчетности (отчеты по закрытым инцидентам ИБ, перечень проведенных проверок и тренингов, отчеты по показателям работы ИБ-департамента). В качестве формы проверки могут использоваться чек-листы с перечнем вопросов, на которые ответственные дают исчерпывающие ответы, подкрепляя их отчетами и выгрузками из ИБ-систем. В случае проведения аудитов на соответствие применимым требованиям проверку проводит, как правило, внешняя организация - это требуется, например, для получения сертификата соответствия требованиям стандарта PCI DSS или стандартов серии ISO 27000, а также для понимания топ-менеджментом того, насколько компания соответствует законодательству в области защиты информации. В случае проведения добровольных (необязательных) аудитов ИБ проверяющие могут дополнительно выдавать технические рекомендации по устранению выявленных недостатков, которые целесообразно оперативно отрабатывать и затем повторять проверку. В целом, можно заключить, что аудит ИБ - это проверка состояния ИБ компании в лабораторных, «тепличных» условиях: проверяются организационно-распорядительные документы, настройки СЗИ, отчеты о выполненных работах, закрытых инцидентах и устраненных киберугрозах, а также качество работы департамента ИБ.

Для того, чтобы выполнить проверку состояния ИБ компании в реальных, «боевых» условиях, можно воспользоваться услугой проведения тестирования на проникновение (пентест, от английского penetration test, сокращенно pentest). Пентесты проводятся независимыми ИБ-экспертами (пентестерами), которые имитируют действия атакующих для обнаружения слабых мест в киберзащите компании. По сути, пентест - это проведение контролируемой кибератаки с целью повышения общего уровня защищенности компании. Пентесты проводятся методами черного, серого и белого ящиков:

• Black-box пентест означает, что пентестеры предварительно получают минимальные знания о тестируемой компании и не имеют никаких привилегий в тестируемой инфраструктуре - такой пентест максимально приближен к реальной жизни, в которой атакующие получают всю информацию о целевой атакуемой компании из открытых источников;

• Gray-box пентест означает, что пентестеры заранее получают ограниченную информацию о проверяемой инфраструктуре, которая дает им ограниченное представление о возможных способах атаки;

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

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

При проведении пентеста важно поставить в известность руководителей профильных департаментов компании и нескольких ключевых сотрудников, которые не должны разглашать информацию о проведении тестирования для повышения правдоподобности пентеста. Также следует договориться о рамках и границах тестирования: например, что данные не будут уничтожаться, а сервисы и оборудование не будут перезагружаться и подвергаться избыточной нагрузке. Важно также предусмотреть модель коммуникации между командой пентестеров, их менеджером и ответственным за пентест со стороны проверяемой компании - при возникновении ситуации, потенциально опасной для деятельности компании, важно вовремя приостановить тестирование и провести проверку работы сервисов компании. Одновременно следует следить за реакцией команды реагирования на инциденты - при «слепом» пентесте, когда ИБ-департамент компании не уведомлен о его проведении, команда реагирования или SOC-центр должны своевременно выявить пентест и остановить имитируемую атаку.

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