[toomuchtodo]

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)

[_8j50]

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.

[neochris]

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]

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.

[kjs3]

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]

This is helpful ground truth, thanks for sharing. I only see what I see, but asking everyone else what they see is free(ish).

[kjs3]

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.

[neochris]

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.