All Apps and Add-ons

Splunk Add-on for Cyberark XSL file is faulty?

FrankVl
Ultra Champion

Can someone explain to me what the idea is behind some of the choices made in the XSL file that is bundled with the Splunk TA for Cyberark?

It places the Cyberark "Reason" field in both the cn2 part of the CEF message as well as the msg part. Even though cn2 is actually labeled "Ticket ID". Also: in the msg part, the Reason value is passed through a replacer that escapes any '=' signs, to prevent issues with Splunk's field extractions. While in the cn2 part, the reason field is dumped without escaping. So if the Reason field from Cyberark contains key value pairs, this completely messes up the field extractions. Why duplicating data and moreover: why doing it in an inconsistent way?

Relevant snippet from the xsl:

cn2Label="Ticket Id" cn2=<xsl:if test="/syslog/audit_record/Reason != ''">"<xsl:value-of select="Reason"/>"</xsl:if>  msg=<xsl:if test="/syslog/audit_record/Reason != ''">"<xsl:call-template name="string-replace">
            <xsl:with-param name="from" select="'='"/>
            <xsl:with-param name="to" select="'\='"/> 
            <xsl:with-param name="string" select="Reason"/>
        </xsl:call-template> <xsl:choose><xsl:when test="Severity='Critical' or Severity='Error'">Failure: </xsl:when></xsl:choose>"</xsl:if>

Also, this final bit with the severity choice, does this print the text "Failure:" after the content of the msg field? What is the point in that? Shouldn't that be printed at the start of the msg field?

The original arcsight.sample.xsl as bundled with cyberark (that probably was the inspiration for the file bundled with the splunk TA) does not use the cn2 field, and populates the msg field in a more sensible way: "Reason, ExtraDetails, Failure: Message" (with Failure printed only based on severity).

msg=<xsl:call-template name="string-replace">
    <xsl:with-param name="from" select="'='"/>
    <xsl:with-param name="to" select="'\='"/> 
    <xsl:with-param name="string" select="Reason"/>
  </xsl:call-template>, <xsl:call-template name="string-replace">
    <xsl:with-param name="from" select="'='"/>
    <xsl:with-param name="to" select="'\='"/> 
    <xsl:with-param name="string" select="ExtraDetails"/>
  </xsl:call-template>, <xsl:choose><xsl:when test="Severity='Critical' or Severity='Error'">Failure: </xsl:when></xsl:choose><xsl:call-template name="string-replace">
    <xsl:with-param name="from" select="'='"/>
    <xsl:with-param name="to" select="'\='"/> 
    <xsl:with-param name="string" select="Message"/>
  </xsl:call-template>
0 Karma

koshyk
Super Champion

The whole purpose of the xsl is to work with the TA. So once you apply the xsl, the messages are expected as per the examples provided in the "samples" director of the TA.

For example For your 1st Query, the message sample is something like. (from sample.cyberark.epv)

Jul 27 23:34:06 VAULT CEF:0|Cyber-Ark|Vault|9.20.0000|308|Use Password|5|act="Use Password" suser=##USER_NAME## fname=Root\x_admin dvc=10.0.1.12 shost=##SOURCE_IP## dhost=##DEST_IP## duser=##DEST_USER_NAME## externalId= app= reason= cs1Label="Affected User Name" cs1= cs2Label="Safe Name" cs2="Domain Admin Accounts" cs3Label="Device Type" cs3="Operating System" cs4Label="Database" cs4= cs5Label="Other info" cs5="10.0.1.12" cn1Label="Request Id" cn1= cn2Label="Ticket Id" cn2="(Action: Connect)"  msg="(Action: Connect)"

The reason the Addon is trying to make is a "key-value" pair of itself hereby trying to achive something like "Ticket Id" = "Action: Connect". Said that I also don't like this method, but I hope there will be TicketId value within the "action connect" in real-world !!

Regarding the "failure" message, the sample is

Jul 27 23:35:40 VAULT CEF:0|Cyber-Ark|Vault|9.20.0000|4|Failure: User Authentication|7|act="User Authentication" suser=##USER_NAME## fname= dvc=10.0.1.12 shost=##SOURCE_IP## dhost= duser= externalId= app= reason= cs1Label="Affected User Name" cs1= cs2Label="Safe Name" cs2= cs3Label="Device Type" cs3= cs4Label="Database" cs4= cs5Label="Other info" cs5="10.0.1.12" cn1Label="Request Id" cn1= cn2Label="Ticket Id" cn2=  msg=

As you said, it is pointless as the "act" field gives the reason code.
by the way, We are sticking to "arcsight" format and we have written TA of our own 🙂

0 Karma

sumitkathpal292
New Member

@koshyk can you share your add-on , rather than me spinning new wheels.

0 Karma

FrankVl
Ultra Champion

Yeah, and that works fine (although pointless to have the same string in 2 CEF fields) when it says "(Action: Connect)". But when for instance the Cyberark 'Reason' field contains something like "(TicketID = 1234567)(System = Servicenow)", it fails horribly due to how the CEF extractions in the TA work. It will actually take "(TicketID = 1234567)(System" as a field name and "Servicenow" as its value.

Which is why in the msg field, any = characters are escaped to \=, to prevent these messed up field extractions. What I don't understand, is why the same data is dropped into the cn2 field without escaping it.

Also regarding the "Failure" part: you example doesn't show the issue, because there the reason was empty. If there is a reason and severity is Critical or Error, the Splunk provided XSL file will print the "Failure: " part behind the reason at the end of the msg field. For example: msg="Invalid userFailure: " instead of msg="Failure: Invalid user"

Note: I'm not so much looking for a solution. I've already rewritten the XSL file to resolve these issues, but I was mostly looking for confirmation / comments on how this XSL file came to be and whether my understanding of how broken it is, is correct (and whether anyone else has been running into this).

0 Karma

sumitkathpal292
New Member

@FrankVl : Help required, i am facing the find of same issue .

2019-06-21T00:44:58Z Testserver CEF:0|Cyber-Ark|Vault|10.2.0000|295|Retrieve[password|5|act="Retrieve] suser=PasswordManager fname=Root\Operating System-mysystem dvc= shost=10.2.1.8 dhost=helloworld.int duser=cyberadmin externalId= app= reason= cs1Label="Affected User Name" cs1= cs2Label="Safe Name" cs2="P-DomainAdmin" cs3Label="Device Type" cs3="Operating System" cs4Label="Database" cs4= cs5Label="Other info" cs5= cn1Label="Request Id" cn1= cn2Label="Ticket Id" cn2="CPM internal process" msg="CPM internal process"

|Retrieve[password|5|act="Retrieve] = splunk is unable to parse.

Can i get the update xsl file to get the correct information into splunk and right tagging is done.

0 Karma

FrankVl
Ultra Champion

That's a different issue and the changes I made to the XSL are not going to help you there. No idea what those [ ] are doing there. Is this a newer version of the XSL with a new bug in it perhaps? You'd have to dig into the XSL to figure out why and how it is printing those [ ] characters there and see if you can fix that.

0 Karma

sumitkathpal292
New Member

@FrankVl thanks, no happy with splunk team they are unable to update the add-on from past 5 years.

0 Karma

marycordova
SplunkTrust
SplunkTrust

a ticket should be opened with CyberArk if they are putting something that is not numeric into a cn* field

the whole purpose of those fields is to supplement the schema with custom fields for values that don't neatly categorize into something else, but if it's really just a rename of the msg field then I would suggest just killing that entire extraction

also...maybe you could post your TA...I find customers (like me) are sometimes better at parsing and understanding the data than the vendor itself 😛

@marycordova
0 Karma

FrankVl
Ultra Champion

Cyberark is not defining what is put into the cn2 field. The XSL file (shipped with the Splunk TA!) determines how Cyberark datafields are mapped to the CEF message. And the XSL file puts the Reason string into the cn2 field (and into the msg field).

0 Karma

marycordova
SplunkTrust
SplunkTrust

regarding cn2, this stands for "custom number 2", so the value here should output as numeric

from the snippet you provided, it looks to me that it is not populating cn2 with the same value of msg but is using this as a conditional check to determine what to populate cn2 with

could you post some samples of the data showing the fields cn2 and msg (as well as any other fields relevant to the remainder of your question and the _raw)

@marycordova
0 Karma

FrankVl
Ultra Champion

It just checks whether the reason field is empty and if not, it puts the Reason into the CN2 field. Then for the msg field, it does the same check whether reason is empty and if not, it passes the Reason field through the string replacer function to replace = by \= to populate the msg field.

0 Karma
Get Updates on the Splunk Community!

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...

What’s New in Splunk Security Essentials 3.8.0?

Splunk Security Essentials (SSE) is an app that can amplify the power of your existing Splunk Cloud Platform, ...

Let’s Get You Certified – Vegas-Style at .conf24

Are you ready to level up your Splunk game? Then, let’s get you certified live at .conf24 – our annual user ...