Alert Tuning Status Mismatch (Says Disabled, but is Enabled)

[corycandia]

Version

2.4.70

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Meets minimum requirements

CPU

4

RAM

16

Storage for /

100

Storage for /nsm

200

Network Traffic Collection

span port

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Perhaps I am doing something wrong? I keep getting alerted for something I want to disable and shows disabled. Detections is the way to do it now, instead of config/idstools/sids/disabled, but that already shows disabled.

I find an alert for a rule (2030387) I'd like to disable.

I use the tuning pivot, and the new Detections module shows me its status is 'disabled'.

I check the rules file /opt/so/rules/nids/suri/all.rules and it shows enabled (not #). Maybe this doesn't matter because it's now where Detections pulls its status.

Maybe this is my fault because (prior to the 2.4.7 update), this is my /opt/so/saltstack/local/pillar/idstools/soc_idstools.sls:

idstools:
    sids:
        disabled:
            - re:ET INFO
            - "2030387"
            - "2009208"
            - "2009207"
        enabled:
            - re:ET MALWARE
            - re:GPL MALWARE
            - re:ET EXPLOIT
            - re:ET EXPLOIT_KIT
            - re:ET MOBILE_MALWARE
            - re:ET ADWARE_PUP
            - re:ET WEB_SERVER
            - re:ET ATTACK_RESPONSE
            - re:GPL EXPLOIT
            - re:GPL WEB_SERVER
            - re:GPL ATTACK_RESPONSE
            - re:ET ATTACK_RESPONSE
            - "2027237"
        modify:
            - 2024699 "flowbits" "noalert; flowbits"
            - 2025303 "flowbits" "noalert; flowbits"
            - 2024693 "flowbits" "noalert; flowbits"

Do I need to remove the previous config information from the soc_idstools.sls file and start over with them in detections?

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[defensivedepth]

You will need to remove the regex re:ET MALWARE and then I would suggest upgrading to 2.4.80, which was released yesterday. This fixes a couple Detection-related issues you may be seeing.

[corycandia]

Josh,

remove the regex re:ET MALWARE

From a logic standpoint, you're suggesting this comes down to the order of pulledpork's(?) configuration of enabled/disabled/modified? For example, is it likely then that my implementation is disabling '2030387', then enabling it because '2030387' is included with 'ET MALWARE'? I've seen a config file where it looked like you could specify the order the three lists where implemented. I assume this is a separate issue then from the mismatch of detections showing disabled.

General Question: This will be personal/organizational, but I have not seen a lot of recommendations on how to do sweeping rule management. Is it a bad idea enable whole categories? My thought was to enable all of it (which will cause lots of alerts) and then eliminate the ones that aren't applicable. I thought this better than some being disabled by default, mostly because I don't feel confident enough to know which ones I should be manually enabling that wouldn't be enabled by default. This was all before the new detections panel feature, so maybe a default installation with no customization will list all the rules with the enabled/disabled status now and there's at least a visual/GUI way to hunt through alerts?

Thanks for the info. I'm updating the grid. I'll see if that change at least helps match what the detections panel says to what's actually enabled by reg ex.

EDIT:

Josh,

The rule 'ET EXPLOIT Possible CVE-2020-11899 Multicast out-of-bound read' still shows 'status: disabled' after the update to '2.4.8'. Should it?

I understand I could remove the regex that's turning that group on, but my untrained intuition tells me the status should reflect what's being sent to the sensors as enabled?

[defensivedepth]

So the regex like you have it is not currently supported in Detections, though we are looking to add support in the future. Having a regex in there will cause the rule mismatch, because Detections is not aware of the regex and cannot account for it.