Статья

Awesome Image
Awesome Image

4 августа 2019


Давайте вместе попробуем разобраться в том, что это такое, и как решения стека Big Data могут помочь решать проблемы в области ИБ


Презентация нашего видения развития стека инструментов 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? Но, как ожидаемо, «серебряной пули» не существует. На пути встанут множество преград. Ключевые вызовы, с которыми сталкиваются подразделения ИБ при реализации подобных инициатив:

  • Cтек технологий нетипичный для служб ИБ. Дефицит квалифицированного персонала;
  • Необходимость подключить множество источников, при этом добавление их должно проходить «прозрачно» основе открытых и стандартных протоколов;
  • Необходимо переиспользовать данные из SIEM, особенно если в его развитие вложено значительное количество ресурсов;
  • Нужно обрабатывать и предоставлять интерфейсы: визуальные (для аналитиков), технологические (для интеграции в существующие ETL\BI инструменты и процессные инструменты ИБ);
  • Требуется организация системной работы над качеством данных, в том числе и на источниках. Если этого процесса нет – «озеро данных» быстро превращается в «болото» и ценность решения теряется.


Data Lake

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

  • Определить цели и задачи использования Data Lake;
  • Определить модель и методологию построения хранилища;
  • Определить требования к источникам;
  • Выбрать инструменты извлечения данных;
  • Разработать процедуры загрузки данных;
  • Сделать первичную загрузку данных;
  • Сделать инкрементальную загрузку данных;
  • Бесконечно поддерживать изменения на источниках;
  • Бесконечно работать над качеством данных.


"Парадигма Security Data Lake – не цель, и не дорогая красивая игрушка"


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