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