History of the creation of ASoar: from idea to implementation of the cybersecurity system

Background: personal experience and first steps

I described my journey in the previous article https://habr.com/ru/articles/813239/, but in short, my career in information security began, like many others, with working in IT infrastructure. Initially, my company was engaged in maintaining the stability of networks and systems for various companies, and regularly faced typical problems associated with cyberattacks. One day in a company where the information security staff was minimal, we implemented SIEM - a solution that was supposed to radically improve security. However, it was an expensive and labor-intensive process. SIEM not only did not meet expectations but also generated a bunch of incidents, most of which did not pose a real threat. Specialists spent time analyzing many events that were essentially insignificant. With each new false alarm, trust in the system fell. Eventually, people just started ignoring the warnings, believing the system was safe, although it was far from it.

So I formulated the key problem of SIEM:
In ordinary organizations, where the number of information security specialists is limited, the use of SIEM often does not lead to the expected results. And this is what opened my eyes to the need to find a new approach. I began to think about how security processes could be automated without burdening the team with false alarms and complex settings.

Why SIEM-based automation does not work out of the box
In practice, it turned out that setting up SIEM is another big headache. Each incident needs to be classified, understood what is important and what is just noise. Building correlation rules for incidents is a complex task and takes time. When I started working with SOAR systems, which were supposed to automate incident handling, it became clear that they only work in conjunction with SIEM, which means that before achieving technological maturity of SOAR within the company, it is necessary to go through a difficult path of setting up and training SIEM with employees and infrastructure. At this stage, most organizations face huge difficulties, and the systems are either not fully configured or start to overload the team with false incidents. When we faced real problems with SIEM implementation, it became clear: existing solutions are overloaded with incidents and require too many resources to configure.

At one of the meetings, I shared these thoughts with my colleagues, and we started thinking about how we could build a solution that would bypass these problems. We remembered the old and well-known principle of fail2ban - if someone does suspicious actions, we block them, there is even a set of libraries with the same name. Of course, this solution seemed too harsh and one-sided to us, but this is how the idea of a new system was born, based on a similar approach, but in addition we needed: flexibility, learning ability, positive feedback.

Practice: development of a scoring system

Instead of blocking everyone at the first suspicion, we decided to use a real-time scoring system. We based it on the concept of two indices: the utility index and the danger index. We started building a flexible system that could distinguish between real threats and random, non-dangerous actions.

• Utility Index: this parameter shows how much the agent (user or device) performs useful actions on the network. Of course, its configuration is complex, as utility depends on specific tasks and often the index parameters will need to be adjusted in the final system.

• Danger Index: here everything is much simpler. Most systems automatically record suspicious actions of agents, such as attempts to access non-existent pages, scanning network resources, etc. The danger index accumulates for such actions.

Our key idea was that if the utility index is low and the danger index is growing, then access to such an agent should be temporarily restricted. This would minimize the risk of intruders while avoiding false positives.

It quickly became clear that we needed a "cooling" mechanism, as we cannot ban everyone forever. We implemented a TTL (Time To Live) system for both indices. This means that danger and usefulness "cool down" over time — in particular, if an agent stops performing suspicious actions, their danger index decreases. For example, if a user accidentally enters somewhere with the wrong password, they will not be immediately blocked — the danger index will increase by only one unit for a few hours, but in the case of repeated and multiple actions, it will continue to grow.

Thus, first theoretically and then practically, we developed a system with detailed and dynamic assessment of agents' actions. The introduction of two indices — usefulness and danger — allows flexible access management, minimizing false positives and maintaining high response accuracy. This solves the main problem of SIEM and SOAR — an excessive number of events and the complexity of rule settings. Such a system, in essence, not only responds to incidents but also learns from real activity, and it turns out that the larger the protected perimeter, the more protected each element of the network is, as its protection is based on overall statistics.

Example from practice
One of the most striking cases of implementing our scoring system occurred in a project for a large e-commerce client. In the website protection system, we began tracking the actions of users trying to access administrative areas through requests to pages such as /wp-admin, /phpMyAdmin, /bitrix, and so on (here is an example regex: hpMyAdmin|wp-admin|admin|administrator|phpmyadmin|bitrix|typo3).

We set it up like this: when an agent sends such requests and receives a 404 from the server, we understand that he is looking for an admin panel, this is practically not a dangerous action in itself, and we slightly increase the danger index for this agent. This allowed our system to flexibly manage access: if a user accidentally "stumbled" upon admin areas, we did not block him, but if it was a targeted scan, the danger index accumulated, and access was restricted.

And then everything went smoothly: it turned out that all systems one way or another report on how they work with the user, and even set the levels of criticality for their messages, this allowed us to quickly accumulate a large database for signal sources. The systems are smart on the one hand, but on the other hand, they are completely unable to exchange information with each other and have no memory. These are the two tasks we started to solve: now we accumulate scoring across the entire network, deeply over time and differentiated by threat levels.

We have tested and implemented all these ideas in our own product, thoroughly checked it in our infrastructure and with partners. Less than a year ago, we entered the market with ASoar — a TDR (Threat Detection and Response) class system. The name Active SOAR emphasizes our philosophy: SOAR automates security orchestration, and Active in the name indicates our commitment to proactive threat detection and immediate response. Thus, we are at the intersection of TDR and SOAR systems, combining the best of them.

Another breakthrough — GHostHost

The HoneyPot concept has long been known in the world of cybersecurity, but in practice it is rarely used, especially in corporate segments. Many believe that setting traps for attackers is more of an academic interest than real protection. We decided to develop this idea and make it more applied.

Instead of having something at the end of the firewall rules that disposes of requests, like "deny all", we created a subsystem within ASoar called GHostHost — a virtual machine with many HoneyPot traps. All requests that do not find their recipient are redirected to this machine. As a result, we get logs of all attack attempts and send them to ASoar for analysis. This approach not only helps us identify attackers at the reconnaissance stage but also confuses them. Attackers see false targets, which makes their work less effective.

How it works
Suppose an attacker tries to scan our network by sending requests to various ports and IP addresses. Instead of these requests being blocked at the firewall level, they are redirected to GHostHost — a virtual server with a set of HoneyPot traps. This server logs all the attacker's actions: which ports he scanned, which protocols he used, which login attempts he made, etc. These logs are then sent to ASoar, where the system automatically evaluates the agent's actions and assesses their threat level.

Most importantly, thanks to this approach, the attacker cannot conduct reconnaissance of our real infrastructure either inside or outside the perimeter. He hits false targets that seem real to him, and therefore wastes time, while our system manages to respond and block him.

Practical example
At one of the sites, our specialists implemented GHostHost to protect the internal network. On the very first day of operation, we recorded numerous scanning attempts from one of the machines where a careless administrator had installed a "free antivirus". Thanks to the fact that all requests to non-existent addresses were redirected to GHostHost, the system managed to timely detect the source of the scanning and isolate it.

Reporting

One of the key elements of a successful cybersecurity system is accessible and understandable reporting. I won't even go into detail again about how in cybersecurity everyone loves to show their importance with empty reports and create "paper security" instead of real security. ASoar provides not only deep analysis capabilities for each agent's trace and actions but also data visualization tools that allow for quick situation assessment. For example, an administrator can easily see how the danger index rose or fell for a specific agent, what events occurred, and how they affected the assessment of their activity.

ASoar reporting helps answer key questions:

• How many agents were blocked in the last minute, hour, or day?

• How many logs are received from each system?

• Which correlation rules triggered most often?

For ease of analysis, all data is presented on time charts, which simplifies infrastructure monitoring and timely problem detection, such as log loss or data source failures. The system also allows for automatic report generation for regular presentation to managers or clients, increasing transparency and control over security processes.

Overall, there is still a lot of work to be done, so the ASoar reporting system is the most dynamically developing part and is constantly being improved, with new ideas and features constantly appearing.

Market Realities

In modern conditions, companies face a serious shortage of qualified cybersecurity specialists. Their deficit grows annually, and their services become more expensive. This is because cyber threats evolve faster than companies can train new specialists. And as my friend said: "The period of calm is ending, and the world is no longer a safe place." As the complexity of attacks and networks grows, the load on cybersecurity specialists increases, and the requirements for their qualifications become higher.

Such realities of the cybersecurity market create increased demand for solutions that can automate protection and minimize human involvement in incident processing. ASoar in this regard turns out to be the optimal choice for companies that do not want to maintain large cybersecurity teams. It replaces dozens of hours of manual work with automatic data processing and real-time threat analysis, significantly reducing security costs.

Consumer properties of ASoar

ASoar was created taking into account the real needs of companies striving to optimize security costs and minimize the human factor. The system has the following consumer properties:

Automation: Most of the processes that require the involvement of specialists in traditional SIEM systems are automated in ASoar. This significantly reduces the load on the security team and allows for quick response to threats, giving administrators the opportunity to sleep peacefully at night.

Flexibility and adaptability: ASoar easily integrates with existing security systems, collecting logs from various sources and providing universal solutions for companies at different stages of technological maturity.

Efficiency: Even companies with limited resources can achieve a high level of protection without the need to maintain large teams of specialists. Thanks to the agent scoring model, the system allows for accurate threat detection and blocking without overwhelming staff with false positives.

Low level of false positives: An important advantage of ASoar over competitors is the low level of false positives. The system uses intelligent algorithms to analyze agent actions in real-time, weighing the utility index and the danger index. This allows for more accurate assessment of suspicious actions and minimizes the number of false alarms. As a result, administrators do not waste time on unnecessary incident checks and can focus on real threats. This is especially important for companies with limited resources in the field of information security.

Thus, ASoar not only reduces information security costs but also increases its level through process automation and the use of modern technologies such as GHostHost and real-time agent scoring systems based on overall network usage statistics.

ASoar now and future plans

At the moment, ASoar provides powerful tools for automating and orchestrating cybersecurity processes. The GHostHost signaling subsystem further enhances ASoar's sensitivity, detecting and stopping intrusions at different levels. Our reporting system allows administrators to see how and why the danger index of agents increased, what actions they performed, and also monitor statistics on blocked agents and security rules. We provide timelines for monitoring logs and their sources, which allows for quick identification of infrastructure issues.

However, we understand that system development should not stop there. We are already planning further development of interfaces and expanding integration capabilities with external security and management systems, planning to implement artificial intelligence to identify complex correlations and algorithms based on entropy calculation to detect anomalies (anomaly detection index implementation is planned).

Conclusion

The history of ASoar's creation is a story of searching for new approaches in cybersecurity. We realized that traditional systems, such as SIEM and SOAR, do not always provide sufficient protection. That is why we created a system that works in real-time, focuses on automation and flexibility, allowing administrators to focus on real threats rather than false incidents.

Today, ASoar is not just a protection system, it is the implementation of a comprehensive security approach that helps companies improve their cybersecurity and reduce maintenance costs. ASoar not only effectively filters agents based on their behavior but also provides the necessary information for monitoring and improving security processes. This makes the system attractive to both technical specialists and managers responsible for security in the organization.

And it is important in the current realities to point out that ASoar was developed in Russia and is included in the register of domestic software.

Thanks

In this whole story, I represent not only myself but our entire team, and I want to express my great gratitude to the people who made a huge contribution to the creation of ASoar. First of all, these are my colleagues, our full-time and part-time development team who brought ideas to life, tested, and brought the project to commercial launch. And I want to thank all my friends and colleagues from related companies whom I invited for consultations and brainstorming sessions, who shared their experiences and supported our product, helped to fine-tune it, agreed to be the first users, and provided constructive feedback!