How many layers protect your files? Behind the scenes of the open source stack at WebDisk
WebDisk Blog · category: Security · reading time: ~9 minutes
In short:- Security at WebDisk is not a single product but a system of layers: an application firewall and a network sensor at the edge, sensors inside the systems, central event correlation and automatic alerting around the clock.- We build it on proven open source projects – including Suricata, Wazuh, Falco and open-appsec – and we observe the whole thing on a single screen.- One principle holds it all together: no single safeguard is infallible – which is why every layer backs up the others.
When you entrust your files to someone, what you are really buying is two things: technology and vigilance. We wrote about the technology in earlier parts of this series – about encryption, access without permanent keys and copies that cannot be deleted. Today we invite you behind the scenes of that second part: what the system that watches over our platform day and night looks like – and why we built it out of open source building blocks. A set of cooperating tools like this is called a stack – and that is the word we will stick to here.
Philosophy: a vault behind walls
In security we do not believe in single miracle solutions. We believe in defense in depth – a principle older than IT, familiar from every bank: a vault has walls, then an armored door, then a safe, and cameras and sensors watch all of it. A burglar would have to get through each layer in turn – and every one of them has a separate alarm.
Our platform works the same way. Before a request from the internet reaches your files, it passes through successive checkpoints; and even if one of them failed, the layers behind it watch what happens next – and raise the alarm, keeping the time between an event and the response as short as possible.
Why open source?
All the key elements of our security stack are open source projects. That is a deliberate decision, for three reasons:
- Transparency. In closed products, security has to be taken on faith. In open ones, every mechanism can be inspected, and the processes for reporting and patching flaws are public: you can see not only the code, but also how the project responds to the weaknesses that are found.
- Independence. We are not hostage to a license or a price list. We can tune, combine and replace components the way our architecture requires – not the way a contract allows.
- Industry standards. Suricata, Wazuh and Falco are tools that security teams have relied on for years – by using them, we also draw on the experience of the entire industry.
One honest caveat: open source in itself does not provide security – it provides verifiability. Security comes from configuration, tuning and daily work with these tools. And the rest of this article is precisely about that work.
Layer one: the edge – a firewall that learns
All traffic from the internet reaches our edge servers first. Two independent mechanisms work there:
WAF (Web Application Firewall) – an application firewall based on the open-appsec project, which analyzes HTTP requests directed at our applications. Unlike classic firewalls with a list of rigid rules, open-appsec uses machine learning: it builds a model of the normal behavior of each service in order to catch deviations – including ones that are not yet in any signature database. We choose the operating mode service by service, depending on how mature its model is: some services are actively protected by the firewall, which blocks suspicious requests, while the rest run in learning and detection mode, in which traffic is analyzed and feeds the layers described below – we switch blocking on once the model of a given service has matured.
Suricata – a network sensor that analyzes traffic at the packet level. It runs tens of thousands of detection rules that are kept up to date: it recognizes scanning patterns, attempts to exploit known vulnerabilities and suspicious protocol behavior. It operates across the entire edge of our infrastructure – not only in front of applications, but also in front of supporting services.
Layer two: the inside – sensors where the work happens
A firewall at the edge is not enough – good security assumes that someone may one day get past it. That is why a second line of sensors works inside the platform:
Falco watches over running containers and systems in real time – at the level of the operating system kernel (eBPF technology). It detects behavior that should not happen: a process that suddenly reads sensitive files, a container that tries to run an unexpected command, unusual network activity. It is the equivalent of a motion sensor in a vault – even if someone got through the door, they leave traces inside, and those traces are exactly what we pick up.
On top of that, we run file integrity monitoring of system files on the platform's key servers (an unauthorized configuration change leaves a trace), along with classic system hardening mechanisms – from automatically blocking addresses that try to guess passwords to restrictive permissions.
Layer three: a single picture – a SIEM that assembles the signals
A single sensor sees only its own slice. The strength of the whole system is correlation: events – from the firewall, from the network sensor, from the runtime sensors, from the operating systems – flow into a central SIEM-class system based on the Wazuh project, fed by agents spread across the entire server fleet.
This is where individual signals form a story: a failed login on one server is noise; the same source scanning ports, touching the firewall and trying passwords on three systems – that is already an attack pattern. Wazuh classifies events by severity, and in defined scenarios it can respond automatically – without waiting for a human.
In parallel, logs flow to a central analytics platform where they are stored and searchable – because in security, the ability to reconstruct the course of events down to the second is just as important as detection.
Layer four: we look for holes in our own systems – before someone else finds them
Defense is not only about waiting for an attack. A permanent part of our work is actively looking for our own weaknesses:
- Vulnerability scanners regularly x-ray the entire infrastructure – from operating systems to web applications and TLS configuration.
- Supply chain security: every release of our applications goes through a pipeline that generates a list of components (SBOM), and dependencies are automatically checked against known vulnerabilities – before they ever reach production.
- Detected vulnerabilities land in one central system, which orders them by severity and tracks remediation deadlines – the more serious the vulnerability, the shorter the deadline.
- Certificates and encryption are monitored continuously – we know about an expiring certificate long before anyone from outside notices it.
Layer five: everything on one screen – and under external supervision
Every element of the stack reports its health to central monitoring based on Grafana and Prometheus. The team sees the state of each layer in real time: whether the sensor is working, whether the firewall is analyzing traffic, whether some sensor has stopped reporting. Below is a fragment of a real view of the traffic analyzed by our network sensor:
The system raises alerts automatically at any hour of the day or night – notifications reach the team immediately, regardless of whether anyone happens to be looking at a screen. And because "who watches the watchman?" is a fundamental question in monitoring – the monitoring system itself is supervised by an independent watchman operating outside our infrastructure, one that would raise the alarm even if our entire platform fell silent.
In fact, we hand part of that visibility over to you: the public status.webdisk.io page shows the availability of our services in real time – without embellishment, straight from the monitoring system.
The most important layer: people and habits
Tools are no substitute for the way a team works. The stack makes sense because there is daily practice behind it:
- rules and exceptions are tuned – a system that shouts a thousand times a day for no reason teaches people to ignore alerts; our detections go through a tuning cycle until an alert means an alert,
- the stack's configuration lives in repositories as code – changes are versioned and reproducible,
- procedures and risk assessments (including DPIAs for features that process data) are written down and kept up to date, and we build our compliance program on recognized security frameworks,
- and finally – we assume our own safeguards will fail. That is not pessimism but a method: every layer exists because some other one may one day fail.
This last principle applies to us as well. That is why we publish a security.txt file and a vulnerability disclosure policy: if you are a security researcher and find a weakness in our systems, tell us about it – we would rather hear it from you than learn about it from an incident.
What this means for you
Let us count: the edge, the inside, correlation, our own tests, monitoring – five layers of technology and one human layer. This system works in the background every time you upload a file to WebDisk Files or send someone a link through WebDisk Send. You do not need to know about it – and that is exactly the point. And where security meets your decisions, we hand you concrete tools – the ones we described in earlier parts of the series: encryption at rest (SSE), access without permanent keys (STS) and WORM storage with the Anty-Ransomware feature.
Security is a process, not a state – which is why this set is constantly evolving: new detections, new layers and new tests are added. If you have questions about how we protect your data – or would like to talk about the security requirements in your organization – write to us.
This article is part of a series on data security in WebDisk services. Previous parts: encryption at rest (SSE-S3, SSE-KMS, SSE-C), access to S3 via STS/SSO, and S3 Object Lock and Anty-Ransomware protection.