We invite you to a joint event by OCS and SolidSoft, a Russian developer of the SolidWall WAF firewall. The tool protects web resources and applications, controls operating scenarios, and minimizes the possibility of exploiting business logic errors: SolidWall WAF is quick to deploy, easy to use, and has flexible settings for specific tasks.
The event will feature Grigory Vasiliev, Head of Application Security at SolidLab, and Sergey Trunov, Head of Partner Relations at SolidSoft.
SolidSoft has been on the market for over 10 years. They started with a group of specialists from the Faculty of Computational Mathematics and Cybernetics (VMK) of Moscow State University. And to this day, VMK MSU graduates form the core of the team, including specialists who continue to work at the VMK department. We started with application security analysis, infrastructure security analysis, and penetration testing. In other words, our initial experience with security was through attempts to overcome it. These competencies are still actively developed in our group of companies. However, while working with security solutions and encountering them, we saw that web application security solutions were not effective enough because they were either too simple to configure (providing protection only against basic attacks), or there were solutions with a large number of security options that were not well configured and set up. And the settings were often outdated. And therefore, they were easy to overcome in about half an hour. Looking at this, we realized that we had an opportunity to develop our own product, which we will talk about today.
But, before we begin, I would also like to mention that our company also offers other solutions and services. Application and infrastructure security analysis and penetration testing are still available. We have expertise that we actively offer to our clients. This includes the implementation of secure application development processes. We protect applications during operation.
Our products include SolidWall WAF - an undisputed flagship, SolidWall DAST - a security scanner that we are launching on the market. We are also launching an on-line training solution called "Secure Development Practice". And this is not all. There are many other interrelated solutions for analyzing application security and for ensuring security during the operation of web applications. And 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 after the start of the SMO. And in general, it is important to understand that almost all web applications need to be protected, which are now associated not only with the presentation of website business card pages, as was the case before, but also with business processes within the organizations themselves. In other words, if 15 years ago, in order to penetrate the company's infrastructure, attackers sometimes tried to go through web applications, and the applications themselves were of little interest to them, now their attention is drawn to the applications themselves. Because the entire business is now tied to them. In other words, already within the web applications there are business processes, the interruption of which is critical for the company and for the organization. Already within web applications there is critical information, the loss of which would be very serious for the organization and would be a tasty morsel 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, now web applications and mobile applications (as one of its options) are no longer a through, transit point for attackers trying to penetrate the corporate infrastructure. Now it is the applications that are the target of attackers. And protection must counter these attacks to the fullest extent.
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, 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 singled out 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 firewall. This is protection against typical OWASP top 10 attacks (Open Web Application Security Project). This is a typical set of commercial organizations 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 just the most relevant ones that need to be protected against.
Protection against syntactic attacks, against attacks on a user, on a session. Protection against zero-day and first-day attacks - all this should be. And we have it too. But there are other 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 the 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 web application, which requires skills in security, is much more difficult. And here we are able to 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 websites. Even if this application is used within the organization, these are often applications that are available through a web interface or through mobile applications. In other words, these are the same technologies. Corporate applications also need to be protected, but here the specifics may be related to protection against corporate data leakage, from insider activity, this situation is also possible. Mobile applications are also web applications. In other words, 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 on their own 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. In other words, 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 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. What is now an established trend, web applications are very actively updated and changed, which 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 until the application has 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 emplimentary configuration, which is relatively less time-consuming. It turns out that the protection of web applications within the framework of the active development cycle can be ensured 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 of masking and the requirement of constant checking 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 a possibility. In other words, there are no "handles" 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 "handles", but they require human resources, up to the point that you have to use built-in scripting languages to configure the rules. In other words, 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 are configured once, and their protection is outdated due to the fact that the threat vectors have 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 time-consuming. 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, against 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, a real typical anti DDOS product is needed. And we strongly recommend putting anti DDOS class solutions in front of the 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 the exhaustion of computing resources. These can be attacks on the booking of some resources. Such as booking goods, tickets or rooms in hotels. These attacks are related to business logic.
About our advantages. The maximum range of use cases. In various segments, we know how to protect specialized applications well for almost any business task. 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 a brute-force attack, 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 exactly 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 adjustable by the administrator. In other words, they look as if the user created them himself. Naturally, the user would name the rules, for example, "login to the system" 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, you do not 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. And 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 for compliance, to the requirements for them, to the business logic level and the session level. We can, if necessary, sequentially 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 framework of the product.
False positives. There is a whole range of tools 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 the positive sequence of business actions and the negative one. 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 they had an older version of the application, and even with this information alone, it was possible to counter the attack. The settings here are very fine. And you can also work with the targets of brute-force attacks, determine what exactly the attacker is trying to brute-force, and immediately block these actions.
Now on home
