After collecting

Most of the analysis workflows presented in the FADe project have been based on collecting the traffic of the System Information Blocks from all the towers or antennas monitored within the networks of interest. These System Information Blocks are part of the GSM (Global System for Mobile Devices) specification and some complementary protocols that contain information on:

  • The current tower or antenna being monitored, such as the transmitting frequency, country, and service provider.
  • Contextual information about the place and the network around the monitored tower, such as the frequency of neighboring towers and an area code shared between other towers in the same geographic area.
  • Technical performance parameters for each tower, such as the minimum signal strength of a phone to connect to a tower, how often the connection needs to be ‘refreshed,’ or how much power is required to maintain a connection over time.
  • The data related to specific areas of other protocols used, such as GPRS (General Packet Radio Service) or additional parameter 4G. This information is only obtained when those protocols are used in such a general way that we get fewer details of this type.

Event selection criteria for each type of test

Both in the results maps and the table of cases handled in the project, three (03) levels of the anomaly are proposed, low, medium, and high alert, to add emphasis to the most relevant cases:

All default cases are added with a medium level, except in the following scenarios:

  • When there are more than two (02) cases in the same tower, the level is increased to “high.”
  • When there is one (01) case in a high importance test, the level is raised to “high.”
  • In some particular cases, by developing a justification, increasing the level to “high” is possible.
  • If there is only one (01) case in a tower, from a test marked as having lower reliability, the level is changed to “low.” 

                 Low

          Medium

        High

High

Figure 1. Anomaly levels in results

 

Review of expected country and network codes

 

By having access to the database of measurements captured by the Crocodile Hunter sensor, a query can be made listing the unique combinations of MCC (country) and MNC (cellular company) codes searching for unexpected values. With these values ​​obtained, it will be possible to make other queries to determine which specific antennas were detected with country code and/or mobile network anomalies.

In some potential scenarios, specific suspicious values ​​of country codes (MCC) and network (MNC) known to be from providers in foreign countries can be found. In this case, depending on each set of values ​​observed, the anomaly could be explained (e.g., an antenna from a neighboring country in a border sector). In other cases, it is possible to observe anomalous codes that are not associated with any country or are associated with very distant countries.

In the same way, in the case of suspicious values ​​of network codes (MNC), these can even be accompanied by correct country codes but associated with unknown network codes for that country, so it is also relevant to analyze any anomalies in these fields even if the country code appears to be correct.

To take into consideration:  Some of the cases presented below are already considered in the Crocodile Hunter code or are being implemented. At the time of data analysis from the Bogotá (Colombia) and Santiago (Chile) monitoring, most of these analyzes were done manually. After the publication of this documentation, it is expected this analysis will be done effectively and reliably in an automated way.

Review of antennas detected in public services

 

Using, for example, the Google Geolocation API, Wigle, or OpenCellID services, it will be possible to consult the antennas seen and saved as cases of interest to those that are unknown by these services.

The Crocodile Hunter tool tries to make these queries for Wigle and OpenCellID when there is internet connectivity during the measurement. However, in those cases where the sensors do not have internet access at some monitoring moments, it is recommended to make these checks in a Handbook. In this sense, a simple adaptation of the SEAGLASS methodology workflow can also be used for Crocodile Hunter and thus carry out the automated query of antennas through their promoted codes on the network.

When doing this review, we will find, in most cases, consistent information (the antennas are recognized in locations similar to those observed). However, in some anomalous cases, some antennas may be unknown for these services. It can be due to several reasons:

  • The antenna was recently installed or reconfigured. In this sense, it is recommended to consider how much time passed between the moment it was seen for the first time and the moment when the check is carried out.
    • If the antenna was seen for the first time very recently, the services used to check might not have the information about this antenna yet.
    • If the antenna was seen for the first time, a reasonable time in the past compared to the check-in the services of interest (for example, in the FADe Project, there were at least two (02) months between the completion of the measurements and the check of these antennas), and it is considered that the data provided by the service of interest is reliable and fast enough to update, it may show that the antenna was only seen for a brief period of time, so it can be considered suspicious.

In the FADe Project, Google Geolocation API was used to do these checks since they have more reliable and frequently updated information for developing countries than other services.

 

Crocodile Hunter levels of suspicion check

The Crocodile Hunter tool performs several checks that can help detect suspicious antennas. For this, it uses an index of suspiciousness that indicates how suspicious an antenna looks. This index is available both in the Crocodile Hunter sensors’ web interface as in the database of each device. Those antennas marked with high values ​​of “suspiciousness” can be validated manually and added as interest cases.

Since the tests carried out by Crocodile Hunter can change over time, it is recommended to compare the antennas marked as suspicious with those considered in the previous tests. So as not to be regarded as a new case since some criteria that are considered to construct Suspicion’s index may well come from considerations already foreseen in the tests described above.

FADe project is an initiative of South Lighthouse with the support of the Open Technology Fund.

 

This website is available under a Creative Commons Attribution 4.0 International (CC BY 4.0) License creativecommons.org