Re: [Mod-security-developers] Tagging Thoughts

[Ryan B. <RBa...@tr...>]

On 5/1/13 4:54 AM, "chr...@po..." <chr...@po...>
wrote:

>Dear all,
>
>Last week, I've attended a workshop where the local security operations
>team, the server operators and the engineering team talked about
>ModSecurity tuning.
>
>During the session, I had an idea: it would really help the security
>operations team to get the alerts enriched with meta-data about the
>service. This could be interesting for all setups, but I believe that
>especially hosting providers / ISPs would benefit from this feature.
>
>Right now, our security operations team gets the errorlog entry and a
>link to the auditlog in their SIEM.
>
>As you know, a typical errorlog entry looks as follows:
>[Wed May 01 02:00:28 2013] [error] [client 98.154.171.101] ModSecurity:
>Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file
>"/.../modsecurity-rules/base_rules/modsecurity_crs_21_protocol_anomalies.c
>onf"] [line "47"] [id "960015"] [rev "2.2.3"] [msg "Request Missing an
>Accept Header"] [severity "CRITICAL"] [tag
>"PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag
>"OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "www.example.com "] [uri
>"/.../application.do"] [unique_id "UYBk2x5RkRSAbHkhE9IAAXDQ"]
>
>I would like every entry to be extended with the following tags:
>[tag: "Safety Class: 3"] [tag "Service License Agreement: 24/7"] [tag
>"Service-ID: 38475"] [tag "Documentation
>https://ourwiki/.../ExampleComService"]
>or
>[tag: "Metadata: Safety Class 3; Service License Agreement 24/7;
>service-id: 38475"; documentation https://ourwiki/.../ExampleComService"]
>with a strong preference for the former.
>
>It would be possible to configure the SIEM to add this data itself. But
>the SIEM is operated by the Security Operations and they would have to
>look up all this information. Besides, I think it should be part of the
>error-log of the server generally.
>
>If I get the ModSec tagging system correctly, the tags are always bound
>to a rule. Tags are a property of the rule. Additionally, I would like to
>see tags as a request property or even a service-property.
>Obviously, I could update all the rules (right now, most of them are
>shared between different services) or I could write UpdateRules, that add
>the tag to every rule at request time. Both variants seem quite
>inefficient to me.
>
>What would be efficient is a directive resembling the following ones:
>SecAction "id:'10001',pass,nolog,addtag:'Safety Class: 3',addtag:'Service
>License Agreement: 24/7',addtag:'Service-ID: 38475',addtag:'Documentation
>https://ourwiki/.../ExampleComService'"
>or
>SecTag "Safety Class: 3"
>SecTag "Service License Agreement: 24/7"
>SecTag "Service-ID: 38475"
>SecTag "Documentation https://ourwiki/.../ExampleComService"
>
>Now I do not know if this is feasible or even possible from a development
>viewpoint. But it sure looks desirable to me as a person configuring
>ModSec in corporate environments.
>
>Sorry for crossposting this to developers and users. I think both groups
>might have something to say. Feedback / support from other users would be
>especially welcome.
>
>Best regards,
>
>Christian

Christian,
Unless I am missing something obvious, why can't you just use the regular
"tag" action?
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-tag


SecAction "id:'10001',pass,nolog,tag:'Safety Class: 3',tag:'Service
License Agreement: 24/7',tag:'Service-ID: 38475',tag:'Documentation
https://ourwiki/.../ExampleComService'"


Why would this not work for your use-case?

-Ryan


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.