IDE for development of no-code security features

Eva Belyaeva, Security Vision

Introduction

The paradigm we are used to is turnkey products: ready-made solutions with a specific set of functions, options and buttons, with a specific visualisation tailored to the internal architecture. Each vendor has its own vision not only of the needs, but also of how much of the ‘inside’ it is willing to open up to the end user. As a result, there is either no flexibility or there are so many variants of addons and plugins, it's like giving a fish instead of a fishing rod.

And if we have products with different code base and architecture and logic in our infrastructure, it is very difficult to ‘make friends’ with them even within one vendor, and a specialist who works with it will have to learn several different logics until he learns how to systematise and navigate it.

Once upon a time there was a concept of customised products on the market: custom development for a specific TOR, but this is too private history. Such solutions are not universal as much as possible and are unlikely to be suitable for anyone else but the original customer, as all the logic is tied to internal processes. On the other hand, the customer himself knows exactly what such a system has inside.

Imagine that you go into the tooling of a product and you have no quickstart guide, no training, nothing. How will you understand it? How are you going to configure it? How can the product look like so that it can be used and developed immediately?

The root of the problem

It all depends on how to interpret entities and functions in the overall scope of the product; for example, if you are already familiar with development, then knowing the basic principles of programming languages (available from learn X in Y minutes guides) you can relatively quickly understand someone else's code or ‘translate’ your own from one language to another, because in the end all approaches are the same with the same meanings and principles: the base does not change. The structure and architecture are picked up from a common canvas, using familiar materials. It is important to note that this will only be relevant for simple scripts or for understanding the overall architecture of an application.

Contrast this with systems that either have nothing internal and only the necessary and sufficient settings left; or you have to go down a very strange path to create the one entity you need or to perform what you think is a simple action: first preparing parameter A for parameter B, then B along with C is loaded into D... it's hard to remember and hard to get used to and recall quickly if the system doesn't rely on any of the familiar logic.

It's like with a constructor: you can guess what the final machine will do if it's built from familiar elements: you know which one is responsible for what and does what, and you can figure out a device you're seeing for the first time. Because you have already seen each unit in action somewhere or other or used it yourself. And it's really not just about standards, but also about putting the underbelly on top so that it's not just easier to navigate, but also to add and refine elements of the application.

The solution itself becomes more transparent, like a formula in maths and physics, if the formula itself is familiar to you, and you put the variables in their places yourself, whether the object is an incident or a threat, etc. And here you don't need to invent some new standard, because, in fact, the product is the same code, and inside your asset will be exactly the same in the form of an object with properties and actions-functions.

In particular, if we talk about BPMN-notation of processes, it will be easy for a person who is used to work with them to set up both a playbook for response and a finite state automaton for an object, because the foundation is common.

Examples

Let's take a few systems as an example - SGRC and SOAR. What will be objects in them? How will these be related? First of all, as an object we can identify an asset that the company has. This object will relate to both one and the other system. But how will they be specified? In what number of steps? What set of parameters will they have? Namely, the properties of the object and the possible functions.

Both systems, developed independently, will have a product card with information and buttons, but it is likely to be a bit difficult to realise that they are the same thing.

Inheritance is also very important here, because in one way or another all IS/IT/business products overlap with at least one object, and eventually our builder turns into something bigger, when very many different things can be combined into one product with one common window.

If you're a bit of a coder, this will be much easier for you to understand. But if you are, let's say, a SIEM engineer, it will be easier to understand one solution after working with three of this class. However, if you have always dealt with NGFW class products, then perhaps a VM scanner or some SGRC will baffle you at first.

The threshold of entry not only in IT but also in IS is lowered when the tool speaks a visual language. It is very hard for a person from outside to understand IS topics at a glance, they are some incomprehensible sets of properties and parameters, which are not clear how they interact inside under the bonnet. But if we bring it to UI, we get... a language understandable to everyone instead of a specific syntax of development languages.

Transferring the basic principles of development to UI pulls low-code and now-code approaches, because all you start to see in front of you and work with is a visual set of blocks and transitions, structures.

OOP in no-code format

As an example, the ability to set rules in SIEM both through the constructor and through the code. Opinions vary about convenience and what experienced developers choose (and in some of their studies analysts are more likely to talk about code), but again we are talking about products without flexibility, where everything is packaged and sealed.

The no-code approach is typically characterised by 100% visual representation. Low-code is a symbiosis of two approaches: syntactic and visual. For whom is this approach relevant? The key audience is professional developers who use a visual format for ease of development.

These approaches are most often used for global automation, integrations, and cross-system collaboration. It is easier for teams to collaborate in these formats because the competency threshold for developing a product in these formats is significantly lower than the development threshold; and all team members - designers, analysts - can also shape the product.

It is also worth noting that low-code is used for scaling and flexibility, while no-code is used for specific and clear tasks, and this option is more closed.

Those who turn to no-code at the start of their journey are usually technically unsophisticated and learners. Then they switch to full code, for as much flexibility and hardcore as possible. And then, when they are finally satisfied, people go back to no/low-code to do their work even faster and more efficiently, because they know what exactly they need and how to solve certain tasks, they already have a specific toolkit that is convenient for them, with the help of which they are used to solving absolutely any problem. That is, in the end, this approach is more popular among beginners or professionals.

General postulates of development

The development architecture at the start can be any, but it is the one you have to stick to later, unlike the backend, which can be rewritten in almost any programming language without losing its meaning. Monolith, microservice or module - it depends on the needs; the main thing is that because of the common approach with development, the product can be made safe by design.

In essence, it's still the same native OOP, albeit in the format of forms and buttons. However, this code still needs to be optimised and safe, understandable to someone outside. The advantage is that all objects and their links can be ‘touched’ and evaluated visually, which increases the speed of perception.

And just as some developers reuse their own code between projects, you can isolate individual building blocks with objects and migrate them into linked products.

Conclusion

Using this approach instead of syntactic languages in some ways flips the usual perception of the applications we use on a daily basis. Once you dive into it, it's impossible to unlearn.

Now everything familiar - a messenger or a game - can be mentally decomposed into a system of objects and relationships, and perhaps some part of the functionality of unfamiliar software will become clearer.