Introducing R&S®Trusted Application Factory, a solution designed for DevSecOps teams, operating in start-ups, companies creating digital factories and SaaS software vendors.
I- Main objectives
Our design goals for the solution are simple:
Integrating security as close as possible to the application code offers many opportunities to define a more precise and relevant security policy. This layer of security deployed in the form of a micro-WAF with the application will allow it to "scale" with the application. By including the security configuration within the application code itself, security is always up-to-date and aligned with the application’s version.
Another major challenge for DevSecOps teams is simplicity. This involves integrating the security solution into their world. This means using the same tools, languages and concepts. A simple tool for a security team or a network team is not necessarily simple for a development team.
Finally, one of the strong demands is to provide visibility to the various users and managers: Developers, Infrastructure (Ops) but also security. R&S®Trusted Application Factory tracks the application from design to execution in production, thus providing indicators on its security status throughout its lifecycle.
II- Special features of the solution
a. A container that adapts to the workload of the application
In contrast to a conventional application barrier, which is delivered as a single entry point for all applications, the R&S®Trusted Application Factory application security service is deployed as a container for each application. This container can therefore scale together with the application in Kubernetes or Docker clusters, for example. It can thus automatically adapt to the application's workload. Another benefit is that, as it accompanies the application, it can be deployed both On Premises and in the Cloud, whether private or public. All the services are managed from a SaaS administration console that allows the security of the various applications to be monitored.
b. Context description to improve efficiency
In terms of improving the level of security, the solution is based on the concept of "Context description". Indeed, the specifics of each application, which the development teams define, is very valuable information for the configuration of the security policy. Data such as the type of persistence used, the programming language, the server's operating system and the data formats, enable protection policies to be automatically adapted by invoking the appropriate security engines. This results in increased security and a reduced risk of false positives.
It is even possible to go further for teams who wish to do so by providing context on each resource: the pages of a web application or the end points of the REST APIs. The DevSecOps team can actually specify the format, the maximum size of requests and responses, the behaviour of the page (rate limiting in particular). For that, the extension of Open API schemas will give developers the ability to very precisely document their APIs.
III- R&S®Trusted Application Factory: embedding security in cloud native applications
a. Built for developers
The R&S®Trusted Application Factory solution is a major breakthrough and contributor for the future of application security. Instead of creating more work or adding complexity, it integrates into their environment and complements the tools they already use. It leverages the same concepts, languages and technologies DevSecOps teams are familiar with.
b. Security As Code
The notion of "Security As Code" means integrating the security configuration into the application code and implementing it within the continuous integration and continuous deployment (CI/CD) pipeline with existing tools. Thus, policy is created and updated via configuration files stored within the application itself, "versioned" with the application code in Git, SVN or other version management tools. It is then pushed into the micro-WAFs that are deployed by CI/CD tools such as GitLab CI or Jenkins on test and build environments. This does not require new tools and allows a security configuration aligned with the application and identical on the different environments (test, qualif, preprod or prod). The configuration files themselves use formats already known to development teams such as YAML.
All the security services will be supervised from a central console. This will provide an overview of the security status of all applications and APIs. This console will offer dashboards with security, performance and quality indicators on each application in its development phase: security level on the different resources with the possibility of raising alerts if there are problems with specifications or tests. The "production" phase part is also supervised with, in particular, statistics on the use of resources. This makes it possible to identify those that are no longer being used and to reduce unnecessary areas of attack.