DCN June 2016 - Page 34

automation tools ALERT AND ACTION Companies can encounter problems when collecting more packet data, which requires them to sift through so much more data following a breach. If the right tools aren’t in place and the right processes aren’t followed this increased monitoring could be a real time and budget waster. Here, Tom Rowley of Savvius outlines what alert automation tools should be considered, how they should be implemented and best practice in a breach situation. B usiness networks have changed in three important ways over the past few years. First, they’re faster than ever. Second, they connect to more devices (thank you, BYOD), and third, a growing share of network traffic consists of rich media such as VoIP and video that is highly sensitive to network delays.  As well as being faster, more connected, and voice and video centric, our networks have also become more difficult to troubleshoot and secure. Some of this is due to the fact that they transport too much data for traditional network monitoring and troubleshooting tools to reliably collect and analyse. Many analysis tools end up relying on snippets or samples of traffic and high level statistics, but these lack the details and hard evidence that IT engineers need when troubleshooting problems and characterising security attacks.  Given the near certainty that your organisation will be breached, it’s clear that modern best practices for enterprise security need an overhaul. As part of that change, they have to include specific tools and expertise to 34 help them respond to an attack. While an enterprise needs to build the best defence it can, and constantly monitor its network as closely as possible, it also needs to be ready to immediately launch an investigation when hints of a breach become apparent. Evidence of intrusion The key to conducting a successful investigation is to have historical data at hand that can be examined for clues to the attacker’s behavior. No matter how good an attacker is, the culprit will unavoidably leave evidence of the intrusion. This evidence will typically be found in one of three places: in the memory of the computers and servers on the network, in the logs files that record actions on each individual computer, and in the traffic (packets) that traversed the network. Some of these forms of data are more useful than others. Memory data can be very useful if the attacker is still present in your computers, but they are often long gone and the memory erased. Log data can provide very detailed clues to the attacker’s behavior but, unfortunately, it’s relatively easy to erase or forge. As a result, modern forensic investigators are increasingly turning to network data as the prime source of forensic clues. Network traffic and packet data recordings can’t be easily forged since they are stored in real time, making then difficult to modify. Lots of attacks do involve manipulating network and packet data but all of that attacker behavior can be indelibly recorded and later used to replay the assault. The old adage that ‘packets don’t lie’ is not only true, it also gives forensic investigators an important advantage. In the ideal world, investigators would have logs and network packets at their disposal to reconstruct an attacker’s behavior and assess the damage caused. But the question remains, how long does an enterprise need to save log and network data? Unfortunately, modern attackers can be very good at disguising their entry into an enterprise, and it may be an extended period of time before the breach is discovered. According to the 2015 Trustwave Global Security Report, the median time to detect an attack was 86 days – nearly three full months. Other studies have shown an average time-to-detect of up to 270 days. And how long does it take