3 рекомендации по улучшению приказов ФСТЭК. Привязка защитных мер к угрозам

В конце января я написал заметку о том, как можно было развить БДУ, добавив в нее привязку к этапам атаки (там где угроза является низкоуровневой, а не стратегической) и затем уже к матрице MITRE ATT&CK. Сегодня я хотел бы посмотреть на эту проблему немного с другой стороны. Одним из часто задаваемых вопросов касательно инициатив ФСТЭК является — «Как связать угрозы из БДУ с защитными мерами из приказов?». Сергей Борисов уже писал об этом и даже провел колоссальную работу, выложив соответствующую табличку.

Однако, как я писал в январе, сама по себе БДУ решает задачу скорее бумажной ИБ, чем практической, и маппинг мер 17-го приказа в перечень угроз из банка данных (а точнее наоборот) не сильно помогает бороться с реальными атаками, которые описываются с помощью матрицы ATT&CK или более высокоуровневой модели Kill Chain.

Первый вариант является частью самой матрицы ATT&CK — в описании многих из тактик нарушителей есть раздел по мерам их нейтрализации и способам обнаружения. Да, он неполный. Например, в отношении угрозы использования DGA-доменов ATT&CK предлагает сетевые IPS и локальные DNS-sinkhole, напрочь забывая о решениях класса ISG (Internet Security Gateway) или SASE или DNS Firewall. Но как точка отсчета и как пример реализации, этот вариант подходит неплохо.

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

Нравится мне матрица ATT&CK — многоплановая она, позволяет использовать для совершенно разных целей, которые я еще опишу в блоге. Но есть и другой вариант, позволяющий ассоциировать угрозы с мерами защиты и он, как мне кажется, проработан получше варианта с ATT&CK, которая первоначально создавалась именно как перечень возможных тактик и техник злоумышленников и только потом стала расширяться за счет добавления в нее новых сущностей, одной из которых и стало описание защитных мер, которое пока находится в самом начале своего пути.

Второй вариант был предложен Центром Интернет-безопасности (CIS), который разработал модель CAM (Community Attack Model), задачей которой было, отталкиваясь от Топ20 защитных мер, приоритезировать их исходя из хакерских техник, чаще всего используемых в мире. Методология CAM может быть описана следующим образом:

• проанализировать источники данных (CIS анализирует кучу TI-отчетов и источников)
• идентифицировать ключевые тактики и техники
• идентифицировать способы защиты от ключевых тактик и техник
• связать методы защиты с мерами CIS Control.

Учитывая, что CIS расположен в США, где одним из самых популярных фреймворков по ИБ является NIST CSF, то CAM использует его в качестве основы для группирования защитных мер. По горизонтали матрицы у нас 5 блоков защитных мер по NIST CSF (Identify, Protect, Detect, Respond, Recover — идентификация, предотвращение, обнаружение, реагирование, восстановление), а по вертикали — этапы большинства современных атак. Эти этапы немного отличаются от этапов ATT&CK, но в перспективе, во второй версии CAM должен быть маппинг и в матрицу корпорации MITRE. Иными словами, матрица CAM позволяет обсуждать защитные возможности/меры применительно к стадиям атаки.

Схожие подходы уже используются разными компаниями. Например, вместо пяти блоков защитных мер применяется три — предотвращение, отражение, реагирование. Другая компания применяет шестиэтапную модель МинОбороны США (я о ней уже писал) — detect, deny. disrupt, degrade, deceive, destroy. Столбцы в свою очередь могут быть разбиты дополнительно на типы нарушителей. В любом случае в ячейках на пересечении вписываются защитные меры. Наиболее популярный вариант матрицы  CAM выглядит так.

Но так как основная задача CAM развивать и поддерживать CIS Controls, то связь защитных мер из списка Топ20 с этапами атаки выглядит таким образом.

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

Так как MITRE ATT&CK сегодня становится все более и более популярной, то Center of Internet Security в рамках развития CAM ведет работы по связыванию защитных мер CIS Controls с техниками и тактиками ATT&CK, существенно расширяя те возможности, которые предоставляются самой MITRE. По сути получается, что если MITRE использует матрицу ATT&CK как точку отсчета и уже потом привязывает к ней защитные меры, то у CIS подход другой — они отталкиваются от защитных мер и потом уже смотрят на матрицу MITRE.

Резюмируя, приказы ФСТЭК можно было бы еще улучшить за счет привязки защитных мер к угрозам из БДУ, которую в свою очередь стоило бы улучшить за счет привязки к конкретным тактикам и техникам злоумышленников. При этом, матрицу MITRE ATT&CK я привожу как пример того, как это может быть реализована. Она тоже не идеальна, фокусируясь преимущественно на APT и группировках, использующих те или иные методы. В итоговую матрицу попадает далеко не все, что используется при атаках. Но сама идея матрицы очень неплоха и на ее основе, раз уж у нас не любят в лоб использовать американские наработки, можно сваять что-то отечественное. Правда, в последнем случае мы получим очередной импортозаместительный костыль, который без должной поддержки со стороны сообщества умрет. А поддерживать его, увы, никто не будет, как и многие другие инициативы, исходящие от государства (отечественная Википедия, отечественный Гитхаб, отечественный стандарт обмена данными об инцидентах и т.п.). Будем вариться в собственном соку, в то время как иностранцы будут обходить нас по многим направлениям ИБ.