Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
412 Military Communications and Information Technology... in higher level fusion of multiple information sources for a general detection of bot behaviour in network traffic. B. Guide railing features In section IV, we discussed the expected design for future botnets, focusing on the most promising approaches from a bot herder’s point of view and then described an approach for detecting botnets following the implied design principles. We are aware however, that a protocol may be designed particularly to evade approaches as the one presented in this publication, e.g. by using oversized transport headers for messaging to simulate packets without any application payload. As pointed out in section IV.B, this would constitute a more striking anomaly than the ones we aim to detect with the described features, but could nevertheless reach the goal of evading detection in the described feature space. For a practical deployment, our model should thus include additional features that indicate such evasive behaviour, i.e. provide strong evidence of malicious activity. C. Signatures As pointed out in section VII, legitimate applications may to some degree exhibit the behaviour associated with botnet clients. To avoid false alarms without allowing botnets with a loose C 2 channel to go undetected, it may be helpful to allow incorporating signatures matching the behaviour of these applications regarding our feature space so that the measurements they generate can be filtered. X. Conclusions In this paper, we discussed key elements of the botnet design which is likely to emerge from their ongoing evolution. Our analysis suggests that future botnets will use proper encryption and integrity checks for their protocol messages and authentication for commands and updates. Those measures, potentially complemented by tunnelling through legitimate protocols, would render them invisible to payload based approaches currently dominant in network intrusion detection. Based on careful analysis of the relationship between properties that remain observable to a network intrusion detection system under these circumstances and the behaviour of applications communicating through a network, we suggested to observe the delay between flow initiations to a similar protocol endpoint, the count of failed flow initiations and the count of payload bytes transferred for botnet detection. We drafted a system which exploits the measurement of these and possibly additional features as an input to an iterative likelihood ratio test for assigning one of three classes of hosts to each observed system. These classes include a model for hosts that have been infected with a botnet client, i.e. the classification reveals a malware infection.
Chapter 4: Information Assurance & Cyber Defence 413 While our prototype implementation does not cover all aspects of our approach yet and some issues remain open for further research, we were able to verify that the suggested features were affected by the Miner botnet client in the predicted manner. Single measurements will however not provide the level of certainty traditional payload signatures can provide for today’s botnets. Thus, detection has to be carried out as an iterative process, taking into account a series of measurements for each observed system. Similar problems have been studied in the field of sensor data fusion and thus our current and future research is part of a joint effort to migrate the methods and algorithms developed in that field into network intrusion detection. Acknowledgment We would like to thank our colleagues at the FKIE Cyber Defense and Sensor Data and Information Fusion departments, the University of Bonn Computer Science Department 4 and the Singapore DSO National Laboratories for our fruitful discussions and their advice. Our special thanks go to Daniel Plohmann of FKIE Cyber Defense for providing a reverse engineered implementation of the Miner C 2 protocol and his support in setting up our evaluation environment. References [1] D. Plohmann, E. Gerhards-Padilla, and F. Leder, “Botnets: Measurement, detection, disinfection and defence.” Technical Report published by the European Network and Information Security Agency (ENISA). Editor: Giles Hogben, 2011. [2] N. Falliere, L.O. Murchu, and E. Chien, “W.32 Stuxnet dossier,” Technical Report published by Symantec, 2011. [3] V. Paxson, “Bro: A system for detecting network intruders in real-time,” in Proceedings of the 7 th USENIX Security Symposium, 1998. [4] “Snort Official Website.” Available: www.snort.org [5] K. Rieck, G. Schwenk, T. Limmer, T. Holz, and P. Laskov, “Botzilla: Detecting the ‘phoning home’ of malicious software,” in Proceedings of the 2010 ACM Symposium on Applied Computing, 2012. [6] G. Gu, R. Perdisci, J. Zhang, and W. Lee, “BotMiner: Clustering analysis of network traffic for protocol- and structure-independent botnet detection,” in Proceedings of the 17 th USENIX Security Symposium, 2008. [7] M. Celenk, T. Conley, J. Willis, and J. Graham, “Predictive network anomaly detection and visualization,” in IEEE Transactions on Information Forensics and Security, vol. 5, no. 2, 2010. [8] T. Karagiannis, K. Papagiannaki, and M. Faloutsos, “BLINC: Multilevel traffic classification in the dark,” in Proceedings of the 2005 ACM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, 2005.
- Page 362 and 363: 362 Military Communications and Inf
- Page 364 and 365: 364 Military Communications and Inf
- Page 366 and 367: 366 Military Communications and Inf
- Page 368 and 369: 368 Military Communications and Inf
- Page 370 and 371: 370 Military Communications and Inf
- Page 372 and 373: 372 Military Communications and Inf
- Page 374 and 375: 374 Military Communications and Inf
- Page 377 and 378: Development of High Assurance Guard
- Page 379 and 380: Chapter 4: Information Assurance &
- Page 381 and 382: Chapter 4: Information Assurance &
- Page 383 and 384: Chapter 4: Information Assurance &
- Page 385 and 386: Chapter 4: Information Assurance &
- Page 387 and 388: Chapter 4: Information Assurance &
- Page 389 and 390: Chapter 4: Information Assurance &
- Page 391 and 392: Chapter 4: Information Assurance &
- Page 393 and 394: Chapter 4: Information Assurance &
- Page 395 and 396: Network Traffic Characteristics for
- Page 397 and 398: Chapter 4: Information Assurance &
- Page 399 and 400: Chapter 4: Information Assurance &
- Page 401 and 402: Chapter 4: Information Assurance &
- Page 403 and 404: Chapter 4: Information Assurance &
- Page 405 and 406: Chapter 4: Information Assurance &
- Page 407 and 408: Chapter 4: Information Assurance &
- Page 409 and 410: Chapter 4: Information Assurance &
- Page 411: Chapter 4: Information Assurance &
- Page 415 and 416: Methodology for Gathering Data Conc
- Page 417 and 418: Chapter 4: Information Assurance &
- Page 419 and 420: Chapter 4: Information Assurance &
- Page 421 and 422: Chapter 4: Information Assurance &
- Page 423 and 424: Chapter 4: Information Assurance &
- Page 425 and 426: Chapter 4: Information Assurance &
- Page 427 and 428: Chapter 4: Information Assurance &
- Page 429: Chapter 4: Information Assurance &
- Page 432 and 433: 432 Military Communications and Inf
- Page 434 and 435: 434 Military Communications and Inf
- Page 436 and 437: 436 Military Communications and Inf
- Page 439 and 440: On Multi-Level Secure Structured Co
- Page 441 and 442: Chapter 4: Information Assurance &
- Page 443 and 444: Chapter 4: Information Assurance &
- Page 445 and 446: Chapter 4: Information Assurance &
- Page 447 and 448: Chapter 4: Information Assurance &
- Page 449 and 450: Chapter 4: Information Assurance &
- Page 451 and 452: Chapter 4: Information Assurance &
- Page 453 and 454: Chapter 4: Information Assurance &
- Page 455 and 456: Generation of Nonlinear Feedback Sh
- Page 457 and 458: Chapter 4: Information Assurance &
- Page 459 and 460: Chapter 4: Information Assurance &
- Page 461 and 462: Chapter 4: Information Assurance &
412 <strong>Military</strong> <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong>...<br />
in higher level fusion of multiple information sources for a general detection of bot<br />
behaviour in network traffic.<br />
B. Guide railing features<br />
In section IV, we discussed the expected design for future botnets, focusing on<br />
the most promising approaches from a bot herder’s point of view <strong>and</strong> then described<br />
an approach for detecting botnets following the implied design principles. We are<br />
aware however, that a protocol may be designed particularly to evade approaches<br />
as the one presented in this publication, e.g. by using oversized transport headers<br />
for messaging to simulate packets without any application payload. As pointed<br />
out in section IV.B, this would constitute a more striking anomaly than the ones<br />
we aim to detect with the described features, but could nevertheless reach the goal<br />
of evading detection in the described feature space. For a practical deployment, our<br />
model should thus include additional features that indicate such evasive behaviour,<br />
i.e. provide strong evidence of malicious activity.<br />
C. Signatures<br />
As pointed out in section VII, legitimate applications may to some degree<br />
exhibit the behaviour associated with botnet clients. To avoid false alarms without<br />
allowing botnets with a loose C 2 channel to go undetected, it may be helpful to allow<br />
incorporating signatures matching the behaviour of these applications regarding<br />
our feature space so that the measurements they generate can be filtered.<br />
X. Conclusions<br />
In this paper, we discussed key elements of the botnet design which is likely to<br />
emerge from their ongoing evolution. Our analysis suggests that future botnets will<br />
use proper encryption <strong>and</strong> integrity checks for their protocol messages <strong>and</strong> authentication<br />
for comm<strong>and</strong>s <strong>and</strong> updates. Those measures, potentially complemented by<br />
tunnelling through legitimate protocols, would render them invisible to payload based<br />
approaches currently dominant in network intrusion detection. Based on careful<br />
analysis of the relationship between properties that remain observable to a network<br />
intrusion detection system under these circumstances <strong>and</strong> the behaviour of applications<br />
communicating through a network, we suggested to observe the delay between<br />
flow initiations to a similar protocol endpoint, the count of failed flow initiations<br />
<strong>and</strong> the count of payload bytes transferred for botnet detection. We drafted a system<br />
which exploits the measurement of these <strong>and</strong> possibly additional features as an input<br />
to an iterative likelihood ratio test for assigning one of three classes of hosts to each<br />
observed system. These classes include a model for hosts that have been infected<br />
with a botnet client, i.e. the classification reveals a malware infection.