«Война — это путь обмана»

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

 Архитектура

Архитектурно типовая реализация ханипота состоит из:

• сенсоров;
• ядра;
• управляющей консоли;
• внутреннего лог-сервера.

Сенсор — основной рабочий элемент ханипота, тот самый уязвимый хост. Сенсор может имитировать практически любой элемент ИТ-инфраструктуры: рабочую станцию с WinXP, необновленный Linux-сервер с открытым SMB, SCADA-систему, сетевое устройство или даже принтер с открытой консолью администратора и дефолтным паролем на SSH. Основная задача при проектировании и разработке сенсоров заключается в том, что необходимо добиться их аутентичности и органично вписать их в окружающую ИТ- инфраструктуру. Например, если это банк, hostname сенсора может быть kbr-test (имитация АРМ КБР, автоматизированного рабочего места клиента Банка России), но никак не arm_asu_sklad1.

Практические советы по проектированию сенсоров

1. Перечень активных сенсоров не должен храниться в открытом виде. Доступ к нему должен быть только из управляющей консоли для строго ограниченного круга лиц.

2. На каждом сенсоре должно быть включено максимально полное журналирование и обеспечено как локальное с достаточным запасом по глубине, так и передача логов в централизованное хранение.

3. Необходимо четко представлять эталонное поведение каждого типа сенсоров. По сути, на сенсоре должна быть создана замкнутая программная среда, нарушение которой и будет сигналом о событии ИБ.

4. С заданной периодичностью необходимо тестировать сетевой доступ как от сенсоров до управляющей консоли, так и от сенсоров к детектирующим СЗИ. Будьте готовы, что сетевые администраторы в процессе оптимизации ACL могут «порезать» необходимый доступ.

5. Размещайте сенсоры во всех критичных сетевых сегментах (пользовательские, серверные, DMZ).

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

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

8. Если сенсор представляет собой рабочую станцию, не забывайте время от времени ее выключать.

Ядро — сервер под управлением Window или Linux, мозг системы, обеспечивающий работу всей ее логики; используется для централизованного управления сенсорами и доступными на них сервисами.

Практические советы по проектированию ядра

1. Шифруйте трафик между сенсорами и ядром, а также направляйте его на нестандартные порты. Это дополнительно поможет скрыть наличие ханипота в инфраструктуре.

2. Так как сенсоры должны быть установлены в большом количестве сетевых сегментов (в идеале в каждом), ядро должно быть расположено в том сегменте, из которого доступны все остальные, например, в администраторском mgmt-сегменте. Исходя из этого к самому ядру должны предъявляться строгие требования по защищенности.

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

4. Между сенсорами и ядром не должно быть постоянно установленного сетевого соединения. Злоумышленник, скомпрометировав сенсор, не должен обнаружить, что это часть ханипота, а не легитимный хост.

Управляющая консоль — классическая консоль управления средством защиты. Может быть реализована как отдельный сервер или совмещена с ядром.

Практические советы по проектированию консоли

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

2. Само собой доступ к управляющей консоли должен осуществляться по https по нестандартному порту.

Внутренний лог-сервер — сервер для хранения логов сенсоров. Так как на сенсоре должно быть включено полное журналирование, нецелесообразно передавать все системные логи в log-management систему или SIEM. Однако их хранение необходимо для последующего разбора инцидентов и, возможно, расследования.

Плюсы и минусы

Рассмотрим основные концептуальные преимущества и недостатки ханипотов.

Плюсы

Минимальное количество ложных срабатываний. Сама идея ханипотов заключается в том, что легитимные пользователи не должны совершать с ними никаких манипуляций. Это кратно сокращает количество системных событий и событий ИБ на уровне сенсора ханипота, напрямую влияя на количество ложных срабатываний. Удаленный вход, обращение по smb, открытие веб- страниц и т.д. — все это свидетельствует, если не об обязательных манипуляциях киберпреступника, то, как минимум, о чрезмерной и, по сути, нелегитимной активности пользователей.

Синергия с другими средствами детектирования следует из предыдущего пункта. Ханипот позволяет существенно повысить эффективность других детектирующих средств защиты — того же SIEM. Выделение событий ханипота в отдельный поток, придание им особых атрибутов и сверхвысокого уровня критичности вкупе с минимальным количеством ложных срабатываний позволяет кратно уменьшить время первичного реагирования на события ИБ.

Отсутствие нагрузки на ИТ- инфраструктуру и необходимости менять сетевую архитектуру. Ханипот — пассивное средство защиты, которое, по сути, не увеличивает нагрузку на ИТ- инфраструктуру. Трафик, передаваемый между компонентами ханипота незначительный, как и логи, передаваемые по syslog, про просадку производительности на серверах боевых систем речь не идет вообще, так как ханипот с ними не интегрирован. Также практически не требуется изменять сетевую архитектуру. Единственный вопрос, который необходимо учесть на стадии проектирования, — это ресурсы среды виртуализации, но и их нельзя назвать значительными, ведь на сенсорах ханипота не предполагается разворачивать тяжелые бизнес-приложения.

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

Масштабирование. Сенсоры ханипота по своей сути являются преднастроенными виртуальными машинами. Это позволяет с легкостью масштабировать решение в сторону как увеличения, так и сокращения количества сенсоров.

Форензика. Ханипот можно использовать не только с целью детектирования злоумышленника, но и в форензике, в рамках контролируемого взлома. При этом полное журналирование, настроенное на сенсоре, поможет собрать необходимые свидетельства.

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

Решение проблемы Shadow- IT — следствие из предыдущего пункта. Ханипоты — это один из ответов на все возрастающую проблему — Shadow-IT, т.е. неучтенные, невидимые для ИТ и ИБ- службы ресурсы. Данные ресурсы в силу своей невидимости не покрыты классическими средствами защиты, не обновляются и фактически не защищаются. Ханипот же, так как он не нацелен на защиту конкретных активов, позволяет хоть как-то снизить негативный эффект, который вносит Shadow-IT в обеспечение безопасности, за счет защиты инфраструктуры в целом, независимо от того, какие в ней содержаться активы — учтенные или нет.

Минусы

Необходимость в средствах мониторинга. Ханипоты сами по себе не являются средством мониторинга — сенсоры генерируют поток событий, который где-то должен быть обработан и визуализирован. Да, это может быть собственная консоль ханипота, но практичнее использовать специализированные log-management tools или SIEM

Секретность. По понятным причинам о факте наличия подобной системы должны быть уведомлен только минимально необходимый круг лиц. Это создает дополнительные сложности во взаимодействии с ИТ-службой, а также в случае смены ее штата.

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

Невозможность внедрения коробочного решения

Данный пункт нельзя отнести ни к минусам, ни к плюсам, но его стоит учитывать при реализации ханипота. Ханипот сложно купить как коробочное средство защиты, часто его можно сделать под себя, своими силами или силами подрядчика. Во-первых, любой доступный широкой публике продукт, даже платный, со временем будет изучен профессиональными киберпреступниками. Рано или поздно под каждый коммерческий ханипот будут выработаны критерии поиска сенсоров и автоматизирован сам процесс поиска. Во-вторых, закупка коробочного решения оставит многочисленные финансовые следы, в которых будет фигурировать название решения и вендор, что приведет к раскрытию факта наличия данного решения в конкретной организации. С другой стороны покупая коробочное решение сразу приобретается набор сервисов, разработка которых с нуля может занять длительный период. Также нужно учитывать необходимость адаптации сенсоров под конкретную ИТ-инфраструктуру. Это коренным образом отличает внедрение ханипота от инсталляции классических средств защиты. Качественно проведенная адаптация решений, построенных на open source, зачастую на порядок эффективнее развернутого «из коробки» коммерческого решения, лидирующего на рынке.