Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
402 Military Communications and Information Technology... V. Network layer observation of future botnets In this section, we analyse the properties that will remain observable given the expected design of future botnets discussed in section IV. We start with describing the properties that remain directly observable in section V.A, followed by an analysis of how the behaviour of applications correlates with them. Finally, we motivate a granularity below traditional netflows as the base for further analysis and ultimately detection in section V.C. A. Observable features While OSI layer 2 is persistent in local networks only, i.e. its header does not contain any information written by the source of a layer 3 packet unless the point of observation is within the very same local network, we can learn the size of its payload and the observation time from it. The former will be equal to the size of the layer 3 packet transmitted by the source unless layer 3 fragmentation occurs. We suggest however to disregard this special case and treat fragments of a packet as if they were individual packets sent with the observed size. For the latter, i.e. the observation time, a simple relation to the timestamp t source at which an observed packet was transmitted by the source holds. With m denoting the mean time needed for traversing the links until reaching the observation point and j the jitter introduced by differences in network load and routes, we can characterise an observation timestamp t as: t = t source + m + j Thus, while we cannot determine t source exactly without knowing m and j, we can infer that the delay between two consecutive observations differs from the delay at the source only by the differences of the jitter applied to these observations. I.e. the smaller j in the equation given above, the better we can approximate that delay by observing the delay at our observation point. Based on the analysis provided in section IV, we assume that headers at layer 3 and 4 will generally be genuine, but at least allow associating observed packets with a particular flow. Note that forged source addresses, where possible, may serve to complicate attribution but would not impede with gathering and attributing data for the destination system. Our analysis further suggests that while OSI layer 5 and up data may be available technically, it will not contain exploitable features due to the combination of proper encryption and tunnelling through legitimate protocols. Note that with what we would call “not proper encryption”, using payload signatures may still be possible, as pointed out in [5].
Chapter 4: Information Assurance & Cyber Defence 403 B. Relations between application behaviour and observations on the network layer Typically, when a server application receives a request from a system running a client application, it processes the request, generates the answer and then transmits it to the client. Generating and transmitting an answer can be interleaved or executed in parallel. Thus, when an application generates data at the same speed or a higher speed than the capacity of the link that must be traversed when sending the data through the network, the respective packets will be as large as possible and emitted at a constant rate, i.e. the maximum rate permitted b y that link. On the other extreme end, an application may need considerably more time to generate a particular chunk of data than for transmitting it through the network. Therefore, a delay occurs between a request and the transmission of the answer. Finally, an application generating a fixed amount of data in each timestep, such as a voice over IP application, can be considered a special case of the latter type of application. We suggest however to consider this a class of behaviour on its own, leaving us with a total of three classes of observable behaviour: • Data transfer • Computationally expensive/varying data rate • Constant bitrate Figure 1 visualises the network layer observation of these features. Each box refers to a packet sent by an application, where the size of a box corresponds to the size of the respective packet and white spaces between boxes indicate that no data was sent by the application in the respective time frame. In this example, the first five packets fall into the data transfer class, saturating each except the very last packet. Following that, five packets are generated by a mechanism which generates data at a varying rate, observable through the variation of packet sizes and inter-arrivaltimes. Finally, the last five packets in figure 1 are generated at a constant rate and carry the same amount of payload. Time → Application behaviour Data transfer Computationally expensive answer Constant rate Figure 1. Packets observed for different kinds of application behaviour. Wider boxes indicate larger packet size, requiring more time for transmission While the varying data rate mode can easily be identified since it will result in a large variance of either packet sizes, inter-arrival-times or both, the other two classes will both result in a small variance for each of these properties. Thus, to be able to distinguish between them, we have to introduce a third metric. Such a metric should relate to properties of the link traversed in order to reveal whether
- Page 351 and 352: Chapter 4: Information Assurance &
- Page 353 and 354: Chapter 4: Information Assurance &
- Page 355 and 356: Chapter 4: Information Assurance &
- Page 357: Chapter 4: Information Assurance &
- Page 360 and 361: 360 Military Communications and Inf
- 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: 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 and 412: Chapter 4: Information Assurance &
- Page 413 and 414: 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 &
Chapter 4: <strong>Information</strong> Assurance & Cyber Defence<br />
403<br />
B. Relations between application behaviour <strong>and</strong> observations<br />
on the network layer<br />
Typically, when a server application receives a request from a system running<br />
a client application, it processes the request, generates the answer <strong>and</strong> then transmits<br />
it to the client. Generating <strong>and</strong> transmitting an answer can be interleaved or<br />
executed in parallel. Thus, when an application generates data at the same speed or<br />
a higher speed than the capacity of the link that must be traversed when sending<br />
the data through the network, the respective packets will be as large as possible <strong>and</strong><br />
emitted at a constant rate, i.e. the maximum rate permitted b y that link.<br />
On the other extreme end, an application may need considerably more time<br />
to generate a particular chunk of data than for transmitting it through the network.<br />
Therefore, a delay occurs between a request <strong>and</strong> the transmission of the answer.<br />
Finally, an application generating a fixed amount of data in each timestep, such<br />
as a voice over IP application, can be considered a special case of the latter type<br />
of application. We suggest however to consider this a class of behaviour on its own,<br />
leaving us with a total of three classes of observable behaviour:<br />
• Data transfer<br />
• Computationally expensive/varying data rate<br />
• Constant bitrate<br />
Figure 1 visualises the network layer observation of these features. Each box<br />
refers to a packet sent by an application, where the size of a box corresponds to<br />
the size of the respective packet <strong>and</strong> white spaces between boxes indicate that no data<br />
was sent by the application in the respective time frame. In this example, the first five<br />
packets fall into the data transfer class, saturating each except the very last packet.<br />
Following that, five packets are generated by a mechanism which generates data at<br />
a varying rate, observable through the variation of packet sizes <strong>and</strong> inter-arrivaltimes.<br />
Finally, the last five packets in figure 1 are generated at a constant rate <strong>and</strong><br />
carry the same amount of payload.<br />
Time →<br />
Application behaviour<br />
Data transfer Computationally expensive answer Constant rate<br />
Figure 1. Packets observed for different kinds of application behaviour. Wider boxes indicate<br />
larger packet size, requiring more time for transmission<br />
While the varying data rate mode can easily be identified since it will result<br />
in a large variance of either packet sizes, inter-arrival-times or both, the other two<br />
classes will both result in a small variance for each of these properties. Thus, to<br />
be able to distinguish between them, we have to introduce a third metric. Such<br />
a metric should relate to properties of the link traversed in order to reveal whether