One post tagged with "diy"

It's never been easier to DIY a SIEM​

As you're outgrowing your legacy SIEM, it's normal to look at options. DIY using a warehouse or data lake is naturally one of them.

And for good reasons: they're built to handle massive data volumes, and your company probably has one approved and staffed. So why not put your logs there?

In practice, there are four questions you'll need to answer before you get started:

1. Can you allocate the time? There are a lot of missing pieces to build and maintain before you get something decent. Some require specialized skill sets not normally present on a cyber team. Getting it ready takes time, and you must allocate capacity for ongoing maintenance.
2. Can you tolerate the risk? Your data and detection layer is critical infrastructure, so mistakes are costly. Even for a highly competent team, delivery is risky: team turnover, changing requirements, or unforeseen complexity can easily derail a DIY project.
3. Can you hit the cost targets? Third-party warehouses are not cheap either. Unless you apply ongoing tuning and monitoring, costs easily spiral out of control. If your business case for DIY hinges on cost savings, you'll need solid operations, large scale, and heavy reliance on open-source technologies to make the math work.
4. Will end users be productive? Most end users prefer the SIEM experience over a warehouse. Fast search, piped query languages (e.g., SPL/KQL), native detection capabilities, and a familiar UX help them be productive. Unless a lot of care is put into the end-user experience, DIY comes up short.

Let's dig in.

Can you allocate the time?​

From the outside in, a SIEM can look like a warehouse with a bit of UX on top. Under the surface, however, there are a lot of missing components your team will have to build.

For example:

• Connectors: Collect, parse, normalize, index, enrich, and store data from a wide range of sources. This isn't rocket science, but it's tedious and repetitive work across tens of sources. Moreover, monitoring and maintenance are not trivial: a silent source or a corrupted field could have a number of causes spread across the source system, your collector infrastructure, or your warehouse. Debugging that is a pain.
• Detection and alerting: A basic version is trivial: write some detection queries, and run them on a schedule. But if you want more, it gets harder quickly. How do you label or categorize rules? How do you test them? How do you manage load if you're running hundreds of them? How do you let end users edit or expand coverage? Where do you store the results? How do you let users combine detections into multi-stage use cases? How do you ensure alerts are delivered reliably? The list of features your end users will ask for is long, and unless you plan to set aside significant time (or purposefully set the bar low), you'll get in trouble here.
• Performance: Fast search is critical for detecting and responding to incidents quickly. Warehouses might let you index your data, but it's up to you to build and manage the indexes. Moreover, advanced performance optimizations such as data organization, aggregation of frequently used results, and caching require expertise and continued oversight to apply properly. And if you don't tune something, warehouses revert to scanning all the data, which gets expensive fast (more on that in the cost section).

We could go on and on here, but itemizing the full list of work misses the point: is this where you want to spend your team's time and talent? SecOps teams are usually stretched thin, and each hour spent building and maintaining a data platform is an hour not spent building and maintaining your defenses.

Unless you have highly esoteric needs, and the budget to staff a real team to build against them, DIY SIEM is unlikely to be the best use of your team's time.

Can you tolerate the risk?​

Most software projects fail or get delayed significantly. A DIY SIEM is no exception, especially when delivered by a stretched and under-resourced team.

The reasons for delay should look familiar: inadequate staffing, inadequate skills, turnover of critical team members, unforeseen complexity, and changing requirements. Your DIY SIEM is not exempt.

What's different in this case are the stakes. The SIEM is critical infrastructure, and you're choosing to DIY for a reason. Whether that's lack of coverage, lack of budget, or inability to deliver on new initiatives, the consequences of failure are significant.

The longer you're delayed, the longer the coverage gap you were hoping to close stays open. Or you might have to pay up for an expensive renewal you were hoping to avoid. And if something breaks, you're on the hook to find the resources and time to fix it.

Unless DIY provides compelling benefits in terms of time to value, cost, or capabilities, the risk is rarely worth it.

Can you hit the cost targets?​

The primary reason teams choose DIY is to manage cost. And when compared to a legacy SIEM, that's understandable.

But when compared against modern alternatives, the picture is less clear.

Warehouses primarily charge for compute, which makes them look cheap up front, as it doesn't take much compute to ingest data. When you use it, however, the bill racks up quickly.

Data warehouses are built for scanning large volumes of data in parallel. This returns results quickly, but uses a lot of compute unless you're careful. A single query searching for a string against an unindexed column over months will scan the whole dataset. Without proper workload management and timeouts (another thing to configure and manage), you could consume the whole cluster.

Moreover, third-party warehouses mark up their compute by 6-10x over the hardware they run on, so the bill grows quickly as you start using your data more. And if you want to run open source, you need to budget the headcount to set up and manage it, which is usually more expensive (unless you've got an extremely large environment).

The point isn't that DIY can't be cheaper. It absolutely can be, if managed well and used modestly!

But often, it's not.

So take proper care when you build the business case, and rely on benchmarks of production-size workloads rather than vendor estimates when building the cost projections.

Will end users be productive?​

When scoping a DIY project, it's easy to get lost in architecture diagrams, project plans, and business cases.

But don't forget about the end-user experience.

End users such as detection engineers and SOC analysts will (hopefully) rely on your DIY SIEM to detect, investigate, and respond to threats. If the user experience lacks important features, or is needlessly brittle and complicated, that will slow them down and reduce outcome quality and morale.

Specific examples of UX challenges with DIY are:

• Detection management: Managing rules at scale requires a proper UX. Tasks like mapping coverage, assessing load, tuning logic, or backtesting new detection hypotheses are challenging without the right workflows and visual feedback.
• Querying: SQL is meaningfully different from piped languages such as KQL and SPL, which makes it harder for practitioners to transition. Even in a world where AI writes most of the queries, end users still need to review and maintain them (or at least understand them). Without syntax familiarity, this adds friction.
• Performance: Experienced practitioners are used to querying in specific ways, such as searching for an IOC across tables (e.g., search "123.102.10.22"). In a warehouse, this is a very expensive query, as you're essentially reading all data for the specified time period. If you can't deliver adequate performance for the most common query patterns, investigations slow down and users get frustrated. It also drives up costs.

Today's top talent built their skills on the legacy SIEMs and their ecosystems. They rely on their knowledge of the query languages, performance characteristics, workflows, detection capabilities, visualization frameworks, and community content to get their job done.

If you take shortcuts on those fronts, your end users will be less happy and productive.

So what's the alternative?​

If you're looking at DIY, it's usually because you've run out of options: your legacy SIEM is too expensive, and the lack of visibility is becoming an unacceptable risk.

Luckily, modern technology makes it viable to provide a SIEM-like experience on top of a warehouse architecture. A Modern SIEM gets you all of the benefits of DIY (and more), without the cost, complexity, and risk.

Don't settle for less.

FAQ​