What Is Network Security Resilience – Part 2
In Part 1 of this blog, I explained the concept of Network Security Resilience and its benefits. In this blog, I wanted to continue the discussion with some examples of what I was talking about. As you will recall from the last blog, there are a couple key pain points that we are trying mitigate; eliminate if possible. The first issue is that the average time from intrusion to detection of a security breach takes 191 days (on average). The second issue is that over half of victimized companies never discover the breach themselves—they are informed by law enforcement, business partners, customers, or someone else about the breach.
Security resilience is a concept focused solely on this endeavor. It is all about trying to minimize corporate risk and the cost of a breach. The intent is to create a solution that gets the network back up and running (after a breach has occurred) as fast as possible. To that end, here are just some of the specific activities that you can conduct:
- Deploy threat intelligence gateways to prevent the exfiltration of data to known bad IP addresses
- Capture and filter monitoring data, and then send that data to a purpose-built device to look at traffic patterns and indicators of compromise (IOC)
- Use application intelligence to help find IOC
- Decrypt SSL-based monitoring data with a network packet broker (NPB) to distribute data to forensic tools for faster analysis
- Implement adaptive monitoring using the automation capabilities of an NPB to respond to security information and event management (SIEM) instructions in near real-time and pass suspect monitoring data to data loss prevention (DLP) tools for analysis
- Install a security attack replay capability to capture security data and review it in the lab to acquire a tactical analysis of how the breach took place
- Conduct cyber range training so security engineers can recognize threats faster and practice responding to them properly
- Use threat simulation capabilities in your security lab to understand better how a new threat is behaving so you can remediate it faster
One of the first things to do is to deploy threat intelligence gateways to limit, if not prevent, the exfiltration of data to known bad IP addresses. The threat intelligence gateway should hopefully block all incoming traffic from known bad IP addresses as part of a defensive technique. Unfortunately, the IP address may not be known as bad at the time of the attack, thus allowing an attack to succeed. However, if the threat intelligence gateway is constantly being updated with new lists of bad IP addresses, then it may very well be able to prevent exfiltration of data, which would be a resilient technique. Even if a rap sheet (list of bad IP addresses) does not get updated with the new (now known) bad IP address for 30 days, this is still a reduction in the typical duration of a compromise by 83%. Should such an update occur within 15 days or less after the attack, then the breach interval could be reduced by over 90%.
Security breaches almost always leave behind some indication of the intrusion, whether it is malware, suspicious activity, some sign of other exploit, or the IP addresses of the malware controller. Some examples of those IOC include:
- Unusual levels of outbound traffic
- Outbound traffic to unusual IP addresses and geographies
- Unusual increases in application bandwidth flows
- Increases in read volume size
- Unusual increases in SAN access volume
- Applications using unusual ports
- Mobile device profile changes
Large amounts of data being stored in the wrong places
At this point, a network packet broker (NPB) should be deployed in your network. The NPB can filter and distribute the proper kinds of data to purpose-built tools for deep packet inspection (DPI) and data analysis. A well-built NPB will also have the capability of using application intelligence to look at IOC natively as well.
The packet broker can also perform SSL/TLS decryption for investigation of malware. While this functionality is often performed before data enters the network, malware attacks can, and are missed, by security analysis devices and security engineers. Once the security threat enters the network, the packets concealing it may still be encrypted. To understand and remediate the threat, those packets need to be decrypted again and sent to purpose-built devices like an intrusion detection system (IDS) or DLP for further analysis. Built-in SSL decryption within the NPB makes this a simple and easy task to perform at this juncture.
Automation capabilities within the NPB allow it to perform adaptive monitoring functions which means that it can respond directly to commands from SIEMs and other security devices through a standardized API (like REST). This allows the network to respond much faster to security threats as no human intervention (and subsequent delays) are introduced into the security response plan.
These and other security resilience techniques allow IT to focus on the two most important tasks after a breach: identification and remediation. For more information about best practices for Network Security Resilience, read this whitepaper. You can also read the whitepaper on Security Resilience—The Paradigm Shift Is Here to get a refresher on the security resilience concept.