IBM Security QRadar

Expand all | Collapse all

DSM Parser

  • 1.  DSM Parser

    Posted 6 days ago
    Hello Experts,

    I want to integrate a log source (Forcepoint V series) to QRadar, i am sending my logs to the Event Processor, however the logs are not passed nor mapped.

    I checked the Console, using rpm -qa | grep -i forcepoint i saw the DSM-ForcepointVseries-********noarch. but i cant see this same dsm on my EP.

    I tried installing this dsm on the EP but it failed , saying dependency DSM-DSMCommon is needed. I am using QRadar 7.4.1. The Force point DSM is also version 7.4.

    While i tried to install the dependency on the EP, it failed saying DSM-DSMCommon can only be installed on a console.
    I am using yum -y install <dsm_name>

    Kindly assist!.

    ------------------------------
    benjamin Nworah
    ------------------------------


  • 2.  RE: DSM Parser

    Posted 6 days ago
    Hello Benjamin,

    you DON'T need to install the DSM RPM on other managed host but the Console.

    Your investigation should point out:
    • are the logs arriving at the EP ? (tcpdump is a good tool to investigate it)
    • are they parsed? (you should see events not parsed in the SIM Generic Log logsource related to your EP
    Then you could continue to analyze the payload to verify that:
    • if the logsource is SYSLOG based, the payload MUST adhere to the RFC164 or RFC5424
    • the logsource identifier is correct


    Generally speaking, you shouldn't try to change or force QRadar configuration from command line as the first attempt to solve this kind of problems.

    Hope this help.
    Best regards,
    Mario



    ------------------------------
    Mario Sebastiani
    ------------------------------



  • 3.  RE: DSM Parser

    Posted 6 days ago
    Hello Mario,

    Thank you for the input,

    From tcpdump the logs are arriving at the EP, however looking at the log activity tab, i can see the log source with SIM-generic to the EP, not parsed nor mapped. In addition i manually created the same log source, and the logs are not parsed nor mapped despite using the  forcepoint v-series DSM. I am surprised why i am getting another log source auto detected after creating a log source manaully. I thought QRadar is not meant to discover another log source since i have created one already. 

    The IP address on both log sources is the same. For the manually created log source, the payload is in LEEF format, but the values are empty, like src= dst= usrname=, while the log source that was auto detected, the payload seems fine. i.e. it has values like src=x.x.x.x dst=x.x.x.x usrname=xxx.

    Regards,

    ------------------------------
    benjamin Nworah
    ------------------------------



  • 4.  RE: DSM Parser

    Posted 5 days ago
    Benjamin,
    my comments inline <quote> From tcpdump the logs are arriving at the EP, <quote> good you verified that!

    <quote> however looking at the log activity tab, i can see the log source with SIM-generic to the EP, not parsed nor mapped. <quote> autodetected! not hitting your manually created logsource - YES STANDARD PROBLEM

    <quote> In addition i manually created the same log source, and the logs are not parsed nor mapped despite using the forcepoint v-series DSM. <quote> same log source? IP or hostname based? regardless of what you do you may need to change log source parsing order is admin tab

    <quote> I am surprised why i am getting another log source auto detected after creating a log source manaully. I thought QRadar is not meant to discover another log source since i have created one already. <quote> that would be true if you disabled autodetection or changed log source parsing order - dont think - know!


    <quote> The IP address on both log sources is the same. <quote> so far so good. does logdata come in with IP in log header? pls double check with tcpdump. If not you need to specify hostname as logsource identifier rather than IP address

    <quote> For the manually created log source, the payload is in LEEF format, but the values are empty, like src= dst= usrname=, while the log source that was auto detected, the payload seems fine. i.e. it has values like src=x.x.x.x dst=x.x.x.x usrname=xxx. <quote> very confusing. if parsing order has two log sources only one of them should work. In your case it is the autodetected one not the manually defined logsource right? Payload is always fine because it will never be changed by qradar. normalization by DSM is not. Make sure the payload is mapped to the correct logsource. Thats not the case yet. Then you should be fine.


    ------------------------------
    [Karl] [Jaeger] [Business Partner]
    [QRadar Specialist]
    [pro4bizz]
    [Karlsruhe] [Germany]
    [4972190981722]
    ------------------------------



  • 5.  RE: DSM Parser

    Posted 5 days ago
    Hi Benjamin,

    I had same issue with Forcepoint V series, then i raised the issue with Forcepoint support to get this resolved(logs not getting forwarding to syslog or siem). there was issue from Forcepoint v series.

    Thanks
    Robin

    ------------------------------
    robin jangid
    ------------------------------



  • 6.  RE: DSM Parser

    Posted 2 days ago
    Edited by COLIN HAY 2 days ago

    Hi Benjamin (and Mario and Karl),

    There's a lot going on in this thread and some comments are not completely accurate so I'm going to comment on several statements and then provide some additional advice.

    Benjamin: "I checked the Console, using rpm -qa | grep -i forcepoint i saw the DSM-ForcepointVseries-********noarch. but i cant see this same dsm on my EP."

    As Mario indicated, this is expected. DSM RPMs are only installed on the console and the artifacts they deliver are then deployed out to all managed hosts via deploy actions.

    Mario: "if the logsource is SYSLOG based, the payload MUST adhere to the RFC164 or RFC5424"

    This is not entirely correct. The syslog header on the events must conform to RFC 3164 or 5424 for QRadar to parse the syslog header and use the IP/hostname/identifier in it as the source of the event. This extracted value is used to "route" the event to a configured log source by matching it to a Log Source Identifier. If no matching log source exists, the event will appear in Log Activity associated with a SIM Generic Log log source, as it is a "catch all" bucket for any events which don't match the Log Source Identifier of any available log sources.

    If a syslog event does not conform to the RFCs, QRadar will still accept it and attempt to parse it, but in this case the source of the event will default to the IP address from which it was sent.

    From QRadar version 7.4.0 onward, there is a Log Source Identifier property/field in the Log Activity event details view, so for events being collected by a SIM Generic log source, you can see what the system considered the source to be - this tells you what Log Source Identifier value to use when creating a log source to handle the event.

    Benjamin: "From tcpdump the logs are arriving at the EP, however looking at the log activity tab, i can see the log source with SIM-generic to the EP, not parsed nor mapped. In addition i manually created the same log source, and the logs are not parsed nor mapped despite using the forcepoint v-series DSM"

    If you can see the events in tcpdump from the EP and can see the events in Log Activity (regardless of which log source they are associated to), this means the events are being successfully sent to QRadar and read off the network. The fact that the events are being routed to SIM Generic means there is no log source configured with the correct Log Source Identifier. If there was such a log source, the events would be linked to it, even if the associated DSM couldn't parse the events (they would appear with category = Stored).

    Benjamin, after you manually created the log source, are the events being linked to it as Stored, or are they still going to SIM generic? If still SIM Generic, it means you need to fix your Log Source Identifier. If they are with the correct log source but are Stored (and not parsed correctly), then there is a parsing problem occurring.


    Benjamin: "I am surprised why i am getting another log source auto detected after creating a log source manaully. I thought QRadar is not meant to discover another log source since i have created one already. "

    A few questions here:
    1. What log source type is the autodetected log source, and what type is the manually created log source (I assume it's Forcepoint V Series, but just want to be sure)

    2. Does the autodetected log source have the same Log Source Identifier as the manually created log source?

    QRadar will autodetect log source(s) on the same Log Source Identifier as a manually created log source if events are coming into the system which no log source can successfully parse. For example, say you manually create a log source with LSI (Log Source Identifier) 10.10.10.10. Any events originating from that IP will be routed to that log source for attempted parsing. If the log source can successfully parse the events, the events are not considered for autodetection, they simply stay with that log source. However, if they are not parseable by the existing log source, they will appear in Log Activity as Stored events (meaning they were just stored, not parsed) and will also be analyzed for the purpose of autodetection. If enough such events are received which can be parsed by another log source type (DSM), then QRadar will autodetect a log source of that type for 10.10.10.10, with a lower parsing order than the manually created log source (meaning the original log source has higher precedence/priority for any events coming from 10.10.10.10). We do this because it is possible to have multiple log sources for the same LSI - there could be a log source for the OS (Linux, Windows, etc) and then additional log sources for applications, databases, etc running on that OS.

    Benjamin: "The IP address on both log sources is the same."

    When you say "the IP address is the same", you mean that the LSI is the same? If so this answers one of my questions above. But this suggests that they are not the same log source type, as QRadar does not allow two log sources of the same type to coexist on the same LSI.

    Benjamin: "For the manually created log source, the payload is in LEEF format, but the values are empty, like src= dst= usrname=, while the log source that was auto detected, the payload seems fine. i.e. it has values like src=x.x.x.x dst=x.x.x.x usrname=xxx."

    Ok so you're saying that both your manually configured log source and the autodetected log source are actively receiving events, and they're both LEEF? Then I assume the LEEF headers must be different, and that one log source (presumably the autodetected one) is parsing events successfully?

    If the LEEF attributes for the manually created log source are empty, this could explain why it isn't parsing. Is the LEEF header also empty? This sounds like a configuration problem on the sending side where it's just sending bad data for some events. It would be really helpful to see a payload sample from each log source.

    Karl: "that would be true if you disabled autodetection or changed log source parsing order"

    Parsing order doesn't actually affect autodetection in any way, it just defines the order in which a set of log sources which share a Log Source Identifier attempt to parse an event which matches their LSI. The first one to successfully parse the events "wins" and any log sources lower in parsing precedence don't get the chance to try. As long as one log source can accept the event, the autodetection engine will never see it, it's only if all log sources reject it that the autodetection engine gets it.

    Karl: "does logdata come in with IP in log header? pls double check with tcpdump. If not you need to specify hostname as logsource identifier rather than IP address"

    To be clear, you only need to use the hostname if it is present in an RFC3164 or RFC5424-compliant syslog header. If there is no header or if the header is non-compliant, you need to use the IP address for the LSI, and if there is a compliant header, you need to use whatever value is in the header (could be IP address, could be hostname, could be something else, depending on how the sending system is configured)



    My advice:

    First, answers to some of the questions above would help me provide a clear explanation.
    Second, a general bit of wisdom for cases like this is to first determine if the events are even entering the system (that has been done - we know they are), and if so, launch the DSM Editor with the intended log source type and some sample events from Log Activity to check if the intended DSM can handle the event format. The DSM Editor allows you to pass raw events directly to a target DSM, without needing to worry about Log Source Identifier misconfiguration, so it eliminates a variable. If the DSM Editor's Log Activity Preview says that the event format is good, then the problem is almost certainly a routing problem, where the log source's Log Source Identifier is set incorrectly. If the DSM Editor's preview indicates that the DSM cannot handle the events, then this is the root problem that will cause autodetection to fail and manually-created log sources of that type to fail, and it means the 3rd party system is sending data in a format that the DSM doesn't understand, which typically can be solved with a config change on the sending side.

    Cheers
    Colin



    ------------------------------
    COLIN HAY
    IBM Security
    ------------------------------



  • 7.  RE: DSM Parser

    Posted 2 days ago
    Edited by benjamin Nworah 2 days ago
    Hello Colin,

    Thank you for your input, i have been expecting your input :).

    Let me make it a bit clearer based on what i have discovered. 

    First, i have five forcepoint V-series devices, out of which three of these log sources are parsing and mapping correctly. Let me focus on the one that is not parsing and mapping as seen from the DSM editor, the log source was manually created with the log source type as Forcepoint V-series. On the log source side as mentioned the LEEF format was used as stated in the DSM guide, so on QRadar side from the DSM editor i changed it from JASON to LEEF, also looking at the raw logs they are in LEEF format.

    For the manually created log source, the payloads have empty values for the various attributes, like src = , dst =, etc. so i guest something is wrong with the configuration on the log source side, Note, these logs are not parsed nor mapped. I was not surprised after i discovered the raw logs have no values. However the customer noticed that the same log source is sending logs to QRadar, as SIEM generic and these log were equally not parsed nor mapped viewing the DSM editor. But i also thought the raw logs will have no values as mentioned above, but when i view the logs from the DSM editor i saw it does have values. This manually created log source has cat=stored. Note Collin, this was tied to the Log source identifier when setting up the log source on QRadar.


    And lastly Colin, I ran "rpm -qa | grep -i dsm" on both Console and EP, i was expecting to see the same DSMs on both appliances, however on my console i saw a lot of DSMs, while none on my EP. You made mentioned that the console deploy the artifacts to the EP, do you mean the same DSMs? or something else.?

    Sorry Colin, i can't share the customer payload on this platform, these are sensitive information, but i will share with you on Linkedin.

    Thank you. I await your response.


    ------------------------------
    benjamin Nworah
    ------------------------------



  • 8.  RE: DSM Parser

    Posted 2 days ago
    Hello Benjamin and all.

    Thanks @COLIN HAY for integrating and explaining the point. Sometimes my poor English leads me to be too succinct and less precise than necessary.

    @benjamin Nworah again, you don't need to install any RPMs on the EP or on any other managed host unless you are explicit requested by the IBM Support. The needed internal component are distributed automatically by the QRadar from the Console.

    Regards,
    Mario

    ------------------------------
    Mario Sebastiani
    ------------------------------



  • 9.  RE: DSM Parser

    Posted 2 days ago
    Hello Mario,

    I understand you clearly. let me ask the questions again.

    ** If i install say XYZ DSM on the console, will this XYZ DSM be moved to my managed hosts.? or what is that internal component as you mentioned. Sorry i like having accurate knowledge on things.

    so what is that artifacts, or Internal components that are distributed to the managed host? or is the same DSM that was installed on the console is distributed to the Managed host? . Because take for example i send logs to EP, the EP should perform the parsing using DSM for that particular log source, right? so my question why can't i SEE the DSM on the EP? when i run a basic linux command like rpm -qa | grep -i <dsm_name>?

    Hope i am clear now Mario

    Regards,

    ------------------------------
    benjamin Nworah
    ------------------------------



  • 10.  RE: DSM Parser

    Posted 2 days ago

    Hello Benjamin,

    I understand your wish to know as much as possible about the QRadar.

    Most of the topics are covered by our official documentation

    https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.4/com.ibm.qradar.doc/qradar_IC_welcome.html

    integrated by technote

    https://www.ibm.com/community/qradar/home/knowledge/

    Some topics are related to how QRadar works internally and they aren't public. I also ignore the precise distribution mechanism, but I'm sure that it's the way QRadar works. For sure, the needed component are distributed automatically to the EP (and also to the EC if present). It doesn't matter if they are jar files, xml files, config files or whatever else. I don't need to interact with this internal component, it is like a black-box and I accept this.

    I think (and hope) that you trust QRadar since it is one of the leading SIEM in the market. QRadar is a robust platform based on appliances, this particularity includes, among other things, that the manual operation on the environment are limited and strictly related to manage specific issues. If you were requested to install something manually (and it is a real rare case) you should follow the instructions provided and nothing else.

    Hope this clarify my point of view.

    Regards,
    Mario



    ------------------------------
    Mario Sebastiani
    ------------------------------



  • 11.  RE: DSM Parser

    Posted 2 days ago
    Hello Mario,

    Thanks a lot. I was just concerned what to check if i run into issues with DSMs.

    This answer my question. 

    Regards,

    ------------------------------
    benjamin Nworah
    ------------------------------



  • 12.  RE: DSM Parser

    Posted 2 days ago
    Edited by COLIN HAY 2 days ago
    Hello Benjamin,

    I'm a bit confused at this point about what the outstanding problem is.

    We know one problem is that one device is sending empty events, which is a problem on the sending side (not on the QRadar side).

    Is there a second problem whereby some properly formatted events are going to SIM Generic?


    Perhaps I should try to summarize my understanding of the situation, please correct anything I have wrong:

    1. You have 5 Forcepoint devices, 3 are working fine, so presumably 2 are not. I'm not clear on if the 3 working ones were manually created or autodetected, but it doesn't really matter since they are working. Lets refer to the three working devices as Device 1, Device 2, Device 3.

    2. One of the non-working log sources has been manually created as type Forcepoint V-series, the events are in LEEF. My understanding is that this log source is receiving events, but they are Stored because the LEEF events are "empty" (which is expected). Let's call this Device 4 - it has a problem with how it's generating its logs - this cannot be solved on the QRadar side.

    3. From the paragraph below, it sounds like the 5th device is sending valid events but they are unparsed and going to SIM Generic instead of a proper log source, but I'm confused by the reference to "the same log source is sending logs to QRadar as SIEM generic". Is this statement referring to the 5th device, or to Device 4 previously discussed? If it's Device 4, are you saying that some events are empty and going to the manually configured log source as Stored, and some are valid and going to SIM Generic?

    "However the customer noticed that the same log source is sending logs to QRadar, as SIEM generic and these log were equally not parsed nor mapped viewing the DSM editor. But i also thought the raw logs will have no values as mentioned above, but when i view the logs from the DSM editor i saw it does have values. This manually created log source has cat=stored."

    I also don't understand this statement:
    "Note Collin, this was tied to the Log source identifier when setting up the log source on QRadar."
    I'm don't know what "this" refers to, or what what you mean by "tied".

    The events going to SIM Generic have no matching enabled log source, I know this for sure, so one of three things is happening:

    - a log source is missing on the QRadar side
    - a log source has its LSI set incorrectly
    - a Forcepoint device is sending some events with one syslog header and sending other events with a different header (or no header) and as such some events are being routed to a correct log source but others are going to SIM Generic


    Thank you for sending me the sample payloads, but if they are from a working autodetected log source, I don't think they are useful information, because there is nothing wrong with them (i.e. there is no problem to solve). If there are some events going to SIM Generic, those payloads would be useful as I could then tell you what Log Source Identifier they would match to.


    Cheers
    Colin

    ------------------------------
    COLIN HAY
    IBM Security
    ------------------------------



  • 13.  RE: DSM Parser

    Posted 2 days ago
    Hello Colin,

    3. From the paragraph below, it sounds like the 5th device is sending valid events but they are unparsed and going to SIM Generic instead of a proper log source, but I'm confused by the reference to "the same log source is sending logs to QRadar as SIEM generic". Is this statement referring to the 5th device, or to Device 4 previously discussed? If it's Device 4, are you saying that some events are empty and going to the manually configured log source as Stored, and some are valid and going to SIM Generic? By the Same, i mean the source IP of the autodetected log source (viewing the log activity tab) is the same with the LSI (IP) of the one created manually.

    "Note Collin, this was tied to the Log source identifier when setting up the log source on QRadar." What i meant is that the LSI of the manually created log source was set up with the IP address of the forcepoint device (the one not parsed by QRadar).

    Assuming the ip address of the forcepoint is "abc"

    To summarize the above. I have a log source created with the LSI (log source identitify) as "abc",---> manually created.

    On the log activity tab I have events labeled SIM generic, and the src and dst fields for these events are "abc", Checking the raw logs there attributes are not empty i.e. src=x.x.x.x dst=y.y.y.y unlike the one that was manually created that has src= , dst=.


    Note: searching for the log source on the QRadar log source Mangmnt app using the IP address of the forcepoint device, i can only see the manually created log source.

    Hope i was able to explain it.

    Regards,
    .

    ------------------------------
    benjamin Nworah
    ------------------------------



  • 14.  RE: DSM Parser

    Posted 2 days ago
    Edited by benjamin Nworah 2 days ago
    Hello,

    The events from the two screen shots are from the same Source IP(Which is the Src IP of the forcepoint device), because the Source IP field is the same. The screen shot with event name  "ForcePoint Appliances Message" has raw logs with empty fields like src= , dst=, while the other screen shot with event name "unknown log event" has the raw logs coming with values like src=xxxx, dst=yyy.

    As mentioned both events seems to be coming from the same source IP, which is the IP of the Forcepoint device.

    I dont expect QRadar to parse or mapped the raw log with empty field, but for the other events with "Unkwown log event" as event name and coming from the forcepoint device, with a well structured raw log (i.e. the fields are not empty) it is unclear to me.

    Hope this is clear now.

    Regards,

    ------------------------------
    benjamin Nworah
    ------------------------------



  • 15.  RE: DSM Parser

    Posted 2 days ago
    Screen shots reference the above comments. both records are coming from the same source IP (which is the ip of the forcepoint)

    ------------------------------
    benjamin Nworah
    ------------------------------



  • 16.  RE: DSM Parser

    Posted yesterday
    Hello Benjamin,

    Thank you, I think I understand the problem now. I'm still not sure what the autodetected log source you're referring to is, but my understanding is that:

    -some events from the Forcepoint on IP "abc" are going to your manually-created log source as Stored, these events have empty values
    -some events from the Forcepoint on IP "abc" are going to the SIM generic log source, these events have valid events

    I would need to see the SIM generic events to know for sure, but my guess is that they have an RFC3164 or RFC5424-compliant syslog header with something other than the IP address ("abc") in that header (a hostname, perhaps). As a result, QRadar is parsing that header and extracting whatever identifier value is in it and attempting to route the event to a log source with a matching LSI. Because your manually-created log source has an LSI of "abc", they do not match, which is why the events are going to SIM Generic (any event which can't be routed to a log source defaults to SIM Generic).

    The fact that the Source IP and Destination IP fields for these SIM Generic events are abc is because if source/dest IP values can't be parsed from the payload, the Source/Dest IP fields are defaulted to the IP address from which the event originated, which would be abc in this case.

    It is odd that some events from the device have a valid header with a non-IP identifier in it, but other events from the same device either don't have a valid header or their header contains the IP address. However, we already know that some events have properly formatted LEEF events and others have empty LEEF events, so something is clearly amiss with that Forcepoint device.

    Cheers
    Colin

    ------------------------------
    COLIN HAY
    IBM Security
    ------------------------------