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

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

Решение о классификации 1. Полезны ли эти данные для обнаружения?

Аналитики безопасности любят иметь свои журналы и оповещения IDS, но все данные необходимо постоянно проверять на предмет актуальности для обнаружения инцидентов. Инженеры по безопасности должны рассмотреть возможность не только удаления бесполезных источников обнаружения инцидентов, но и добавления новых инновационных источников данных. Обычно человек не управляет этой частью цикла — SOC получают все данные, которые могут, из сетей и журналов и надеются, что им будет достаточно для выполнения своей работы. Таким образом, AI/ML вполне может подойти здесь. Вычислительная мощность хоста представляет собой основной блокирующий фактор; поскольку, если хост должен интеллектуально определить, какие данные могут помочь в обнаружении в реальном времени, он будет использовать вычислительные ресурсы для запуска такого алгоритма. Какие бы данные система ни решила отправить, они перейдут к следующему решению о классификации.

Решение о классификации 2. Является ли это инцидентом?

После принятия решения о том, какие данные передавать нашей системе или системам обнаружения вторжений, система обнаружения вторжений должна решить, характеризуют ли данные вредоносную активность. Это проблема бинарной классификации, так почему же на изображении выше три случая? Инженер по машинному обучению разработает алгоритм для определения того, характеризуют ли системные данные инцидент, на основе входных обучающих данных. Этот алгоритм вернет вероятность возникновения инцидента. Таким образом, случаи представляют собой пороги в этой возвращенной вероятности. Аналитики должны будут определить надлежащий порог, чтобы избежать усталости предупреждений и обработать необходимое количество предупреждений в день. Порог случая 1 будет очень высоким. Обратите внимание, что поскольку инциденты, как правило, происходят реже, это может быть пороговое значение, не близкое к единице — пороговое значение для случая 1 фактически может быть очень близким к нулю, просто выше следующего порогового значения. Порог для случая 2 по-прежнему будет высоким, но будет сгенерировано несколько предупреждений. Это позволит аналитику прочитать данные, вызвавшие предупреждение, и принять решение о том, как классифицировать событие. Цикл, показанный с SIEM, возвращающим точку принятия решения, представляет этот итеративный процесс.

Расследование инцидента и реагирование

Концепция кибербезопасности NIST определяет инцидент кибербезопасности как событие кибербезопасности, которое, как было установлено, оказывает влияние на организацию, вызывая необходимость реагирования и восстановления. Мне никогда не нравилось это определение, и здесь нужно что-то более конкретное. Я предпочитаю более простое определение: инцидент кибербезопасности — это событие, которое аналитик решил исследовать дальше. Это естественным образом приводит к первому пункту NIST Cybersecurity Framework в анализе реагирования: Уведомления от систем обнаружения расследуются. Расследование инцидентов и реагирование на них также являются проблемами классификации. На рисунке ниже показаны три проблемы бинарной классификации, которые аналитики должны решить, чтобы закрыть инцидент после генерации.

Решение о классификации 3. Достаточность контекстных данных

Классификация снова возвращается к качеству предоставленных данных. Пункт принятия решения 2 классифицировал инцидент на основе данных из пункта принятия решения один, но эти данные были сосредоточены на обнаружении, а не на расследовании. Другими словами, нам просто нужно было ответить на вопрос: является ли это аномальным поведением, на которое мы должны обратить внимание? Теперь нам нужно ответить: что именно произошло, и как мы можем это исправить? Аналитику, вероятно, потребуется запросить дополнительные источники данных, чтобы ответить на эти вопросы. AI/ML может принести здесь существенную пользу, поскольку он может быстро определить, какие данные могут быть полезны аналитику для расследования, на основе данных контекста, и автоматически добавить эти данные в объект инцидента (гидратация данных) для дальнейшего анализа аналитиком.

Решение о классификации 4: реальный инцидент

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

Решение о классификации 5: Эффективность смягчения последствий

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

Нацеливание машинного обучения и аналитики на решение проблемы

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