Military Communications and Information Technology: A Trusted ...

Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...

22.01.2015 Views

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

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!