SO Vul. Scanning

[BBCan177]

Hi Doug,

In your Roadmap plans, do you envision Security Onion incorporating any Vulnerability Scanning Systems which could be run in off hours?
Like Nessus (not open Source!) or OpenVAS.

[Shane Castle]

Just for my curiosity, for an NSM, what are "off hours"? :)

I think the short answer here will be "no". An NSM has plenty to do
without adding active vuln scanning.

--
Shane Castle

[Doug Burks]

Hi BBCan177,

I have no plans in the short-term to add any vulnerability scanners:
https://code.google.com/p/security-onion/wiki/Roadmap

Since we're based on Ubuntu 12.04, folks can easily install Nessus or
OpenVAS if they choose to do so. However, as Shane said, NSM sensors
are busy enough and my preference would be to run vulnerability
scanners on separate systems.

> --
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Doug Burks

[Michal Purzynski]

On 2/10/14, 12:18 PM, Doug Burks wrote:
> Hi BBCan177,
>
> I have no plans in the short-term to add any vulnerability scanners:
> https://code.google.com/p/security-onion/wiki/Roadmap
>
> Since we're based on Ubuntu 12.04, folks can easily install Nessus or
> OpenVAS if they choose to do so. However, as Shane said, NSM sensors
> are busy enough and my preference would be to run vulnerability
> scanners on separate systems.

Yes, the best idea is to run a separate system doing just the active
vulnerability scanning. The OpenVAS / Rapid 7 / whatever else you use
require a lot of CPU power and memory. We actually run some kind of
vulnerability scanning software on a physical servers with like 8 cores
and around 24GB of RAM. And the hardware is being utilized.

Also, the active vulnerability scanning host might want to (using SSH
with keys) login at the user level to all/many systems and as such it
should be separated, isolated, monitored because it ... has a user level
access to everything. You do not want to mix functionalists on critical
security systems.

This makes me think - we have Bro that can recognize software versions,
there are databases of vulnerabilities... get the picture? A small
correlation and voila, a passive vulnerability scanning system. Now you
can learn about all the outdated browsers on the client's systems like
phones, tablets, etc.

It's somewhere on my list of things to do for sure.

[BBCan177]

What open source Vul. Program would anyone suggest for a Windows/Linux environment? I think having atleast a passive system in SO would be important?

In regards to Off hours, i mean to say lower activity. With Scheduled tasks, Im sure that scans could be done individually at low peak times (pausing with increased activity).

In regards to the Isolation of Credentials, maybe this could be achieved by having a Scanning Server separate from SO but using the sensors infrastructure to perform the scanning? It just seems like a waste of hardware/management costs to have separate systems?

Tying together the Scanning data with Current activity in ELSA would be more functional. I guess a separate scanner could send its logs to ELSA?

So if I suggest a package like "Kismet" which could be another agent in SO to monitor an interface for Wireless infrastructure is out of the question in SO?

[Doug Burks]

On Mon, Feb 10, 2014 at 10:51 AM, BBCan177 <bbca...@gmail.com> wrote:
> In regards to the Isolation of Credentials, maybe this could be achieved by having a Scanning Server separate from SO but using the sensors infrastructure to perform the scanning? It just seems like a waste of hardware/management costs to have separate systems?

In another thread, your sostat output showed you were running a sensor
with only 2GB RAM and it was already overwhelmed. There's no way you
could add a vulnerability scanner to that system and expect reliable
performance.

> Tying together the Scanning data with Current activity in ELSA would be more functional. I guess a separate scanner could send its logs to ELSA?

Yes, that's a better idea. Let your NSM systems focus on doing NSM.

> So if I suggest a package like "Kismet" which could be another agent in SO to monitor an interface for Wireless infrastructure is out of the question in SO?

We don't have the resources to tackle a project like that right now.
If you'd like to work on it, maintain it, and support it, please let
us know.


--
Doug Burks

[BBCan177]

I think that's how Open Source works lol... 90% are O.S. consumers while the 10% provide the technical know-how....

I will support D.B. S.O. till the day I die!