Отказ от ответственности: ничто в этом блоге не связано с повседневной работой автора. Контент не является аффилированным лицом и не спонсируется какими-либо компаниями.

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

«Только алгоритмы заботятся о том, что правильно, а что нет, безопасность зависит от стоимости».

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

Хрупкость от алгоритма

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

Результаты «неправильного прогноза» существуют объективно, и специалисты по данным не могут игнорировать или опасаться их существования, поскольку мы, специалисты по данным, являемся единственными поставщиками этих моделей. Вывод большинства научных статей о якобы идеальном AUC — это только начало работы всей отрасли. Обычный показатель ложных срабатываний в 0,1 процента в документах по машинному обучению может быть увеличен за счет того, что миллиарды записей превратятся в сотни тысяч результатов в очереди операций безопасности, ожидающих, чтобы их забрал бедный парень из SOC (извините за это), где каждое предсказание Результат по модели связан со временем работы и стоимостью человеческих ресурсов. Иногда из-за негативных отзывов от операционных или продуктовых групп о стоимости ложных срабатываний специалисты по данным опасаются ложных срабатываний и ограничивают свое мышление при построении алгоритмов, например, делая 30% или более компромиссов в отзыве для незначительного улучшения на 0,1% или меньше. точности, или вручную добавляя большое количество правил списка для фильтрации результатов предсказания модели и страдая от сопровождения правил, или даже отказываясь от новой модели, потому что она может достигать только 90-процентной точности, и так далее. Наиболее распространенной причиной неустойчивости алгоритма является игнорирование или опасение неправильных результатов прогнозирования.

Вместо того, чтобы игнорировать или бояться этого, мы должны противостоять первопричине «неправильного прогноза» и начать думать о том, как правильно с ней бороться. Наиболее распространенной причиной ложных срабатываний или ложных отрицательных результатов с алгоритмической точки зрения является неполная информация о наблюдении за событиями безопасности, что является объективным недостатком кибербезопасности с оборонительной стороны. Злоумышленник может проектировать и вкладывать значительные средства в ресурсы атаки с разных точек зрения, в то время как защитники могут моделировать только то, что они видят. Даже если активы защитника полностью покрыты всеми точками обнаружения, сложно полностью проанализировать все действия злоумышленника, не говоря уже о том, что полные точки обнаружения невозможны, как и «Слепые и слон»*, «у людей есть склонность заявлять об абсолютной истине на основе своего ограниченного субъективного опыта, поскольку они игнорируют ограниченный субъективный опыт других людей, который может быть в равной степени истинным»2. Неопределенность, связанная с моделированием с неполной информацией, требует принятия неопределенности с точки зрения системной инженерии, а также выявления и обработки ошибочных результатов.

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

Хрупкость от техники

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

Большинство алгоритмических моделей в индустрии кибербезопасности основаны на таких источниках данных, как журналы, собранные внутри компании или на клиентских платформах, которые создаются специальными командами и сохраняются во взаимоисключающих форматах файлов, от pcap до csv, в какой-либо графовой базе данных или в двоичном формате. файлов на AWS S3 с разной задержкой и надежностью, а также с использованием разных платформ данных для вывода в сочетании с различными анализами угроз и сторонними форматами, а также с различными определениями полей и конфликтами в данных. Эти задачи по сбору данных, которые не упоминаются в научных статьях, являются одной из немногих сложных тем, с которыми приходится сталкиваться специалистам по данным перед моделированием.

Даже если пригодный для использования набор данных успешно собран и скомпилирован, стабильные и своевременные вычисления являются еще одной инженерной уязвимостью. Когда мы реализовали родительскую модель обнаружения DGA, 'domain2vec'*, модель, которая преобразует вероятности совпадения последовательностей доменных имен в геометрическое векторное пространство, вычислительная мощность, необходимая для обработки примерно 1 миллиарда записей DNS в час, стала серьезной инженерной проблемой. . Поскольку трафик данных DNS может иметь совершенно разные шаблоны для каждого периода времени, мы должны завершить сбор данных и расчет модели в течение определенного периода времени, чтобы избежать задержек в результатах и ​​засорения вычислительной платформы.

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

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

Хрупкость от эксплуатации

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

Исследователи данных часто считают, что задача моделирования ограничивается предоставлением результатов прогнозирования, и что если прогноз верен, все в порядке; если это не так, единственное, что имеет значение, — это компромисс между точностью и отзывом. Однако правильные результаты также должны быть рабочими, например, когда модель обнаруживает видео со сценами насилия, и оперативной группе приходится искать видео кадр за кадром в течение более часа, или когда модель обнаруживает новый APT C&C, но операционная группа должна вручную проверять десятки хостов, сотни процессов и файлов один за другим! Ходят слухи, что команде Amazon по алгоритму отправки посылок пришлось целый месяц ехать с курьером для доставки посылок, поэтому группы специалистов по обработке и анализу данных не смогут эффективно моделировать данные, если они отвлекутся от операционного бизнеса.

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

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

Несколько советов, как уменьшить хрупкость

Борьба с нестабильностью и ее последствиями требует почти всех этих усилий с точки зрения системной инженерии:

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

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

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

  • Обратная связь на основе функций модели: обычно это правило эвристики или модель машинного обучения, основанная на других функциях. Например, если алгоритм предсказывает, что главной страницей Google будет страница целевого фишинга, ее можно проверить с помощью модели ранжирования трафика и исключить на основании того факта, что «сайты с высоким трафиком имеют низкую корреляцию с целевым фишингом» в большинстве случаев (отказ от ответственности: не всегда!). Этот тип метода обратной связи использует ряд других функций, которые эффективно дополняют ограниченное представление модели обнаружения при наблюдении за шаблонами атак, обеспечивая теоретическую основу для обратной связи и помечая подавляющее большинство ошибок.
  • Обратная связь, основанная на знаниях ассоциации: если прогноз верен, результат ассоциации также должен быть правильным, если только ассоциация не расширена на несколько шагов для получения неправильного результата. Например, если алгоритм предсказывает доменное имя как вредоносный C&C, двоичный файл в VirusTotal или других механизмах обнаружения или результаты двоичного анализа группы безопасности могут быть расширены путем связывания записи IP, соответствующей записи поиска DNS, с доступом к этому IP. в песочнице, пока вся цепочка не будет завершена. Этот тип обратной связи опирается на сторонние знания за пределами пространства функций для независимой проверки; это немного дороже, чем обратная связь по функциям модели, но это полезное дополнение к методам обратной связи по функциям модели.
  • Обратная связь с пользователями: после предыдущих этапов осталось очень небольшое количество результатов, которые могут быть достигнуты пользователем, которому необходимо работать. Пользователи могут судить о результатах, комбинируя свой собственный опыт и другие сведения с помощью контекстной информации, предоставляемой алгоритмом. На этом этапе обратная связь с пользователем включает в себя не только правильность или неправильность результатов, но и суждения, сделанные пользователями, на основе какой релевантной информации. Короче говоря, пользователи должны указать «что» и «почему».

Алгоритм также должен обеспечивать максимальную интерпретируемость результатов прогнозирования, не только для неверных, но и для правильных результатов. Это включает в себя объяснение функций алгоритма (обычное для моделей глубокого обучения), маркировку и определение основания для суждения (например, какая конкретная строка фрагмента вредоносного скрипта) и контекстную информацию о прогнозируемом результате (например, связанные знания, упомянутые выше, например, что двоичный файл был распространен реализацией URL-адреса, другие известные вредоносные действия по этому URL-адресу и т. д.). Вот хороший пример важности интерпретации результатов: ясно, что когда дело доходит до эффективности моделей данных по сравнению с моделями правил, группы операций по обеспечению безопасности по-прежнему предпочитают модели правил, даже несмотря на то, что модели данных в большинстве случаев имеют хорошие показатели на бумаге. Это связано с тем, что операционный персонал может понять основы модели, прочитав сами правила, а также собственный опыт обеспечения безопасности, а также дополнительные исследования и другую последующую работу на основе информации модели, и в конечном итоге сделать обоснованное суждение. Основываясь на этой концепции, команда Sophos AI открыла хороший репозиторий с открытым исходным кодом для перевода соответствующих правил yara на основе результатов модели машинного обучения*, что представляет собой очень интересную работу с использованием метода объяснения с помощью функций. Пожалуйста, следуйте ссылке для дальнейшего чтения. Стоит отметить, что улучшение объяснимости результатов модели — это больше, чем просто перевод в правила yara; модель правил не дает идеальной интерпретации, и универсального решения не существует.

Алгоритмы также должны обеспечивать быстрый способ обработки ошибочных результатов и частичной автоматизации, например, соответствующие алгоритмы сортировки и достаточный объем контекстной информации для помощи операциям, среди прочего. Алгоритмы сортировки часто упускают из виду в науке о данных и исследованиях в области безопасности из-за отсутствия обсуждения в научных кругах и промышленности. Обычный сценарий заключается в том, что хорошая модель обнаружения аномалий забрасывается в производстве из-за большого количества прогнозируемых событий, необходимых для работы, что является огромной потерей как для специалистов по обработке данных, так и для групп операций по обеспечению безопасности, в то время как алгоритмы сортировки могут эффективно ранжировать прогнозируемые результаты на основе оперативных приоритетов и рационализировать оперативные ресурсы. Одним из примеров является презентация моего коллеги на Botconf 2017, Asiaee et al «Расширенный интеллект для масштабирования борьбы людей с ботнетами»*, в которой участвовали миллиарды журналов DNS в час. Система использует модель обнаружения аномалий для вывода всех невидимых доменов, «domain2vec» для построения корреляций доступа между доменами и шаблоны сильной корреляции в качестве показателей операционной важности для ранжирования сортировки, а десять миллионов аномальных событий в час были сокращены до дюжины допустимых кластеров и успешно применяется для обнаружения вредоносных программ с помощью DGA. Алгоритм сортировки имеет ряд метрик и методов, таких как кластеризация и сортировка, и представляет собой направление исследований в области науки о данных, связанное со знаниями в области безопасности, которые можно обсудить в следующих постах, если читатели заинтересованы.

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

Еще одна причина технической неустойчивости — проблема барьера данных, которая становится все более распространенной в индустрии кибербезопасности. В дополнение к некоторым организациям или альянсам открытых данных технически важно упомянуть инженерные реализации моделей данных, сохраняющих конфиденциальность, что просто означает, что модели не требуют расшифрованных данных для обучения и прогнозирования. Федеративное обучение — популярный подход, использующий архитектуру сервер-клиент для защиты конфиденциальности модели и сторон данных, позволяя модели получать желаемые функции без расшифровки необработанных данных. Эти подходы к федеративному обучению распространены в некоторых стартовых продуктах NDR и XDR, но в настоящее время используются только в простых сценариях. Что касается реализации федеративного обучения, FATE* прочно закрепилась благодаря ряду усилий с открытым исходным кодом, пожалуйста, ознакомьтесь со ссылкой для дальнейшего чтения. В некоторой степени вычисления с сохранением конфиденциальности требуют более высоких вычислительных затрат для смягчения проблемы барьера данных, но до фундаментального решения проблемы барьера данных еще далеко.

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

Резюме

Решение проблем уязвимости является первоочередной задачей кибербезопасности. Как, возможно, обнаружили опытные исследователи в области кибербезопасности, приведенное выше обсуждение уязвимости также относится к другим аспектам, таким как использование сторонней информации об угрозах с дальнейшей автоматической проверкой информации об угрозах, например, с использованием облачного или телекоммуникационного трафика. Точно так же модели правил, основанные на знаниях и опыте исследователей в области безопасности, сталкиваются с проблемами хрупкости: правила интеллектуального обнаружения требуют достаточного объяснения, большое количество устаревших правил белого списка необходимо поддерживать и обновлять, чтобы противостоять пробам и догадкам красной команды, отсутствие сортировки и ранжирования результатов обнаружения моделей и так далее. Это проблемы, с которыми должны бороться модели правил. Мы поднимаем этот вопрос здесь и хотим пролить свет на хрупкость модели правил и ее решений, разработанных исследователями безопасности.

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

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

Ссылка

Первоначально опубликовано на https://toooold.com 18 октября 2021 г.