Show HN: Tracecat – Open-source security alert automation / SOAR alternative(github.com)
github.com
Show HN: Tracecat – Open-source security alert automation / SOAR alternative
https://github.com/TracecatHQ/tracecat
70 comments
Please put a stake in the heart of Palo Alto's XSOAR SOAR. Wishing you much success.
Edit: Keep in mind, the folks who operate this are typically not engineers. They are security analysts and other non dev infosec/cybersec stakeholders. Refer to how Palo Alot XSOAR uses drag and drop playbooks [1] (somewhat like n8n's workflow builder [2], a Zapier competitor). I recommend building a library of default playbooks that customer SOCs and other detection response consumers of your product can adopt (based on customer product feedback and conversations), like you adapt your business to SAP vs customizing SAP to your business.
[1] https://xsoar.pan.dev/docs/playbooks/playbooks-overview
[2] https://docs.n8n.io/courses/level-one/chapter-4/
(head of infosec in finance, xsoar comes out of my spend)
Edit: Keep in mind, the folks who operate this are typically not engineers. They are security analysts and other non dev infosec/cybersec stakeholders. Refer to how Palo Alot XSOAR uses drag and drop playbooks [1] (somewhat like n8n's workflow builder [2], a Zapier competitor). I recommend building a library of default playbooks that customer SOCs and other detection response consumers of your product can adopt (based on customer product feedback and conversations), like you adapt your business to SAP vs customizing SAP to your business.
[1] https://xsoar.pan.dev/docs/playbooks/playbooks-overview
[2] https://docs.n8n.io/courses/level-one/chapter-4/
(head of infosec in finance, xsoar comes out of my spend)
Hear,hear! I can't express this sentiment enough. Default playbooks are great but integrations with every possible tool,appliance and platform is a must.
Save time and money. That's what we are here for.
Any thoughts on our analysis regarding case management and log storage? These are two technical decisions we made before writing a single line of code to bring down cost and increase value-for-money.
Any thoughts on our analysis regarding case management and log storage? These are two technical decisions we made before writing a single line of code to bring down cost and increase value-for-money.
Staying within the tool to manage cases is good vs shelling out to Jira or another ticketing tool. Folks with purchasing authority typically want their analysts in the tool as much as possible (in my experience; you may find customers who want to open incidents elsewhere so keep that interface in mind).
Also a good choice in storing logs. Make a margin but don't be greedy, otherwise you turn into Splunk, where folks don't want to use the product effectively because they can't afford to. Make it easy to route logs to S3 cold storage or other "reliable enough" object storage systems based on criteria, but retaining the capability to retrieve them if needed for forensics or compliance/audit sampling. Log storage intervals are traditionally some variation of 30, 60, 90 days, a year, seven years, etc. Architect accordingly based on your customers' record retention schedule(s), control/compliance requirements, etc.
Also a good choice in storing logs. Make a margin but don't be greedy, otherwise you turn into Splunk, where folks don't want to use the product effectively because they can't afford to. Make it easy to route logs to S3 cold storage or other "reliable enough" object storage systems based on criteria, but retaining the capability to retrieve them if needed for forensics or compliance/audit sampling. Log storage intervals are traditionally some variation of 30, 60, 90 days, a year, seven years, etc. Architect accordingly based on your customers' record retention schedule(s), control/compliance requirements, etc.
you may find customers who want to open incidents elsewhere so keep that interface in mind
My large financial (and many in our peer group that I've talked to) see "open incidents elsewhere" (WorkDay in our case) as minimum table stakes. YMMV.
My large financial (and many in our peer group that I've talked to) see "open incidents elsewhere" (WorkDay in our case) as minimum table stakes. YMMV.
This is helpful ground truth, thanks for sharing. I only see what I see, but asking everyone else what they see is free(ish).
I only see what I see
Well...that's a problem you need to think about. If all you see is how startups or SMB do this (or what people tell you on HN), you're going to be massively missing the mark when you talk to more large/enterprise customers. Things like "well of course Discord" will be met with "we use Teams", or even worse "yeah...we're still on Notes". I had one vendor recently who said "why would we ever need to integrate with Archer?"...well, we have a GRC requirement to attest to certain actions your tool is supporting, and our auditors look at Archer as a source-of-truth, and noone wants to manually update Archer with the output of your tool. Lightbulb moment.
Tl;dr - make integrations drop dead easy, because you never know what baroque workflow you're going to need to dovetail with the make the sale.
Well...that's a problem you need to think about. If all you see is how startups or SMB do this (or what people tell you on HN), you're going to be massively missing the mark when you talk to more large/enterprise customers. Things like "well of course Discord" will be met with "we use Teams", or even worse "yeah...we're still on Notes". I had one vendor recently who said "why would we ever need to integrate with Archer?"...well, we have a GRC requirement to attest to certain actions your tool is supporting, and our auditors look at Archer as a source-of-truth, and noone wants to manually update Archer with the output of your tool. Lightbulb moment.
Tl;dr - make integrations drop dead easy, because you never know what baroque workflow you're going to need to dovetail with the make the sale.
Glad to hear we are on the right track.
Tracecat is still in alpha, but would be great to have your thoughts / opinions / feedback in our Discord community. We are anon-friendly. There's still a lot more we can innovation on.
Tracecat is still in alpha, but would be great to have your thoughts / opinions / feedback in our Discord community. We are anon-friendly. There's still a lot more we can innovation on.
Kudos on the effort for sure. Your biggest challenge is having good integrations for literally everything. Second big challenge: companies that will use open source are a rarity.
I can't express how much stuff is my bread and butter. No one wants to write scripts, that's the whole point of a soar in the minds of people using this. Really, the support is most of the cost not the product itself. Just have splunk create an app or whatever integration. Then your playbooks have to be easy to manage which I am sure you can figure out.
But then you have to implement case management too, no one wants a separate case management tool. These days, even the SIEM is expected to be just another tab/feature in the soar.
I hope you don't expect security teams to self-host either. It's a major PITA.
I like opensource, but not having support first and foremost is a huge redflag for me since I have been burned badly by foss projects. If you have a fully managed and supported commercial version of the product, that's be great.
Edit: oh and the "ai" stuff only impresses management types, great if that's your audience but at least in my experience, you better be ready to answer questions around that and expect mild hostility because of how gimmicky it is (just my $0.2)
I can't express how much stuff is my bread and butter. No one wants to write scripts, that's the whole point of a soar in the minds of people using this. Really, the support is most of the cost not the product itself. Just have splunk create an app or whatever integration. Then your playbooks have to be easy to manage which I am sure you can figure out.
But then you have to implement case management too, no one wants a separate case management tool. These days, even the SIEM is expected to be just another tab/feature in the soar.
I hope you don't expect security teams to self-host either. It's a major PITA.
I like opensource, but not having support first and foremost is a huge redflag for me since I have been burned badly by foss projects. If you have a fully managed and supported commercial version of the product, that's be great.
Edit: oh and the "ai" stuff only impresses management types, great if that's your audience but at least in my experience, you better be ready to answer questions around that and expect mild hostility because of how gimmicky it is (just my $0.2)
Thanks for sharing. Agreed on having automation + Jira-like tracking in one place. We've implemented case management[1] and have a Cloud version[2]. We're still early but we ship fast.
We will have a full post on the AI part next week. A few unique ideas to look forward to -- open source LLMs for specialized tasks and multimodal evidence for cases (i.e. multimodal search across images, deepfakes etc.)
[1]: https://docs.tracecat.com/core/case-management [2]: https://platform.tracecat.com/
We will have a full post on the AI part next week. A few unique ideas to look forward to -- open source LLMs for specialized tasks and multimodal evidence for cases (i.e. multimodal search across images, deepfakes etc.)
[1]: https://docs.tracecat.com/core/case-management [2]: https://platform.tracecat.com/
Cool. Forget Jira though, think more "thehive" which is opensource (implemented it once myself). There may also be cortex responders you can copy+adapt.if you won't have good commercial support soon, your audience is people using thehive. IR case management has needs like evidence collection and reporting (mitre integration usually). Best of luck. Glad someone is doing this.
I don't know why so many people here are shitting on you guys. It is an impressive demo and launch and a wide-open market. I'm rooting for you, guys. There's an easy opening even just after the "inbox" for the security alert use case.
Maybe pointed at me - criticism comes from a sec startup selling a tool that, when deployed correctly, plugs into every upstream and downstream mission-critical data source, sees every security event worth responding too, and runs response… paired with zero upfront context on how the startup does security themselves (and upon further discussion, it’s not in their background, they have no hires, didn’t know 101 enterprise sec, and what is present is outsourced), what their roadmap is in this regard, why their tool is safe to use given those integrations, and the only info avail in this direction was a boilerplate security.md on GitHub.
All together, it tells me they know how to do great data eng, but not how to do their own blue team and didn’t consider this a critical topic to handle, but also want to sell to blue teams.
Security Saas with great tech are burning sec teams left and right these last 3 years, such that vendor risk questionnaires are changing to ask specifically about what I did in my thread.
All together, it tells me they know how to do great data eng, but not how to do their own blue team and didn’t consider this a critical topic to handle, but also want to sell to blue teams.
Security Saas with great tech are burning sec teams left and right these last 3 years, such that vendor risk questionnaires are changing to ask specifically about what I did in my thread.
D&R at startup scale = set up billing alerts for different resources. Get a good CSPM. Run Trufflehog every pre-commit.
Yes can run the whole thing through a set of AWS lambdas, pull basic sec platform alerts from your GSuite and so on, dump all them into slack webhooks, dump into slack sec channels, align any sec IR processes to you Ops IR processes which you’ll need anyway.
From there, be disciplined about password managers early, get on at least separate OS logins if still doing BYOD, link up 2FA via Google auth, and figure out your email infra and where the root email that matters for infra is. Enterprise sec up and running.
From there, be disciplined about password managers early, get on at least separate OS logins if still doing BYOD, link up 2FA via Google auth, and figure out your email infra and where the root email that matters for infra is. Enterprise sec up and running.
Dude. I do not trust Lambdas. I've seen way too many CTFs and Cloud privesc paths to know how one even slightly misconfigured Lambda can led to full admin access.
We have a more local solution to query our security logs.
We have a more local solution to query our security logs.
Thanks for the comment Ross. Folks seem to have strong opinions about integrating or separating workflows and ticketing ala alert inbox. We like integrations a lot, but of course there needs to be security specific innovations on top of "just" an inbox that will make us the no-brainer choice.
You’re not measuring against
Splunk, you should be measuring against Tines. And tines is def broader than fortune 10, they sell the heck out to startups, so I think you’ve got your market wrong. Expensive boogeyman Splunk is replaced by a lot of solid vendors now that aren’t $100k+.
This flow isn’t really accurate either “ A security engineer would use it to build alert automations that look like this…”
Also, you’re competing against the difficult rep of other open source sec tools, namely Elastisearch. It’s not used much for a reason.
**But my very very top of mind, and what you’ll get asked by any sec team worth its salt, is what is your own security program, team of 2 data engineers?
Literally, do you have anyone hired to do it? Who? Why should I ship you any of my data, let you tag it, and plug into my sec platforms, when I assume it’s basically nonexistent. Your environment becomes my env if I do, and we all know startup security posture bc we’ve worked on that side of the coin in the past. So don’t sell us nonsense around what audits you’ve passed. Open Source adds an interesting margin of safety here, but you’re a YC company with plans to make revenue, so the exposure is there somewhere.
SaaS vendors are a massive supply chain vector right into a company, happens all the time and is growing, and the teams trying to sell me security tools with a 0.0% security program themselves are humorously many.
This flow isn’t really accurate either “ A security engineer would use it to build alert automations that look like this…”
Also, you’re competing against the difficult rep of other open source sec tools, namely Elastisearch. It’s not used much for a reason.
**But my very very top of mind, and what you’ll get asked by any sec team worth its salt, is what is your own security program, team of 2 data engineers?
Literally, do you have anyone hired to do it? Who? Why should I ship you any of my data, let you tag it, and plug into my sec platforms, when I assume it’s basically nonexistent. Your environment becomes my env if I do, and we all know startup security posture bc we’ve worked on that side of the coin in the past. So don’t sell us nonsense around what audits you’ve passed. Open Source adds an interesting margin of safety here, but you’re a YC company with plans to make revenue, so the exposure is there somewhere.
SaaS vendors are a massive supply chain vector right into a company, happens all the time and is growing, and the teams trying to sell me security tools with a 0.0% security program themselves are humorously many.
Just to drive the point home as I parsed through the details and looks like yall know the tech side well.
Roadmap - you’re asking to plug into every mission critical sec tool. Nowhere on your roadmap is sec program details, who is doing it now, when will you get some from of pentest/audit (so so even then) or hire someone, or what yall know about security yourselves vs Facebook data eng.
Tech descriptions - nowhere in it are you describing how youve done your appsec, or more accurately who has done it. Why should I give you api keys to crowdstrike and defender in that light. And you’re offering a cloud version already, depsite hitting on 0 of this.
I think a big jump devs have trouble making when looking at security is this specific area. Sure, you’re saving me money and building slick tech. But Splunk isn’t going to get me hacked and roast my Saturday night. You (or more fairly vendors in the same profile as you) will. None of the data eng finesse and $50k in cost savings is worth that risk, or rather I price that risk at $50k haha. If the founders aren’t in the right headspace about their own security, I stay away - and you haven’t mentioned it once.
Obviously im a little crusty from SaaS vendors burning firms over and over this way. But that’s the candid feedback.
Deeper dive - The extent you discuss prodsec of your own sec tool is a token security.md file with nothing of value in it. If you are “practitioner obsessed” as mentioned in there too, then SaaS vendors owning the company and how/if/when id find out is a big part of what we obsess about. Look up the Jumpcloud hack for an example of this.
Roadmap - you’re asking to plug into every mission critical sec tool. Nowhere on your roadmap is sec program details, who is doing it now, when will you get some from of pentest/audit (so so even then) or hire someone, or what yall know about security yourselves vs Facebook data eng.
Tech descriptions - nowhere in it are you describing how youve done your appsec, or more accurately who has done it. Why should I give you api keys to crowdstrike and defender in that light. And you’re offering a cloud version already, depsite hitting on 0 of this.
I think a big jump devs have trouble making when looking at security is this specific area. Sure, you’re saving me money and building slick tech. But Splunk isn’t going to get me hacked and roast my Saturday night. You (or more fairly vendors in the same profile as you) will. None of the data eng finesse and $50k in cost savings is worth that risk, or rather I price that risk at $50k haha. If the founders aren’t in the right headspace about their own security, I stay away - and you haven’t mentioned it once.
Obviously im a little crusty from SaaS vendors burning firms over and over this way. But that’s the candid feedback.
Deeper dive - The extent you discuss prodsec of your own sec tool is a token security.md file with nothing of value in it. If you are “practitioner obsessed” as mentioned in there too, then SaaS vendors owning the company and how/if/when id find out is a big part of what we obsess about. Look up the Jumpcloud hack for an example of this.
We're going to work with these guys: https://www.oneleet.com/. They are awesome.
I see that and I see a bad security posture, and the responsibility passed up chain and even harder to answer the same questions about oneleet. Will they secure your gsuite email I assume you’re using? Will they respond to phishing attacks at you? Will they prevent SMS 2FA? Will they get you into SSO? Is a password manager in place? Are y’all using personal laptops still? Segregated logins? Will they tell you not to share publicly as a VC-backed startup about who is doing your infrasec and by a pretty clear implication what your infra likely looks like?
How to not turn you into me hacked is a balance of the prod/infrasec (like the company you linked), and bread and butter enterprise sec, which only comes from in house. So, in house team, or at least a 1x hire, such that there is at least a more than vague indicator that someone in house there day to day knows how to do security, or it doesn’t matter from a vendor risk point of views.
The list of vendors that have passed audits with complaint environments and gotten hacked is very long.
How to not turn you into me hacked is a balance of the prod/infrasec (like the company you linked), and bread and butter enterprise sec, which only comes from in house. So, in house team, or at least a 1x hire, such that there is at least a more than vague indicator that someone in house there day to day knows how to do security, or it doesn’t matter from a vendor risk point of views.
The list of vendors that have passed audits with complaint environments and gotten hacked is very long.
A way to handle this pragmatically is give board advisory shares to a person who straddles the following abilities (and listen to them), until you have enough funds to hire a sec eng:
- is technical enough to know what needs to get done and why
- has enough startup sec experience to know what pragmatic advice is in light of tight funding for startups
If you’re YC-backed this should be easy to source.
Why this thread matters and I’ll close it is dev-speak (“awesome, delightful, obsessed”) doesn’t matter at all for selling to a sec team, which is who is going to pay and vet this. That language just tells me it’s going to be a slog through VC sales-speak to answer the concerns I listed. It’s all about the above I mentioned, plus the tech setup which I think you have done with the right mindset (just plug into everything, parse it, ship it to the usual sources. Don’t try to reinvent Jira or Slack please).
The other reason you have to think about this is what market SOARs sell into. They aren’t needed until a lot of other due diligence is done - EDR deployments, enterprise sec, email sec, etc etc. So, that’s a decently established company, and if they’re paying for SOAR, it means they are either the lucky program with healthy budget support, or have a threat environment just justifying it all. A lot of places just get a bad MSSP and call it a day. So, if you are a company justifying SOAR (bc of implied budget and program maturity), you deal with threat actors who know their stuff well enough. And, as a fair number of exploits indicate this part 2-3 years, they know to evaluate SaaS vendors as the way in. Looking at the stack, they could try Okta, CrowdStike, MSFT, GSuite and all the difficulty there… or the two data engineers and their startup. Gotta take it seriously, a lot of sec is abstract risk but this is happening in the wild now.
- is technical enough to know what needs to get done and why
- has enough startup sec experience to know what pragmatic advice is in light of tight funding for startups
If you’re YC-backed this should be easy to source.
Why this thread matters and I’ll close it is dev-speak (“awesome, delightful, obsessed”) doesn’t matter at all for selling to a sec team, which is who is going to pay and vet this. That language just tells me it’s going to be a slog through VC sales-speak to answer the concerns I listed. It’s all about the above I mentioned, plus the tech setup which I think you have done with the right mindset (just plug into everything, parse it, ship it to the usual sources. Don’t try to reinvent Jira or Slack please).
The other reason you have to think about this is what market SOARs sell into. They aren’t needed until a lot of other due diligence is done - EDR deployments, enterprise sec, email sec, etc etc. So, that’s a decently established company, and if they’re paying for SOAR, it means they are either the lucky program with healthy budget support, or have a threat environment just justifying it all. A lot of places just get a bad MSSP and call it a day. So, if you are a company justifying SOAR (bc of implied budget and program maturity), you deal with threat actors who know their stuff well enough. And, as a fair number of exploits indicate this part 2-3 years, they know to evaluate SaaS vendors as the way in. Looking at the stack, they could try Okta, CrowdStike, MSFT, GSuite and all the difficulty there… or the two data engineers and their startup. Gotta take it seriously, a lot of sec is abstract risk but this is happening in the wild now.
Really appreciate the advice here. I also hate security theatre. We will make it triple clear that our Cloud version is JUST for preview, not production.
Repeat (as we mentioned in our README) for anybody reading this thread: Cloud is just for preview! Upload a known malware SHA-256 sample, send it off to VirusTotal, then pass the JSON response into a LLM action to summarize. There are plenty of workflows you can run to test our platform without exposing sensitive data.
Excited to work on securing our platform though. Thanks for the basic checklist. We have a lot more work to do and will find the best security professionals to work with. There are plenty of scary good practitioners, folks who have seen and responded to APTs in their previous work, within the YC network. The first thing we did when we got into YC was network with the YC security community.
Here are some shout outs who are helping YC companies and beyond truly improve their security posture: - Oneleet: 10 year+ experienced red teamers, now building an all-in-one pentest, vCISO, vSOC, and compliance platform and service - 0Pass: FIDO2 keys as service (ex-SpaceX, Amazon Cognito security engineers) - Infisical: open source secrets management
Repeat (as we mentioned in our README) for anybody reading this thread: Cloud is just for preview! Upload a known malware SHA-256 sample, send it off to VirusTotal, then pass the JSON response into a LLM action to summarize. There are plenty of workflows you can run to test our platform without exposing sensitive data.
Excited to work on securing our platform though. Thanks for the basic checklist. We have a lot more work to do and will find the best security professionals to work with. There are plenty of scary good practitioners, folks who have seen and responded to APTs in their previous work, within the YC network. The first thing we did when we got into YC was network with the YC security community.
Here are some shout outs who are helping YC companies and beyond truly improve their security posture: - Oneleet: 10 year+ experienced red teamers, now building an all-in-one pentest, vCISO, vSOC, and compliance platform and service - 0Pass: FIDO2 keys as service (ex-SpaceX, Amazon Cognito security engineers) - Infisical: open source secrets management
Same sort of questions - if the whole YC suite is secured by other YC security startups, that’s raises the same questions about where does the risk recursion stop - is anyone using yubikeys, vetted secrets management platforms, plainjane google auth, is there an internal SOC + SSO anywhere, and done by hires with actual blue team experience?
Sec teams don’t want to sign vendors to support innovation. We sign them to not get hacked, increase the odds that we’re not, and save money after. The less bread and butter deployments seen, the more skepticism is needed. Again, this model is actively exploited currently bc threat actors do this same logic.
Sec teams don’t want to sign vendors to support innovation. We sign them to not get hacked, increase the odds that we’re not, and save money after. The less bread and butter deployments seen, the more skepticism is needed. Again, this model is actively exploited currently bc threat actors do this same logic.
Appreciate the Tines comparison.
These are exciting times in the cybersecurity industry with the recent growth of open-source security tools (osquery, Fleet, Wazuh, etc.). Anyway, I'm skeptical about the detection efficacies, usefulness, and scalability of those products. I do not see them widely adopted either. These are my observations from your pitch:
Your pitch mentions large costs for traditional SOAR products and that you want your solution to be focused on smaller companies that don't have money to pay for expensive SOC tools. Nevertheless, the market reality is that if a company has a SOC team (who is the traditional end-user of SOAR tool), they don't care about $100k for a SOAR because they will spend hundreds of thousands a month for log storage, security tools, and HR. It's much more common for your target audience to use ITSM as a security incidents management tool. Just look at what ServiceNow is doing in this space for example: https://docs.servicenow.com/bundle/washingtondc-security-man.... Based on this one fact, I think that you didn't spend enough time understanding your target customer who are in this case not SOC/Security teams, but IT teams.
Incident management is a critical process for every SOC team and its effectiveness is tracked by measuring the mean-time-to-resolve metric. How do you want to convince SOC teams to use open-source tools for their mission-critical process rather than buying one of the established SOAR tools that are integrated with their security stack? (& there are many options in the SOAR space) How can your product help companies lower the operational costs of case management? (improving the mean-time-to-resolve KPI)
Please, don't get discouraged by my comments. SOAR is an essential part of every security stack and the current offerings have flaws. But the narrative in your pitch is flawed and indicates a lack of understanding of current security buyers and personas.
Your pitch mentions large costs for traditional SOAR products and that you want your solution to be focused on smaller companies that don't have money to pay for expensive SOC tools. Nevertheless, the market reality is that if a company has a SOC team (who is the traditional end-user of SOAR tool), they don't care about $100k for a SOAR because they will spend hundreds of thousands a month for log storage, security tools, and HR. It's much more common for your target audience to use ITSM as a security incidents management tool. Just look at what ServiceNow is doing in this space for example: https://docs.servicenow.com/bundle/washingtondc-security-man.... Based on this one fact, I think that you didn't spend enough time understanding your target customer who are in this case not SOC/Security teams, but IT teams.
Incident management is a critical process for every SOC team and its effectiveness is tracked by measuring the mean-time-to-resolve metric. How do you want to convince SOC teams to use open-source tools for their mission-critical process rather than buying one of the established SOAR tools that are integrated with their security stack? (& there are many options in the SOAR space) How can your product help companies lower the operational costs of case management? (improving the mean-time-to-resolve KPI)
Please, don't get discouraged by my comments. SOAR is an essential part of every security stack and the current offerings have flaws. But the narrative in your pitch is flawed and indicates a lack of understanding of current security buyers and personas.
Startups win by questioning every assumption from first principles. We look forward to the fight.
\_(-_-)_/ good luck with that
[deleted]
This is awesome; we need this kind of alternative to overpriced software like Splunk. We built and open-sourced Quickwit to see this kind of tool built on top of it.
We will follow Tracecat closely. I'm convinced this will impact our roadmap, and I'm happy to receive any feedback so you can get the most out of Quickwit for Tracecat.
Good luck, guys!!!
We will follow Tracecat closely. I'm convinced this will impact our roadmap, and I'm happy to receive any feedback so you can get the most out of Quickwit for Tracecat.
Good luck, guys!!!
Thanks for the support! Looking forward to taking Quickwit/Tantivy into production.
What is your plan for monetization with this? Open source core with the hosted platform being paid? Or specific features being paid?
Any price ranges in mind? I am tired of all the SaaS paper cuts bleeding budgets, especially for the SSO tax.
I find it interesting this is another current batch YC company doing "Show HN" and not "Launch HN"... would love to know if these new show posts are sticky and drift down like the launch / job posts are.
Any price ranges in mind? I am tired of all the SaaS paper cuts bleeding budgets, especially for the SSO tax.
I find it interesting this is another current batch YC company doing "Show HN" and not "Launch HN"... would love to know if these new show posts are sticky and drift down like the launch / job posts are.
Cloud version. No SSO tax. We're doing a Show HN as we had strong conviction our message would resonate without the "sticky" Launch HN board. Looks like we were right!
Cloud version - what cloud sec eng have you hired or plan to hire. When? See my other comment.
We are building out an OSS startup security program: Prowler as the CPSM, Trufflehog for secrets scanning, for code scanning...I personally think GitHub CodeQL is good enough, but please tell me otherwise. Our security model for our AWS infra definitely relies a lot on having fine-grained ACLs and security groups. The stack is all in AWS CDK and open source (of course, I'm not a fan when OSS security platforms claim to support self-hosted but it's only a docker-compose file). Supply chain attacks. We keep dependencies light and also rely on GitHub's dependency scanner.
I believe you're a fan of Panther? I find that funny because their out-of-the-box detection rules are limited. Once again, a good CSPM and SSO will do a lot more than a SIEM for startup security. Unless you are really telling me we need a 24/7 blue team monitoring our 10-15ish alerts. Oh by the way, we use AWS SSO and org, only role based permissions for everything, fine-grained GitHub SSO for CICD (down to the repo level because we know about that sneaky privesc path when you use *), and isolated SCPs for prod and staging (of course).
You mentioned phishing two technical founders as some real security threat. That might FUD someone with no security experience and don't have FIDO2 or device MFA set up. But turns out, my cofounder and I have both those things!
And because we know what are doing, CloudTrail is set up in a separate OU to avoid log tampering in case of a breach.
I believe you're a fan of Panther? I find that funny because their out-of-the-box detection rules are limited. Once again, a good CSPM and SSO will do a lot more than a SIEM for startup security. Unless you are really telling me we need a 24/7 blue team monitoring our 10-15ish alerts. Oh by the way, we use AWS SSO and org, only role based permissions for everything, fine-grained GitHub SSO for CICD (down to the repo level because we know about that sneaky privesc path when you use *), and isolated SCPs for prod and staging (of course).
You mentioned phishing two technical founders as some real security threat. That might FUD someone with no security experience and don't have FIDO2 or device MFA set up. But turns out, my cofounder and I have both those things!
And because we know what are doing, CloudTrail is set up in a separate OU to avoid log tampering in case of a breach.
I wouldn’t recommend panther or a SIEM for small startups.
D&R is a bit less important for startups beyond some python scripts piping in the boilerplate alerts via API that gsuite, SSO and cloudtrail generate for you. Prowler is going to buy you a lot of overhead that just enabling GuardDuty and SecHub would do for you quickly and pivot back to revenue ops.
What will get you, and secure infra providers wont do for you, and is a blind spot often with startups who focus all on infrasec (like you mapped out), is enterprise sec, which goes beyond phishing.
- are y’all all still on personal laptops? Personal emails anywhere, those laptops have any sort of EDR on them? Personal phones? What’s your SIM swap plan and setup?
- is a pw manager in place? A corporate account vs individual accs? Are you storing secrets on BYOD, any hanging out in envvars or apple notes?
- phishing: I here you, but devs are often the biggest phishing failure stats. And MFA measures in half of it. The other half is you click, doesn’t push you to a login page, just drops something on your endpoint, and no EDR there to tell you it happened.
- is there someone there telling you not to get social engineered by an annoying hackernews account into listing out large chunks in detail of your security stack, which is very closehold data?
Also - going back through six months of comments to find something about Panther is odd
D&R is a bit less important for startups beyond some python scripts piping in the boilerplate alerts via API that gsuite, SSO and cloudtrail generate for you. Prowler is going to buy you a lot of overhead that just enabling GuardDuty and SecHub would do for you quickly and pivot back to revenue ops.
What will get you, and secure infra providers wont do for you, and is a blind spot often with startups who focus all on infrasec (like you mapped out), is enterprise sec, which goes beyond phishing.
- are y’all all still on personal laptops? Personal emails anywhere, those laptops have any sort of EDR on them? Personal phones? What’s your SIM swap plan and setup?
- is a pw manager in place? A corporate account vs individual accs? Are you storing secrets on BYOD, any hanging out in envvars or apple notes?
- phishing: I here you, but devs are often the biggest phishing failure stats. And MFA measures in half of it. The other half is you click, doesn’t push you to a login page, just drops something on your endpoint, and no EDR there to tell you it happened.
- is there someone there telling you not to get social engineered by an annoying hackernews account into listing out large chunks in detail of your security stack, which is very closehold data?
Also - going back through six months of comments to find something about Panther is odd
This all makes a lot of sense. I agree that SOC2 can be security theatre (I mean a lot of the language of the standard is suggestive, not a requirement). But a lot of your points about having MDM and EDR set up is covered by that cert. It's just how you implement it. And we intend to do it well. The cert and the "trust page" is a signal of our security practices, but at least we wouldn't have to go through it over at HN...
Maybe because I did cryptography at a mathematical level in college, I never really bought into the idea of security through obfuscation. Also the empirical evidence behind whether hiding your tech stack makes you more secure as a non-state level actor / software company actually leans towards the side of "it doesn't really matter".
We obviously do a lot more in our infra/corp sec side that I'm not sharing. But really everything I listed are well known best practices that any attacker should assume a relatively non-stupid security-aware startup should have.
I mean I guess I do believe a bit in security through obfuscation. Not sharing our password manager and IdP as many providers haven't had (as you mentioned) great track record in this space.
I do think it might be a difference of where we learned security. I found folks like yourself from your certain gov/military background to buy into security via obfuscation a lot more. I guess we can agree to disagree.
Maybe because I did cryptography at a mathematical level in college, I never really bought into the idea of security through obfuscation. Also the empirical evidence behind whether hiding your tech stack makes you more secure as a non-state level actor / software company actually leans towards the side of "it doesn't really matter".
We obviously do a lot more in our infra/corp sec side that I'm not sharing. But really everything I listed are well known best practices that any attacker should assume a relatively non-stupid security-aware startup should have.
I mean I guess I do believe a bit in security through obfuscation. Not sharing our password manager and IdP as many providers haven't had (as you mentioned) great track record in this space.
I do think it might be a difference of where we learned security. I found folks like yourself from your certain gov/military background to buy into security via obfuscation a lot more. I guess we can agree to disagree.
I don’t buy into security via obfuscation at all, but that meme comes from the context of hoping your infra is too confusing for an attacker to figure out once they find it.
For the context of digging into your sec stack on open-access platforms, ya def obfuscate haha, public review is step 0 in pentests for a reason.
For the context of digging into your sec stack on open-access platforms, ya def obfuscate haha, public review is step 0 in pentests for a reason.
Help us out? I really would like to hear your advice / thoughts / experience in private. Please find me via email (no getting making this public unfortunately)!
I am curious though. Have you ever seen an attack path from a personal device compromise to full Cloud account takeover (or something along those lines like an exfil job or cryptojacking).
I haven't?
Usually compromised personal devices at the startup level comes from a spray-and-pray watering hole campaign. Likely to be used as part of a botnet, where your device is 1 in a million. Nothing really targeted where the end goal is to compromise a seed / series A's crown jewels.
Once again, please share stories if I should be more worried.
I haven't?
Usually compromised personal devices at the startup level comes from a spray-and-pray watering hole campaign. Likely to be used as part of a botnet, where your device is 1 in a million. Nothing really targeted where the end goal is to compromise a seed / series A's crown jewels.
Once again, please share stories if I should be more worried.
This was how Lastpass was exploited +/- details, lot of write-ups on this.
Devops eng ran a personal unpatched Plex server, threat actor came in via home network/plex, pivoted to personal, devops eng accessed production via the personal.
To your point, this is fairly targeted.
But to your other point, you miss what I’m hammering above - Series A’s Crown Jewels, if it is selling SOAR (or any other sec tool in this direction) are its clients and their sec infra. 90% of the time, Series A can get hacked and who cares really. If you’re selling SOAR, you’re hacked to hack clients. JumpCloud, selling identity, was hacked this way last yr.
Threat actors know about the angle I am describing in this thread wrt to this. Sec and identity infra has been targeted heavily for the last 24 months, specially to pivot into client companies. If you’re selling SOAR, this is what to plan for.
This is also pretty common across crypto.
All in all, depends on your threat model, and if you’re selling security tools, your clients’ threat model becomes your own, bc threat actors know and exploit this now.
Devops eng ran a personal unpatched Plex server, threat actor came in via home network/plex, pivoted to personal, devops eng accessed production via the personal.
To your point, this is fairly targeted.
But to your other point, you miss what I’m hammering above - Series A’s Crown Jewels, if it is selling SOAR (or any other sec tool in this direction) are its clients and their sec infra. 90% of the time, Series A can get hacked and who cares really. If you’re selling SOAR, you’re hacked to hack clients. JumpCloud, selling identity, was hacked this way last yr.
Threat actors know about the angle I am describing in this thread wrt to this. Sec and identity infra has been targeted heavily for the last 24 months, specially to pivot into client companies. If you’re selling SOAR, this is what to plan for.
This is also pretty common across crypto.
All in all, depends on your threat model, and if you’re selling security tools, your clients’ threat model becomes your own, bc threat actors know and exploit this now.
“AI-native” here seems more like buzzword soup but otherwise product is interesting.
I can see adoption failing at most enterprise companies since CIOs are suckers for all in one platforms. But otherwise I hope yall succeed.
I can see adoption failing at most enterprise companies since CIOs are suckers for all in one platforms. But otherwise I hope yall succeed.
Daryl from Tracecat here - great point! We have a short section on this at our github repo https://github.com/TracecatHQ/tracecat?tab=readme-ov-file#wh... but in summary:
1. Our case management system is built on top of a vector database
2. We are building out multimodal semantic search capabilities for our LLM nodes + case management, so you can correlate not just text but screenshots and audio etc. This unlocks use cases like analyzing spoofed/phishing websites.
3. We're also working on supporting open source LLMs for specialized tasks - e.g. MITRE attack labelling
1. Our case management system is built on top of a vector database
2. We are building out multimodal semantic search capabilities for our LLM nodes + case management, so you can correlate not just text but screenshots and audio etc. This unlocks use cases like analyzing spoofed/phishing websites.
3. We're also working on supporting open source LLMs for specialized tasks - e.g. MITRE attack labelling
CIOs are suckers for all in one platforms
Yup. Palo Alto has been buying up everything in sight for this reason.
Yup. Palo Alto has been buying up everything in sight for this reason.
Neat! Another FOSS SOAR platform. Quick read through built-in integrations. Any support for Elastic both SIEM and EDR?
And do you all have like an MSP program? Assuming not, but always need to ask.
Also forgot to ask, any chance of moving some of the develop/feedback off of Discord? I understand a number of projects are making this choice now, but I find whenever I need to search Discord for information, I'm not the most effective at it.
And do you all have like an MSP program? Assuming not, but always need to ask.
Also forgot to ask, any chance of moving some of the develop/feedback off of Discord? I understand a number of projects are making this choice now, but I find whenever I need to search Discord for information, I'm not the most effective at it.
We plan to add integrations and pre-built workflows in the coming weeks. Would love your input in our Discord channel! https://discord.gg/n3GF4qxFU8
We're building a motley crew of blue teamers, security engineers, and data folks.
We're building a motley crew of blue teamers, security engineers, and data folks.
Great start! I was on the SE side of Phantom pre-Splunk. One thing I see a lot of traction in over the last year is data warehouses like Databricks & Snowflake and dumping OCSF data into those. I think an area where you can outshine is by offering something like Clickhouse as a data lake alternative along with OCSF as a schema for a bulk of your builtin integrations.
If you want to chat regarding feel free to reach out.
If you want to chat regarding feel free to reach out.
We see this trend as well. And AWS Security Lake goes exactly there.
Right now, we‘re working on OCSF normalization in our pipelines to drop structured security telemetry in the right format where you need it. Like a security ETL layer.
We considered ClickHouse and DuckDB but struggled with making the execution engine multi-schema, e.g., more jq-like but still on top of data frames. So we started with a custom catalog and engine on top of Parquet and Feather that we will later factor into a plugin to transpile our query language (TQL) to SQL. The custom language because security people are not data engineers.
https://docs.tenzir.com
Right now, we‘re working on OCSF normalization in our pipelines to drop structured security telemetry in the right format where you need it. Like a security ETL layer.
We considered ClickHouse and DuckDB but struggled with making the execution engine multi-schema, e.g., more jq-like but still on top of data frames. So we started with a custom catalog and engine on top of Parquet and Feather that we will later factor into a plugin to transpile our query language (TQL) to SQL. The custom language because security people are not data engineers.
https://docs.tenzir.com
I'd actually love to chat from an adjacent/overlapping area for what we're doing in louie.ai in llm-powered investigation & automation. (We're less interested in yet-another-phantom/tines/xsoar, more interested in where security is going next.) Any good way to reach?
[deleted]
As for the MSP program, absolutely 100% yes. Would love to hear your use-case / pain points regarding existing SOARs (both oss and close sourced). Shuffle is the OG of FOSS SOARs, but the momentum behind that project seems to have stalled...
I couldn't find a way to delete nodes after I placed some. It also seemed laggy in the sense that when I drag and dropped a node from the left to the scene it took 2-3 seconds at first and now it's always roughly one full second.
Hey, sorry it wasn't clear. You just hit backspace to delete a node. Did not expect this level of traffic - turns out we have to 5x the resources we initially gave it :( still waiting for our AWS credits...
Oh ok that works, for some reason that didn't even occur to me. I kept trying to press the Delete key.
Will add some instructions for this! Feel free to reach us on Discord if you have other questions.
Congrats! What is the business model? Also, I see that the license is permissive which is great but how do you protect yourself from other companies hosting your solution and competing your cloud offering?
Great question! Unlike a pure infrastructure tool (MongoDB, Elastic, Terraform), UI/UX is a critical factor for adopting a SOAR.
Even if other companies fork / host Tracecat, we believe we can out iterate the incumbents in building the best SOAR experience. And I think we are just getting started with UI/UX for AI features in security products. It's definitely not a clippy chatbot...
My cofounder and I wrote every line of code for the frontend, design, data pipeline, docs. I don't think the incumbents can build as quickly and accurately (from customer feedback to implementation) as we can.
Even if other companies fork / host Tracecat, we believe we can out iterate the incumbents in building the best SOAR experience. And I think we are just getting started with UI/UX for AI features in security products. It's definitely not a clippy chatbot...
My cofounder and I wrote every line of code for the frontend, design, data pipeline, docs. I don't think the incumbents can build as quickly and accurately (from customer feedback to implementation) as we can.
I wish you all the best but unfortunately I think you will find out that this business model doesn't work and if you give something for free most companies won't pay for it even if they have the money as it doesn't even worth to go through procurement if it is free. You will have to lock some features in an open core way or other way to paywall companies to pay-up.
Hope Im wrong but I think in the last few years all companies realised that FOSS is not a business model.
Hope Im wrong but I think in the last few years all companies realised that FOSS is not a business model.
(I work at Tines)
We're flattered by the mention & imitation ;-)
But seriously, congrats on shipping, and for bringing some new ideas into the fold.
One point of clarification: Tines is certainly not only for the Fortune 10. We have a forever free, generous Community Edition [1] with tens of thousands of happy users, as well as a massively-discounted startup program [2] for early stage companies. Reliable workflow automation matters for teams of all sizes, and we're proud to welcome them all.
1: https://tines.com/community-edition
2: https://www.tines.com/pricing#startup-program
We're flattered by the mention & imitation ;-)
But seriously, congrats on shipping, and for bringing some new ideas into the fold.
One point of clarification: Tines is certainly not only for the Fortune 10. We have a forever free, generous Community Edition [1] with tens of thousands of happy users, as well as a massively-discounted startup program [2] for early stage companies. Reliable workflow automation matters for teams of all sizes, and we're proud to welcome them all.
1: https://tines.com/community-edition
2: https://www.tines.com/pricing#startup-program
I don't have a horse in this specific race, but my life experience has been that having the source is usually a bazillion times better than "segfault and wait for support to respond" or in this specific case "send email to support to download the thing"
Also, w.r.t. <https://www.tines.com/docs/self-hosting/docker-compose/tines...> what the hell is going on with using some rando effectively dead repo <https://github.com/linuxserver/docker-docker-compose#depreca...> to install docker-compose?
Also, w.r.t. <https://www.tines.com/docs/self-hosting/docker-compose/tines...> what the hell is going on with using some rando effectively dead repo <https://github.com/linuxserver/docker-docker-compose#depreca...> to install docker-compose?
Ah, thanks for pointing that out! We've updated the docs to avoid referencing that deprecated repository.
FYI self-hosted is usually something that customers in highly regulated industries opt for – the vast majority of our customers are on our managed cloud.
FYI self-hosted is usually something that customers in highly regulated industries opt for – the vast majority of our customers are on our managed cloud.
Interesting product. I'm curious about the output of example flow (phishing mail scan).
Will post an updated demo with the output and share it here later today! But here is what one response looks like:
"Thank you for your report. the AI labelled this email as malicious. It contained the url https://to58gnrroh2pot.pages.dev/smart89/. The summary: The URLScan report indicates a high likelihood of phishing activity associated with the analyzed URL. The overall score is 100, with identified categories including "phishing" and specific branding as a "tech support scam." The report highlights the presence of malicious intent, with tags such as "phishing" further supporting this classification. The analysis involved IPs from Germany and the Netherlands, associated with the domains "to58gnrroh2pot.pages.dev" and "ipwho.is," and servers named "cloudflare" and "ipwhois." Various URLs, domains, certificates, and hashes were examined during the scan, pointing towards a comprehensive evaluation of the webpage's content and its potential threat level. The verdicts from URLScan and the community reinforce the malicious nature of the webpage, emphasizing the need for caution."
"Thank you for your report. the AI labelled this email as malicious. It contained the url https://to58gnrroh2pot.pages.dev/smart89/. The summary: The URLScan report indicates a high likelihood of phishing activity associated with the analyzed URL. The overall score is 100, with identified categories including "phishing" and specific branding as a "tech support scam." The report highlights the presence of malicious intent, with tags such as "phishing" further supporting this classification. The analysis involved IPs from Germany and the Netherlands, associated with the domains "to58gnrroh2pot.pages.dev" and "ipwho.is," and servers named "cloudflare" and "ipwhois." Various URLs, domains, certificates, and hashes were examined during the scan, pointing towards a comprehensive evaluation of the webpage's content and its potential threat level. The verdicts from URLScan and the community reinforce the malicious nature of the webpage, emphasizing the need for caution."
Looks neat, will be checking it out.
Just a note that I think you have a typo twice in the GitHub readme: “practioner” -> “practitioner”.
Just a note that I think you have a typo twice in the GitHub readme: “practioner” -> “practitioner”.
Thanks for pointing this one out! Fixed now
This name reminds of an LogCat, Android Studio’s logging tool.
The average security analyst deals with 100 alerts per day. As soon as an alert comes in, you have to investigate and respond. An average alert takes ~30 minutes to analyze (and 100 x 30 min = 50 hours > one whole day) Lots of things get dropped, and this creates vulnerabilities. Many breaches can be traced back to week old alerts that didn’t get properly investigated.
Since the risks and costs are so high, top security teams currently pay Splunk SOAR $100,000/year to help automate alert processing. It’s a click-and-drag workflow builder with webhooks, REST API integrations, and JSON processors. A security engineer would use it to build alert automations that look like this: (1) webhook to receive alert (e.g. unusual powershell cmd) from Microsoft Defender; (2) send yes/no Slackbot to ask employee about the alert; (3) if confirmed as suspicious, send malware sample to VirusTotal for report (4) collect evidence from previous steps and dump it into a ticket.
If $100k a year seems wildly expensive for a Zapier-like platform, you’d be half right. Splunk SOAR is actually a Zapier + log search + Jira ticketing system.
Log storage—that’s how Splunk turns a $99/month workflow automation tool into a pricey enterprise product. Every piece of evidence collected (e.g. Slackbot response, malware report, GeoIP enrichment) and every past workflow trail has to be searchable by a human incident responder or auditor. Security teams need to know why every alert escalated to a SEV1 or not.
My cofounder and I are data engineers who fell into this space. We heard our security friends constantly complain about being priced out of a SOAR (security orchestration, automation, and response platform) like Splunk SOAR.
We both wrote a lot of event-driven code at school (Master’s thesis) and work (Meta / PwC). We’re also early adopters of Quickwit / Tantivy, an OSS alternative to Elasticsearch / Apache Lucene that is cheaper and faster. It didn’t seem that difficult to build a cheaper open source SOAR, so we decided to do it.
Tracecat is also different as it can run in a single VM / laptop. Splunk SOAR and Tines are built for Fortune 10 needs, which means expensive Kubernetes clusters. Most security teams don’t need that scale, but are forced to pay the K8s “premium” (high complexity, hard to maintain). Tracecat uses OSS embedded databases (SQLite) and an event processing engine we built using Python 3.12 asyncio.
So far, we’ve just got a bare-bones alpha but you can already do quite a few things with it. e.g. trigger event-driven workflows from webhooks; use REST API integrations; parse responses using JSONPath; control flow using conditional blocks; store logs cheaply in Tantivy; open cases directly from workflows; prioritize and manage cases in a Jira-like table.
Tracecat uses Pydantic V2 for fast input / output validation and Zod for fast form validation. We care a lot about data quality! It’s also Apache-2.0 licensed so anyone can self-host the platform.
On our roadmap: integrations with popular security tools (Crowdstrike, Microsoft defender); pre-built workflows (e.g. investigating phishing email); better docs; more AI features like auto-labeling tickets, extracting data from unstructured text etc.
We’re still early so would love your feedback and opinions. Feel free to try us out or share it with your security friends. We have a cloud version up and running: https://platform.tracecat.com.
Dear HN readers, we’d love to hear your incident response stories and the software you use (or not) to automate the work. Stories from security, site reliability engineering, or even physical systems like critical infrastructure monitoring are all very welcome!