The sensor network
Exposed systems that receive real attack attempts and record address, method and time. On the order of sixty sensors across around fifty countries.
Where the threat data comes from
All blocking in WF SecurityCloud rests on one question: do we know that this address attacks? The answer does not come from guesswork but from attack attempts that have actually happened.
Attackers reuse themselves
Automated attacks are cheap to repeat and expensive to vary. The same infrastructure is used against a great many targets before it is abandoned: the same servers, the same domains, the same tools.
That repetition is what WF SecurityCloud exploits. Once an address has been seen attacking one system, there is good reason not to let it into the next. The more places that see the same address, the safer the conclusion.
Collection happens on several levels
The sensor network is the foundation, but not the whole picture. Several independent levels feed the same assessment, which makes it harder to fool.
Protected devices
Clients and websites report what they have blocked. An address stopped in many places confirms that it is still active.
Our own collection systems
Systems we have built to reach threat data that is not visible in the open. We do not describe publicly how they work — that would make them easier to avoid.
What is watched
Attackers do not stick to one service. The sensors therefore receive attempts against the protocols that are actually targeted, and distinguish between what each attempt is after.
- Remote desktop — by far the most common target in our measurements
- SSH — login attempts against remote administration
- HTTP and HTTPS — attacks on websites and web services
- SMTP — attempts to abuse mail servers
- FTP — login attempts against file transfer
- MySQL and MSSQL — attempts to reach databases directly
- Reconnaissance — port and vulnerability scanning that precedes an attack
We also analyse several other kinds of data to improve the assessment. The more independent observations point the same way, the safer the conclusion that an address really is dangerous.
What a sensor records
The connection
Which address connects, against which port and at what time.
The method
What the attempt is after: a login, a scan, a known vulnerability or some other pattern.
The repetition
How often the same address returns, and whether it changes method between attempts.
The spread
Whether the same address appears across several independent sensors, or only in one place.
From raw data to block list
A single hit is not enough. One failed login attempt can be a misconfigured server or a user who mistyped. Only when the pattern persists, or shows up in several places, does the address gain weight.
Working in the other direction matters just as much. Addresses get reused — a server compromised last week may be cleaned up today, and a cloud address can change customer. So addresses drop out of the lists when they stop appearing.
- Isolated events are not enough for a block
- Hits from several independent sensors carry more weight
- Repetition over time strengthens the assessment
- Addresses that stop appearing drop out of the lists again
- Lists are updated continuously, not in large batches
How the protection reaches you
Your devices fetch updated lists from us continuously. The direction matters: the device asks for protection, we do not ask the device for anything.
What goes back are events about what was blocked — an address, a type and a time. That is what lets you see in the panel what has been stopped, and it is also all of it.
Contribute a sensor of your own
A sensor on your network gives you a picture of what is aimed at you, and makes the threat data better for everyone.