We’ve enhanced account security by incorporating email activation and TOTP 2-factor authentication.
When first creating your account, and also when changing your password, you’ll now be sent an email to which you’ll be required to respond in order to complete the remaining steps in the process. This change applies in the following situations:
The Kentik Detect portal now allows users to add 2-factor authentication to their account. The flavor we use is called Time-based One Time Password, aka TOTP. It works with any mobile app allowing you to register TOTP tokens, including the following, which can be found on Google Play and the Apple app store.
To enable TOTP in the Kentik Detect portal, open your User Profile page by clicking on your username at the right of the navbar. You will now see a ‘security’ section in the User Information pane at right.
Click the Register for TOTP button and follow the instructions (you’ll be presented with a QR code to enroll your mobile device). Once you’re enrolled, at each login you’ll be prompted for a TOTP token after entering your login/password.
If for some reason you lose your token or change your device, please contact an Admin user within your organization. This user can disable TOTP for your account by going to Admin » Users to access the Edit User page for your account, then clicking the Disable TOTP button. At this point you’ll be able to log back in and re-enable TOTP with your new device.
Several recent changes have expanded the dimensions and metrics available for use in your queries.
Depending on the time-range of a Kentik Detect query, the individual one-minute slices stored in the KDE (Kentik backend) may be aggregated into wider aggregation steps for returned results (for more explanation, see Time Rounding in the Kentik KB). For queries whose time-range was 24 hours or more, each aggregation step used to represent 20 minutes. We’ve now halved that to 10 minutes, doubling the resolution of results from these longer queries.
The options available for metrics include more than a dozen that count unique instances. Until recently we computed these over a single time-slice for a single device, but we announced back in May that for Unique Src/Dst IPs we were now computing across the union of all devices. From that first step toward enhanced accuracy we’ve now extended these improvements in two ways:
The ability to look across time-ranges and devices all combined together is now enabled in our portal UI with a new Total option in the drop down Display and Sort By list in the Advanced Options section of the Query pane (Data Explorer sidebar). Without using Total, the returned value would represent all devices but only in the time-slice with the greatest number of unique instances of the counted metric. Using Total, you’ll instead get the total number of “uniques” across all devices for the entire width of the query, which is a much more realistic method for counting uniques across devices and time.
While the new Total capability is particularly interesting for unique counts, it will also come in handy to compute things like total bytes, packets, flows, and retransmits that could previously be displayed and sorted by Max, Avg, or p95th for one time-slice. For non-timeseries display types you can now specify total over the entire time-range.
With the addition of this latest metric you can now look at variations in the number of unique source and destination ports over multiple devices. This should be particularly useful for the purpose of security assessment, where seeing a significant change in the number of source/destination ports could be a warning sign of scans or attacks.
We continue to expand the range of options available for you to receive notifications from our anomaly detection and alerting system.
PagerDuty is the latest add to the list of our alert notification integrations. With this integration, Kentik alerts can now create incidents within PagerDuty. PagerDuty is a widely adopted and nicely straightforward Incident Resolution Platform as a service (it’s the one we actually use at Kentik). If you haven’t tried it before, check it out.
Each of your PagerDuty services can be configured in the Kentik Detect portal as a separate notification channel and assigned to one or more alert policies, which allows you to map notifications for various kinds of conditions to the relevant network team. For example, you can have capacity-related alerts trigger a PagerDuty incident on a service that’s handled by your network provisioning team, while security incidents can trigger notifications to a different service that’s owned by your network security team. Check out our knowledge base entry on PagerDuty integration for step-by-step configuration details.
Speaking of our KB, the entries on alert notification channels have been updated with additional information to make it easier to set up channels that integrate with external systems and to assign channels to alerts. The Alert Notifications section should be your first destination for guidance on configuring notification channels. As a reminder, you can currently integrate Kentik Detect alert notifications with Syslog, JSON Webhooks, Slack notifications and, now, PagerDuty. As always, email notifications are available as well.