OSSEC alternatives

[tildelowengrimm]

OSSEC is a hassle. It provides convoluted, opaque and hard-to-parse alerts by email (how 20th century). Is there something better that SecureDrop could use instead? It would be lovely if that something supported contemporary notions like on-call rotations.

It would also be particularly convenient one didn't have to understand SecureDrop's innards to parse a notification. Did the machine just reboot successfully? Was this a regular software update? I would like to be able to glance at a notification and know the answers to these sorts of questions. Currently, I have no idea.

[conorsch]

OSSEC grates on me, as well. Making sense of the email alerts is a challenge, particularly for new admins. What I'd like to see is a total overhaul of the Monitor Server, with more modern and less painful tooling. A few options to consider:

• osquery
• artillery (Functionality equivalent to OSSEC to my eye, plus optional honeypot)
• MozDef (Impressive, but likely overkill for our use case)
• custom ELK dashboard

The custom ELK option seems like a workable compromise between functionality and ease of use. We could even take the existing OSSEC config and pipe its logs into ELK as another data point. The primary obstacle right now is that the ELK workflow mostly expects admins to come to it—meaning we'd need to bolt on alerting functionality by way of another tool.

Riemann is a possibility for adding alerts, but I'm open to suggestions. One neat aspect of Riemann is that it leaves the door open for how alerts are sent—it doesn't assume they're going to be email. One reason we're using email now is the ability to encrypt the alert contents. Receiving an encrypted email alert is essentially a pop-up notification (depending on device settings, of course) that says "Something's up with SecureDrop!" and you need to decrypt the message—likely on a different device—in order to get the details. In theory, this is a nice setup—but OSSEC is noisy, and the false positives likely reduce confidence in its alerts.

[conorsch]

Given our security requirements, specifically that we want alerts to be encrypted, we should consider using Signal for shipping the alerts. Even before we migrate away from OSSEC, refining the alerting logic in OSSEC and then providing a Signal transport, rather than GPG-encrypted email, would go a long way in making the monitoring setup more useful to Admins.

[b-meson]

There is a signal-cli tool that may be leveraged here.

[conorsch]

@freddymartinez9 I've been tinkering with that for server alerting and it works rather well. We'd have to document provisioning a cell number for the Monitor Server, though, as a sender identifier, then pass in the Admin recipient cell number to receive the notifications. Certainly possible, but would need to be clearly explained.

[ageis]

@conorsch has a nice initial list. Didn't know of artillery or MozDef. The real consideration is whether we're talking about general-purpose monitoring solutions or things that tackle security (HIDS/FIM/vuln assessment) more in explicit. If the Wazuh thing I filed in #2140 isn't the key, then:

1) Probably osqueryd on App and osquery on Mon, cause I like their security-focused query packs, but I don't know what other backends, alerting or stream managers one combines it with. 2) AlienVault comes up again and again, one of their products is called OSSIM. I guess it's the cheaper, open-source offering of SIEM? (security info event management, for the acronym nerds)

Look, there's a great list of stuff aggregated at awesome-incident-response. I would have to say, after finding about MozDef, and from what I know of osquery, each of those are near top that I would suggest you look at next.

While we're talking about IDS and IM in general, then I just wanted to add that with James around back in the day I recall him mentioning plans to add auditd... I'm not sure if we're getting that kind of information recorded in any other way, as in, a verifiable and immutable trail of commands/shell history and procs executed and sockets/net activity per user on the machines. But it would be totally useful to have and might deserve a separate ticket. Ubuntu system audit logs, however you can get em, audit logs would be great if forensics is ever needed in a suspicious situation.

I think system auditing (logging everything a user does in general) is one of the most important things you could have. And I would point out that auditd hooks up to OSSEC pretty easily, I think auditd logs are one of the first rules files they include. Some good info aggregated here: https://github.com/EricGershman/auditd-examples

If needed to ship these off-site for any reason at all that part is easiest since a multitude of tools are at your disposal: syslog-ng, rsyslog, fluentd, logagent, logstash's lumberjack input (in addition to filebeat)

Auditing and vulnerability assessment and integrity monitoring is crucially tied into standards as well, which is why I opened https://github.com/freedomofpress/securedrop/issues/2145 (got moved to the forum) that pointed out OpenSCAP and SIMP.

It's a lot of info. I honestly don't know whether I'll even find time to get around to playing with those, and I think at least those last two is targeted to RHEL only, but just to have it around would look good, on account of the NIST and NSA standards that are basically certifying, "hey, this machine conforms to its security policies and there are no active CVEs on it".

As a general purpose metrics-based monitoring solution, then Prometheus+Alertmanager on Mon Server with Google's mtail which has a default Prometheus exporter but you'd have to write extraction patterns for each type of log (example) , and prometheus-node-exporter on Application Server, which gives you everything that Metricbeat does and more. Not so much about security, but I now prefer this for straight up resource and conditional monitoring (instead of Beats+LS+Kibana+ES, as long as no logs aren't needed), which can easily be accessed with Grafana as the viz. which has somewhat prettier graphs. That's more of a general opinion/tip and not related to SecureDrop. I just came to enjoy the more simple format of how Prometheus rules are written in comparison to Logstash filters.

[conorsch]

Right now our plan for next steps on the monitoring story is upgrading OSSEC (#2136) to take advantage of the JSON logging option, which will allow us to pass events into an ELK setup with minimal manual munging (we won't have to write custom parsers).

In the spirit of #973, we should allow orgs to opt-in to sending alerts to FPF, so we can observe trends across instances and respond proactively, rather than waiting for diligent Admins to report issues to us (e.g. #2456 , :tophat: to @sighmon). An Onion Service for submission over Tor—optionally Authenticated, for trusted orgs we work regularly with—seems the best bet for log ingestion by FPF.

Managing versions between ELK stack components can be painful. Still, the monitoring is in dire need of improvement, so we should investigate improving OSSEC first, then expand the aggregation and alerting mechanisms thereafter.

[ageis]

In terms of simple file integrity monitoring, Tripwire is a common open-source alternative. https://github.com/Tripwire/tripwire-open-source

[ageis]

Falco is a threat detection engine which uses eBPF to capture system calls; although it's well-suited for Kubernetes and containers, it can be run against non-containerized workloads.