• Grey Twitter Icon
  • Grey LinkedIn Icon
  • Grey Facebook Icon

For more information please contact Javier Augusto Gonzalez, R&D Project Management, Televés, S.A.

www.televes.com

Rúa da Benéfica de Conxo, 15706 Santiago de Compostela, Spain  |  jaugusto@televes.com  |  Tel. +34 981 522200

This project has received funding from the European Union’s Horizon 2020 Framework Programme for Research and Innovation under grant agreement No 740923. The content of this website reflects only the views of the project owner. The European Agency / Commision is not responsible for any use that may be made of the information it contains.

 

Search
  • GHOST

Is your tablet hacked or just a Sunday morning?

Imagine that you have an ML-powered security module residing inside your access point that tracks network traffic and is able to identify possible attacks and malfunctions on your interconnected devices. In order for this security module to be trustworthy, and thus useful, it should not only correctly identify anomalies, but also ensure that alarms are not raised unnecessarily. In other words, this system must minimize both false negatives (i.e. anomalies that are not detected) and false positives (i.e. unnecessary alarms). A frequent problem, though, in the design of such systems, is that the more sensitive a system is configured to be, the more probable it is to consider normal operations as attacks, and raise false alarms. On the other side of the same coin, in order to minimize false alarms, then sensitivity usually goes down, and thus attacks may pass unnoticed.

In applications where there is little variation in monitored values during normal operation, it is quite easy to identify the sweet spot in the configuration of the ML-based system that allows the latter to identify anomalies while raising the minimum number of false alarms. Things are different, though, when the objective is to track anomalies in network traffic generated in a home. Indeed, in this case, there is no one size fits all solution, as traffic varies depending on factors such as the number of devices and users connected, time of day, day of the week, etc. For example, on a Sunday morning, more family members are connected via their devices to the Internet, compared to a Tuesday morning, as in the latter case they will be at work or at school. But even if the same number of devices is connected at any given day, there is a huge difference in traffic generated during the day, compared to the one created during the night. It becomes clear that devices operated or affected by humans, create traffic that is affected by the human circadian and weekly rhythm, as well as by social conventions, whereas devices that are not affected by humans, such as a room thermometer, create traffic that does not follow a similar pattern.

In order to accommodate all these different behaviors of devices, we are equipping the GHOST platform with a Profile Builder module. As its name suggests, this module generates network traffic profiles based on the day of the week and the time of day for different protocol types during the training phase and compares these profiles against real traffic in order to detect possible anomalies with greater accuracy and fewer false positives and negatives. As a result, the GHOST platform will be able to correctly identify a device that has been hacked and generates irregular traffic but not be puzzled by a device that creates traffic only during weekends, and detect an anomaly if it senses that a device has possibly maliciously been gotten out of use but not raise an alarm simply because this device was silenced on a typical Monday morning. End-users, then, are enjoying higher prediction accuracy and fewer false alarms as they surf the web on a Sunday morning.


EXUS AI Labs

18 views