[HN Gopher] Show HN: Tracecat - Open-source security alert autom...
       ___________________________________________________________________
        
       Show HN: Tracecat - Open-source security alert automation / SOAR
       alternative
        
       Hi HN, we are building Tracecat (https://tracecat.com/), an open
       source automation platform for security alerts. Tracecat automates
       the tasks a security analyst has to do when responding to a
       security alert: e.g. contact victims, investigate security logs,
       report vulnerability.  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!
        
       Author : neochris
       Score  : 119 points
       Date   : 2024-03-25 18:05 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | ThaDood wrote:
       | 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.
        
         | neochris wrote:
         | 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.
        
           | neochris wrote:
           | 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...
        
           | windexh8er wrote:
           | 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.
        
       | catkitcourt wrote:
       | Interesting product. I'm curious about the output of example flow
       | (phishing mail scan).
        
         | neochris wrote:
         | 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."
        
       | yevpats wrote:
       | 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?
        
         | neochris wrote:
         | 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.
        
       | toomuchtodo wrote:
       | 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)
        
         | neochris wrote:
         | 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.
        
           | toomuchtodo wrote:
           | 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.
        
             | neochris wrote:
             | 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.
        
             | kjs3 wrote:
             | _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.
        
               | toomuchtodo wrote:
               | This is helpful ground truth, thanks for sharing. I only
               | see what I see, but asking everyone else what they see is
               | free(ish).
        
         | badrabbit wrote:
         | 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.
        
       | xyst wrote:
       | "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.
        
         | kjs3 wrote:
         | _CIOs are suckers for all in one platforms_
         | 
         | Yup. Palo Alto has been buying up everything in sight for this
         | reason.
        
         | daryllimyt wrote:
         | 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
        
       | francoismassot wrote:
       | 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!!!
        
         | daryllimyt wrote:
         | Thanks for the support! Looking forward to taking
         | Quickwit/Tantivy into production.
        
       | 1as wrote:
       | (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
        
         | mdaniel wrote:
         | 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?
        
       | justusthane wrote:
       | Looks neat, will be checking it out.
       | 
       | Just a note that I think you have a typo twice in the GitHub
       | readme: "practioner" -> "practitioner".
        
         | daryllimyt wrote:
         | Thanks for pointing this one out! Fixed now
        
       | badrabbit wrote:
       | 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)
        
         | daryllimyt wrote:
         | 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/
        
       | leetrout wrote:
       | 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.
        
         | neochris wrote:
         | 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!
        
       | tomashertus wrote:
       | 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.
        
         | neochris wrote:
         | Startups win by questioning every assumption from first
         | principles. We look forward to the fight.
        
       ___________________________________________________________________
       (page generated 2024-03-25 23:00 UTC)