Автор: Илья Лорич, ведущий инженер-эксперт Innostage
Представьте себе мир, в котором инженер, эксплуатирующий средства защиты информации (СрЗИ), может открыть единое окно управления и выполнить большинство своих должностных задач в одном интерфейсе. Или мир, в котором инженер сопровождения, отслеживающий работоспособность средств защиты, может получить весь необходимый контекст «здесь и сейчас», с учетом временного разреза, задач и уведомлений в плановых и регламентных обязанностях — также в одном окне. А может быть мир, где руководитель департамента ИБ может отслеживать все необходимые метрики, текущие и плановые задачи, корректировать вектор развития и оценивать текущую ситуацию и покрытие, не бегая по почтовым сервисам, отчетам и трекерам?
А если все эти миры возможно реализовать в одном продукте? Именно с таким вопросом мы начали лето этого года. Статья будет посвящена концепту единой платформы управления средствами защиты информации, которая должна не только упростить жизнь специалистам ИБ, но и снизить порог вхождения в профессию эксплуатантов разных средств защиты, а также предоставить механизмы ситуативной аналитики и оркестрации повседневных и регламентных действий.
Предпосылки
Начнем по порядку. Мы – InnoStage, как компания-интегратор, вендор и сервис-провайдер в сфере ИБ, ежедневно сталкиваемся с широким спектром разноплановых задач, которые часто требуют творческого подхода. Но в большинстве случаев эти задачи ложатся в цикл: анализ (потребности) – предложение (ТЗ) – формализация (проектирование) – реализация – презентация (ПСИ) + обучение – техническое сопровождение и дальнейшая модернизация. Другими словами, ГОСТовый подход, никого этим не удивишь. Но на комплексных проектах, где внедряются более двух-трех решений и модернизируются или обновляются уже существующие решения, мы стали замечать, что на этапах принятия в эксплуатацию и в процессе дальнейшей работы у Заказчиков, зачастую возникают проблемы. Работа проделана большая, системы настроены, и каждая из них уникальна. И с этими системами нужно уметь работать. У каждой системы есть своя консоль управления, свой набор функций, управляющих воздействий, аналитики, сработок, задач на обслуживания и многое другое.
В современных реалиях, когда тренды направлены на оптимизации процессов, небольшой штат инженеров ИБ в момент принятия таких систем начинает осознавать – это теперь все на нас. Все эти консоли с кучей кнопочек, табличек, представлений… И теперь талмуды эксплуатационной документации заменяют сначала книжку перед сном, а потом становятся настольной библиотекой, занимающей место, где привычно стоял кофе.
Сейчас сделаем оговорку, важную для восприятия контекста текущей статьи: мы не говорим, что консоли управления средствами защиты информации плохие или их недостаточно. Наоборот, годы рефлексии Российских производителей и опыта взаимодействия с Заказчиками сделали системы и консоли управления из первых «топорных» решений управления действительно мощные комбайны, позволяющие выстраивать не только точечные защитные функции в архитектуре ИБ, но и в архитектуре ИТ. Но и вместе с тем, сильно повысили требования к набору компетенций и знаний конкретных решений, чтобы в т. ч. проводить ежедневную эксплуатацию.
Пообщавшись с коллегами, пришло понимание, что сложность первоначального вхождения в функционал вновь сдаваемых систем, это не единственная проблема, с которой сталкивается служба ИБ в части взаимодействия с множествами консолей управления. Хотя предпосылки «плюс-минус» у других проблем одинаковые.
Вот примеры этих проблем:
Отложенный или отсутствующий тюнинг, потому что в «моменте» нужно было разобраться, а других задач хватало.
Аналитика по событиям откладывается: «Анализ данных по сработкам СрЗИ сделаю, когда запросят. Его же надо сводить».
Поиск нужных функций: «А в какой вкладке находится та или иная операция? — «Ай, не важно, не горит».
Ограничение доступа для новичков: «Молодняку» доступ не давать — сам сделаю, а то еще чего сломает».
Выполнение регламентов по памяти: «Так, что у нас по плейбуку — нажать здесь, отправить письмо, проследить сроки, а потом нажать вот здесь — не забыть бы чего и не пропустить».
Отслеживание покрытия: «Что у нас с целевым покрытием СрЗИ?» «Надо открыть Excel, там все записано. А еще на прошлой неделе подключили 3 агента. Надо учесть бы…»
Проверка событий: «Сработки были?» - «Сейчас схожу посмотрю».
И многое-многое другое… Жизненно, не правда ли?
От идеи к концепту
Перейдем к описанию того, что же мы придумали. Но сначала немножко о целях, которые мы преследуем:
сократить количество панелей СрЗИ, используемых в повседневной деятельности;
снизить порог вхождения в администрирование СрЗИ для начинающих ИБ-специалистов;
объединить параметры работоспособности (health check) СрЗИ в одном окне для оперативного реагирования на отклонения;
автоматизировать рутинные процессы с использованием готовых сценариев действий;
унифицировать доступы для сотрудников, выполняющих типовые операции;
повысить зрелость эксплуатации текущих СрЗИ и выявления «Целевого покрытия».
Важно отметить, что помимо целей мы сформулировали ряд ограничений, которые позволят сделать что-то полезное, но при этом не слишком сложное для восприятия (мы же все же про упрощение):
Мы не делаем дубли существующих консолей управления у себя. У нас нет цели повторить вендорские решения. Нам нужно сделать то, что используется часто и приносит понятную ежедневную полезность.
Мы не разрабатываем вторые SOAR, VM, SIEM и другие аббревиатуры, у которых есть свой полноценный функционал и процессинг. Но мы берем лучшее от них в части функциональности и интеграции с ними.
Если нам приходится придумывать функционал – значит, он сложный и на ранних стадиях нам не подходит. Он должен исходить «от сердца», от болей,которые мешают спать, и формулироваться просто.
Наша платформа видится многослойным пирогом, где каждый слой – это набор функций. Они формируются по принципу: мы берем лучшее из возможностей разных систем и консолей управления. Затем дополняем это сценариями использования, основанными на многолетнем опыте внедрения, эксплуатации и поддержки. При этом мы стараемся поставить себя на место пользователя. И в результате получается нечто, что должно упростить жизнь и помочь выстроить процессы и контроль.
Пройдем коротко снизу вверх. Снизу нас встречает слой интеграции, задача которого собрать данные, выполнить воздействия, отдать данные. По сути, набор команд по взаимодействию с целевыми системами, базирующиеся на определенных типах транспорта (коннекторы).
Над ним идут два основных слоя. Операционный – все то, что повседневно делает инженер ИБ на средствах защиты, и все то, что может ему в этом помочь. Регламентный же слой нужен, чтобы выстроить все контроли, сформировать планы, а из них задачи, которые позволят обеспечивать нормативное функционирование и с точки зрения техники, и с точки зрения регулятора и лицензирования.
Верхушка нашего пирога – аналитический слой. Это вся та информация, которая позволит инженеру в моменте понять, где требуются его руки здесь и сейчас, а руководителю понять эффективность и зоны роста.
Можно бесконечно обсуждать, какие возможности надо добавить в каждый функциональный блок, а также расширять количество блоков и их наполнение. Однако на старте мы придерживаемся одного простого принципа: «Часто» + «Полезно».
В основе нашего продукта планируется комбинация:
сущности (то, с чем взаимодействует пользователь),
рабочих процессов (то, что формирует нужные данные в нужных полях и предоставляет механизмы взаимодействия),
данных и их визуализации (дашборрды и виджеты),
функциональности, которые формируются из пользовательских историй,
коннекторов, т.к. основная ценность – это взаимодействие со сторонними системами, без них никуда.
Все это очень сильно напоминает системы классов ERP, ITSM, SOAR.
Т.к. мы интегратор по ИБ и знаем, как работает класс таких решений, и наша задача решать проблемы, было принято решение строить продукт на базе no-code/low-code платформы. Решение пришло мгновенно, как и выбор конкретного вендора, а именно нашего партнера Security Vision. Коллеги в основе своих продуктов разработали гибкую и удобную платформу, которая позволяет оперативно формировать нужные нам функциональности, и при этом уже является ИБ-направленной.
Что делаем сейчас
Все вышеперечисленное требует полного классического цикла разработки, но с учетом возможностей no-code/low code.
Обозначим основные вехи того, что мы делаем сейчас и куда идем:
Собираем пользовательские истории (User story). Берём всё, что хотелось, но по разным причинам либо сложно, либо отсутствует.
Делаем коннекторы – анализируем, какие операции по взаимодействию с конечными средствами защиты нам нужны и при помощи каких транспортов их можно доставить и получить результат.
Формируем сущности – анализируем и описываем, какие представления, какие поля, какие кнопочки и какие связи между ними должны быть.
Выстраиваем рабочие процессы – как из коннекторов, сущностей и задач получить тот самый процессинг функционала, обеспечивающий пользовательские истории.
Ну и, конечно же, много общаемся. Общаемся внутри группы разработки и аналитики – а это преимущественно инженеры, которые имеют обширный опыт внедрения систем автоматизации процессов ИБ. Общаемся с инженерами направлений, которые внедряют целевые средства защиты и знают боли при передаче средств защиты в эксплуатацию не понаслышке. Общаемся с технической поддержкой и собственной эксплуатацией, теми людьми, чей браузер похож на новогоднюю елку от разноцветных кнопочек и уведомлений. А самое главное: стараемся сделать удобно и полезно.
Наша цель – создать MVP, который способен показать визуал и необходимый минимум, позволяющий понять: «Что это», «Зачем это» и «Это полезно!».
Вместо заключения
Мы лишь кратко описали текущую работу. Цель этой статьи – не только познакомить с концепцией «как подойти к централизации функций», но и на основе идеи задать некий тренд для рынка потребителей и рынка вендоров.
Уже сейчас на ранних стадиях мы видим, что механизмы управления классные и зрелые, а механизмы взаимодействия со сторонними системами далеко не всегда прозрачны или вовсе отсутствуют.
С каждым днем автоматизация проникает все глубже и комплекснее:
от простой: «то, что делалось руками, делается автоматически»;
к более системной: «то, что организовывалось постоянным ручным процессом, организуется автоматизированным процессингом»;
до трендовой: «то, что анализировалось и генерировалось аналитиком, теперь генерируется посредством автоматизации в т. ч. с применением ИИ».
И именно туда мы идем, чтобы облегчить рутину и заниматься по-настоящему интересными и важными вещами.
Мы исходим из принципа открытости и здоровой обратной связи. Поэтому, если вы нашли в статье частичку ваших болей, желаний и потребностей или в целом вам интересен концепт, приходите. Мы открыты к новым идеям и предложениям, апробациям и взаимодействиям.
Вместо заключения хочется добавить, что это наша первая статья. Далее в планах, с периодичностью один-два месяц, мы будем рассказывать о пути к достижению цели, а также делиться своими проблемами и успехами.
