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

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

Какими же технологиями можно и нужно дополнить классическую SIEM, которая является основой любой SOC? В последнее время заметен тренд на внедрение ИБ-систем, анализирующих действия пользователей с учетом контекста. Уже сам факт наличия такой системы с демонстрацией ее активности дисциплинирует сотрудников. Но, к сожалению, в настоящий момент нет отраслевого стандарта на системы класса User and Entity Behavior Analytics (UEBA), которые закрывали бы все потребности финансовых организаций, поэтому чаще всего имеет место матрица различных решений. Это различные Employee Monitoring Tools (EM), Network traffic analysis (NTA), Data Loss Prevention (DLP). Если говорить о финансовых организациях, то в списке «must have» появляется еще и Anti-Fraud Solutions. На Западе в связи с бурным ростом облачных технологий растет актуальность систем класса Cloud Access Security Broker (CASB), в будущем такой спрос должен сформироваться и у нас.

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

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

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

Универсальной мерой целесообразности всегда является «цена инцидента». Скорость реакции на инцидент должна давать возможность уменьшить убытки организации

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

Если наибольший ущерб может быть вызван внутренними инцидентами, в основе которых лежат действия сотрудников, или сбоем в оборудовании и в бизнес-приложениях, то нужно обязательно включать в периметр журналы событий серверов и рабочих станций пользователей, журналы аудита СУБД, логи бизнес-приложений (CRM, ERP, АБС, биллинг и пр.) Важно, чтобы SIEM-система не дублировала функции antifraud-системы банка.

Если подойти к вопросу с точки зрения минимизации внешних источников, то наиболее важными источниками являются те, которые требует регулятор ГосСОПКА, ФинЦЕРТ. Есть и другие источники от крупнейших производителей антивирусного ПО. Однако нужно отметить, что они все во многом дублируют друг друга, так что целесообразность их использования неочевидна.

Конечно, во главе любого центра теперь будут процессы управления, и для менеджеров нужен слой визуализации в разрезе контроля основных KPI SOC: общее количество событий, количество выявленных инцидентов в динамике с возможностью drill-down в различные разрезы по классификациям инцидентов, по источникам.

Кроме того, смещение парадигмы занятости персонала требует новых технологий и инструментов. Тут на первый план выходят технологии потоковой аналитики и предиктивного анализа, содержащие в себе смесь инструментов ML/AI. Ведь теперь главными являются способность выявления аномалий в потоке данных всей организации и способность молниеносно реагировать.  

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

Отказ от коробочных решений приведет, с одной стороны, к снижению затрат на лицензии, но с другой — к увеличению затрат на адаптацию open-source программного обеспечения и создание собственного

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

Также не обойтись без поиска резервов уменьшения совокупной стоимости владения (TCO). Как известно, ТСО складывается из затрат на оборудование, на лицензии ПО и выполнения работ.

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

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

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