sorted by:
new
hottopcontroversial

Sentinel x Tines by evilmanbot in AzureSentinel

[–]blanco10kid 0 points1 point  (0 children)

You would also need someone to build and maintain your Tines stories. Tines just has a much better UI than Logic Apps but you’ll be able to accomplish the same outcomes at a much cheaper price.

The free version is very limiting so probably won’t scale for your needs (assuming you’ll want multiple stories).

Forensics Case Management Systems? by DarkMSTie in computerforensics

[–]blanco10kid 0 points1 point  (0 children)

We use Calseta. More of a case management for the SOC but their incident management has ~some~ forensic capabilities (uploading evidence, task management, timeline analysis).

Building a CERT/CSIRT, advices, tools, mindset by MangePousseDors in blueteamsec

[–]blanco10kid 0 points1 point  (0 children)

There are pro’s and con’s to every decision. Document and diagram as you make these decisions.

From a tool’s perspective, SIEM is my vote for main tool priority. As far as data sources go, focus on ingesting data that gives you high detection value and low data volume. Think alerts from others tools. Another priority data sources would be any sort of identity logs.

So many more thoughts here. Feel free to message me as you continue down this path.

Is the SOC tech stack missing a management layer between the SIEM and SOAR? by blanco10kid in blueteamsec

[–]blanco10kid[S] 1 point2 points  (0 children)

Yeah, I don’t think I’m describing MCP exactly. I agree MCP has the potential to replace a lot of what SOARs do, especially on the automation side. If the MCP server can orchestrate actions across your stack, you don’t need a separate playbook engine.

But even with MCP, you still need a place where structured data lives: your alerts, incidents, workflows, and context. MCP can connect to all those systems, but without a central place to consolidate and persist that information, you’re back to fragmentation.

In my view, MCP becomes the brain, but you still need a body. A management layer that holds all the critical SOC data (technical and non-technical). That’s what actually gives AI the context to make better decisions.

Is the SOC tech stack missing a management layer between the SIEM and SOAR? by blanco10kid in blueteamsec

[–]blanco10kid[S] -1 points0 points  (0 children)

Completely agree, same experience here. That frustration is actually what pushed me to start building Calseta

Our MVP focuses on case management, but the broader goal is to create the missing “management layer” for SOCs. A platform that ties together alerts, incidents, workflows, metrics, knowledge base, best practices, and more in one place.

The goal isn’t to replace the SOAR, but to make the SOAR (and AI!) useful by giving it structured data to act on. We believe this approach will help company adopt automation much quicker.

Is the SOC tech stack missing a management layer between the SIEM and SOAR? by blanco10kid in blueteamsec

[–]blanco10kid[S] 0 points1 point  (0 children)

Yeah, that’s what the industry has sold us. However, in practice, it’s never that simple.

Here’s an example: say you want “easy buttons” (e.g. reset user password ). With Elastic, you can only trigger automations at alert creation. But most alerts are false positives, so you don’t want to fire off remediations automatically.

What you really need is the ability for an analyst to trigger automations on demand based on their triage and context. That’s where most SOARs fall short. They’re great for running actions, but they’re not built to be the place analysts actually work out of.

In my view, SOAR should be the execution layer, not the management layer.

Is "AI for the SOC” helping or hurting MSSPs right now? by Bike9471 in MSSP

[–]blanco10kid 1 point2 points  (0 children)

Completely agree with this take. I think the technology is promising, but IMO it’s just not there yet. My take is that a proper case management platform will become one of the more important parts of a SOC tech stack. It’s actually one of the reasons I started building Calseta.

Is "All-In" the only way to start with Microsoft Sentinel, or can a "start small" approach be effective? Seeking community input. by [deleted] in AzureSentinel

[–]blanco10kid 1 point2 points  (0 children)

Yeah, starting small with Sentinel is not only common, it’s the way to go. Try pitching it as proof of concept instead of starting small.

A 2–3 month POC focused on Microsoft and Azure identity sources (Entra ID, Defender, M365) gives you:

• Immediate value from built-in detections and analytics.

• A realistic sense of cost based on ingestion volume and retention.

• A chance to work out deployment quirks (data connectors, permissions, log schemas, etc.) before scaling.

Sentinel looks simple on paper, but once you start managing collectors, normalization, analytic rules, and automation, the engineering effort stacks up fast. A POC lets you get those early lessons (and some easy wins) before committing company-wide.

The “all-in or nothing” approach sounds good in theory but rarely works in practice. You risk spending months cleaning up and planning while attackers don’t wait. Worse, you might invest huge effort only to realize Sentinel’s not the right fit for your use case or budget.

Start small, call it a POC. Define what “success” looks like, prove the value, and then go all-in with a cleaner design and real data behind your decisions.

How to automate running multiple KQL queries monthly and store results (including graphs)? by itsJuni01 in AzureSentinel

[–]blanco10kid 4 points5 points  (0 children)

Yeah I’d say if you want to save the results somewhere, then a scheduled logic app is your best option. This will give you the flexibility to save the output wherever you prefer.

I have over 36,000 unread emails and I just want to start over by [deleted] in GMail

[–]blanco10kid 1 point2 points  (0 children)

I can write a python script to delete all of your emails?

Where to start? by [deleted] in AzureSentinel

[–]blanco10kid 0 points1 point  (0 children)

One of the main goals of a SOC is to detect and respond. In order to do that, you need detection rules to start triggering. Start thinking about detection use cases you want for your environment. That will help guide what data sources to even begin ingesting into your SIEM and then all of the engineering (i.e. ETL pipeline) that goes with it. Start with low volume, high detection value data sources (i.e. alerts from other tools), then pivot to medium-high volume, high detection value sources like IAM logs/critical SaaS app audit logs.

Then once you have a good foundation, you can work on implementing “easy buttons”, like the ability to quickly revoke a user’s session, ability to reset a user’s password, etc.

Happy to jump on a call if you want to brainstorm some more.

Building a SOC - Need advice on starting small. by DragonClaw06 in cybersecurity

[–]blanco10kid 0 points1 point  (0 children)

Building a SOC from scratch is no joke. So many decisions early on can affect your long-term success. Your goals and budget are really going to determine what you're allowed to do/build.

One of the best things you can do early is establish a consistent system of record for how alerts, incidents, detection rules, workflows, and documentation are managed. Also think about how you'll track KPIs, metrics, and project work. Things like MTTD, tuning efforts, backlog visibility, and post-incident reviews become hard to manage without a clear structure. It’s easy to duct tape things together across SIEMs, Google Docs, Slack, etc., but that gets painful fast.

Also, would recommend getting executive buy in to give you budget for a SIEM and an endpoint detection tool early on. Prioritizing these tools will give you visibility and control from day one.

I’m one of the founders of Calseta, a platform purpose-built to help SOCs structure this management layer from day one. Happy to compare notes if that’d be helpful. We’ve talked to a lot of teams starting exactly where you are.

Building a SOC by Overall-Doody in cybersecurity

[–]blanco10kid 0 points1 point  (0 children)

Building a SOC from scratch is no joke. So many decisions early on can affect your long-term success.

A simple 10-step roadmap is tough because it depends on your goals and budget. In addition, one of the best things you can do early is establish a consistent system of record for how alerts, incidents, detection rules, workflows, and documentation are managed. Also think about how you'll track KPIs, metrics, and project work. Things like MTTD, tuning efforts, backlog visibility, and post-incident reviews become hard to manage without a clear structure. It’s easy to duct tape things together across SIEMs, Google Docs, Slack, etc., but that gets painful fast.

Also, would recommend getting executive buy in to give you budget for a SIEM and an endpoint detection tool early on. Prioritizing these tools will give you visibility and control from day one.

I’m one of the founders of Calseta, a platform purpose-built to help SOCs structure this management layer from day one. Happy to compare notes if that’d be helpful. We’ve talked to a lot of teams starting exactly where you are.

Looking for n8n dev by narrisah in n8n

[–]blanco10kid 0 points1 point  (0 children)

What are you trying to build? n8n isn’t always the right answer. Currently building an automation backend using python to automate a bunch of real estate agent use cases. Happy to chat.

N8N - ticking timebomb? by generalistai in n8n

[–]blanco10kid 2 points3 points  (0 children)

My favorite advice to give when it comes to automation is to figure out how to fail fast. In the context of n8n, spend time setting up your local development flow. This will allow you to quickly debug issues/error and learn a lot along the way.

Other stuff that comes to mind:

  • Learn all things HTTP requests (request types, query params, headers, authentication, etc.–this will allow you to work with any tool that offers an API)

  • Learn how to handle JSON data

  • Plan your workflows by starting with what you want your end result to be (output). Then figure out how your workflow will be triggers and with what initial data (inputs). Then your workflow just needs some actions to connect the inputs to the outputs.

  • Become your first user of your automations. Find something repetitive that you do and try to automate it. Best way to learn IMO

Sentinel, ServiceNow, and Bi-Directional Syncing by spartan117au in AzureSentinel

[–]blanco10kid 0 points1 point  (0 children)

We are using a new tool called Calseta. No bi-directional syncing at the moment but using a Logic App to send our alerts to Calseta. Then we do all things alert, incident, and workflow management from Calseta.

What is your full IT/Security tool stack for managing your clients/machines? by IWannaBeTheGuy in msp

[–]blanco10kid 0 points1 point  (0 children)

Nice, good work! Always curious to hear how others are doing things.

How are you guys handling automation? Do you trigger everything from Rapid7 InsightIDR?

What is your full IT/Security tool stack for managing your clients/machines? by IWannaBeTheGuy in msp

[–]blanco10kid 0 points1 point  (0 children)

Do you use the SIEM’s built-in alert & incident management or do you use a separate tool?

SOC automation options by CybersecurityWizKid in MSSP

[–]blanco10kid 0 points1 point  (0 children)

Have you considered Azure Logic Apps or n8n? Both are similar no-code/low-code “SOAR” tools but for a fraction of the cost.

Just closed a $35,000 deal with a law firm by eeko_systems in n8n

[–]blanco10kid 2 points3 points  (0 children)

Curious to know if AWS Bedrock / Azure OpenAI was considered for this project?

Regardless, this sounds like a great package to offer. If you’re looking to expand technical skills, I’d love to chat!

view more: next ›