Big Data в ИБ – очередной хайп?

Автор: Рустем Маннанов, руководитель направления, отдел серверных технологий, ICL Системные технологии.

Презентация нашего видения развития стека инструментов Big Data в контексте ИБ на PHDays 9 ( https://www.phdays.com/en/ ) оставило неоднозначное впечатление. С одной стороны – заметно, что существует неподдельный интерес к теме, более того, многие специалисты ИБ, тесно и совместно с подразделениями ИТ работающие над темой обработки событий уже успели прикоснуться к данной тематике и набрать соответствующий опыт. С другой стороны, сложилось впечатление, что знания о текущих возможностях применения стека Big Data инструментов достаточно поверхностны. На вопросы - что это такое, когда это нужно использовать, а когда нет, и какую пользу может это вам принести получали иногда очень разные ответы – от «я знаю, что это не для нас», до «у нас уже есть – вон стоит решение вендора на букву S – нам больше ничего не нужно». Давайте вместе попробуем разобраться в том, что это такое, и как решения стека Big Data могут помочь решать проблемы в области ИБ.

Термин Big Data появился далеко не вчера. Многим - даже стал несколько обыденным. Для многих стал «почти ругательным». Уважаемая компания, обожающая рисовать синие квадраты в 2015 году даже исключила этот термин в своих заключениях, и разделила его на пятерку отдельных технологий – видимо оттого что он значил «все» и «ничего» одновременно и невозможно было понять, что именно имелось ввиду, когда об этом говорили. Многие успели прикоснуться к большой волне хайпа на Big Data, свалились в кривую завышенных ожиданий и отложили эту тему до лучших времен. Некоторым, особо упорным - даже удалось получить из всего этого тренда работающие продукты.

При чем здесь Информационная Безопасность?

Зрелым с точки зрения ИБ компаниям на текущем этапе развития технологий - альтернатив построения единого хранилища событий ИБ на стеке технологий Big Data для целей информационной безопасности по факту не осталось.

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

· Централизованной антивирусной системы

· Системы контроля утечек данных (DLP)

· IDS (или если бюджет позволял – IPS на критичных участках инфраструктуры)

· Системы управления событий информационной безопасности (SIEM)

· Прокси-серверов и систем безопасного доступа в интернет

· Систем управления логами (Log Management)

· Систем управления инцидентами ИБ (IRP)

· Систем управления идентификационными данными (IDM)

· Локальных или облачных систем защиты от DDOS

· И прочих полезных в реальной жизни ИБ систем и процессов

У кого-то этот список может быть короче, у кого-то длиннее. Те «у кого длиннее» гордо ходили к руководству и с упоением рассказывали, что вот – смотрите чего мы тут интегрировали, безопаснее некуда, жизнь прекрасна и стабильна. Риски минимальны, спите спокойно коллеги. И действительно - имели на то полное право. Казалось бы, все было хорошо. Если бы не одно «но» - умопомрачительными по масштабу шагами вперед шла цифровизация основных бизнес-процессов. Термины Agile, DevOps, Time To Market взбудоражили умы многих, и маятник качнулся в обратную сторону и из процесса разработки новых решений и продуктов как раз выпали те службы ИБ, у кого список был «длиннее всех». Ждать реализации всех мер ИБ и интеграции этих продуктов в Distruptive-решения никто не хотел, да и объективно и не мог. Исходно целостная стратегия построения набора «специализированных решений» для разных предметных областей ИБ стала трещать по швам. Гвоздем в крышку гроба «классического» точечного подхода в ИБ стала контейнеризация. Решений, выходящих за рамки «контроля входа\выхода на периметре» - нет. Разговоры про DevSecOps так и остаются по большей части разговорами, и так будет продолжаться пока ключевая метрика – Time To Market поставлена во главу угла.

Особо продвинутые коллеги, заранее предусмотрев данный сценарий, стали готовиться к нему заранее, и, казалось бы, ответ придуман и очень давно. SIEM казался решением, позволяющим и от регуляторов закрыться, и процесс корреляции построить, и источники привести к единому формату, и инцидент эскалировать в какую-нибудь IRP. Однако реальность оказалась не так радужна. Для одних – производительность SIEM стала узким местом, для других – не подошла цена EPS, третьим не повезло еще больше – известный глобальный вендор решений ушел из России. Для избранных, бизнес которых рос и масштабировался экспоненциально, стали актуальны вопросы, на которые «классические» SIEM ответить не в состоянии. Как детектировать аномалии, не поддающиеся регулированию четкими правилами? Почему расследование инцидента ИБ занимает месяц, когда Google отдает мне информацию за 500 миллисекунд? Почему задавшись целью хранить не только «скоррелированные» но и «сырые» события совокупная стоимость владения SIEM растет в 10 раз, он ведь не начинает приносить в 10 раз больше пользы? Как сохранить приемлемый уровень риска и стоимости при увеличении потока событий в 20 раз, например, вследствие внедрения микросервисной архитектуры в основных бизнес-приложениях компании? Как приносить больше пользы ключевым заказчикам? Как «встроить» процессы обеспечения ИБ в ключевые бизнес-процессы организации?

Вопросы очень непростые, как и ответы на них.

Но общее у всех вопросов одно - ответы лежат в плоскости, которая существует и развивается лет тридцать – управление данными. Да, не удивляйтесь – события ИБ – такие же данные, как и транзакции, клиентские операции, справочники в CRM и остатки на складах. Методы работы с ними уже пережили не одну и даже не две «смены парадигмы» - от классических OLAP – схем и кубов, до «модного» нынче распределенного хранения и обработки данных на распределенных вычислительных кластерах. При этом в подавляющем большинстве организаций такие решения, так же, как и компетенции - есть. Так почему бы не применить существующий стек технологий, давно уже переживший пору «детских болезней» для благих целей обеспечения ИБ – построить Security – ориентированное хранилище данных - Security Data Lake?

Но, как ожидаемо, «серебряной пули» не существует. На пути встанут множество преград. Ключевые вызовы, с которыми сталкиваются подразделения ИБ при реализации подобных инициатив:

1. Стек технологий нетипичный для служб ИБ. Дефицит квалифицированного персонала.

2. Необходимость подключить множество источников, при этом добавление их должно проходить «прозрачно» основе открытых и стандартных протоколов.

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

4. Нужно обрабатывать и предоставлять интерфейсы: визуальные (для аналитиков), технологические (для интеграции в существующие ETL\BI инструменты и процессные инструменты ИБ)

5. Требуется организация системной работы над качеством данных, в том числе и на источниках. Если этого процесса нет – «озеро данных» быстро превращается в «болото» и ценность решения теряется.

При этом не нужно забывать, что Data Lake – такое же хранилище данных, как и любое другое, а значит придется:

· Определить цели и задачи использования Data Lake

· Определить модель и методологию построения хранилища

· Определить требования к источникам

· Выбрать инструменты извлечения данных

· Разработать процедуры загрузки данных

· Сделать первичную загрузку данных

· Сделать инкрементальную загрузку данных

· Бесконечно поддерживать изменения на источниках

· Бесконечно работать над качеством данных

При этом, очень важно понимать – парадигма Security Data Lake – не цель, и не дорогая красивая игрушка, а инструмент достижения долгосрочных стратегических целей. При этом, вполне уместны сценарии, когда Security Data Lake стоит «после» SIEM - решения, так и сценарии, когда является для него основным поставщиком данных.

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