Problem with the D-statistic -> nan

[daffi1238]

Good day to everyone,

I wanted to report a problem with the virtual machine offered by the project. When I start following the instructions in the README, first the script to activate nfcapd and after that the start_script.sh, when the project is running I check the logs of the routerR1 with tail -500f ~/msnm-sensor/examples/scenario_4/routerR1/logs/msnm.log and I recive, after some minutes:

'2021-06-12 12:43:11,515 WARNING - IntervalThread_7 - mod: datautils, method: getAllVarNames, msg: There are no remote sources configured: 'remote' 2021-06-12 12:43:11,516 DEBUG - IntervalThread_7 - mod: datautils, method: getAllVarNames, msg: 144 variables found 2021-06-12 12:43:11,518 DEBUG - IntervalThread_7 - mod: manager, method: launch_monitoring, msg: Observation generated of 144 variables at 202106121242. 2021-06-12 12:43:11,519 DEBUG - IntervalThread_7 - mod: manager, method: launch_monitoring, msg: obs 202106121242 added to the batch as number 1. 2021-06-12 12:43:11,519 INFO - IntervalThread_7 - mod: sensor, method: do_monitoring, msg: Running do_monitoring ... 2021-06-12 12:43:11,520 DEBUG - IntervalThread_7 - mod: sensor, method: do_monitoring, msg: Preprocessing the observation of (1, 144). 2021-06-12 12:43:11,520 DEBUG - IntervalThread_7 - mod: sensor, method: do_monitoring, msg: Computing statistics ... 2021-06-12 12:43:11,521 WARNING - IntervalThread_7 - mod: mspc, method: computeQst, msg: Qst has a complex value of (8256.991136639113+0j). Getting just the real part. 2021-06-12 12:43:11,522 DEBUG - IntervalThread_7 - mod: sensor, method: do_monitoring, msg: Qst obtained: 8256.991136639113 2021-06-12 12:43:11,523 WARNING - IntervalThread_7 - mod: mspc, method: computeDst, msg: Dst has a complex value of (nan+nanj). Getting just the real part. 2021-06-12 12:43:11,523 DEBUG - IntervalThread_7 - mod: sensor, method: do_monitoring, msg: Dst obtained: nan 2021-06-12 12:43:11,524 DEBUG - IntervalThread_7 - mod: manager, method: launch_monitoring, msg: MONITORING --> UCLd: nan | Dst: nan 2021-06-12 12:43:11,524 DEBUG - IntervalThread_7 - mod: manager, method: launch_monitoring, msg: MONITORING --> UCLq: 0.02626967412154494 | Qst: 8256.991136639113 2021-06-12 12:43:11,526 DEBUG - IntervalThread_7 - mod: manager, method: launch_monitoring, msg: Remote sources to send the packet #7: {'borderRouter': {'ip': '127.0.0.1', 'port': 9004}} ' The cause I think is about something is no convergin, the Q-statistics is being each time bigger and the D-statistic tend to zero. I'm using the standard traffic that the virtual machine is generating but I tried as well generate traffic using tcpreplay with a pcap. The point is trying to check the reliavility in a particular situation and be able to add malicious traffic in real time. Some advice about this?

Thank you.

[nesg-ugr]

Dear Jesús,

It is an interesting issue but sadly I have not been able to reproduce it in my local environment. Maybe this is motivated by the initial calibration of the model built from a randomly generated matrix. High values in Q and D statistics are, in this initial period, justified since the information of the calibration matrix is totally different from the information gathered from, in the case of routerR1, network traffic flow.

After 30 minutes (default dynamic calibration window) a new model is built but now from previously gathered network traffic. Let the experiment running for more than this time and you will see how the sensor adapts is behavior to this environment. It is can be seen in the dashboard monitoring graphs. Remember that this time can be on demand tuned so I suggest you to set up a small calibration window if you want to see the effect quickly.

Anyway, could you export me all the data of the experiment? I mean compress all the experiment_4 folder and share it with me whichever the way you want. Maybe through a shared link in GDrive.

Now we are working in several sensor improvements but it should be great to hear new ideas and proposals from people using the sensor. So, feel free to suggest whichever you want and to contribute with the project.

Roberto.

[daffi1238]

Good morning Roberto, I already discover the seed of the problem, after do 'git pull' in the project (I'm using the virtual machine uploaded in GDrive) the default iterations to automatic dynamic calibration is 2. (In /home/msnm/msnm-sensor/examples/scenario_4/routerR1.yaml): Sensor:

  diagnosis: data/diagnosis/
  dynamiCalibration:
    **B: 2**
    enabled: true
    lambda: 0.1
  output: data/monitoring/output/
  observation: data/monitoring/observation/
  prep: 2
  phase: 1
  model: data/calibration/

After changing that to 10 or 60 it looks to work but just routerR1 (I guess that is because the traffic flow is not enough and I should do the same thing to get the others functional as well).

The folder of the experiment_4 is the same that you get if import the virtual machine using the .ova file you offer and after that you do a git pull in the folder. Having solve the problem I think the issue can be closed.

Thank you and greetings, Jesús.

[nesg-ugr]

Dear Jesús,

'B' parameter set ups the size of the window (batch of observations) the EWMA algorithm considers for the re-calibration of the PCA model. I should be good to test and identify potential and functional associated issues with this parameters and the EWMA model.

Feel free to open issues in this way to help us to fix bugs and improve the project.

Thanks for all!

Roberto.