The event will feature Grigory Vasiliev, Head of Application Security at SolidLab, and Sergey Trunov, Head of Partner Relations at SolidSoft.
SolidSoft has been in the market for over 10 years. They started with a group of specialists from the Faculty of Computational Mathematics and Cybernetics (CMC) of Moscow State University. To this day, CMC MSU graduates form the core of the team, including specialists who continue to work at the CMC department. We started with application security analysis, infrastructure security analysis, and penetration testing. Initially, our experience with security came through attempts to overcome it. These competencies are still actively developed within our group of companies. However, while working with security solutions, we noticed that web application security solutions were not effective enough because they were either too simple to configure (providing only basic attack protection) or had a large number of protection options but were not well configured and tuned. The settings were often outdated, making them easy to bypass in about half an hour. Seeing this, we realized we had an opportunity to develop our own product, which we will discuss today.
Before we begin, I want to mention that our company also offers other solutions and services. Application and infrastructure security analysis and penetration testing are still available. We also offer expertise to our clients in implementing secure application development processes and protecting applications during operation.
Our products include SolidWall WAF - the undisputed flagship, SolidWall DAST - a vulnerability scanner that we are launching on the market, and an online training solution called "Secure Development Practice". And this is not all. There are several other interconnected solutions for analyzing application security and providing protection during the operation of web applications. We continue to actively develop in this direction.
But let's get back to Application Firewall. There is no doubt that they are needed now, and no one disputes this anymore, especially after Russia faced massive attacks following the start of the Special Military Operation. In general, it is important to understand that almost all web applications need protection, as they are now connected not only to the presentation of website business cards, as they were in the past, but also to the business processes within the organizations themselves. That is, if 15 years ago, attackers sometimes tried to penetrate a company's infrastructure through web applications, and the applications themselves were of little interest to them, now their attention is drawn to the applications themselves. This is because the entire business is now tied to them. That is, there are already business processes within the web applications themselves, the interruption of which is critical for the company and the organization. There is already critical information within the web applications themselves, the loss of which would be very serious for the organization and would be a tempting target for attackers. And the downtime and unavailability of web applications now also lead to direct risks for the business and are a direct threat to the company's reputation. Therefore, web applications and mobile applications (as one of its variants) are no longer a through, passing point for attackers trying to penetrate the corporate infrastructure. Now it is the applications themselves that are the target of attackers. And protection must counter these attacks adequately.
Now let's figure out what script is needed to choose this solution. Let's look at the sectors. On the slide on the left: Finance, Media, Government Sector, and customers. This is what we actively know how to protect. And not just protect. In each of these sectors, we have clients who have been using our product for a long time and successfully, and feedback from them allows us to develop our solutions in such a way that the specifics of the set of threats faced by these organizations are taken into account in our product, and that clients can successfully counter these threats. It is clear that these threats are different. In E-commerce, there is a threat of scraping attempts, i.e. determining information using a bot valuable offers that are of interest to competitors, or an attempt to find a promo code or some other data that will allow you to make some financial transactions that are beneficial to attackers. Each sector has its own specific threats, and we always take them into account. You can also add industrial organizations here, which are largely state-owned, and therefore are not separated into a separate sector.
Now about the use case, about the technologies. What is indicated on the slide in blue on the left is what should be in any web-application in a firewall. This is protection against typical OWASP top 10 attacks (Open Web Application Security Project). This is a typical set for a commercial organization that regularly updates the most relevant and profile attacks and threats for web applications. Top 10 does not mean that there are only ten of them, and that's it. There are many more of them. These are simply the most relevant ones that need to be protected against.
Protection against syntactic attacks, against attacks on users, on sessions. Protection against zero-day and first-day attacks - all this should be. And we have it too. But there are also technologies in which we feel more confident than our competitors. These are logical attacks. Here there is an understanding that web applications are increasingly tied to the business process, and, accordingly, to the business logic within web applications. And it is always individual. Unlike technologies that use typical sets of frameworks. And the threats, vulnerabilities that are there are patched, and this is a common story, often hidden by signature technologies. But the business logic in each application is different. And the vulnerabilities that developers build, and they often leave them unattended, because writing a web application, the entry threshold for which is significantly lower than the entry threshold for writing a secure protected web application, which requires security skills, is much more difficult. And here we can take into account these features of business logic both when configuring and when training the system, and protect these web applications. This protection is individual.
Protection against bots. Unique technologies are used here, which we will talk about a little later. Fraud prevention.
Protection of internal corporate sites. Even if this application is used within the organization, these are often applications that are available through a web interface or through mobile applications. That is, these are the same technologies. Corporate applications also need to be protected, but here the specifics may be related to protection against corporate data leaks, from insider activity, this situation is also possible. Mobile applications are also web applications. That is, what we see on a mobile phone as an application is essentially just a means of communicating with the server part of the mobile application. The main actions take place on the web server and, accordingly, it also needs to be protected.
About service resources. The fact is that the expertise that I mentioned above may be available to the customer as part of the support of our product. The customer can choose any set of services starting from the basic service desk (questions and answers). This is in case the customer plans to work with the product independently and if they have sufficient competence for this, but sometimes consultations with our specialists are simply required. And ending with the option when applications are protected by our engineers. That is, some kind of outsourcing, remote access, monitoring. And when attacks and incidents occur, our specialists inform the customer, configure protection themselves, block attacks, and when the web applications themselves change, they reconfigure and modify our protection rules. And as a result of attacks, they give recommendations on how to protect existing applications at the development level, up to the point that our experts recommend making some changes to the web applications so that they themselves become less vulnerable. And all the expertise that we have, within the framework of these services, becomes available to the customer.
Active web application development cycle. The fact that web applications are now a well-established trend are very actively updated and changed, leads us to the fact that protection must keep up with these changes. If such situations are unacceptable to us, when, for example, a new release is released, the automatic reconfiguration of protection has not yet occurred, and while the application has not updated its settings, it is more vulnerable than usual, then the configuration is made on the test server and then it is transferred to the system together with the new release. This is not a configuration from scratch, it is an implementary configuration, relatively less labor-intensive. It turns out that the protection of web applications within the framework of the active development cycle can be provided constantly.
We, of course, are faced with the requirements of regulators, and here a significant factor for us is FSTEC certification. We received this certificate about a year ago. And in this regard, we meet the requirements of regulators. We are also in the Register of Domestic Software. And from this point of view, we meet the requirements of the President's decree on the need to use Russian products.
Systems that use our SolidWall WAF will have to be certified. And in this context, our product, together with the entire system, is ready for certification and passes certification due to the fact that the necessary technologies are implemented there. In particular, the requirement for masking and the requirement for constant verification of all traffic.
When it comes to targeted attacks, to attempts to protect applications even more subtly and more efficiently, the customer faces a situation where these solutions simply do not have such an opportunity. That is, there are no "knobs" that allow you to finely tune the protection of such solutions and technologies that provide this. At the other pole are powerful solutions that have a lot of "knobs", but they require human resources, up to the point that you have to use built-in scripting languages to configure the rules. That is, this requires additional competencies and consumes expert time. This is what we have encountered. When powerful solutions are used, they are not used to their full potential because either there is not enough expertise and resources to use their full potential, or they were configured once, and their protection lagged behind due to the fact that the threat vectors changed, and you have to protect the application itself, which has become very different from what it was before. And we are again faced with the fact that such WAFs provide poor protection against targeted attacks. Their protection is lagging behind or does not meet the requirements at all. Or a lot of resources are spent on maintaining this protection in an up-to-date state.
Our solution is not a compromise between these two poles. It combines the requirements for rapid deployment and protection almost immediately after the solution is installed, and combines the ability to fine-tune protection against almost all attacks on web applications. And this protection is not so labor-intensive. It does not require much effort from engineers because there are technologies that save human resources. Of course, we are talking about machine learning here.
The main scenarios that we use are typical attacks, bot attacks, OWASP top 10, logical, zero-day, one-day attacks, protection against bots, fraud, protection of mobile applications. Let's mention separately protection against DOS and DDOS attacks. When it comes to a massive attack with a huge number of http requests, even if they are simple, but massive, for example, distributed attacks, then in this case, when faced with such attacks, you need a real typical anti DDOS product. And we strongly recommend putting anti DDOS class solutions in front of WAF. But there are attacks that, passing through a coarse cleaning filter, which is anti DDOS, from the point of view of web application protection, can pass through it. For example, attacks aimed at exhausting certain web application resources. In particular, if you run several requests that will compare not one or two product offers, for example, goods on the website of an online store, but 1000 or 2000. Such requests will pass through anti DDOS because they are not massive, but at the same time they can overload the computing power of the web application itself. And protection against such smart DOS attacks at the L7 level is the specificity of our solution, the specificity of Web Application Firewall.
About resource exhaustion, we can say that these can be attacks not only on exhausting computing resources. These can be attacks on booking certain resources. Such as booking goods, tickets, or hotel rooms. These attacks are related to business logic.
About our advantages. The maximum range of use cases. In various segments, we know how to protect applications specialized for almost any business task well. Here we can essentially reflect the business logic of a web application in the configuration rules, take into account the sequence of actions, i.e. the sequence of requests. Obviously, in order to log in, the user must first request the authorization page. And if he immediately throws a request that contains a login - password, then this is strange, it requires attention. This can simply be prohibited. It is possible to track responses such as brute-force attempts. When brute-forcing, there are a lot of negative responses from the web server. We track this situation, we see that there is brute-forcing, an attempt to find a password or promo code, or some other information. We can even track exactly which parameter they are trying to find and we can block such an attack. We look at the results of these requests, and we also look at the structure of the requests themselves to see which parameter they are trying to brute-force.
Interpreted machine learning. This is exactly what allows engineers to free up their hands for more interesting work. Our solution is not a black box that creates rules, and if the customer is not satisfied with them, it is very difficult for the engineer to understand what is happening, and why, and to configure something himself. Because all these are hidden rules. In our case, the rules created by the web application as part of machine learning are interpretable and correctable by the administrator. That is, they look as if the user created them himself. Naturally, the user would name the rules, for example, "login" or "payment". The Web Application Firewall itself will not name the rules like that, but it will create a model that will be almost indistinguishable from the model created by the administrator, and in this case it is easier for the administrator to work with such results, and it is relatively easy to reconfigure them. If the web application has changed, there is no need to redo all the rules. We understand in which part it has changed, we can use machine learning in this part, we can reconfigure something ourselves.
Powerful technologies for countering false positives are that if we see that some rule causes a false positive, then for us this is not a reason to disable the rule. We can see what exactly this false positive is reflected in, for example, in a certain parameter. And for this parameter for some special request settings, up to the point that, for example, up to a certain limit of some parameter. For example, it can be a payment up to 100 rubles or less than 100 rubles. We can block this rule. But otherwise, this rule will work and will not cause false positives. And thus, we will not reduce the level of protection by countering false positives. Here, the balance between false positives and the level of protection is more effective.
Next, you can talk about technologies. Models for all aspects of the application. They are unique, and at different levels. At the entire stack level, from basic things such as analyzing the execution of rules, according to which a request is made compliance with the requirements for them, to the business logic level and the session level. We can, if necessary, consistently display the authorization model on the WAF settings, and understand that these actions relate to the sequence of the session of this user. Here he came in, here he worked, left, all this can be reflected in the product.
False positives. There is a whole range of tools here that make this work convenient. From blocking false positives with one button to fine-tuning, choosing the level at which the false positive occurs, and for which we make this setting relevant. Reflection of business logic, including both positive sequence of business actions and negative ones. We can even make a chain of actions that should not happen in life, and when such a sequence of requests appears, we will react accordingly.
A comprehensive algorithm for protecting against brute-force attacks and bots is also a powerful tool. This is both the ability to block the source of attacks by various parameters, and not just block IP, but identify a parameter that is relevant for the identified bot, and automatically. Moreover, this works for both browser web applications and mobile applications. For example, one of the parameters that can be taken into account is not the target of the attack, but the version of the mobile application. We have also encountered this when attackers parsed a mobile application, and organized an attack using the parsed mobile application. It is clear that their version of the application was older, and even with this information alone, it was possible to counter the attack. The settings here are very fine. And also, in addition to sources, you can work with brute-force targets, determine what exactly the attacker is trying to brute-force, and immediately block these actions.