Давайте вернемся на пару лет назад, когда все зарубежные компании в области ИБ как один ушли из России и прекратили обслуживать поставленные ранее средства обнаружения угроз, включая поставку обновлений для них. Формально это не превратило средства защиты в кирпич (исключая решения одного американского вендора), но фактически сделало невозможным их применение. По мере появления новых угроз и из-за отсутствия контента для их обнаружения они стали медленно, но верно превращаться в тыкву.
Контент обнаружения — это любая информация, помогающая обнаруживать угрозы. Включает в себя не только сигнатуры атак и хеши вредоносных файлов, но и индикаторы компрометации различного типа (доменные имена, e-mail, названия файлов, ключи реестра и т. п.), правила корреляции, шаблоны аномальной активности, модели машинного обучения и т. д.
Многие компании и специалисты по кибербезопасности впервые задались вопросом: «А что делать, чтобы не зависеть на 100% от производителя средств обнаружения угроз?» Очевидно, что определенная зависимость все равно останется, но как сделать так, чтобы при любых условиях можно было по-прежнему использовать приобретенные средства защиты и обновлять их знанием о современных угрозах?
На самом деле история с внезапной потерей доступа к контенту обнаружения началась не в 2022 году, а раньше. Еще в 2014 году DTCC и FS-ISAC (аналог нашего ФинЦЕРТа) объявили о создании совместного предприятия по разработке решения Soltra, которое позволяло автоматически обмениваться данными об угрозах. До этого момента консолидация фидов из множества источников и их анализ с последующим распространением осуществлялись преимущественно вручную. Фокусировка на финансовом секторе и грамотная архитектура решения привели к тому, что спустя год его использовали 2900 компаний из 77 стран (считается, что именно благодаря Soltra стали популярными протоколы STIX и TAXII, превратившиеся, по сути, в стандарты де-факто). В 2015 году DTCC и FS-ISAC решили уйти от P2P-архитектуры в сторону централизованной и лучше масштабируемой схемы, а также выйти за пределы финансового сектора. Они запустили Soltra Network — ее, по мнению основателей, было проще монетизировать. Однако что-то пошло не так, и 15 ноября 2016 года DTCC и FS-ISAC объявили о немедленном (!) прекращении поддержки и обновления Soltra. Руководство двух организаций признало, что это создает трудности для пользователей, но так и не объяснило причину столь стремительного, без какого-либо переходного периода, завершения поддержки своей TIP-платформы. Да, на тот момент на рынке уже присутствовали несколько десятков коммерческих и open-source-решений, поддерживающих STIX/TAXII, но сама история была очень неприятной.
В свежем исследовании SANS 2023 Detection Engineering Survey, которое было проведено преимущественно среди американских специалистов по ИБ, особо отмечается, что основная причина пропуска атак в компаниях — недостаточная разработка контента или инструментов для обнаружения новых угроз, а также большое число ложных срабатываний (см. рис. 1).
Первый очевидный шаг для борьбы с этими проблемами — использование фидов с индикаторами компрометации для средств защиты от ушедших с российского рынка компаний. Такие фиды стали выпускать некоторые отечественные компании (например, Positive Technologies), и их можно использовать в иностранных системах обнаружения вторжений (IDS/IPS), SIEM и т. п. Но это все равно временная мера: мы просто перекладываем проблему на плечи другой компании до тех пор, пока не найдем адекватной замены продукту от «кинувшего» нас вендора.
В 2015 году внезапно прекратила свое существование одна из компаний, занимавшихся Threat Intelligence, — Norse (хотя некоторые эксперты обвиняли Norse в том, что она часто распространяла не то что не проверенные, а просто сырые, а иногда и вовсе фейковые данные об угрозах). Компания была известна своим расследованием взлома Sony в 2014 году и интерактивной картой кибератак. История до сих пор умалчивает все детали произошедшего, но факт есть факт — сайт компании внезапно ушел в офлайн в январе 2016 года, а ее e-mail’ы не отвечали. Заказчики перестали получать фиды от Norse. Сейчас про эту компанию уже никто и не вспоминает, но эта история вновь подсвечивает проблему зависимости от поставщиков данных об угрозах.
В идеальном мире мы должны самостоятельно создавать контент обнаружения угроз. Но как гарантировать его качество? Как сделать так, чтобы, невзирая ни на какие санкции и внезапные уходы компаний с рынка или просто их переориентацию, мы могли и дальше продолжать обнаруживать угрозы? Все просто — надо научиться писать свой контент :)
В 2001 году в своей книге «Обнаружение атак» я приводил следующую статистику: 87% пользователей систем обнаружения атак не создают собственных сигнатур атак (контента обнаружения), даже если у используемых ими решений есть такая возможность. В 2023 году агентство TAdviser выпустило исследование по SIEM в России. Согласно собранной статистике, контент обнаружения «из коробки» используется только в 32% случаев; 9% опрошенных используют внешние сервисы по написанию контента обнаружения. Написание собственных и доработка существующих правил присутствуют в 59% случаев (существенный скачок вперед). Исследование SANS 2023 Detection Engineering Survey показывает, что у американцев ситуация схожая: 67% компаний пишут контент обнаружения самостоятельно. Почти 40% опираются на внешних провайдеров (у TAdviser давался единственный выбор, а у американцев — множественный, поэтому в сумме получается больше 100%). Эти цифры говорят нам, что процесс сдвинулся с мертвой точки и компании готовы всерьез заниматься самостоятельной разработкой контента обнаружения.
Threat Detection as a Service — услуга разработки и доставки качественного контента обнаружения, получаемая из рук внешнего поставщика (провайдера Threat Intelligence или аутсорсингового SOC).
Detection as a Code — что это вообще такое
Давайте посмотрим на процесс обнаружения угроз в целом (см. рис. 2). Кстати, подумайте на досуге, насколько хорошо он у вас выстроен и эффективно ли вы управляете каждым из компонентов этой схемы.
Процесс Detection Engineering скрывается за левым верхним прямоугольником «контент обнаружения». Нельзя сказать, что он является самым главным, но без него эффективного результата не достичь, какие бы решения вы ни использовали. При его отсутствии, что мы все и увидели в марте 2022 года, вся схема рушится.
Detection Engineering — процесс, когда мы, ориентируясь на знание об угрозах (Threat Intelligence), разрабатываем, тестируем, оцениваем, используем и распространяем контент обнаружения.
Обратите внимание на этапы этого процесса, упомянутые в определении на полях. Они очень напоминают процесс разработки ПО, и поэтому не случайно процесс создания контента обнаружения еще часто называют Detection as a Code (DaaC). Но задача заключается не только в выстраивании процесса непрерывного написания новых сигнатур атак или правил корреляции, но и в повышении качества этого контента и снижении числа ложных срабатываний. Они сводят на нет все преимущества технологии обнаружения и много лет назад даже привели к появлению высказывания «IDS мертвы». Им на смену пришли SIEM. И они сейчас тоже находятся при смерти из-за большого числа ложных срабатываний, связанного с ростом числа событий безопасности, которые должны обрабатываться в системах мониторинга.
Если вам интересно будущее решений класса SIEM, могу порекомендовать свою большую статью на Хабре с анализом тенденций в этом сегменте
Это вообще гонка брони и снаряда, когда сначала технология вас устраивает, а потом наступает некий предел и начинаются проблемы, которые пытаются решить новой технологией, у которой тоже наступает предел, и т. п. Это тупиковый путь развития технологий обнаружения, который можно попробовать хотя бы замедлить, но не за счет увеличения числа правил обнаружения и скорости их выпуска (что тоже немаловажно), а за счет роста их качества. И Detection Engineering позволяет это реализовать.
Система обнаружения угроз включает в себя не только системы обнаружения вторжений (IDS/IPS), но и SIEM, NTA/NDR, EDR, антивирусы, TDIR, CDR, IDR, DLP, UEBA, MTD, обманные системы и т. п.
Подход DaaC позволяет не бояться, что мы что-то сломаем, так как после создания контента он не сразу внедряется (деплоится) в систему обнаружения, а проходит проверку, на которой могут быть выявлены все ошибки и неточности. Но мы должны помнить, что в DevOps, откуда и пришла концепция Detection as a Code, одним из ключевых параметров является непрерывность (не зря же в аббревиатуре CI/CD целых две буквы C — Continuous). Поэтому каждый день мы (точнее, инженеры по обнаружению угроз) должны задаваться вопросами:
- А написанный нами вчера контент обнаружения позволяет обнаруживать угрозу сегодня?
- Не сменились ли логика/инструментарий/подходы у злоумышленников?
- Описанная нами в контенте обнаружения логика все еще позволяет детектировать угрозу?
- Не пора ли проверить и поменять контент обнаружения?
Без процесса Threat Intelligence нельзя эффективно разрабатывать контент: вы просто не будете знать, что поместить в соответствующие правила, сигнатуры, шаблоны и т. п.
Эти непростые вопросы, задаваемые ежедневно, подводят нас к мысли, что процесс разработки контента обнаружения должен длиться не очень долго. Вполне логично, что мы плавно приходим к гибкой разработке, то есть разбиению крупного процесса на множество повторяемых небольших шагов (планирование — написание контента — тестирование — внедрение). Будете вы называть это Agile, Scrum или Kanban, не так уж и важно. Любая система, поддерживающая Kanban-доски, подойдет для отслеживания статуса контента обнаружения (Jira была бы неплохим вариантом, но 24 февраля смешало карты). Например, процесс генерации контента обнаружения мог бы выглядеть так (см. рис. 3).
Все начинается с идеи, которую вам необходимо проверить, опираясь на данные, пришедшие с процесса Threat Intelligence. Эта гипотеза будет описываться определенным образом в зависимости от источника данных, в котором вы будете искать ее подтверждение. Это могут быть не только журналы регистрации или активность пользователей и приложений, но и сетевой трафик, файлы, электронная почта, домены и т. п.
Список источников будет зависеть от того, какие угрозы и нарушители для вас будут актуальными, а также от того, какие техники, согласно матрице MITRE ATT&CK, они используют. В указанной матрице, а также в иных связанных проектах MITRE для большинства техник указаны необходимые для работы источники данных.
Чтобы понять, насколько часто используются те или иные источники данных, посмотрите на все ту же американскую статистику 2023 года. Удивляет то, что события от NDR/NTA стоят ниже облачных логов и журналов регистрации SaaS. Но если убрать облачную телеметрию, то схожее распределение мест будет наблюдаться и у нас.
Почему именно MITRE ATT&CK? Этот фреймворк многогранен, его можно использовать не только для моделирования угроз или эмуляции действий хакерских группировок, но и для оценки эффективности мониторинга и уровня покрытия детектами инфраструктуры. У меня есть модель угроз, которая маппится в техники нарушителей, и дальше мы смотрим, насколько наши средства обнаружения их детектят (примерно вот так).
Типы контента обнаружения
Очевидно, что в зависимости от типа источника событий обнаруживать данные в них можно по-разному. Обычно в качестве контента обнаружения рассматриваются сигнатуры, которые точно описывают ту или иную угрозу. Например, вот так может выглядеть сигнатура для вредоносного ПО TrueBot:
alert tcp any any -> any any (msg:”TRUEBOT: Client HTTP Header”; sid:x; rev:1; flow:established,toserver; content:”Mozilla/112.0 (compatible|3b 20 4d 53 49 45 20 31 31 2e 30 3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 31 30 2e 30 30 29|”; httpheader; nocase; classtype:http-header; metadata:service http;)
Имея низкий уровень ложных срабатываний, сигнатуры долгое время считались основным, а иногда и единственным способом обнаружения угроз. Яркими примерами инструментов обнаружения атак на базе сигнатур являются бесплатные системы Snort (сигнатура выше написана как раз на ее языке), Suricata или Zeek, которые прекрасно понимают язык Snort. Это позволяет использовать один и тот же контент в разных решениях ИБ.
Да, на первое место я поставил сигнатуры, куда уж без них. Но что еще? Более оперативным и доступным из множества источников (для снижения зависимости от одного поставщика) является способ, ориентированный на индикаторы компрометации, которые позволяют обогатить существующие события безопасности и сделать обнаружение более точным. Да, до 80% всех прилетающих в фидах индикаторов — это шлак и ничего не стоящая информация. Но часто именно этот способ, особенно если IoC поступают не от самого производителя вашей системы обнаружения вторжений, помогает обнаруживать то, что пропущено сигнатурами. К тому же IoC можно загружать в различные системы аналитики, таким образом обогащая имеющиеся сырые данные и повышая их точность. Например, для упомянутого выше TrueBot индикаторами в виде названия вредоносного домена, названия файла или хеша MD5 будут (всего три из нескольких десятков):
ms-online-store[.]com
Secretsdump[.]py
F33734DFBBFF29F68BCDE052E523C287
Триггеры позволяют отделять нормальную активность от аномальной. Например, решение для защиты электронной почты позволяет выявлять компрометацию почтовой учетной записи пользователя по числу отправляемых вовне сообщений. А система класса Network Traffic Analysis (например, PT NAD) выявляет утечки данных через разрешенные сетевые протоколы, например DNS, за счет оценки числа DNS-запросов и ответов со стороны отдельных узлов сети и размера этих запросов и ответов. Превышение пороговых значений может означать аномалию, а то и пропущенный инцидент ИБ.
Эмуляция (или поведенческие признаки) позволяет обнаруживать вредоносную активность. Например, можно запустить подозрительный файл в тестовой среде (как вариант, в песочнице PT Sandbox) и проверить, не осуществляет ли он какой-либо опасной деятельности — шифрования файлов, сканирования в поисках уязвимостей, утечки информации, установления соединения с командными серверами и т. п.
Правила позволяют выявлять угрозы, комбинируя различные события безопасности, а также обогащая их дополнительными сведениями типа индикаторов компрометации. Такие правила, задаваемые в решениях класса SIEM или EDR (например, MaxPatrol SIEM или MaxPatrol EDR), могут быть как достаточно простыми, так и сложными, состоящими из множества атомарных событий. Только их комбинация в определенной последовательности и в определенный интервал времени характеризует вредоносную активность. Вот так будет выглядеть правило на языке YARA для ВПО TrueBot:
rule CISA_10445155_01 : TRUEBOT downloader
{
meta:
Author = "CISA Code & Media Analysis"
Incident = "10445155"
Date = "2023-05-17"
Last_Modified = "20230523_1500"
Actor = "n/a"
Family = "TRUEBOT"
Capabilities = "n/a"
Malware_Type = "downloader"
Tool_Type = "n/a"
Description = "Detects TRUEBOT downloader samples"
SHA256 = "7d75244449fb5c25d8f196a43a6eb9e453652b2185392376e7d44c21bd8431e7"
strings:
$s1 = { 64 72 65 6d 6d 66 79 74 74 72 72 65 64 2e 63 6f 6d }
$s2 = { 4e 73 75 32 4f 64 69 77 6f 64 4f 73 32 }
$s3 = { 59 69 50 75 6d 79 62 6f 73 61 57 69 57 65 78 79 }
$s4 = { 72 65 70 6f 74 73 5f 65 72 72 6f 72 2e 74 78 74 }
$s5 = { 4c 6b 6a 64 73 6c 66 6a 33 32 6f 69 6a 72 66 65 77 67 77 2e 6d 70 34 }
$s6 = { 54 00 72 00 69 00 67 00 67 00 65 00 72 00 31 00 32 }
$s7 = { 54 00 55 00 72 00 66 00 57 00 65 00 73 00 54 00 69 00 66 00 73 00 66 }
condition:
5 of them
}
Обратите внимание, что многие решения ИБ-производителей не поддерживают ни распространенные языки описания контента обнаружения типа YARA, Snort, SIGMA и т. п., ни саму возможность создавать собственный контент
Графы взаимодействия позволяют не проводить длительные исследования на выявление вредоносной активности, а с помощью визуализации ее компонентов и их взаимодействия делать выводы о наличии или отсутствии угрозы. Таким образом действуют решения, анализирующие инфраструктуру злоумышленников, с которой осуществляется рассылка вредоносных программ или хостинг фишинговых доменов и командных серверов; а также решения, относящиеся к классу «автопилот ИБ», например MaxPatrol O2.
Последним в списке, но не последним по значимости типом контента обнаружения являются алгоритмы, способные выявлять различные аномалии в активности сети, узла, приложения или пользователя, а также классифицировать их как вредоносные. Например, таким образом можно выявлять редко запускаемые процессы на защищаемых серверах или в контейнерах. Или можно без агентов на хостах выявить работу программ-шифровальщиков или установленные в сети посторонние устройства, крадущие информацию. Разновидностью алгоритмов являются модели машинного обучения, которые позволяют выявлять сложные атаки (например, вредоносный код внутри зашифрованного трафика), а также ранее не встречавшиеся угрозы (например, атаки с новых вредоносных доменов).
Последние два типа контента (графы и алгоритмы, включая модели машинного обучения) можно самостоятельно создать, только если и само средство защиты, в котором они будут использоваться, компания создавала и поддерживает самостоятельно. Дело в том, что их разработка требует очень глубокого погружения в архитектуру этой системы
Detection as a Code — с чем его едят
Если вы только начали выстраивать процесс Detection Engineering, то писать контент обнаружения лучше на уже упомянутых языках Snort, YARA, а также SIGMA. Для них есть уже готовые базы правил, которыми обмениваются специалисты по всему миру. Есть компании и эксперты, которые считают, что писать контент обнаружения надо на универсальном и гибком языке, таком как Python, так как это дает больше преимуществ, чем использование специфических, ориентированных на конкретные задачи языков. Но я считаю, что начинать с него точно не стоит. Может быть, потом, когда вы решите, что и чужие (пусть и open source) системы обнаружения угроз вам не нужны, вы перейдете на Python и с помощью него будете не только писать контент обнаружения, но и обнаруживать угрозы (но не факт).
Еще одно преимущество Detection as a Code — это возможность повторного использования уже написанного контента обнаружения. Да, в чистом виде будет сложно повторно применить контент обнаружения так, как это происходит в мире программирования. Но очевидно, что какую бы фишинговую кампанию мы ни взяли, они все используют схожие методы, только разные формулировки, тексты, вредоносные ссылки или аттачи. Почему бы не использовать уже написанный контент для описания новой вредоносной кампании? А может быть, мы со временем сможем любой фишинг описывать одним общим шаблоном, учитывая только какие-то специфические нюансы (да-да, речь о концепции наследования из объектно-ориентированного программирования). Если посмотреть исследование Positive Technologies «Тренды фишинговых атак на организации в 2022–2023 годах», то мы увидим, что до 80% всех техник в фишинговых кампаниях похожи друг на друга — меняется только текст рассылок. Значит, их можно описать в одном шаблоне, просто подгружая новые текстовые приманки из регулярно пополняемой базы знаний.
Та же история идеально ложится на написание сценариев (use case) для деятельности SOC. Например, мне надо написать плейбук для обнаружения попыток манипуляции административным доступом. Очевидно, что существует общий набор действий хакеров, который мне надо проверить/обнаружить независимо от системы (Windows, Linux, macOS, Cisco, Oracle, Postgres, AWS и т. п.). А дальше уже начинаются нюансы работы конкретной платформы. Повторное использование помогает ускорить создание плейбуков для каждой новой платформы, которую мы будем использовать в компании.
Целесообразен подход с созданием библиотеки контента (на базе локального репозитория или Git). Это позволяет иметь отчуждаемый от технологии или инструмента обнаружения источник информации, который можно без особых проблем переносить от решения к решению (с оговорками), от компании к компании, а также делиться им с комьюнити. Да и пополнять свою библиотеку, построенную по определенным правилам, чужим контентом также будет проще, чем ориентироваться на встроенные в продукт проприетарный формат хранения сигнатур и правила обнаружения. Например, на GitHub можно найти репозиторий правил SIGMA или YARA.
Применение методов тестирования (Quality Assurance, QA) к контенту обнаружения отличает Detection as a Code от обычно применяемых подходов к написанию сигнатур атак или правил для SIEM. В рамках QA мы можем выявить слепые зоны для разработанного контента, проверить его на ложные срабатывания, расширить на нужные источники телеметрии, тем самым повышая его эффективность без разрастания числа правил обнаружения. Когда семь лет назад началась эпидемия WannaCry, некоторые вендоры писали под каждую его модификацию (а их было не менее 400) свою сигнатуру. Это позволяло им хвалиться числом сигнатур атак в своих решениях, но ничего не говорило об их качестве.
Quality Assurance также позволяет чуть-чуть почувствовать себя хакером, который, прежде чем пойти в виртуальный бой, тестирует свое вооружение на обнаруживаемость (для этого есть свои аналоги VirusTotal), подкручивает что-то, подтюнивает, а потом ка-а-а-ак жахнет. Вот и инженеры по обнаружению постепенно докручивают свой контент, внося в него улучшения, вводя исключения и т. п. Попутно они документируют свои изыскания в Jira, Redmine или ином аналогичном решении (если продукты Atlassian стали недоступны), чтобы можно было всегда к ним вернуться и понять, почему было принято то или иное решение.
Как проводить тестирование контента обнаружения? Тут мне видится пара вполне очевидных вариантов — статическое и динамическое тестирование. Первый вариант самый простой и очевидный — в нем тестированием управляют инженеры, которым, увы, свойственно ошибаться. При росте числа инженеров и правил это может стать проблемой. Поэтому нужна автоматизация, и в качестве примера я назову следующие инструменты:
- Visual Studio Code с расширением для YAML позволяет подсвечивать ошибки в синтаксисе правил SIGMA, а скрипт sigmalint — проверять правила SIGMA на соответствие схеме языка.
- Скрипт sigmac позволяет проверять корректность написания правила для того или иного средства мониторинга ИБ, а скрипт sigma-test — определять тестовые сценарии для правил SIGMA и проверять, что то или иное правило действительно позволяет их детектировать.
- Для тестирования правил YARA можно использовать функцию Retrohunt в VirusTotal, проект Касперского KLARA или онлайн-сервис YARA Scan Service.
Статические тесты не позволяют выявить проблемы в контенте в процессе его отработки в реальном времени. Эту задачу решают динамические тесты, которые требуют участия систем обнаружения угроз (например, SIEM или NTA). Они могут давать обратную связь в рамках непрерывного конвейера CI/CD. Например, число срабатываний правил или длительность поиска могут быть свидетельством неправильно написанного контента, и это может быть проанализировано без участия человека. Внутренние системы обработки ошибок в средствах мониторинга тоже позволяют выявить некачественный контент обнаружения. Правда, это еще не динамические тесты в их истинном смысле.
Зато, в отличие от классического DevOps, в ИБ есть возможность организации динамических тестов с помощью атак, которые как раз и отвечают на вопросы «Позволяет ли мой контент обнаружить угрозу?» и «Мой контент все еще обнаруживает угрозы?». Небольшие тесты, подготовленные в рамках фреймворка Atomic Red Team, разработанного компанией Red Canary, представляют собой постоянно пополняемую коллекцию скриптов для тестирования систем обнаружения угроз. Правда, с этими тестами есть своя засада. Это тоже код, который надо тестировать в рамках концепции DevOps, то есть применять к нему тот же конвейер CI/CD и тестировать его на предмет корректности.
Придется где-то поставить точку, чтобы не загонять себя в бесконечный цикл. Она может быть поставлена на уровне фреймворка Atomic Red Team, которому мы можем доверять. А можно перепроверять его с помощью собственной команды red team, которая будет не только подтверждать корректность тестов фреймворка от Red Canary, но и дополнять его своими тестами и скриптами. Как вариант, можно использовать решения класса Breach & Attack Simulation (BAS) для автоматизации оценки эффективности написанных правил идентификации вредоносной активности.
Но надо признать, что автоматизация тестирования контента обнаружения пока не достигла достаточного уровня зрелости. Гораздо чаще различных скриптов используются услуги своих специалистов или аутсорсинговых компаний.
И это объяснимо: для запуска тестов необходимо иметь тестовую среду, которая должна копировать вашу инфраструктуру, включая стек защитных средств. Да, это непросто, но, с другой стороны, сегодня такие тестовые окружения созданы во многих компаниях для тестирования нового ПО, патчей, обновлений. Их же можно задействовать и для тестирования контента обнаружения. Сделать это можно так: запускать по расписанию нужные тесты и следить за тем, будут ли они обнаружены имеющимися ИБ-средствами, для которых мы писали контент обнаружения. Последующий анализ логов (по временным меткам) подскажет, было ли обнаружение успешным на 100% (на всех нужных платформах и для всех средств обнаружения) или лишь частично.
Затем мы можем зафиксировать результаты теста в системе управления проблемами и при необходимости инициировать доработку контента обнаружения. Такая автоматизация запуска тестов и позволит нам ответить на вопрос «Мой контент все еще обнаруживает угрозы?». Эта же тестовая среда позволит проверить способность нашего контента обнаруживать новые угрозы, информацию о которых мы получили в рамках обмена данными об угрозах или в результате работы команды пентестеров / red team. Они смогут быстро (я надеюсь) разработать соответствующие скрипты и включить их в непрерывно действующий ИБ-конвейер CI/CD. Отсутствие же автоматизации приводит к достаточно большим интервалам тестирования, что может, в свою очередь, привести к пропуску новых атак.
Подход Detection as a Code — это больше чем просто тестирование и снижение числа ложных срабатываний. Это еще и возможность повысить качество контента обнаружения за счет его модульности, расширяемости (кто мешает добавлять в контент новые блоки для обнаружения схожих по принципу действия угроз?) и версионности (кто мешает иметь несколько версий контента с обнаружением вредоноса на разных платформах?). Не сработало? Откатились на предыдущую версию и смотрим, что в ней нужно изменить. Мы всегда можем проверить, последнюю ли версию контента обнаружения мы используем, и если нет, то почему.
Ведение истории изменений — это еще и хороший способ не потеряться в постоянных обновлениях и в работе нескольких инженеров обнаружения. А если посмотреть чуть шире, то контроль и управление изменениями помогают нам регулярно возвращаться к уже написанным правилам и при необходимости переписывать их под новые требования или произведенные в инфраструктуре изменения (новые ОС, приложения, устройства, протоколы и т. п.).
***
Сегодня российские компании, слезающие с иглы американских ИБ-вендоров, продемонстрировавших свою «надежность» и повернувшихся «лицом» к заказчикам, могут трезво оценить свою способность детектировать атаки. Выстраивая функцию обнаружения угроз, можно наконец-то всерьез задуматься о том, как это делать правильно. Как не только снизить число необнаружений (false negative) и ложных срабатываний (false positive), но и эффективнее использовать тот инструментарий, который уже есть на балансе или который рассматривается к приобретению и(или) внедрению? Как снизить свою зависимость от поставщиков продуктов и услуг? На все эти вопросы и помогает ответить процесс Detection Engineering.
