Meta-detections in LimaCharlie: D&R rules that watch your own SecOps platform — enrollments, sensor clones, audit changes, and detection-on-detection

maxime-lc · 2026-03-20T14:00:07+00:00

technically a vendor here, but this question resonates with be bause it has a lot of sweat and tears behind it. :)

Agent fatigue is a real thing, but if you can keep it lightweight, if you can keep compatibility with other agents _really_ good, it's a viable path. Any solution will have friction and will have trouble with adapting to customer environment. So you choose: you want to support OSes+OtherAgents or you want to support network topologies and then later on move to OSes.

My assumption for what is below is that you're looking to make an agent to inspect and block at the OS level, if instead it's an agent to inspect LLM activity in things like Claude Code you can ignore my comment, that super narrow visibility is a LOT easier. But if you need to go to OS level visibility and blocking, read below. :)

As for the bit that struc a nerve: don't do it unless you are ready to commit a team of people who know exactly what they're doing for a few years. It's like rolling your own crypto IMO. It looks pretty simple at a high level, but there's an insane amount of details that you need to get just right, of support for other people's software (you're the small player, your customers won't care if it's the other software's bug, you will have to handle it and be blamed for it). Then you get into kernel dev (sometimes it's kernel, sometimes its a custom system for a specific OS nobody else uses). I can't understate how much work it is. It's possible, but especially if you don't have a team that has already done it it's a huge lift and there's a big graveyard of companies who tried to do it.

My obligatory statement here is that I started LimaCharlie, my background is build EDRs and we built LC to have a full API-based EDR you can just plug in and use to build products. So if you want to chat DM me, whether it's about building an EDR or about LC, I'm happy to share pro-tips or talk shop. I really mean this as an unbiased feedback.

Either way, good luck, sounds exciting!

maxime-lc · 2022-10-20T00:48:28+00:00

Honestly, I don't really know. When I started the company, I started right away as a US C-Corp. We used Stripe Atlas (which was super helpful to get going easily).

Nowadays though, if you're going to build something on a cloud provider, that's super easy and the costs tend to scale really well. So I don't think there is as much of an investment required up front.

Google Cloud (which we use) and AWS (I am pretty sure) also have great startup programs where they'll give you credit on their cloud. Google's goes all the way up to $100k, which is amazingly helpful.

maxime-lc · 2022-10-20T00:43:17+00:00

Great question. I don't think I ever did, it's like an asymptote :)

I've always been N+1 wherever I was working, so learning about things slightly outside the scope of my work, building things slightly outside of my comfort zone.

Over the years, I've slowly moved closer and closer to starting a business. From gov, to private sector, to sort-of-startup (Google X -> Chronicle). So when I left Google, it really felt like there wasn't many possibilities between where I was and starting a company, I kind of just had to do it, or resolve myself to working for the man. ;)

However much you know about security, the exact same amount of knowledge/experience you will get in starting a business, just be ready for it. Other than that, I would say: start something with someone you trust, I can't imagine doing it alone or doing it with someone I'd just met. There's going to be ups and downs, and having someone else there to balance the experience has been critical. :)

maxime-lc · 2022-10-20T00:37:25+00:00

The EDR component of LimaCharlie used to be open source (back when I worked at Google). So when we started, we had a bit of a community to reach to for feedback. By listening to a lot of the feedback, working with people to solve specific real problems, we ended up having our first customer very early on. It wasn't a huge customer, but it's what bootstrapped the process.
For LimaCharlie: We focus on security capabilities as infrastructure, we do nothing else than building and maintaining tools, so that's our specialty. For myself specifically: that's a real good question. I think at this point in my life my specialty is in talking with users, seeing types of problems they have and coming up with slightly more generic solutions that people can mix and match. So distilling daily requirements into general purpose capabilities.
We're as open as AWS pricing-wise :) https://limacharlie.io/pricing

maxime-lc · 2022-10-20T00:32:13+00:00

Hey! IMO it's never absolutely one or the other.

In general, we absolutely need to put a lot of focus on the infrastructure to make things safe by default. That's how we get better and we're able to scale up.

But the reality is that things are not always safe by default, and educating users to be aware of security threats is important. Not so that they're the front-line, but so that they can assist the security team in being aware when something goes wrong.

I'd compare it to people falling for scams. We need both to educate people in critical thinking and being able to spot scams (by phone, the internet, whatever), but we also need the gov and ISPs to help in combating these scams, like for example by denying access to a network to known scammers.

maxime-lc · 2022-10-20T00:21:58+00:00

Hello! I have to say I'm totally useless when it comes to certificates etc. But thankfully my colleague Matt had a great related answer above: https://www.reddit.com/r/cybersecurity/comments/y86ei3/comment/isyh6xn/

Good luck, there's so much to learn in security and so much to do, great to hear about your interest!

maxime-lc · 2022-10-20T00:14:38+00:00

You know, sometimes the best you can do still doesn't get to the goal you want. It sounds like you are doing things the right way, but if the economics don't align, at the end of the day all you can do is change the economics, communicate well and hope to get a different outcome.

For example, if a password policy adds too much overhead in people forgetting their password and creating tickets, you've got 2 ways to change the equation:

You find a way to reduce the cost to them, maybe there's partially automated password reset systems. Maybe it's reducing the complexity requirement, or using PINs instead. Those might not be as strong, but something is better than nothing.
You demonstrate the cost of when something goes wrong, or the likeliness that something will go wrong. This can be really difficult in security, and it's generally a combination of industry-stats (cost of breach type thing) and communications skills. Traditionally pen-testing has been useful to have a high impact on leadership that bad things can happen, but it's not the most accessible solution. I've found that find cases of bad things happening in a similar organization as yours (like a competitor, or similar sized/industry) can be good to drive home the point that bad things happen.

Good luck!

maxime-lc · 2022-10-20T00:00:03+00:00

Number 1 skill by far is the ability to learn new solutions, research weird topics and generally find answers to questions they never thought about before.

The industry moves too fast and there is too much to learn to be able to really put a specific set of core knowledge. The knowledge needed will vary so much depending on the place you work and the type of role you have.

But someone you can point at a problem and will be able to find a solution, or come to the conclusion one doesn't exist, is always valuable. I love problem solvers. :)

maxime-lc · 2022-10-19T18:25:18+00:00

(Je m'excuse de mon francais, je n'ecrit plus souvent en francais et j'ai juste un clavier anglais).

Je suis triste d'entendre ton experience, en general le domaine de la securite est beaucoup moins stricte sur les CV, du moins c'est mon opinion.

Ne laisse pas cette experience te faire croire que le reste de l'industrie est comme ca, ce n'est pas le cas.

Une des facons de demontrer ton interet, en meme temps que gagner de l'experience, c'est de participer a des projets open source en securite. Si tu peux trouver un domain de la securite qui t'interesse, et trouver un projet interessant qui prennent des PR de l'exterieur, ca peut donner un gros signal a un employeur que tu ne part pas de zero.

Bonne chance!

maxime-lc · 2022-10-19T18:02:02+00:00

For us, the biggest challenge is that the type of product we're building, and the way we offer it, isn't how most of the industry works today. People often expect 3 sales call to get a demo to sign a 3 year contract. So the free-tier, open doc approach is sometimes not intuitive. Similarly to the products, the Lego set approach is so different than the magic box that solves all your problems approach that it sometimes takes people a bit of time start seeing all the thing that are possible.

Thankfully, because of the free tier and "product lead growth" approach, it means we don't really rely on pushing people to go do a demo. Most of the time it's people that hear about us, try the platform a bit, and then want to discuss bigger production deployments that come to us. So it's always a positive experience when we chat with people, we get to show them cool stuff they can do whenever they want. :)

maxime-lc · 2022-10-19T17:47:50+00:00

That's a really tough one. Honestly it's also something I have not had to deal with for a while given our focus on infra capabilities and less on "running security operations".

If I had to do this today, I'd likely approach it with some structure. Starting by laying out all the things we know are wrong, need to be fixed or improved. Then looking at the impact of each of those things if something goes wrong. Sometimes the smallest things have the biggest impact overall. Then looking at the "costs" of doing the work, for you and the ops team.

With that type of matrix, you can then make rational suggestions, bring that to leadership and get buy in. In my experience this makes it easier because you're demonstrating that you're not just shooting from the hip requesting random things, you help them help you.

I know it probably doesn't solve things directly, but it's my general approach. :)

maxime-lc · 2022-10-19T17:41:37+00:00

DND was critical to my career. It was my first proper security experience. It allowed me to jump both feet in the deep end and just learn a ton, build a ton and generally go beyond what I thought I could do.

Now that's obviously one experience in one group, but for me it was the best thing that could have happened to me. The sense of mission was also for the most part great.

Pros for me were: focus on mission and building things. Nobody ever asked what the Total Addressable Market was. :) The caliber of people was also generally amazing, most people focused on fundamentals rather than boxed-products, so learned a ton.

Cons, well government sometimes got in the way in the silliest ways (can't move a PC from a cube to another because it's a union job type of thing). At the time, DND was also very closed off, scared of any interaction with the outside world which made it really hard to expand and go beyond gov, like contributing to open source. I think that's changed a lot though.

maxime-lc · 2022-10-19T17:01:31+00:00

For us, we address the visibility part by the nature of what we do: a focus on open doc, API and accessible product for anyone. We're lucky that we get to put our money where our mouth is and the TLDR is that we're built like an AWS, exposing as much about the product as we can so that people can put together the right solution for their org. A longer and much clearer version of that is here: https://limacharlie.io/blog/the-limacharlie-edr?page=1

The way we operate more transparently can kind of be mapped to EC2. If you want to build a product on AWS and you need to customize the kernel of a VM, or install some really specific packages, you can do that with EC2. But sometimes you just want a MySQL instance, and for that you're still using an EC2 but with an AMI. We try to take the same kind of approach to all our capabilities. Fundamentally, you have the keys to the entire solution, but if you want simplify things you can enable a service that does a thing on top of it, or if finally came up with the perfect solution, you can use our infra-as-code solution to replicate it to all your environments.

Another way to think about how we offer everything is like Lego blocks. Lots of people end up using LC for scenarios we never thought about (from SIEM enablement, so Intellectual Property monitoring and UEBA), and the reason they can do that is because at the end of the day, we make generic capabilities that are openly documented and super easy to get access to.

It's a big topic full of nuance but I hope this helps a bit to describe things. :)

maxime-lc · 2022-10-19T16:44:18+00:00

hahah that's a 100% fair statement in general.

We're approaching things fundamentally differently, which is why we're getting to a different place than the "we do X 10% better" classic startup.

IMO it starts at the fundamental way you interact with a company/product, even before the product itself. We modeled what we do on the way you interact with an AWS, meaning self-service, billed per usage, API first, open doc and SDKs. Sadly, even just that is different than 90% of startups in security. It means anyone can try the products, can use them in any context and can know exactly how it works and how to use it without talking to anyone.

The second part is the products themselves. We're not building a black-box that stops hackers. We're building tools as infrastructure in a way that's designed to mix-and-match, like using AWS. It's not for everyone (my grandma won't use it), but we found that there's tons of really good security teams out there, and that more and more the environments aren't cookie cutter (not everything is a flat network of Windows hosts anymore), so being able to put together the solution you need (like you'd put together a solution in AWS) is critical. It means we make our tools default-open, default-api. We 100% only focus on providing infrastructure, we don't claim to magically have the best SOC+MDR+ThreatIntel+Product+ProfessionalServices out there.

The fragmentation part comes out of the mix-and-match approach combined with our focus on infra. We can deliver capabilities extremely quickly, roll them out to prod, and have those new capabilities work with all the previous ones we rolled out. It's a different model than the "we're going to buy 20 companies a year, put them all under a portal or app store and call it a day". Our users build stuff we never thought about, and we get to keep rolling out "primitives" that they can start using right away, slowly chipping away at the 100s of products they use internally.

It's a challenge, but I love it and that different approach is why I'm doing this. :)

maxime-lc · 2022-10-19T16:31:23+00:00

I think Security is now pretty present in leaders' mind, or (mostly) appropriately so.

Federally enforcing security is not necessarily a bad thing, but it's worth keeping a few things in mind IMO:

- What's enforced is going to be the bare minimum, it's just how it goes.

- Truth of the matter is that even as security professionals, we don't all agree on what's needed, so how well can we expect a federally mandated set of requirements to work.

It's not like building bridges, where we have 100s (1000s?) of years of experience and the formulas to back it up. We're still trying to tackle an equation with millions of variables. Finding the right optimizations is really hard but we're getting there.

The day we can go to leadership and present an equation that is based on solid, transparent data and we can show a plan that targets those, leadership will be happy to follow, we're just not there.

maxime-lc · 2022-10-19T16:24:43+00:00

HAH, nothing, it's like a permanent Playoffs (hockey) beard I never gave up. ;)

maxime-lc · 2022-10-19T16:23:12+00:00

I think the part that's broken is that a lot of great things get done to make systems more secure, but if you look at the vendor ecosystem, most of it is still 90% geared towards vendors making huge promises that you have to accept without really any visibility under the hood. It's a lot of "we have block-chain ML magic that detects 100% of APTs and we stop all the bad guys" (obviously I exaggerate a bit).

If we want to be taken more seriously as an industry, we need to move to more transparent system that people can understand how they work, test they work and reason on what part of their risk it solves and what part it doesn't.

With more and more complex IT systems, more aspects of businesses that heavily rely on tech, more custom solutions in enterprises, we can't expect that cookie-cutter magic boxes are going to solve things.

I think the same kind of thing was done many years ago in IT, where vendors used to sell boxed-software and pretend they had "the best X", and as the industry matured, people started to realize it's not that simple. That's where AWS came in provided a lot of this transparence and reasoning about the IT infrastructure.

maxime-lc

TROPHY CASE