IDE для разработки средств защиты в формате no-code

Ева Беляева, руководитель отдела развития производственного департамента Security Vision

Введение

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

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

Когда-то раньше существовал на рынке концепт продуктов под заказ целиком: кастомная разработка под конкретное ТЗ, но это слишком частная история. Такие решения максимально не универсальные и вряд ли подойдут кому-то еще, кроме первоначального заказчика, так как вся логика завязана на внутренние отработанные процессы. С другой стороны, сам заказчик точно знает, что у такой системы внутри.

Представьте, что вы заходите в оснастку какого-то продукта и у вас нет quickstart guide, обучения, ничего. Как вы в нем будете разбираться? А как настраивать? Как может выглядеть продукт для того, чтобы им могли и сразу пользоваться, и сразу разрабатывать?

Корень проблемы

Все зависит от того, как трактовать сущности и функции в общем скоупе продукта; например, если вы уже знакомы с разработкой, то зная основные принципы языков программирования (доступные по гайдам learn X in Y minutes) можно сравнительно быстро разобраться в чужом коде или «перевести» свой с одного языка на другой, потому что в конце концов все подходы одинаковы с теми же смыслами и принципами: база не меняется. Структура и архитектура подобраны по общей канве, с использованием знакомых материалов. Важно отметить, что актуально это будет только для простых скриптов или для понимания общей архитектуры приложения.

В противовес этому системы, у которых или не вынесено ничего внутреннего, и оставлены только необходимые и достаточные настройки; или нужно пройти очень странный путь для того, чтобы создать одну сущность, которая вам нужна или выполнить простое по вашему мнению действие: сначала подготовка параметра А для параметра B, потом B вместе с C загружается в D… это сложно запомнить и сложно к такому быстро привыкнуть и воспроизвести по памяти, если система не опирается ни на одну из привычных логик.

Это как с конструктором: вы можете догадаться, что будет делать итоговая машина, если она собрана из знакомых вам элементов: вы знаете, какой за что отвечает и что выполняет, и можете разобраться с устройством, которое видите впервые. Потому что каждый блок вы так или иначе где-то уже видели в действии или использовали сами. И это на самом деле не только про стандарты, но и еще про вынесение подкапота наверх для того, чтобы было не просто легче ориентироваться, но и дополнять и дорабатывать элементы приложения.

Само решение становится прозрачнее, подобно формуле в математике и физике, если сама формула вам знакома, а переменные вы ставите на свои места сами, будь объектом инцидент или угроза и т.д. И тут не нужно выдумывать какой-то новый стандарт, потому что, по сути, продукт – это тот же код, и внутри ваш ассет будет точно так же выполнен в виде объекта со свойствами и действиями-функциями.

В частности, если мы говорим о BPMN-нотации процессов, человеку, который привык работать с ними, будет несложно настроить и плейбук по реагированию, и автомат конечных состояний для объекта, потому что фундамент у этого общий.

Примеры

Возьмем как пример несколько систем – SGRC и SOAR. Что в них будет объектами? Как это будет связано? В первую очередь, как объект мы можем выделить актив, которым располагает компания. Этот объект будет относиться как к одной, так и к другой системе. Но как они будут заданы? Через какое количество шагов? Какой набор параметров у них будет? А именно, свойств объекта и возможных функций.

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

Тут еще очень важно наследование, потому что так или иначе все продукты по ИБ/ИТ/бизнесу пересекаются хотя бы одним объектом, и в итоге наш конструктор превращается во что-то большее, когда очень много разноплановых вещей можно объединить в один продукт с одним общим окном.

Если вы немного кодер, то понять вам все это будет гораздо проще. Но если вы, допустим, инженер SIEM, то разобраться в одном решении после работы с тремя такого класса будет проще. Однако если вы всегда имели дело с продуктами класса NGFW, то, возможно, сканер VM или какой-нибудь SGRC вас на первое время озадачит.

Порог входа не только в ИТ, но и в ИБ снижается, когда инструмент говорит на визуальном языке. Человеку со стороны с наскока понять ИБ-тематику очень тяжело, это какие-то непонятные наборы свойств и параметров, которые неясно как взаимодействуют внутри под капотом. Но если мы выносим его в UI, то получим… понятный каждому язык вместо конкретного синтаксиса языков разработки.

Переложение базовых принципов разработки на UI тянет за собой low-code и now-codе подходы, потому как все, что вы начинаете видеть перед собой и с чем работаете – это визуальный набор блоков и переходов, структур.

ООП в формате no-code

Как пример, возможность задавать в SIEM правила как через конструктор, так и через код. Тут мнения разнятся про удобство и про то, а что же выбирают опытные разработчики (и в некоторых своих исследованиях аналитики скорее говорят про код), но снова идет речь о продуктах без гибкости, куда все запаковано и запечатано.

No-code подход как правило характеризуется 100% визуальным представлением. Low-code – симбиоз двух подходов: синтаксического и визуального. Для кого такой подход релевантен? Ключевая аудитория – это профессиональные разработчики, которые пользуются визуальным форматом для удобства разработки.

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

Еще стоит отметить, что для масштабирования и гибкости используют low-code, для конкретных и понятных задач – уже no-code, и такой вариант получается более замкнутым.

Те, кто обращаются к «коду без кода» на старте своего пути, – как правило, технически неподкованные, обучающиеся. Потом они переходят на full code, для максимально большой гибкости и хардкора. И потом, окончательно преисполнившись, люди идут обратно к no/low-code, чтобы делать свою работу еще быстрее и эффективнее, потому что они знают, что конкретно им нужно и как решать те или иные задачи, у них уже собран конкретный удобный им инструментарий, с помощью которого они привыкли решать абсолютно любые проблемы. То есть в итоге этот подход популярен скорее среди совсем начинающих или совсем профессионалов.

Общие постулаты разработки

Архитектура разработки на старте может быть любой, но как раз ее придется придерживаться потом, в отличие от бэкенда, который может быть переписан практически на любом языке программирования без потери смысла. Монолит, микросервис или модуль – это зависит от потребностей; главное, что из-за общего с разработкой подхода продукт можно сделать безопасным by design.

По сути, это все то же родное ООП, пускай и в формате форм и кнопок. Однако, этот код все равно должен быть оптимизированным и безопасным, понятным кому-то со стороны. Плюс в том, что все объекты и их связующие звенья можно «потрогать» и оценить визуально, что увеличивает скорость восприятия.

И подобно тому, как некоторые разработчики переиспользуют свой собственный код между проектами, можно выделять отдельные строительные блоки с объектами и мигрировать их в связанные продукты.

Заключение

Использование такого подхода вместо синтаксических языков в некотором смысле переворачивает привычное восприятие приложений, которыми мы пользуемся ежедневно. Один раз вы в это погружаетесь – и это невозможно развидеть.

Теперь все привычное – мессенджер или игру – мысленно можно будет разложить на систему объектов и связей, и, возможно, какая-то часть функционала непривычного ПО станет понятнее.