SO vs Suricata & Zeek

[BradMic]

I'm wondering what the benefit would be to installing a SO distributed architecture (manager and some forward nodes as sensors) as opposed to installing Suricata and Zeek on systems to act as sensors. We already have an Elastic cluster used by ~250 elastic agents to forward log data to. If I installed SO, I wouldn't need the ELK portion so what benefit would I gain by installing SO instead of just Suricata and Zeek and then using elastic agent integrations to foward the Suircata and Zeek data to our existing ES cluster? TIA

[dougburks]

Using our Security Onion distributed architecture allows you to take advantage of our centralized management so that you can do everything from one manager rather than having to individually manage a bunch of different sensors.

You might also consider a best-of-both-worlds approach by building a full Security Onion deployment including the Elastic stack (so that you can take full advantage of our Alerts interface, dashboards, threat hunting, pcap and other capabilities) and then configuring cross cluster search so that you can query both Elastic deployments from one location.

[BradMic]

Thanks for responding so quickly Doug. I have installed the manager node and am currently installing the sensors. My plan is to install a manager node so I can centrally control the sensors using Grid in SOC. I will then install the elastic agent on the sensors and use the Suricata and Zeek integrations to forward the data to our existing Elastic cluster so we have a single pane of glass for analysis. With this plan, I don't think I need ELK running on any nodes. When running the so-setup-network script on the manager node, I wasn't given the option to not install the Elastic stack (I remember in an older version of so-setup that was something you could select). If I choose not to use the Elastic stack in SO, how would I go about making sure that no resources are being used by ELK on the manager node? Please feel free to point out any flaws/gotchas with this approach.

[petiepooo]

Some observations from someone who's used Security Onion since the v14.04 release...
Among other things, it gives you a huge collection of excellent dashboards, the alerts/hunts pages, a case management tool, and several research tools. Plus I haven't found anything that parallels Security Onion's capability to easily pivot from zeek or suricata to the associated raw pcaps, if that's your thing. I recommend you at least try a standard grid deployment first to see what parts you like.
I have found it's best treated as an appliance (or collection of appliances) rather than just an app, as the setup script makes assumptions that aren't always sysadmin-friendly. If you want to use an existing Elastic cluster, you're already stepping out of the normal deployment and published best practices, but it sounds like you likely have the skill needed to mold SO to your vision anyway.
You may have deployed a Manager/Search node already instead of just Manager, which is what I was going to suggest you do. That way you can get it working as designed, figure out the default pipelines, adapt it to use your ES cluster, and finally disable the unneeded states on the manager. You will need a solid base of SaltStack knowledge if you haven't built that up already.
To answer your most recent question, I think you would fiddle with the .../default/pillar/top.sls file to disable the states that start your ELK containers.
Incidentally, you could also manage your fleet of elastic agents via Security Onion.