Всю свою историю информационная безопасность тяготела к победам «в прошедшей войне» − основу функционирования средств защиты составляли «черные списки», явные признаки атак и нарушений. Вспомните, как антивирусные производители мерялись количеством сигнатур в антивирусных базах, а потом – частотой обновления этих баз. Все потому, что каждая антивирусная сигнатура – образец вируса – это фактически хотя бы один пострадавший, на основе ущерба которого выделены точные признаки опасного вируса. Поэтому, как только признак вируса определен, он должен быть немедленно распространен всем антивирусным клиентам, чтобы они могли его распознать и заблокировать.
Что не запрещено…
«Черные списки», сигнатуры, шаблоны атак, цифровые отпечатки, регулярные выражения – все эти механизмы лежат в основе большинства средств безопасности, задача которых – обнаружить признак атаки или неправомерных действий пользователя в потоке событий, коде, трафике, сообщении и т. п. Уже упомянутые антивирусы, межсетевые экраны, системы обнаружения вторжений, DLP-системы, антиспам, статические и динамические системы исследования защищенности приложений, системы противодействия мошенничеству, GRC-системы, SIEM и т. д. – каждое такое средство защиты содержит «черный список»: базу образцов атак, уязвимостей или нарушений, а также средство их постоянного обновления.
Все это работает достаточно точно и быстро, образец последовательно сравнивается с признаками уже найденных нарушений, до тех пор пока не будет найдено совпадение и система не отреагирует на него так, как положено реагировать на конкретное нарушение (сценарий реакции обычно включается в базу признаков). Или же «черный список» не закончится, тогда включается сценарий позитивного реагирования типа «нарушений не обнаружено». Поэтому метод «черных списков» иногда называют «всё, что не запрещено, разрешено», в противовес «белым спискам» − «всё что не разрешено, запрещено».
Современные вычислительные мощности и средства онлайн-обновления сигнатур позволяют осуществить защиту быстро и дешево. Мягко говоря, вся информационная безопасность сегодня – индустрия поиска признаков нарушений в потоках данных. Признаком атаки или нарушения может быть событие, последовательность событий или корреляция различных событий, лишь бы разработчики смогли это выразить шаблоном, регулярным выражением, формулой, графом и т. п. Основная проблема информационной безопасности, во многом обязанной своим восхождением именно «черным спискам», заключается в том, что такой метод защищает только от известных атак, уязвимостей или неправильных действий.
«Черные списки» перестают работать, если атака или нарушение проводится таким образом, который не был выявлен ранее и его не смогли смоделировать в лаборатории, занимающейся пополнением образцов неправильных последовательностей данных и их корреляций. Если атака, уязвимость, мошенничество произошли хотя бы один раз, то исследователи быстро добавили бы найденный при расследовании признак в базу запрещенных действий. А если эти опасные действия происходят впервые?
Что не разрешено…
Сегодняшние атаки успешно маскируются под легитимные действия, чтобы оставаться незаметными для средств защиты, работающих по принципу «черных списков». Переключиться на «белые списки» (запретить все, что явно не разрешено) не всегда возможно – для этого пришлось бы описать все варианты действий (свойств кода, трафика) и запретить остальные, что в большинстве информационных систем нереально.
Одними из первых с неэффективностью «черных списков» столкнулись разработчики анализаторов поведения пользователей (User Behavior Analytics − UBA). Сегодня не составляет проблемы собрать, хранить и обрабатывать огромное количество данных о пользователе корпоративной информационной системы, но как выбрать из этого облака событий те действия, которые опасны? Можно, конечно, пофантазировать, поставить себя на место нарушителя и записать некоторые признаки. Например, на этом компьютере была нажата комбинация клавиш, приводящая к снимку экрана, а в тот момент был открыт конфиденциальный файл. Но это такое небольшое количество запрещенных действий (причем условно запрещённых, поскольку существуют вполне легитимные процессы, требующие подобных действий, скажем, подготовка внутрикорпоративной презентации), что заводить отдельное программное решение ради нескольких корреляций неэффективно.
С похожими проблемами столкнулись и производители решений по противодействию мошенничеству (antifraud). Невозможность придумать точные признаки нарушений при, например, осуществлении онлайн-платежей, привела к довольно циничному решению: сигнатура нарушения делается достаточно широкой, и все совпадения блокируются, если срабатывание будет ложным. Инициатору платежа придется позвонить и провести этот платеж в ручном режиме. В большинстве таких систем признаком мошенничества являются платежи в один день из трех стран, от чего часто страдают путешественники, летящие с пересадкой: расплатился одной картой в Москве, затем на пересадке в Париже, а по прилету в Мехико при попытке выпить кофе ваш платеж заблокируют. Вы будете звонить, ждать оператора, авторизоваться, и вот уже с учетом роуминга ваша чашечка кофе по цене сравняется с бутылкой виски. Или другая банальная легальная ситуация: находясь в отпуске, вы решили поздравить зарубежного друга с днем рождения и отправить ему букет цветов, но платеж русской картой из Таиланда на немецкий сайт будет воспринят системой как мошеннический и не пройдет. Альтернатива – позвонить и сообщить заранее о планируемой поездке или операции, и тогда вас или конкретный платеж на какое-то время внесут в исключение, т. е. выведут из-под мониторинга системы безопасности, что тоже не очень удобно.
Сильные и слабые
Но не всегда пользователь будет так терпелив и последователен, как плательщик в системе антифрода. Ложные срабатывания систем безопасности в цифровых системах приводят к потерям, с которыми не будет мириться владелец цифрового процесса. Мы попадаем в дилемму: «черные списки» не покрывают всего пространства нарушений, а «белые списки» делают систему настолько жесткой, что ее эффективность катастрофически падает. «Нужно что-то среднее, да где же его взять», как пел Булат Окуджава. И тут на помощь приходит искусственный интеллект.
Если у вас есть достаточно большой массив размеченных данных, т. е. вы можете сказать искусственному интеллекту, что хорошо, а что плохо, то у вас появляется возможность поручить ему самостоятельно определить признаки «хорошего» и «плохого». Скажем, у вас имеется массив переписки пользователей информационной системы за год, и вы можете явно указать, например, что вот эти пользователи уволились, а эти нет. Тогда задача найти, что общего как в данных, так и в динамике у уволившихся людей, – стандартная задача для искусственного интеллекта, это то, в чем он действительно хорош. Если данные собраны и размечены хорошо, модель построена надежно и ваши бизнес-процессы, использующие электронную почту, не менялись, вы получите отличный инструмент прогнозирования увольнений. Искусственный интеллект подскажет, например, что переписка конкретного сотрудника на 92% похожа на переписку сотрудника, который через две недели уволится. Вам не нужно будет вручную вводить контентные (конкретные термины и их сочетания) или статистические (частота, размер, плотность, разнообразие и т. п.) признаки скорого увольнения – искусственный интеллект определит их сам. Заметим, что явно сформулировать эти признаки он не способен. Как и в любой задаче с предиктивной аналитикой, он лишь может сказать, что данные, которые он обрабатывает, в высокой степени совпадают с данными, которые однажды привели к конкретному результату.
Тот же принцип применим и к противодействию мошенничеству. Рассмотрим, например, мошенничество при закупках. Пусть есть жесткие корпоративные правила, чего нельзя делать, они работают как стоп-сигналы: например, конкурс не считается состоявшимся, если нет трех предложений от различных участников. Мы можем придумать «черный список», состоящий из придуманных нами способов обойти это правило: скажем, все три или два из трех предложений были выложены на сайт закупок с одного ip-адреса. Либо метаданные файлов предложений содержат совпадения по автору, времени или месту создания. Это явно указывает на подделку предложений или сговор участников, т. е. налицо признаки мошенничества. Можно ввести как подозрительный признак наличия в базах регистраторов пересечения акционеров в компаниях, подавших заявки. Но что делать, если наша фантазия по составлению «черных списков» иссякла, а закручивание гаек детальным регламентированием всего и вся при закупках замедляет и удорожает процесс?
В этом случае можно создать «цифрового двойника процесса» − набор событий в десятках информационных систем, задействованных в процессе закупок: электронной почте, мессенджерах и других средствах коммуникации, вплоть до корпоративной АТС (если нет доступа к контенту – не беда, сойдет и факт коммуникации, время и место коммуникации, длительность, регулярность и другие неконтентные атрибуты), системе документооборота, учетных системах, ERP-системах, серверах доступа в Интернет, соцсетях, логах удаленного доступа, событий на рабочей станции, СКУД-систем, носимых устройств, «умных» камер и т. п. Любые действия сотрудников в процессе закупок разделим на сильные – явно продвигающие закупку по этапам процесса в информационных системах, и слабые – сопутствующие события, связанные с сильными событиями. Например, действие «утвердить», выразившееся в постановке галочки в специальном поле закупочной системы, – сильное. А уточняющие звонки, заходы в Интернет, базы данных учредителей и т. п., которые были перед утверждением, – слабые. Если слабые действия происходят, а связанное с ними сильное так и не случилось – это нормально. А вот если прошло сильное действие, а слабых не было – плохой признак. Возможно, галочка поставлена инсайдером, халатным пользователем, а то и хакером или же она появилась в результате ошибки либо компьютерного сбоя.
Итак, мы получили скелет сильных, обязательных действий и вокруг них облако слабых, необязательных действий. Если у нас есть сильные и слабые данные тысяч закупок приблизительно одинаковой номенклатуры (очевидно, что процесс закупки танка отличается от процесса закупки офисной бумаги), то появилась работа для искусственного интеллекта. Самое время поручить ему выбрать какой-то небольшой процент экземпляров рассматриваемого процесса (конкретных закупок), которые отличаются от остальных, т. е. указать на аномалии.
Важно понять, от чего отсчитывать аномалии. Хорошо, если процесс не просто детально, до мелочей описан (назовем его идеальным), но и соблюдается именно так, как описан. Даже первое – большая редкость, обычно детально описываются лишь те процессы, которые попадают под регулирование, например проведение платежей в целях борьбы с отмыванием доходов. Как правило, процессы описываются достаточно крупными блоками, внутри которых есть регламенты, но как они реализованы в конкретных информационных системах на уровне событий – нигде не описано. Второе – скорее из области фантастики. Даже в детально описанном процессе на уровне событий имеются нюансы, выполнение которых отдается на откуп исполнителям. Тем не менее необходимо выбрать, от чего отсчитывать аномалии, т. е. принять какой-то процесс за «норму». Обычно за норму берется не идеальный процесс, а статистически средний: для владельцев процесса степень отличия нормального процесса от идеального − отдельный шок.
Владелец процесса может решить, что делать с аномалиями, т. е. с экземплярами процесса, которые явно не укладываются в статистически средний сценарий, – блокировать, провести с ручным контролем или дать закончиться и проводить расследование. Все зависит от бизнес-целей.
Заключение
Является ли вышеописанное в принципе информационной безопасностью? Зависит от определений. Это точно не подпадает под классическое определение – мы с вами не искали уязвимости, не ловили хакеров и не оперировали триадой «конфиденциальность – целостность – доступность». Мы смотрели, как происходящие в цифровой системе события связаны с бизнес-процессом и как они влияют на результат. В такой постановке задачи нам вообще неинтересно, чем вызваны аномалии: кибератакой, мошенничеством, ошибкой оператора или компьютерным сбоем. Нам важно, чтобы «хорошие» процессы не замедлялись, а «плохие» не происходили. Но именно в этом и есть сверхзадача безопасности, не правда ли?
Такой подход может существенно изменить ландшафт безопасности. Вспомним пару нашумевших случаев: покупку квартиры с помощью нелегитимной электронной подписи и фотографии банковских счетов, сделанных с экрана. Для вышеупомянутого подхода это «сильные» действия в отсутствии «слабых», вопиющие аномалии. Оформление продажи квартиры, которая не выставлялась на продажу, не проходила оценку, вообще ничего с ней не происходило в отличие от тысяч других сделок – явно что-то идет не так. Или сотрудник банка обращается к данным клиентов, но на это не было поручений ни от начальника, ни от клиентов, запросу не предшествовали никакие действия, обычные для обращения к клиентским данным в миллионах других случаев, – стопроцентная аномалия. Ни к чему сложные системы безопасности, если ты контролируешь события цифрового процесса во всех приложениях, в которых он происходит.
В любой области применения «любимое» занятие искусственного интеллекта – раннее обнаружение – смертельной болезни или нехватки товара, выхода детали из строя или мошенничества. Чем раньше будет обнаружена потенциально опасная проблема, тем проще будет ее решить. Наконец-то мы дожили до того, что огромное количество данных и относительно дешевые средства их сбора и обработки позволяют это делать даже небольшим компаниям.
