Triggers
Our Cybersecurity Threat Intelligence (CTI) platform uses different indicators. One of the indicators is trigger-based. Whenever a specific trigger is detected, a CTI event is reported.
Possible Triggers
Triggers are ideally defined by customers so they get reports for events that are relevant for them. We support a variety of unique trigger classes:
| Trigger Class | Examples | Ideal for |
|---|---|---|
| Technology | Unix-platform, Bluetooth, RFID | Vendor, product teams |
| Product type | operating system, firewall software, web server | Vendor, product teams |
| Vendor, product, version | operating system, firewall software, web server | Risk manager, vendor, product teams, incident response teams |
| Country, region | Eastern Europe, Russia, Moscow | Enterprise, risk manager |
| Actor | User @ZeroCool on Twitter, AcidBurn on IRC channel #hackers | Enterprise, risk manager |
| Group, campaigns | Lazarus, APT28, OceanLotus | Enterprise, risk manager, incident response teams |
| Vulnerability attributes | buffer overflow + remote exploit available | Enterprise, risk manager, product teams, incident response teams |
| Vulnerability | CVE-2014-6271 (ShellShock), CVE-2014-3566 (Poodle) | Enterprise, risk manager, product teams, incident response teams |
Thresholds
Our CTI Team is monitoring different sources and activities for defined triggers. Observed activities have a weight which can be accumulated by multiple activities. As soon as a pre-defined threshold is reached, a new event is reported.
Thresholds shall not be too low as they might generate a large amount of noisy reports. In a worst case they might even begin to report false-positives. And thresholds too high will cause legitimate events to be missed as false-negatives.
We are happy to explain our approach and define reliable triggers and useful thresholds for your specific use-case.
Delimitations
It is not unusual that we see some undetected events during our monitoring as we have access to quite unique data. We were able to determine some important events weeks or months earlier:
| Event | Public Disclosure | Our Identification |
|---|---|---|
| Cisco IOS XR 0-day exploitation (CVE-2020-3566) | 2020-09-01 | 2020-08-28 (-5 days) |
| North Korea Attacking Banks (AA20-239A) | 2020-08-26 | 2020-07-14 (-5 weeks) |
| Iranian APT Group selling Pulse Secure Accounts | 2020-08-31 | 2020-06-10 (-4 months) |
We try to include references to other research in our reports whenever possible and useful. But we do not compile a complete list of research for an isolated event.
Furthermore, it might be possible that we do not see any interesting activities within our distinct data even though other sources claim to have identified such. In this case we might explain the absence of such validation possibilities and provide an assessment of the confidence of other sources.
Aktualisierung: 26.08.2024 von VulDB Documentation Team