Your company’s culture should have an impact on the way that you configure Kolide. When thinking through your configuration, there are a few aspects to consider:

The Kolide admin portal is very powerful. All admins (except those with billing-only permissions) can access all available data about your fleet. There are three options for admin permissions:

Because admin access is so powerful, we recommend only adding members of the team who need full data visibility as Kolide admins. If you’re a team who has members that need reduced access, you might consider Kolide’s API (https://kolidek2.readme.io/docs) if access is needed real-time, or the Log Pipeline (https://k2.kolide.com/x/log_pipeline/overview) if data is needed in aggregate through a warehousing tool.

To add your teammates as admins, start here by configuring your SAML provider: https://k2.kolide.com/x/settings/admin/sso/saml/edit

Kolide collects data and reports those findings through the Inventory which can be found on your Devices tab. A full list and explanation of data that is collected by default can be found here: https://www.kolide.com/features/device-inventory/properties. However, you can disable the collection of certain device properties.

Disabling the collection of a property halts the collection at the agent level, so this data is never transported to the Kolide server. Privacy and transparency of data is of the utmost importance to us, and we have written about it extensively. We won’t rehash everything here, but you can learn more by following the links below.

Managing Device Data Collection: http://help.kolide.com/en/articles/4979374-managing-device-data-collection

Private Devices: http://help.kolide.com/en/articles/3403308-device-privacy-modes

The Privacy Center: http://help.kolide.com/en/articles/3204333-privacy-center-faq

Checks are the lifeblood of Kolide as they are what control the notifications that users receive from Kolide. It is Kolide’s Checks that will help you reach your compliance goals by pointing users to any open Issues on their device and how to solve them. You can read more about Checks here: https://www.kolide.com/features/checks.

A Check can have one of three possible statuses:

Once you have enabled one or more Checks, you’ll want to decide on the notification strategy to use.

Active Checks hold one of three notification strategies:

The notification strategy can be updated at any time. Each Check runs on a pre-configured schedule that has been strategically dispersed so as to reduce the amount of computational power required to run Kolide and helps to keep our agent “light”. If you’re curious about a Check’s schedule, you can find this information in the Privacy Center.

Notifications for Issues will not be sent immediately, even if “Notify end user” is the selected strategy. Kolide will only send notifications in the afternoon of the user’s timezone and there is a minimum grace period of 24 hours. This is intended to allow users who might have a reason for making the change a designated window of time before the change needs to be reverted.

Part of the Kolide magic is the ability to meet people where they’re at – this extends to the admins helping colleagues resolve Issues as needed. If you’d like someone to brainstorm with, then please reach out to Support and get in contact with our Customer Success team. We would love to hear more about your team, goals, company culture, and recommend some configuration options that we’ve seen work well for similar teams.

To configure notification behavior, first open your Kolide portal and navigate to Settings > Slack App > Escalation Behavior. The configuration options available on this screen impact: Channel-Directed Check Notifications, Automatic Escalations, and Help Requests.

Channel-Directed Check Notifications allows you to dictate a Slack Channel where you can direct specific Checks to notify a channel instead of sending notifications to an end user. The best way Checks for this notification strategy are those that end users are unable to take action on, but include helpful information for the admin team. A good example of this is the macOS Battery Health Check. For this setting we recommend configuring a separate, private Slack channel with the IT team and/or Security team invited.

Automatic Escalation Notifications occur when an end user has not taken action on fix instructions within the expected timeline. These notifications can include sensitive information, so we recommend taking your team’s culture into consideration when deciding where notifications should be directed. Some aspects of team culture to consider include:

Who is responsible for reaching out to the user if they didn’t take action?

How busy do you expect this channel to be?

Who needs access to this information?

This channel should include whichever combination of people will be most effective in helping users resolve issues. A few common groups that are added to this channel may include: the IT Team at large or in part, members of the Security Team, the Managerial Team or subsets as needed, and even whole-company visibility.

Help Request Notifications are driven by the end user. When Kolide sends a message with fix instructions, a button is presented to the user to “Contact an Admin for Help” so that users can get help resolving Issues when needed. Often teams combine this type of escalation to the same channel that receives Automatic Escalation Notifications. Other teams prefer to set these requests to a third channel, or even to use our webhooks to send requests for help directly to the Help Desk ticketing system.

This button can be disabled by not including a channel in this Escalation Behavior option. Without a designated channel, this button will not be presented to your users. Teams tend to prefer this option when they have a designated Help Desk team who maintain specific processes or expectations around how to escalate requests.

Two additional escalation settings are located back on the Checks tab as they can change the way that escalation behavior occurs on a per-Check basis. On each Check’s configuration page, you can update the amount of attempts before an open Issue is escalated to the admins (default is three attempts at user self-remediation) and the amount of grace period before a notification is sent (required minimum is 24 hours, plus it must be afternoon).

Now that your settings are configured in a way that works for you, the next step is to start executing your plan and roll out Kolide.

Step One: Planning Your Initiative http://help.kolide.com/en/articles/6672609-getting-started-guide-planning-your-initiative

Step Two: Configuring Kolide http://help.kolide.com/en/articles/6672642-getting-started-guide-configuring-kolide

Step Three: Rolling Out Kolide http://help.kolide.com/en/articles/6672665-getting-started-guide-rolling-out-kolide

Bonus: Admin FAQ http://help.kolide.com/en/articles/2981407-kolide-faq