Thinkst Blog

In our previous post ( Are Canaries Secure? ) we showed (some of) the steps we’ve taken to harden Canary and limit the blast radius from a potential Canary compromise. Colloquially, that post aimed to answer the question: “are Canaries Secure?” This post aims at another question that pops up periodically: “If I run your Canaries on my network, can you use them to hack me?” This answer is a little more complicated than the first, as there is some nuance. (Because my brutally honest answer is: “yeah… probably”.) But this isn’t because Canary gives us special access, it’s true because most of your other vendors can too.If you run software  with an auto update facility (and face it, it’s the gold standard for updates these days), then the main thing stopping that vendor from using that software to gain a foothold on your network is a combination of that vendor's imagination, ethics, or discomfort with the size of jail cells. It may not be a comfortable fact, but fact remains true with ...

What a question. In an industry frequently criticised for confusing security software with secure software , and where security software is ranked poorly against other software segments , it's no surprise we periodically hear this question when talking to potential customers. We figured we'd write a quick blog post with our thoughts on it. We absolutely love the thought of this question coming up. Far too many people have been far too trusting of security products, which is how we end up with products so insecure that FX said you'd be " better off defending your networks with Microsoft Word ". In fact, it's one of the things we actively pushed for in our 2019 talk on " the Products we Deserve ": ( The Products we deserve ) So, how do we think about security when building Canary? Most of our founding team have a long history in offense and we've worked really hard to avoid building the devices we've taken advantage of for years. From base arc...

Last week team Thinkst downed tools again for our bi-annual HackWeek. The rules of HackWeek are straightforward: Make Stuff; Learn; Have fun. We discussed HackWeek briefly last year : Our HackWeek parameters are simple: We down tools on all but the most essential work (primarily anything customer-facing) and instead scope and build something. The project absolutely does not have to be work-related, and people can work individually or in teams. The key deadline is a 10-minute demo on the Friday afternoon. The demos are in front of the rest of the team, and results count more than intentions. We pride ourselves on being a "learning organization" and HackWeek is one of the things that help make that happen. It's always awesome seeing a software-developer solder their first board or seeing someone non-technical write their first lines of python. Project highlights this year:  Az used the SimH simulator  to run an obscure Soviet Mainframe (the BESM-6 ): Eventually, he had the ...

Canaries and Canarytokens are tripwires that can alert you to intrusions. When alerts trigger, we want to make sure you get them where you need them. While our Slack integration is cool , you might prefer to send alerts through your SIEM. Or to a security automation tool. Maybe you want to leverage our API to integrate Canary alerts into a custom SOC tool. Want to turn a smart light bulb red and play the Imperial March ? You could do that too. Your way or the highway We often puzzle at products that require customers to totally revamp how they do things. We never presume to be the most important tool in your toolbox, which is why our product is designed to be installed, configured, and (somewhat) forgotten, in minutes. We’d rather disappear into your existing workflow, only becoming visible again when you need us most. Our customers dictate where and how they see our alerts. To enable this, we provide a wide variety of flexible options for sending and consuming alerts. By default, you’...

‪If you force people to jump through hoops to handle alerts, they’ll soon stop doing it 🤯‬ ‪Canary optimizes for fewer alerts but we also ensure that you can handle alerts easily without us.‬ ‪So it takes just 4 minutes to setup a Canary but far less to pull our alerts into Slack‬. By default, your console will send you alerts via email or SMS, but there are a few other tricks up its sleeve. It is trivial to also get alerts via webhooks, syslog or our API. This post will show you how to get alerts into your Slack. The process is similar for Microsoft Teams and other messaging apps that use webhooks for integration. It’s quick, painless and super useful. ( This post is unfortunately now also bound to be anti-climactic - it’s going to take you longer to read this than to do the integration ). Did you know how easy this can be? The Canary Console can integrate with Microsoft Teams and Slack in seconds and with a few more steps, can integrate with any other webhook-friendly platform. The ...

...what if someone finds out? Do attackers care if there are canaries in my network? People wonder if they need to hide the defensive tech used on their networks. Like all interesting dilemmas, the answer is nuanced. In defense of obscurity In any discussion about obscurity you will almost certainly have someone shout about “security through obscurity” being bad. As a security strategy, obscurity is a terrible plan. As an opportunity to slow down or confuse attackers, it’s an easy win. Every bit of information an attacker has to gather during a campaign gains the defender time. This is very much a race against time. No breach happens the moment a shell is popped or SQL injection is discovered. Attackers are flying blind and must explore the environments they’ve broken into to find their target. Defenders can seize the opportunity to stop an incident before it becomes a breach. It is often true that attackers typically operate with a fuller view of the chessboard than defenders. However...

We've got hundreds of servers and thousands of Canaries deployed in the world. Keeping them healthy is a large part of what we do, and why customers sign up for Canary. Monitoring plays a big role in supporting our flocks and keeping the infrastructure humming along. A pretty common sight in operations are dashboards covered with graphs, charts, widgets, and gizmos, all designed to give you insight into the status of your systems. We are generally against doing things “just because everyone does it” and have avoided plastering the office with “pew-pew maps” or vanity graphs. (although the odd bird-migration graph does slip through) As with most ops related checks, many of ours are rooted in previous issues we've encountered. We rely heavily on DNS for comms between our bird and consoles, and interruptions in DNS are something we want to know about early. Likewise, we want to ensure each customer console (plus other web properties) are accessible. There are tools available for ...