Buffered Traffic Capture
Usually, the problem of threat prevention is the lack of detail about how the incident happened. Nowadays forensic are great to help to investigate an incident, but related to a traffic incident is not easy to have the full picture of it. usually, you will start a recording of traffic after the incident occurs missing important data about the incident. The idea of store ‘all’ traffic just in case is not always possible.
So, Can we have an option between both? I was watching a TV series, the episode was about a murder detected by a system that listens the street audio to detect a shot pattern and when the shot is detected it provides the audio recording of T seconds before the shot and T seconds after it. The guys investigating the murder asked the system team, How do you know and do start recording? How do you do the T seconds before a shot? and the answer was: a buffer, a buffer like the one that your smart-phone, shop-assistance box, car helper, or any other system nowadays, use to be able to recognize the magic token for listening to a command.
So as simple as that, a buffer.
As I was working with Software TAP configuration, it was easy to adapt the buffer idea to the model. Software TAP implementation in cloud instances, captures traffic and save it in multiple individual files of a determined size. so first buffer definition is “a number of captured traffic files” or “traffic chunks”. To limit the buffer size we will use two possible parameters, capture time and/or file size. Remember, to limit is always good.
So now, we can start recording traffic. Our buffer manager will include new traffic chunks in the buffer until it is full. When full it will start cleaning by asking ‘hey, does anyone need this older chunk?’ a negative answer will remove the chunk, an affirmative one will move the chunk to a traffic-under-analysis queue. Anyway, the chunk will be removed from the buffer.
Decide what Traffic to Capture
Now, what traffic to capture? well, we reduced the effort by delimiting time/size of a capture, but do we need to capture all traffic to analyze an incident? Sometimes the answer is no, adjusting the traffic that we want to monitor will save resources and will simplify our management. Maybe, we will listen for a protocol, or a set of ports, or a set of assets, or a mix of all them, but not all. Anyway, it is something that your scenario will decide for you.
Define the shot
The Shot? Now we need to define the magic token that will tell us ‘Hey OwlH, start recording it!’. this is the hardest part of this configuration. a too light filter will create too many incidents. a really strict one will provide rare ones. A good approach will be to use a few specific network or host ids alerts as the magic tokens to start recording.
Time. Before and after. How much?
You must decide the timing. you must decide how much time do you need before the incident and how much time after it to make your recording useful. I’m sorry, but there is no magical rule about it. Some APT (Advanced Persistent Threat) take days/weeks, other attacks are just a few packets in milliseconds. I’ve found that I will define timing in the following way; I will define the buffer, this must be defined before starting the process, so this pre-incident timing will be the same for any kind of attack. What I can do is define the post-incident time depending on the attack. we can use a parameter to specify how much time/size to capture for a particular attack.
What else?
Do not spend too much time thinking about each one of the constraints here. Just start it, learn, adapt and keep moving. Your network is alive, so your security analysis process should be alive too. Ask if you want to run it in your environment.
support@owlh.net
