The Threats page is your hub for understanding how your devices, application stacks, locations, and departments are vulnerable to attacks. We compile and prioritize all vulnerabilities into a single Threat Level rating, but will give you access to all the underlying data so you can determine course of action.
Every device who has a Threat Check in your environment will have a Threat Level. The higher the level the great the security threat of a particular device.
The Threat Level is determined by combining all known vulnerabilities and the behavior of a device.
- Level 1: A device has an unused listening service
- Level 2: The above and the device has a vulnerability on an installed package
- Level 3: All of the above and that package is running
- Level 4: All of the above and that server connects to the internet
- Level 5: All of the above and when that server connects to the internet it connects to a anonymous proxy
This example is meant to illustrate the logic behind Threat Levels, not be an exact description of how Threat Level is determined.
We recommend at least investigating every device that's level 3 and above.
How are Threats Changing Chart
The chart shows how Threat Levels are changing daily. You can filter this chart and all subsequent tables to specific date ranges either by selecting the start and end dates in the date picker control above the chart or by filtering to a specific date in the tables directly. The page loads with all collected data.
It is important to note that servers will transition between levels based on the time bound nature of certain Threat Checks. For instance, if a server talks to the internet for the first time (when it has not previously) it will trigger a check, but that check will only be relevant for the day we see it exhibit anomalous behavior and then ceases to contribute to the Threat Level.
Threat Checks are a series of checks that are run nightly on every assessment. Threat Checks contribute to a device's Threat Level differently depending on their Check Impact. We list the Check Impact classification in the Threat Checks table. Basically, it takes more checks with low impacts to increase Threat Level than checks with High impacts.
|Device received connection from high-risk area||high||On day of check, device reported a TCP/IP connection where the IP geolocated to a high-risk area AND was the source of the connection|
|Device initiated connection to high-risk area||medium||On day of check, device reported a TCP/IP connection where the IP geolocated to a high-risk area AND was the Destination of the connection|
|Device initiated connection to known anonymous proxy||high||On day of check, device reported a TCP/IP connection where the IP geolocated to a known anonymous proxy where the proxy was the destination of the connection|
|Device received connection from known anonymous proxy||high||On day of check, device reported a TCP/IP connection where the IP geolocated to a known anonymous proxy where the proxy was the source of the connection|
|Device started receiving connections from the Internet||medium||On day of check, device reported a TCP/IP connection to a public IP address where the public address is the source of the connection AND no public IP address connection as the source was previously reported|
|Device started reaching out to Internet||low||On day of check, device reported a TCP/IP connection to a public IP address where the public address is the destination of the connection AND no public IP address connection as the destination was previously reported|
|Device receives connections from the Internet||medium||On day of check, device reported a TCP/IP connection to a public IP address|
|Vulnerable package running||medium||On day of check, device reported an executable that mapped to an installed package that was found to have a vulnerability|
|Vulnerable package communicating||medium||On day of check, device reported an executable in its TCP/IP connectivity that mapped to an installed package that was found to have a vulnerability|
|Vulnerable package installed||low||On day of check, device reported an installed package that was found to have a vulnerability|
|New Listening Process||low||On day of check, device reported a new listening process that did not exist on the previous day|
|New Installed Software||low||On day of check, device reported new software installed that did not exist on the previous day|
|New Running Process||low||On day of check, device reported new process running that did not exist on the previous day|
|Unused Listening Process||low||On day of check, device reported a listening process to which no connections were observed in the previous 30 days|
High Risk Areas
This panel is meant to show where in the world you may be receiving connections from high risk areas. For a definition of "High Risk" please go to the Geolocation Documentation page.
We update our database daily at 4:30AM EST with software vulnerabilities (i.e. Common Vulnerabilities and Exposures (CVEs)) from the National Vulnerability Database (NVD) maintained by the National Institute of Standards and Technology as well as the Open Vulnerability and Assessment Language (OVAL) repository maintained by the Center for Internet Security. CVE data being used is never more than 24 hrs old.
Our ssh collection pulls rpm/dpkg package lists from Linux servers once per day in the environment and compares the package to those listed in the vulnerability data.
We will pull CVEs for the following Linux distributions:
|Oracle Linux||5, 6, 7|
|RHEL Server||5, 6, 7|
|Ubuntu LTS||14.04, 16.04, 18.04|
|CentOS||5*, 6, 7|
No EOL distributions are supported.
*CentOS 5 will match against RHEL 5 OVAL but CentOS stopped providing updates in 2017
**SLES for SAP Applications is not currently supported, nor are non-LTS versions of Ubuntu.
Q: Why do I have so many software vulnerabilities?
A: A single package can have multiple vulnerabilities, and a single server can have multiple packages, and we look at this every day. It's the multiplicative nature of it.
Q: How current is the page?
A: It may be up to 48 hours behind from the current time. Since our processing and uploading works on an aggregation method the time between when a particular performance metric is collected to the time it appears in the portal can be up to 48 hours due to post processing.
Q: Why do I have big dips or spikes in the area chart?
A: Generally, this is caused by performance collection being halted or started on the RN150 appliance. For instance, if you tell the appliance to do a discovery it is not collecting the data needed to do many of the Threat Checks so you would see a corresponding dip in level.