Kentik Detect for Network Security
Protecting Your Network with Comprehensive, Timely Understanding
Network security depends on comprehensive, timely understanding of what’s happening on your network. That requirement dovetails nicely with the primary purpose of Kentik Detect™, which is to enable customers to monitor and analyze network traffic so that they can identify and resolve issues affecting network availability, performance, efficiency, and integrity. The foundation for this work is the network data that is captured and stored by Kentik’s post-Hadoop Big Data backend, Kentik Data Engine™ (KDE), which includes full-resolution flow records (e.g. NetFlow, IPFIX, sFlow), BGP routing tables, GeoIP data, and SNMP. KDE fuses these sources into a unified time-correlated dataset against which customers can run ad-hoc queries that are grouped and filtered on 40+ dimensions, yielding advanced visualizations and detailed tables in seconds. Customers can also access the data via APIs (SQL or REST) that enable tight integration with third-party analytical or mitigation tools.
Among the key value-adds of Kentik Detect are the ways in which it enables network data to be applied — without add-ons or additional charges — to enhance network security. The platform captures data from networks operating at Terabit scale, makes the data available for querying within seconds of receipt, and can store historical data for months in its SaaS platform. That means that security issues can be identified and explored not only in the present but also historically for as long as you remain a customer.
To get a concrete feel for how Kentik Detect applies to security, let’s look at a couple of use cases that Kentik Detect can address. Note that queries created for ad hoc exploration can be converted into alerts that provide proactive notification of future recurrences.
Because Kentik Detect observes all traffic to and from the network, it can easily identify all of the interactions between the monitored networks and the rest of the Internet. You can use this capability to identify compromised hosts and command-and-control communications by setting up queries that break out traffic by protocol and origin (GeoIP). Advanced Big Data style visualizations returned from these queries make it easy to see where the traffic is going and on which ports.
Kentik Detect’s GeoIP functionality can be used to show traffic from regions that you know you don’t operate in or do business with, so you can block traffic of suspicious origin. From there you can drill down into traffic from the remaining regions. Internal servers should have a very limited contingent of hosts and domains that they are allowed to communicate with. With a few simple queries you can investigate further to identify hosts that you don’t recognize and may want to designate as out of bounds.
A complementary approach is to check the protocols used by your traffic. Once again, servers should communicate using a fairly narrow range of protocols, and this is particularly true for internal servers that communicate with the Internet. Parties attempting external command and control (C2) would typically need to use TLS/SSL or non-standard ports for communications. You can use Kentik Detect to catch traffic using these unexpected protocols, especially traffic going to unexplained hosts, which is a significant indicator of unauthorized C2 communications.
Data exfiltration involves an external threat actor or a trusted insider trying to move the data off-site. Indicators of data exfiltration include out-of-time-slot communications, excessively long communications, or significantly increased communications. These signs are easier to see if you’ve already blocked compromised hosts that you identified using the techniques discussed above.
If two known good hosts begin communicating out of their normal time ranges, there may be an exfiltration issue. Using time boundaries on a Kentik Detect query, you’ll be able to see when the communications began and ended, and to cross reference odd-hours transfers against data transfer protocols and TLS traffic.
If two hosts are engaged in extended or otherwise highly patternistic communications that are out of policy or “the norm,” that can also be indicative of dangerous activity such as command and control, reconnaissance, and/or data exfiltration. The flow records in Kentik Detect are sampled, so the detection pattern is dependent upon the volume of data. In the case of data exfiltration, attackers generally try to avoid tripping alarms that look for data spikes or odd-hours transfers, so they use throttled data transfers at regular intervals until the exfiltration is completed. These approaches actually make it easier for Kentik, because the longer the interactions take place the more data is collected to identify the anomalous behavior. The suspect patterns can be identified through Kentik’s search and reporting tools and then remediated using the existing network infrastructure. Since attackers often use redundant C2 servers, additional host-based remediation may also be necessary.
Kentik Detect also makes it easy to see “bursty” or other large-volume communications. Users can drill down into oddly large data flows and compare them with historical flows to identify increases, after which investigation can focus on determining why the flows increased. Even analysts who have only been using Kentik Detect for a short time can quickly identify changes in data flows and volumes, kick off remediation workflows, and create new alerts that will trigger for future similar events.
David Monahan is a senior information security executive with years of experience in physical and information security for Fortune 100 companies, local governments, and small public and private companies.