Often, in the information security community, we bandy about terms like “defence in depth” or “layered defences.”  Most of the time, it’s just a platitude for “buy more stuff.” It’s worth exploring the way these terms evolved, and how we should think about defensive architectures in the world defined not by physical space, but by network connectivity.

Today, we announced our $10M Series A funding led by ForgePoint Capital and Comcast Ventures. Read the press release here. 

Three years ago a conversation - over coffee and in the company of my co-founders – changed the trajectory of my entrepreneurial journey. We were discussing how fragmentation is a major problem in the cyber security industry. What do I mean by fragmentation?  Just take a look at the exhibit floor at RSA Conference and observe the ever-growing sea of vendors offering point solutions, each with their own agent collecting relevant data and covering only a portion of what is needed to achieve good cyber hygiene. The vast majority of these solutions are closed and proprietary, and only extensible by convincing the solution vendor to add some new features to its product roadmap, which could take many months or even years. Within a category, each vendor claims theirs is the best.  But based on what, the security credentials of the founders and technical leadership team?  You can’t look inside the products to see what is going on. It’s more of a “trust me, I know what I’m doing.”  Adding to the problem is that each solution comes with its own UI and threat intelligence, and doesn’t easily share data with other solutions, except through a third solution, typically a SIEM.

It is not often that one runs into situations that so purely fit a classic stereotype. Securing and monitoring Docker containers happens to be one of those conundrums that is a textbook example of a “damned if you do and damned if you don’t” setup. On the surface, securing and monitoring containers seems like a straightforward affair – treat containers like mini virtual machines, and run your security/monitoring agents in each container; or, treat them like processes running on the host OS, and run your security/monitoring agents on the host OS. Sounds simple enough. However, both options run into some surprisingly natty difficulties. 

AHHHH! GDPR day is upon us!

If you've used a service or signed up for anything ever in your life then you've surely noticed the onslaught of "Terms of Privacy Update" emails over the last couple of days. That could only mean one thing: GDPR implementation day has finally arrived! But for all the unavoidable noise around GDPR, we couldn't help but notice a lack in any advice or documentation about osquery and its link to Personally Identifiable Information (PII) -- a focal area in the GDPR regulation (here's a "handy" 100 page reference guide on GDPR). So, let's get right to it then.

This may sound like common sense to developers, but securing the assets in your cloud requires you to recognize just how different a cloud workload is from a user asset. While the high level strategy is nothing new, legacy solutions cannot simply be repurposed in your cloud due to some very straightforward barriers to each fundamental goal.

Late last week, Chris Sanders (@chrissanders88), a former FireEye colleague, posted an interesting "lunchtime poll":

I’ve written before about how I feel open-source technology will prove disruptive in the security industry. Having recently returned from a week in San Francisco for B-Sides SF & RSA, which is known as the annual pilgrimage for "Infosec Sales," I feel that way now more than ever. The growth in adoption of open-source technologies may indicate that people are starting to get more comfortable with the concept or ability of their still being enough room for innovation that companies can charge for what they develop on top of “free” open-source projects. Coming back from the premier sales conference for the information security industry is a great showcase for why I’ve come away with that thought. Let's explore...

There’s a dangerous myth among some Mac users that, unlike Windows, the platform is impervious to malware. Since nothing is bulletproof, it would be dangerous to assume Mac fleet security, so let’s recognize why Macs have historically been low risk and why that looks to be changing.

SQL (Standard Query Language) will be in its mid-forties later this month having been introduced by its creators Donald Chamberlin and Raymond Boyce in the 1970s. Given its age, it isn’t so hard to understand how the 2017 Stack Overflow Developers Survey uncovered that SQL is the second-most common programming language, used by 50% of developers and beaten only by JavaScript.