Финансовая сфера

Банковское обозрение


  • Сергей Лебедь (Сбербанк): О зрелости SIEM и SOC
05.10.2016 Интервью

Сергей Лебедь (Сбербанк): О зрелости SIEM и SOC

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


— Существуют различные методики оценки зрелости SOC, например SOMM (Security Operations Maturity Model). Как бы вы, опираясь на эту методику, оценили зрелость SOC Сбербанка?

— По любой из методологий оценки мы находимся на первой (левой) половине шкалы. Мы это прекрасно понимаем и поэтому прямо сейчас проводим глобальные изменения в технологиях работы нашего SOC. Работа ведется по всем направлениям: и процессы, и люди, и технологии. Планка, которую мы поставили перед собой, находится на очень серьезной высоте. Уровень зрелости должен вырасти сразу на несколько пунктов. Мы должны уверенно держаться не ниже 2/3 шкалы оценки по любой из существующих методологий. К примеру, по SOMM, это четвертый (предпоследний) уровень с уверенным трендом в сторону максимума — пятого уровня.

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

— Может ли считаться SOС полноценным, если у него нет SLA (Service Level Agreement), подразумевающего гарантированное время реагирования на различные события ИБ? Как обстоят дела с этим вопросом в Сбербанке?

— На наш взгляд, не может. Это принципиальный вопрос как с точки зрения понимания, зачем бизнесу ИБ, так и с точки зрения дисциплины внутри подразделения. Заключая SLA, мы начинаем лучше понимать сами себя. Это касается прежде всего ответственности людей за свою работу. Поэтому отношение к подготовке SLA соответствующее. В Сбербанке это процесс имеет две составляющие.

Во-первых, это SLA в вопросах функционирования оборудования защиты, стоящего «в разрыв» и участвующего в процессе предоставления бизнес-сервиса. Здесь мы встроены в IT-процессы и работаем по четким соглашениям об уровне услуг: проблемы с нашим оборудованием — это прямые потери бизнеса.

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

— Не могли бы вы немного рассказать о регламентах реагирования на инциденты и метриках эффективности реакции в Банке?

— Текущие регламенты реагирования в Сбербанке основаны на принципах ITSM (IT Service Management, управление IT-услугами), так как эволюционно они отталкивались от задачи поддержки оборудования защиты (например, межсетевых экранов и криптомарштрутизаторов). В них используются классические метрики, например количество инцидентов, решенных на первой линии, среднее время реакции на инцидент, среднее время владения (для сложных инцидентов, маршрутизируемых между разными группами). Сюда же можно отнести среднее время купирования угрозы, среднее время решения (в части всех формальных процедур расследования).

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

— Какое количество инцидентов фиксируется?

— Ежедневно мы фиксируем около полумиллиарда событий ИБ. После корреляционной обработки остается около 100 подозрений на инцидент, которые преобразуются ежедневно в 50–60 инцидентов.

— Не пересекаются ли зоны ответственности DLP и SIEM? Нет ли синергии от работы этих двух систем в области защиты от внутренних нарушений?

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

— Удалось ли обеспечить анализ DNS-трафика в режиме реального времени и оперативное обнаружение нарушений безопасности?

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

— Есть ли примеры устранения неизвестных угроз за счет автоматического обнаружения нарушений безопасности?

— Такие примеры, безусловно, есть. Были случаи, когда по косвенным признакам мы обнаруживали вредоносный код, который не определялся антивирусами. Сейчас мы активно внедряем анти-APT-решения (advanced persistent threat, целевая кибератака) и рассчитываем повысить уровень выявления неизвестных угроз.

Что касается противодействия вирусам на смартфонах клиентов, на которых установлено приложение мобильного банка Сбербанка, то этим занимается «Лаборатория Касперского» со своей IT-инфраструктурой. Мы же получаем от них агрегированные данные об активности зловредного кода и предпринятых действиях по его нейтрализации.

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

— Имеет ли смысл хранить всю собранную информацию? Как обеспечить сохранность юридически значимых улик?

— Объем хранимой информации должен быть обоснован. К примеру, в рамках SIEM-системы мы храним информацию за прошедшие полгода. Это позволяет нам решать большинство задач корреляции событий. При этом мы понимаем, что среднее время реализации APT-атаки на банк несколько больше. Поэтому мы не ограничиваемся только функционалом SIEM, а занимаемся также внедрением решений класса Big Data, которые позволяют нам работать с ретроспективным анализом на значительно большем интервале времени.

Совсем недавно мы шли по традиционному пути, пытаясь подключить все источники, использовать все правила корреляции, которые только можно придумать. Это делалось для того, чтобы подозрения на инцидент были с большей вероятностью признаны инцидентами. Сейчас же у нас завершается проект «Фаза 0» построения SOC, который реализует компания IBM.

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

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

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

— Как технически реализованы хранение этих гигантских объемов данных и поиск в них корреляций?

— Сейчас для нас технически не является большой проблемой хранить и обрабатывать много данных. Мы выделили для SIEM около 100 ТБ памяти и при правильной оптимизации хранимой информации (а в SIEM-системах этому придается первостепенное значение) поиск и корреляция проходят без труда. Но мы понимаем, что объемы растут, и нам надо очень внимательно к этому относиться. Важно знать возможности своей SIEM-системы и понимать, какими инструментами мы располагаем для снижения нагрузки. Это и системы предварительной корреляции, и Big Data. Очень важно держать руку на пульсе, а не надеяться, что SIEM «переварит» все.

— Как построена работа людей, которые описывают модели угроз и правила корреляции? Есть ли какая-либо методическая поддержка в этом вопросе со стороны регуляторов?

— Это очень важный вопрос, так как подход к написанию правил и моделей — основа SOC. Если мы используем SIEM, то отсутствие этих правил — это отсутствие инцидентов. В последнее время мы многое переосмысливаем в этом вопросе. Мы поняли, что надо отталкиваться от задачи (кейса) и спускаться постепенно вниз, разрабатывая правила и подключая нужные источники данных.

Ведь данных так много, что важно их использовать с умом. Подход, когда можно было загрузить все, а потом думать, что с этим делать, — устарел. С данными надо работать максимально эффективно и сразу отвечать на вопрос: «Что я хочу получить?» Это позволяет провести оптимизацию во многих местах сразу.

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

— Не замкнут ли Сбербанк только на себя? Есть примеры кооперации с внешними источникам данных?

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

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

Дальше, мы видим взаимодействие с поставщиками решений, например SOC Citibank отслеживает доступность серверов обновлений разработчиков различных IT-решений — это и Microsoft, и HP и Apple. И Банк понимает, что если теряются каналы с обновлениями или с технической поддержкой, то это может привести к реализации риска, который сам Банк не отрабатывает, но может заблокировать на время свои соответствующие сервисы.

— А как Сбербанк проверяет уровень своей защищенности?

— Тут всего не перечислить. Скажу только о работе «белых хакеров», которые могут тестировать работу средств ИБ как с внешнего периметра, так изнутри. Мы не исключаем, что потенциально нарушитель может быть сотрудником Банка или неким человеком, который как-то попал в IT-инфраструктуру Банка и действует сообща с реальными хакерам.

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

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

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






Новости Релизы
Сейчас на главной

ПЕРЕЙТИ НА ГЛАВНУЮ