-
Version2.4.190 Installation MethodCloud image (Amazon, Azure, Google) Descriptionother (please provide detail below) Installation TypeStandalone Locationcloud Hardware SpecsExceeds minimum requirements CPU16 RAM128GB Storage for /1TB Storage for /nsm1TB Network Traffic Collectiontap Network Traffic Speeds1Gbps to 10Gbps StatusYes, all services on all nodes are running OK Salt StatusNo, there are no failures LogsYes, there are additional clues in /opt/so/log/ (please provide detail below) DetailOur CISCO is asking for compliance can I get a list of the monitoring, alerts & agent policies. I have looked over these but need more in depth if possible: https://docs.securityonion.net/en/2.4/alerts.html Basically out of the box what would SO be monitoring and alerting on with no additional setup? To quote I want to "make your adversaries cry!" rather than make myself cry over not implementing this correctly i.e. missing a critical component setup! For each agent installed what are it's defaults for monitoring and alerting? i.e. for a windows endpoint it gets the windows event logs, but what would it alert on with zero additional configuration? Same or a linux endpoint etc. More specifically from the above we see: Event Collection - Windows Assuming no customization like advanced scripting what are all the available types of monitoring/alerting. I would rather not recreate the wheel here if I don't have to, so best to know what is already available. Is there a way to dump the current set to provide to an auditor? To ensure certain things are being monitored and also so that we can test trigger those type of events to test alerting is working as expected as well. Thanks community! Guidelines
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Adding to the above. I would love to see update heres: https://docs.securityonion.net/en/2.4/best-practices.html#best-practices Like assuming you have an AWS environment ( very common today ) with windows and linux EC2's and load balancers etc how you go about getting the most out of security onion, with minimal effort. Both what "out of the box" can SO do with very little configuration, make your adversaries cry! And how to customize when needed. In other discussions on this forum I have covered how to get S3 ingestions to alerting ( focusing on cloudtrail logs, also have cloudflare working ) as well as getting logs from a windows EC2, and being able to manipulate the log fields and trigger alerts on those manipulations. Because let's be real you usually have to infer something from a log to get meaning from it, not just detect a log was generated am i right? I think SO is a great product and I want to make it better for our company and the community. |
Beta Was this translation helpful? Give feedback.
-
|
Here is my attempt to answer my own question: Network traffic monitoring is a core component of SO. In an AWS environment this is done by enabling a sensor to monitor the traffic of an ENI These commands allowed me to test such monitoring: This can quickly get more complex when you want to monitor a network of devices and not just a single ENI, but this at least lets one kick the tires on SO/suricata before diving in deeper. The below commands will dump the suricata rules that watch the traffic, note many are disabled by default. But enough are enabled that by test further below will trip many of them. so-rule-update Run from the SO host: nmap will trigger a whole host of suricata alerts. One would think when suricata gets alerts and the SOC is configured to email/slack alerts well that would just work. Oh no. So you go to detections and assume I am using suricata so I should make a suricata alert then to enable email/slack alerts. Oh no. I had to create a sigma alert to email/slack alert on the suricata alerts! Here is an example of that: title: 'Suricata Alert Notification'
These logs can be helpful in troubleshooting This can also confirm your SO hosts monitoring IP is getting the mirrored traffic ( replace eth1 with your monitoring NIC ) I hope this saves someone all the time it took me to get to this answer! Beyond this, I would say the only "easy" setup with SO out of the box is, being able to install an elastic agent on a windows EC2 and that will push event logs etc to SO. This does zero alerting though and requires detection rules to be written to gain anything above being able to search the logs in kibana. I may be wrong on this please correct me if I am. Quoting: https://docs.securityonion.net/en/2.4/notifications.html Types of alerters: https://elastalert2.readthedocs.io/en/latest/alerts.html#alert-types |
Beta Was this translation helpful? Give feedback.
Here is my attempt to answer my own question:
Network traffic monitoring is a core component of SO.
In an AWS environment this is done by enabling a sensor to monitor the traffic of an ENI
These commands allowed me to test such monitoring:
aws ec2 create-traffic-mirror-target
aws ec2 create-traffic-mirror-filter
aws ec2 create-traffic-mirror-filter-rule
aws ec2 create-traffic-mirror-session
aws ec2 describe-traffic-mirror-sessions
This can quickly get more complex when you want to monitor a network of devices and not just a single ENI, but this at least lets one kick the tires on SO/suricata before diving in deeper.
The below commands will dump the suricata rules that watch the traffic, n…