open-appsec is an open-source Web Application & API Security solution, which provides automatic and preemptive security using machine learning. The code is available at GitHub. open-appsec has proven repeatedly to effectively protect against zero-day and OWASP-TOP-10 attacks by using contextual machine learning instead of traditional signatures.
As signatures for new attacks by design can only be created after new attacks have been published, a WAF solution that relies solely on signatures will never protect preemptively (in advance) against zero-day attacks. This is especially important, as a vulnerability usually exists for a long time within the affected code of a software or a library, before the first public disclosure of a corresponding CVE record describing it. For this reason, open-appsec does not rely on signatures at all, so that it can provide true preemptive zero-day protection.
In addition, open-appsec reduces the administrative effort as well as the amount of false positives significantly while providing stronger protection even for unknown attacks. open-appsec supports all typical deployment platforms like VMs, Kubernetes, and Docker and integrates with NGINX, Kong, and other web proxies and ingress controllers for K8s.
open-appsec can be managed in two main ways:
Declaratively using CRDs and Annotations in Kubernetes or using a configuration YAML file in Linux or Docker.
Centrally using a comfortable WebUI.
Using open-appsec’s SaaS Central management (https://my.openappsec.io) provides the features listed below (and more) as well as additional comfort. Moreover, it is already included in the free Community edition. By using it you can:
Centrally manage multiple open-appsec deployments on different platforms like Kubernetes, Linux or Docker from a unified WebUI
Collect, store and analyze security events and other logs centrally in various graphical dashboards from all your open-appsec deployments in unified views
Comfortably edit and view the relevant security configuration
Configure additional agent-related settings like automatic updates
Monitor the status of deployed open-appsec agents
Note – Even when you prefer to manage open-appsec in a local, declarative way, you can still connect it to the central management in order to get most of the benefits available in the central management WebUI, while the security configuration will be shown as “read-only” and cannot be edited (this mode is referred to as “Read-only” further below). This allows you to integrate open-appsec easily into existing DevOps/DecSecOps processes, allowing you to manage it as part of existing GitOps Continuous Deployment (CD) implementations, while still being able to have a comfortable WebUI available.
Independent of the mode you choose for connecting your deployment, you will always keep your existing configuration. When transitioning from local, declarative to central management it will be automatically migrated to the SaaS portal. Instead, when connecting using the “Read-only” option, the local declarative configuration will remain decisive while in parallel being shown also in the SaaS Portal.
In this article, you will learn how you can easily migrate or connect an existing, locally & declaratively managed open-appsec deployment to the WebUI SaaS service, which is as simple as running two commands after preparing the management by creating a new profile for the existing deployment to be connected to. The article will also help you understand more about how open-appsec deployments are organized, managed and configured in the WebUI by using “Profiles”.
At this stage, you are already running one or more locally managed open-appsec agents deployed according to the open-appsec documentation. They can be agents integrated with Kubernetes ingress controllers, or agents deployed as an add-on to existing NGINX or Kong Reverse Proxy servers.
Level of SaaS management involvement for each agent
Before continuing, you should decide the level of SaaS management you require for each of your agents:
Read-only – the SaaS management portal will show events and agent status, but the security configuration will continue to be done locally, using open-appsec CRDs and annotations in the case of Kubernetes, or configuration files in the case of an add-on deployment to an existing Kong/NGINX reverse proxy server.
Full management – both, assets and security configuration, are managed centrally via the SaaS portal for open-appsec.
In both cases, you will not need to define Web assets and security policy in the SaaS portal, as the first option is read-only anyway, and in the second option, the cloud automatically defines these objects according to the local policy configuration that existed. However, when managing security from the open-appsec SaaS portal, it will be possible to modify the existing configuration after the initial connection, as well as add additional protected web assets.
Security configuration and profiles
The open-appsec SaaS portal manages security by defining assets and their security configuration, and selecting the profile objects that will enforce this security.
When open-appsec agents connect to the cloud, they are associated with a single profile for each agent. This allows a granular way to select which agent will enforce which security configuration. If you have only one agent, you will create a single profile object. If you have more than one agent, you will need to decide beforehand how many profiles you will want to create, given the granularity of security enforcement you wish to have. All agents enforcing the same security and protect the same assets will use the same profile objects.
Another consideration is the type of deployment. If you use multiple agents on different deployments, they will require a different profile. Currently, agents integrated to a Kubernetes ingress controller use a different type of profile than agents deployed as an add-on to an existing Kong/NGINX reverse proxy server.
After these considerations, you should have an exact idea of how many profile objects you need and want to create per deployment type, and according to the granularity of security enforcement you wish to have.
Migrating a locally managed agent to being fully managed by the open-appsec SaaS portal
Migrating a single locally managed agent is as simple as two steps:
Creating a profile on the open-appsec SaaS portal and enforce the policy by clicking on ‘Enforce’.
Running the two commands on the host running the agent which are shown on the profile page once created. The actions being downloading an installation binary and then running it.
If more than one agent should connect to the same profile, then there’s no need to redo Step 1.
Step 1 – Create a profile via my.openappsec.io -> Select ‘Getting Started’ -> under “Protection” check ‘I deployed an agent’ -> under ‘Central Management’ click on ‘Manage’ and select the type of deployment of the agent you wish to migrate.
Click ‘Enforce’ to enforce the policy from the blue banner or the top left corner of the portal (The screenshot below is an example of a Linux embedded profile, for the type of deployment - NGINX Reverse Proxy Add-on):
Step 2 – Once created, follow the commands listed in the right pane of the profile window under ‘Connect Existing Deployment’. If you already created a profile, you could reach an existing one via the ‘Profiles’ option at the top menu.
The right pane also allows you to select the mode in which the agent will be managed – Read only (Policy settings are defined via a local ‘Declarative policy’ option), or fully managed from the SaaS portal (‘This management’ option).
Note – once you change the mode of the policy to being fully SaaS-managed, it is not possible to undo this change.
After running these two commands you will be able to see the agents and assets in the appropriate ‘Agents’ and ‘Assets’ pages via the top menu. If you opted to fully manage via the SaaS portal, you will also be able to edit those objects.
Now your open-appsec deployment is associated with a profile in the central management and successfully connected to the open-appsec SaaS portal. You can now check out logs, events, perform configuration adjustments (if you did not choose the “Read-only” mode), monitor the agent status and add additional open-appsec deployments to the same SaaS portal.