[Emerging-Sigs] Case sensitivity on rules classification
nathan at packetmail.net
Thu Jun 4 14:39:39 HDT 2020
Can you use a normalizer with Elastic to use the 'lower' function so
you can treat all strings as case insensitive?
Alternatively, could you simply adjust your own classification.config
to suit your needs?
This really sounds like an elastic issue where the friendly strings are
not friendly enough for the tokenizer. I think the below will likely
be the quickest and easiest solution.
luser at BSDBoxen:~ % curl -o - -k -s https://rules.emergingthreats.net/open/suricata-5.0/classification.config | tr '[[:upper:]]' '[[:lower:]]'
# config classification:shortname,short description,priority
config classification: not-suspicious,not suspicious traffic,3
config classification: unknown,unknown traffic,3
config classification: bad-unknown,potentially bad traffic, 2
config classification: attempted-recon,attempted information leak,2
config classification: successful-recon-limited,information leak,2
config classification: successful-recon-largescale,large scale information leak,2
config classification: attempted-dos,attempted denial of service,2
config classification: successful-dos,denial of service,2
config classification: attempted-user,attempted user privilege gain,1
config classification: unsuccessful-user,unsuccessful user privilege gain,1
config classification: successful-user,successful user privilege gain,1
config classification: attempted-admin,attempted administrator privilege gain,1
config classification: successful-admin,successful administrator privilege gain,1
# new classifications
config classification: rpc-portmap-decode,decode of an rpc query,2
config classification: shellcode-detect,executable code was detected,1
config classification: string-detect,a suspicious string was detected,3
config classification: suspicious-filename-detect,a suspicious filename was detected,2
config classification: suspicious-login,an attempted login using a suspicious username was detected,2
config classification: system-call-detect,a system call was detected,2
config classification: tcp-connection,a tcp connection was detected,4
config classification: trojan-activity,a network trojan was detected, 1
config classification: unusual-client-port-connection,a client was using an unusual port,2
config classification: network-scan,detection of a network scan,3
config classification: denial-of-service,detection of a denial of service attack,2
config classification: non-standard-protocol,detection of a non-standard protocol or event,2
config classification: protocol-command-decode,generic protocol command decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,web application attack,1
config classification: misc-activity,misc activity,3
config classification: misc-attack,misc attack,2
config classification: icmp-event,generic icmp event,3
config classification: kickass-porn,score! get the lotion!,1
config classification: policy-violation,potential corporate privacy violation,1
config classification: default-login-attempt,attempt to login by a default username and password,2
config classification: targeted-activity,targeted malicious activity was detected,1
config classification: exploit-kit,exploit kit activity detected,1
config classification: external-ip-check,device retrieving external ip address detected,2
config classification: domain-c2,domain observed used for c2 detected,1
config classification: pup-activity,possibly unwanted program detected,2
config classification: credential-theft,successful credential theft detected,1
config classification: social-engineering,possible social engineering attempted,2
config classification: coin-mining,crypto currency mining activity detected,2
config classification: command-and-control,malware command and control activity detected,1
luser at BSDBoxen:~ %
On Thu, 4 Jun
2020 23:37:14 +0100 Tiago Faria <tiago.faria.backups at gmail.com> wrote:
> Hey Jason,
> Thanks! My concern was that something like "access to a potentially
> vulnerable web application" could be changed to "Access to a
> potentially vulnerable web application", which, even though a small
> change, has the capability of seriously breaking things. If those
> types of changes are not in the roadmap then it shouldn't be a
> As for the classification file itself I always assumed OISF was
> relying on
> for 5.0. That's a good call and I'll reference this thread on their
> mailing list as well.
> Thank you!
> On Thu, Jun 4, 2020 at 10:34 PM Jason Williams <
> jwilliams at emergingthreats.net> wrote:
> > That's a good question, I encounter the case issue as well in using
> > elastic.
> > We have no plans to change existing categories, there are a few new
> > ones we have tossed around about adding, but no plans to change the
> > existing.
> > For our Suricata 5 ruleset we made new category suggestions to the
> > official Suricata classifications.config (
> > https://github.com/OISF/suricata/blob/master/etc/classification.config)
> > As we are intertwined with OISF/Suricata there, we wanted to make
> > sure to maintain the same classifications.config so there wouldn't
> > be issues. May want to pose this question there as well.
> > On Thu, Jun 4, 2020 at 12:52 PM Tiago Faria
> > <tiago.faria.backups at gmail.com> wrote:
> >> Hi list,
> >> I have a question regarding the classification.config that is used
> >> by the rulesets and its use of case sensitivity.
> >> As a user of Elasticsearch, and there are quite a few debates
> >> about the dangers (from a detection engineering perspective) of
> >> what I'll mention, I can't help but be concerned about a possible
> >> change to the classification file and what that would mean for
> >> anyone who has developed anything with the existing classification
> >> names.
> >> While most categories have a capital letter on the beginning of
> >> each word, many do not. Example:
> >> "Detection of a Denial of Service Attack"
> >> and
> >> "Attempt to login by a default username and password"
> >> Others, for example, don't hold any capital letters, such as
> >> "access to a potentially vulnerable web application" and a few
> >> others.
> >> There are many benefits of using the "full name" of a category when
> >> developing detections or processes around alerts (namely they are
> >> more telling of the event than the short name) but I guess the
> >> question I want to ask is:
> >> Is there a commitment to utilizing these names in the long run? I
> >> don't worry so much about possible new categories as I'm more
> >> concerned about changing existing ones.
> >> In case anyone would like to read more about the Elasticsearch
> >> challenges with stuff like this:
> >> https://github.com/elastic/elasticsearch/issues/53603
> >> Thank you.
> >> _______________________________________________
> >> Emerging-sigs mailing list
> >> Emerging-sigs at lists.emergingthreats.net
> >> https://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> >> Support Emerging Threats! Subscribe to Emerging Threats Pro
> >> http://www.emergingthreats.net
More information about the Emerging-sigs