Sentinel: rethink naming hierarchy
Note: the main goal is to get rid of data collection
term
Currently there is not strict hierarchy in Sentinel components naming from the users point of view. A different version of naming hierarchy is used in the docs and in reForis:
We should unify this and use the same convention wherever possible.
Unfortunately, there is not a simple guideline how to do that. Sentinel-related toolchain consists (from the docs/settings/user point of view) at least of these parts:
- Sentinel threat detecting collectors (minipot, fwlogs)
- Non-sentinel threat detecting collectors (HaaS client)
- Other data collectors where Sentinel is involved: (turris/sentinel/turris-survey>, sentinel status)
- Non collectors: dynfw client
Option 1 (technology first)
Probably the best solution would be to ignore the fact that HaaS client is not a direct member of Sentinel family and it's activation involves visiting haas.nic.cz
- Sentinel
- EULA
- threat detectors (minipot, fwlogs, haas)
- dynfw
- usage statistics (survey)
The bad thing is that Sentinel is depicted here not as a security-only project and involves also survey.
Option 2 (purpose first)
Since Sentinel is mainly a technology, it may be ignored. Security, including threat detectors and dynamic firewall should be strictly separated from usage statistics.
- Intrusion prevention
- EULA
- threat detectors (including haas)
- dynfw
- Usage statistics
Option 3
As survey is only a side-effect of Sentinel technology, we may pretend it's not even part of it:
- Sentinel
- EULA
- thread detectors (with HaaS)
- dynfw
- Usage statistics
Option 4 (conservative)
This option is based on what has been already agreed and is used in reForis. Basically it renames Data collection
to Threat detectors
. Survey is still in this section although it's not a threat detector.
- Sentinel
- EULA
- thread detectors
- dynfw
- HaaS