Protect the Highway – Critical Links (Hacktivism #2)
avatar

Problem to Solve:  What can we do to protect our organization from Hacktivism, specifically in the area of Critical Links and Infrastructure?

traffic network jamHave you ever seen any of your critical business links that look a “little congested“? I bet that some of you have experienced a network that is completely consumed like this highway.  The assumption for the rest of this article is that you probably have security tools already covered on some of your critical infrastructure links. As we build the overall defense strategy, our goal is to extend complimentary functionality for the existing security tool sets, but …. do it from an APM NPM perspective.

Internet Links

Your Internet link most likely consists of firewalls, load balancers, intrusion prevention systems (IPS), intrusion detection systems (IDS), Data Loss Prevention (DLP) engines, SPAM filters, etc. Obviously this is the link that the bad guys/hacktivists have the “easiest access” to from anywhere on the globe. But when you consider that these links carry some of your most business critical applications, you realize this traffic is beyond simple Internet browsing. The reality is that in today’s world, there are likely cloud-based applications or hybrid cloud-based applications also running over that same exact Internet link. We guide our customers to take a look at their most critical applications and services, as it relates to raw Internet link utilization. The question is, how do you feel about the Internet link “not being available“. For example, if you’re running cloud-based applications such a SharePoint, Office365, or Amazon Web services and the Internet link becomes saturated, it will be very detrimental to your business. If your environment is 100% cloud-based then any disruption of Internet service disrupts your business. In my opinion the “hybrid cloud” becomes an even greater challenge, because it is so difficult to determine whether a DDOS attack is being executed from the outside (cloud), or if is it being done on your internal infrastructure that interfaces with the cloud. Either way, from a business perspective, it can be quite painful. 

DMZ (De-Militarized Zone)

If you are hosting a VPN or Web server inside the DMZ that provides access into your backend infrastructure, the DMZ link becomes a critical cog in the application services offered to the outside. In many organizations, the DMZ is heavily instrumented from a security perspective. It is often an interesting exercise to step back and look at the application traffic within the DMZ as it flows through the various security zones and tiers.  This is an example where you can leverage your APM NPM tools to actually keep an eye on your critical links and services running inside of the DMZ.  Any increase or spike in the utilization of the network links that feed the DMZ can cause a business services impact. As I mentioned in my previous article (http://problemsolverblog.czekaj.org/troubleshooting/protect-foundation-critical-services-hacktivism-part-1/) key service enablers are a great place to start the monitoring process.

WAN Links

Whether your Wide Area Network is serviced by MPLS or a “site to site” VPN,  your company’s remote sites connect to the data centers from these links. In today’s world of converged infrastructure, that traffic also includes “Voice over IP” as well as video.  These links are critical due to the importance of the business traffic that traverses these links. Obviously the data center links are high-bandwidth, but any impact to them on the “Data Center side” will also disrupt application services to the remote sites as well. We recommend being proactive and alarming on WAN links so that you know what business services are being impacted due to a sudden spike of traffic. 

B2B Links (Business to Business)

Many customers have links to outside vendor/partners that interface with your internal systems. These links are business-critical as your systems share information with your business partners necessary to conduct business operations. If an attacker can take down your B2B link, then they have effectively taken down business services that you need to maintain from a service perspective to keep your Company functioning optimally.

IoT (Internet of Things) and Big Data Links

IoT and Big Data are emerging technologies that have “all kinds” of business potential. Companies are considering leveraging the IoT and Big Data for their product offerings that provide key service information, proactive maintenance, software updates, and performance metrics. Quite simply, IoT and Bid Data can be used as competitive advantage. This is the challenge to consider.  What would happen if the IoT/Big Data collection service gets taken down from a service perspective because of a spike of traffic? The very thing that your company is leveraging for a competitive advantage, then becomes a liability because the service is not available.

The Pain of Self-Inflicted Wounds

We have seen many unfortunate customer situations, where their critical links were effectively taken down due to an event from “inside the company“. We have seen examples that range anywhere from streaming audio, large file transfers, video conferences, unscheduled v-motion server changes, software distributions, unattended scripts that were executing a load test. We call these types of things “self-inflicted wounds” because these are often perceived as an outside attack on your company resources.  However, they are actual events caused by things that happen inside of your company that you usually cannot anticipate.

What Can You Do?

Based on the criticality of the business traffic and examples of where situations can adversely affect your service, what can you do to protect your company?  Here are some recommendations and strategies that we recommend to our customers to employ.

  1. Traditional Network Indicators – Keep an eye on basic network metrics such as link utilization, frame sizes, and packet rates.  These types of metrics can potentially be indicators of an outside attack (DDOS, SYN flood, etc.). Again, the goal is to leverage your APM NPM tools to compliment what your security tools are doing, as “two heads are always better than one”.
  2. Application Flows and Bandwidth Hogs – Keep an eye on the actual applications flows and services running on the link to see which culprits may potentially be hogging bandwidth or having performance issues. These “could be” an indicator that your environment has been compromised, and potentially allow you to see the output of the outside attack as it unfolds.  Seeing what threat actors and IP addresses are involved assists in the remediation process.
  3. Interface with Security Tools – Use your APM NPM tools to add a level of proactive alarming, and then interface the data with your security solution.  The concept is to put your best foot forward (from a probability perspective) to remediate compromised security. The goal is to use all the information that you have available for your security strategy. In this case, your APM NPM tools can be a large asset to your strategy, specifically from a proactive perspective. Cyber security is everyone’s business, so why not bring all of your available systems and application tools into the fold on your strategy? This approach will provide more return on your investment, and more information on your security situation.  APM NPM tool sets can help to supplement areas of the network visibility where your security tools are not deployed, or have limited functionality.
  4. Know Your Tolerance for an Outage – A key consideration is to know your tolerance for a critical link performance issue. For example, a customer in electronic trading markets or retail banking will have a very low tolerance for a service outage. An outage specifically less than 10 milliseconds may have a business impact on finance related customers.Therefore, you will want to consider your alarming strategy in terms of “time granularity” for which you can look at utilization statistics for a link. This type of information can be leveraged with specific metrics again to compliment your security tools and information they collect. Remember that networks are measured in gigabits / megabits / kilobits per second. An APM NPM solution can usually provide “second by second granularity”, and that is a huge value add during a security event. This is a perfect example where you can leverage multiple tools and disciplines to help facilitate your remediation plan.  Tool sets that provide 15 second, one minute, or five-minute granularity from a pure utilization perspective, are great to use; however, they do present some challenges as well. Specifically, the challenge and concern is what’s called watering down the data. The biggest situation is where you really need to see a second by second graph of utilization data, but the graph display is rolled up into 15 seconds or one minute or five minute increments.  Many times, a microburst spike of traffic will get “watered down” because of the longer time duration of the actual data poll.
  5. Automated Analytics – Leverage the automated analytics capability inside of your APM NPM tools to continually analyze utilization. Many of these tools provide functionality where they can determine shifts, drifts or spikes of traffic that are anomalous. These types of tools are usually geared toward application performance management; however, they can also be an excellent early indicator of a denial of service attack or utilization spike. Additionally, these types of tools usually provide more visibility in terms of “East West” virtualized server traffic which often is a blind spot in most security strategies.   

Most importantly, the thing to remember is ….. the overarching goal of using your APM NPM tools is to compliment the security tool deployments. You want to bring “everything you have to the table” in terms of information, to address security events

Continue on to the next article, “Protecting the Critical Application Services” (Hacktivism #3) http://problemsolverblog.czekaj.org/troubleshooting/applicationhacktivism_3/.