Endpoint security in a remote SaaS DevOps team with CrowdStrike and Kolide.

Skyscrapers is a small but growing company and the team works 100% remote from different countries. Today, we manage about 43 developer platforms (based on AWS, Azure and Kubernetes) for more than 20 SaaS companies, and more are coming.

What we do forms the digital foundation of our customers’ businesses. Those platforms hold troves of business and personal data. Our customers need to be able trust us as we build, deploy and manage those platforms. We don’t take that responsibility lightly.

General awareness on risks, regulatory pressure and general industry professionalisation are also making our customers more conscious. This year we saw quite some of our SaaS customers, even the smaller ones, get ISO/IEC 27001 certified. They rely on us to help them with that.

Security has always been top of mind at Skyscrapers. At the end of 2021 we formed a new circle “Keep Everyone Secure” to have a more structured and continuous approach to improving information security at Skyscrapers.

Why

As a DevOps team, our laptops are the primary tool to get the job done. It is the entry into our and our customers’ systems. That makes them a primary attack vector, both for random and targeted attacks. Our team is quite technical and self-aware about security, but it is not enough. There was no decent baseline of what we considered a “secure default”, no active checking for gaps in configurations and no form of active detection of any threats that may have occurred.

How could we sleep? A big step forward on this front was long overdue. Increasing security on the endpoints was urgently needed.

Challenges

We had some very specific challenges and needs:

1. A very technical team with personalised habits and a principled mind about how to solve this challenge.
2. We really wanted to respect people’s privacy and freedoms as much as possible.
3. As a self-managing team a transparent and equivalent approach was important to us.
4. Our diverse cultural team surfaced different sensitivities, needs and views on what ‘privacy’ really means.
5. The security tools landscape is complex and overwhelming.
6. We have a mix of employees with Skyscrapers-owned machines and contractors with their own machines.
7. Diverse landscape of operating systems: Linux, Windows and macOS

How we tackled it

Engaged with the team. While technically the Keep Everyone Secure team could decide whatever it wanted, we really made sure to engage with the whole team throughout the whole journey. In multiple meetings we explained our intentions, shared our insights, showed progress and collected feedback. While these meetings were not the easiest, they really helped us understand the sensitivities, created alignment and provided valuable technical insights to further shape our final offering. These conversations were supported by a central, continuously evolving shared Google Doc.

Didn’t do it alone, got help. Navigating the security tooling landscape by yourself is intimidating. We teamed up with Niels from IronPeak. From his rich experience around security, he supported us with knowledge and insights that we could use to shape our journey. He pointed us towards the right software tools to use. And he is still with us: today he is actively supporting and monitoring our endpoints. Something we couldn’t or wouldn’t want to do by ourselves.

Improved in other areas as well. Having a computer policy and installing the software was enough to cover our initial needs. While trying to work out how to fit this into the existing security policy, we quickly figured out that our security policy needed an overhaul as well. We completely restructured, updated and improved it as a result. While that cost us a bit more time and energy, the whole endpoint implementation is way more anchored into our overall information security practices. In addition we have a more solid foundation to further evolve our policies on.

The final solution

Software

The software part is composed of 2 tools:

Kolide as security policy compliance checker that checks if endpoints are configured correctly and follow our security policy. Their approach to personal privacy and open-source foundation really charmed us. We source and support Kolide ourselves.

CrowdStrike Falcon is a combination of a local client and SaaS dashboard. It intelligently monitors applications and can detect malicious activity relying on global telemetry intelligence. CrowdStrike is a market leader. We were also pleasantly surprised in how light-weight the client was. IRON Security handles all support and event handling so we don’t have to.

Policy and process

Software doesn’t solve anything by itself, so we also have the following.

A solid security policy that, besides other things, covers the above through a computer policy. When we rewrote the document, we based ourselves on the domains of the Secure Controls Framework. This mature structure will help us shape the policy further and is understood by others as well.

An internal Slack channel #endpoint_security_support and internal support documentation for helping colleagues with their questions, installation and any security events on their machines.

And finally, the Keep Everyone Secure circle performs a biweekly review of all dashboards of Kolide and Crowdstrike. We review past incidents to see if we need to follow-up anything, adjust the policies or adjust our configurations.

Privacy

With both Kolide and Crowdstrike sending metadata to the cloud there were definitely privacy concerns. To mitigate this, we did take some additional steps:

1. We did a deep dive in the suppliers’ privacy policies (Kolide and Crowdstrike), what information was uploaded and what they did with it. After vetting it (it was ok for us) we also detailed it in the support documentation.
2. We opted for using Kolide’s privacy mode so our team can’t see any technical information of any of the machines. We only see high-level data like machine name, serial number and OS. In addition we can of course see alerts.
3. We disabled CrowdStrike’s remote login. This makes quick reaction a bit more difficult, but we felt the personal safety was more important.

As long as the security policy is respected, people are allowed to use their work laptops for personal things. However not everybody wanted the tools to be installed in these ‘mixed’ environments. For Skyscrapers machines the roll-out was quite straightforward. But for our contractors there was more resistance. This was solved by any of the following solutions:

1. Direct install, no separation: similar to Skyscrapers-owned machines
2. Dual-boot, with each partition being encrypted to ensure isolation
3. Make available a dedicated machine for Skyscrapers work

We did consider offering our own machines. But the logistics of sending laptops internationally and some personal concerns (having to lug around two laptops when travelling) put that idea on hold for now.

Conclusions and what’s next

We are happy with the results. The project took longer than we expected. Engaging with the team definitely made it more complicated, but was also key in making this a success.

This project increased our security posture by a couple of notches in one go. It also forms a solid foundation to build further on. And that is needed, because improving security is an ongoing process. And we sleep better now.

What’s next? In the short term we’re looking at improving our general authentication and access setup. Things like zero trust, needs based privilege escalation, role-dependent access, 4 eyes principle, increased audit, etc are on the list.

In the long term there is even more coming up, mainly fed by our risk inventory. Eventually we hope to have reached the milestone of having a fully mature and ISO 27001-certified Information Security Management System (ISMS).