ИТ-портал компании «Инфосистемы Джет»

ML-технологии в ИБ: использовать нельзя отказаться

ML-технологии в ИБ: использовать нельзя отказаться

«Машинное обучение как подростковый секс — все об этом говорят, но никто им не занимается…»

Это статья будет не о байесовской классификации, не о нейронных сетях и, тем более, не о «быстрых алгоритмах нахождения метрических сгущений с использованием матрицы парных расстояний в ранговых шкалах» или других страшных словах. Эти подходы и методы разработаны специалистами, их работоспособность не вызывает сомнения. А поговорить хотелось бы о том, нужно ли применять их и можно ли использовать полученный результат. По факту мы хотим ответить на вопросы: «Нужно ли машинное обучение в контексте информационной безопасности и что с ним там делать на примере своей деятельности?».

Об активном применении ML-алгоритмов в области информационных технологий и коммерции известно достаточно давно, но вот определиться с необходимостью ее использования в ИБ мы не могли, пока сами не ответили на следующие вопросы:

• область, где она будет применена;

• данные, которые могут быть предоставлены для анализа;

• результат, который хотим получить.

Ниже даны подробные ответы на каждый пункт.

«Очень трудно искать в темной комнате черную кошку. Особенно, если там ее нет»

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

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

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

По факту мы получили одну из основных задач ML: выявление закономерностей, существование которых мы предполагаем, но полной формальной информацией о них не обладаем.

Мужик ловит такси:

— Куда вам?

— Нет, к удавам я не поеду...

— Вы меня не правильно поняли...

— Куда вам надо?

— Ну, раз надо, поехали к удавам…

В свое время, занимаясь выявлением инцидентов даже в детально описанных и формализованных процессах, мы столкнулись с проблемами различной идентификации объектов и интерпретации действий с ними. Анализируя события в различных прикладных системах, таких как электронный документооборот, специализированный (дополненный) учет, аналитические системы, мы постоянно сталкивались с отсутствием сквозных идентификаторов и/или минимального достаточного набора признаков для каждого объекта и, как следствие, с невозможностью представить их как единое целое для любой автоматизированной системы. В меньшем масштабе эта проблема актуальна и для объектов доступа. Думаем, многие помнят свои 3–5 имен пользователей для каждой системы, где проводится работа.

Решение этих проблем было одним из самых масштабных с точки зрения взаимодействия с ИТ-, бизнес- (функциональными) подразделениями нашей организации и разработчиками прикладных систем. В результате мы прошли путь получения событий о безопасности из отладочных данных СУБД с использованием многострочных запросов к внедрению IdM с единым именем пользователя и консолидированным журналом событий с указанием действий над объектами из единого реестра.

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

Без решения этих задач применение ML на несвязанном объеме данных может не только привести к неинтерпретируемому результату, но и выявить ложные зависимости: например, увеличение количества попыток подбора паролей от среднего объема удоя коров в Калужской области.

Двое летят на воздушном шаре... Их унесло, и они не знают, где летят сейчас... Пролетают мимо холма, на котором сидит человек. Храбрые воздухоплаватели спрашивают его:

— Скажите, пожалуйста, где мы сейчас находимся?

Человек на холме долго думает, а потом отвечает:

— На воздушном шаре.

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

При этом такие пути решения, как:

• четкое определение соответствия между сотрудниками и процессами;

• детальная формализация процессов;

• введение дополнительных механизмов обоснования доступа

приводили к нерациональным и непропорциональным тратам ресурсов бизнес- (функциональных) подразделений.

Принимая решение использовать технологии ML при постановке задачи «обучение с учителем», мы понимали, что валидация данных, полученных по результатам использования, потребует достаточно больших дополнительных усилий от аналитика, отвечающего за разрешение инцидентов безопасности, в короткий период времени. Эти усилия включали бы:

• использование информации из наложенных средств безопасности, включая инженерно-технические;

• получение информации непосредственно от пользователя и его руководителей;

• построение гипотез о некорректном сборе событий об инциденте, их проверка и пр.

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

Надпись на надгробии: «Не все йогурты одинаково полезны...»

В заключение хотелось бы сказать, что технология ML уже показала себя как полезная и жизнеспособная во многих отраслях нашей жизни. Применять ее или нет в области ИБ в своей организации каждый из нас должен решить сам. Ее использование должно быть осознанным выбором, и мы надеемся, что описанные вопросы и ответы на них помогут вам сделать правильный выбор. У нас слишком мало времени, чтобы тратить его на необоснованные решения. А мы пока находимся в начале своего пути, и о результатах внедрения ML-системы, которая будет стоять на страже нашей ИБ, рассчитываем отдельно рассказать в ближайшем будущем.

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su