Insert Comments into Admin GUI Threshold /Disable SID

[UMHB-InfoSec]

Version

2.4.50

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

lots

RAM

lots more

Storage for /

not alot, but enough

Storage for /nsm

like ... ~120TB

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

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

I would like to add comments to the text fields in the admin GUI for thresholding and disabling SIDs. When I was hand editing the files I could use the jinja comment style {#...#} but the web interface doesn't like that.

I checked the documentation and didn't see anything on how to achieve this. It is possible I missed something. Any assistance is appreciated.

Guidelines

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

[izidood]

Should look like this below:

2019401: #ET POLICY Vulnerable Java Version 1.8.x Detected
  - suppress:
      gen_id: 1
      track: by_src
      ip: xxx.xx.xx.x

[UMHB-InfoSec]

Ha! I was reticent to try that because I was unaware how the interface would handle the comment and I have had issues in the past with making mistakes in the config files and not knowing I screwed something up for a while. I guess, in retrospect, it would have been an obvious test.

[UMHB-InfoSec]

I should have tested this more completely before I marked this as the correct answer. This suggestion seems to work for thresholding but
in the grid configuration under idstools -> sids -> disabled section if I add a comment using the '#' flag no errors are thrown but the disabled sid is not disabled.

This is obviously not a huge issue ( the ability to add comments) but it would be nice.

[aprudnev]

It is actually a VERY important thing. All configuration changes in security systems (like SO) MUST be ticketed and documented. And we MUST have ticket ## or admin name next to every line of code in configuration.

It looks as it works as 'extra line next to the sid' or I can use 're: ' but it can be MUCH better if we can have comments (by # or something) in every such line. As for example our requirement is all configuration changes must be backed by the tickets and it includes DNS, firewalls, routers, and yes, IDS systems like SO.

In addition syntax check in the system is weak - it's pretty often when we made change, change passed config check, but broke application (it is expected so not a huge issue, but anyway).

PS. SO I did it this way
# comment without special symbols
1:sid-code
1:sid-code
...

But comment must be simple else it broke idstool (no '(' etc)

[TOoSmOotH]

It is actually a VERY important thing. All configuration changes in security systems (like SO) MUST be ticketed and documented. And we MUST have ticket ## or admin name next to every line of code in configuration.

It looks as it works as 'extra line next to the sid' or I can use 're: ' but it can be MUCH better if we can have comments (by # or something) in every such line. As for example our requirement is all configuration changes must be backed by the tickets and it includes DNS, firewalls, routers, and yes, IDS systems like SO.

In addition syntax check in the system is weak - it's pretty often when we made change, change passed config check, but broke application (it is expected so not a huge issue, but anyway).

PS. SO I did it this way # comment without special symbols 1:sid-code 1:sid-code ...

But comment must be simple else it broke idstool (no '(' etc)

This has all been moved to detections. You have full audit history as well as operational notes that you can add to any given sid. There is no need to add comments any more for rule tuning as you don't tune rules any more with the config ui.

[aprudnev]

DO you mean, in the new version (I see it was introdced in 2.4.70?) ? As I do not see it in 2.4.60 we run today. Idea is great but it means that, when we tune anything, we must be able to add comments (for example when we apply tuning).
Just to compare, when we change firewall ACL's we add comment lines

acl_name remark TICKET { comment
firewall rules
acl_name remark }

DNS record has T=ticket in the comment. Same for VM's and so on. It allows to make reviews and audits as we can always track back change origin and purpose (and who executed it).

PS. What I would like to do EASILY is - select events in ALERT dashboard, and RECLASSIFY them by a single command. Reclassify can be 'disable | change severity | change minimum ## of events to escalate' and so on. As now we must select SID numbers then manually disable them, instead of using ALERT dashboard to do it. In addition, we may want to set up timing things like disable this SID for 1 month or similar. as usual, main problem with any IDS is to suppress false positives (in my experience, real positive always comes in a group, so it'd not easy to skip, but it's easy to flood operators by false messages so they skip real events_.

[TOoSmOotH]

Yes this was introduced in 2.4.70. The whole idea around detections is there is no more config files any more. Everything is done in the gui.

Check out the video:
https://www.youtube.com/watch?v=oxR4q53N6OI

[aprudnev]

Checked this video already. Great idea. It looks as a first implementation - for example, I did not see an easy way to reclassify events (especially by the group - I can clone then disable old then modify new, but it is not so useful) or to use regexp in the rules but I appreciate the overall idea. We just started to run SO (we deployed 2 instances to replace aging SNORT/SNORBY/NTOPNG) and it was 2.4.60 (so it missed Detection dashboard) and detection looks as absolutely right thing, but I expect it to be improved in the next releases (allow group updates, allow timed and permanent reclassification, and so so on). So thanks for the information, it was very useful. (I skipped SO many years ago, when it was still in baby status, but I see that it became a very powerful system eventually. We are just learning how to get maximum from it /and we teach our INFOSEC teams how to use it, too/.)

…

On Mon, Jun 10, 2024 at 4:45 PM Mike Reeves ***@***.***> wrote: Yes this was introduced in 2.4.70. The whole idea around detections is there is no more config files any more. Everything is done in the gui. Check out the video: https://www.youtube.com/watch?v=oxR4q53N6OI — Reply to this email directly, view it on GitHub <#12446 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQ2RZPKTKVZ2O6H43WGRBTZGY3CXAVCNFSM6AAAAABD4UCJHOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMZSGU2TM> . You are receiving this because you commented.Message ID: <Security-Onion-Solutions/securityonion/repo-discussions/12446/comments/9732556 @github.com>

[aprudnev]

We upgraded and started to test this feature. 1) It is step in the right direction. But it looks as a very first step. 2) One problem is that there is not an easy way to change event severity. Which is necessary pretty often. 3) One more problem is that it is often necessary to reclassify or disable GROUP of events. For example all 'access to .. network group' for some groups - we do have offices in China so all access to chinese groups is 100% OK, and there are many events related to it. 4) And one more thing. It is OFTEN necessary to disable event temporarily. We found few BT usages, we opened cases, we do not want to see these events anymore for next week or 2, but then we expect that problem must be resolved so we want to monitor events again. If I check zabbix (as an example) it allows all these things, as they are very common (temporarily reclassification, or reclassification of the group instead of disabling). (CASES sync with jira is another story, but it is outside of this thread scope).

…

On Mon, Jun 10, 2024 at 4:56 PM Alexei Roudnev ***@***.***> wrote: Checked this video already. Great idea. It looks as a first implementation - for example, I did not see an easy way to reclassify events (especially by the group - I can clone then disable old then modify new, but it is not so useful) or to use regexp in the rules but I appreciate the overall idea. We just started to run SO (we deployed 2 instances to replace aging SNORT/SNORBY/NTOPNG) and it was 2.4.60 (so it missed Detection dashboard) and detection looks as absolutely right thing, but I expect it to be improved in the next releases (allow group updates, allow timed and permanent reclassification, and so so on). So thanks for the information, it was very useful. (I skipped SO many years ago, when it was still in baby status, but I see that it became a very powerful system eventually. We are just learning how to get maximum from it /and we teach our INFOSEC teams how to use it, too/.) On Mon, Jun 10, 2024 at 4:45 PM Mike Reeves ***@***.***> wrote: > Yes this was introduced in 2.4.70. The whole idea around detections is > there is no more config files any more. Everything is done in the gui. > > Check out the video: > https://www.youtube.com/watch?v=oxR4q53N6OI > > — > Reply to this email directly, view it on GitHub > <#12446 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFQ2RZPKTKVZ2O6H43WGRBTZGY3CXAVCNFSM6AAAAABD4UCJHOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMZSGU2TM> > . > You are receiving this because you commented.Message ID: > <Security-Onion-Solutions/securityonion/repo-discussions/12446/comments/9732556 > @github.com> >

[aprudnev]

Sorry, what is the best way to ask questions about automation / scripting? What we want is to run script when CASE is created / updated / closed (so we can create case in JIRA with reference to SOC, for example)?
So, q. 0 is - where/how to configure something which will be called once case is created/updated? (Or where to ask such question?)

Regardihng detection dashboard. It is great but few things can be improved:
1 - First, it is not obvious how to see the history of all TUNINGS? What I need is LOG of tunings, and in parallel a way to export/import all tunings (as we make them in one onion but want to replicate to 2 more - we run one TEST system one OFFICE NETWORKS system and one DATA CENTER NETWORKS system.). I could copy/paste idptools sids setup before, now it is RO feature.
2 - When ALERT is escalated to the CASE, it's big problem that all related events are not inserted into the case automatically. As a result, we must, manually, copy IP-s, names and so on from the events into the case (as HUNT is not the same - if I hunt EVENT I end up with ALL related events, which is not the same - I want CASE assignee to see exact view of events we used to create it, not 'hunt by something'.
3 - ALERT tuning need a way to set up tuning timing. It is very common case when we need to SUPPRESS event BUT only for some time (example - we created case for BT and assigned it to INFOSEC, they promise to send emails investigate etc, and we do not want these alerts, for 1 week, then we want them back again so we can see if BT issue was fixed or not).

[dougburks]

@aprudnev From #1720:

Start a new discussion instead of replying to somebody else's discussion
Please search to see if you can find similar discussions that may help you. However, in order to avoid confusion, please do NOT reply to somebody else's discussion with your own issue. Instead, please start a new discussion and in that new discussion you can provide a hyperlink to the related discussion.