I’m looking at the way parser config works, and transformation of field from 
their native names in, for example the ASA or CEF parsers, into a standard data 
model. 

At the moment I would do something like this: 

assuming I have fields [ipSrc, ipDst, pointlessExtraStuff, message] I might 
have:

{
  "fieldTransformations": [
    {
      "transformation": "STELLAR",
      "output": ["ip_src_addr", "ip_dst_addr", "message"],
      "config": {
        "ip_src_addr": "ipSrc",
        "ip_dest_addr": "ipDst"
      }
    }
  ]
}

which leave me with the field set: 
[ipSrc, ipDst, pointlessExtraStuff, message, ip_src_addr, ip_dest_addr]

unless I go with:-

{
  "fieldTransformations": [
    {
      "transformation": "STELLAR",
      "output": ["ip_src_addr", "ip_dst_addr", "message"],
      "config": {
        "ip_src_addr": "ipSrc",
        "ip_dest_addr": "ipDst",
        "pointlessExtraStuff": null,
        "ipSrc": null,
        "ipDst": null
      }
    }
  ]
}

which seems a little over verbose. 

Do you think it would be valuable to add a switch of some sort on the 
transformation to make it “complete”, i.e. to only preserve fields which are 
explicitly set. 

To my mind, this breaks a principal of mutability, but gives us much much 
cleaner mapping of data. 

I would propose something like:

{
  "fieldTransformations": [
    {
      "transformation": "STELLAR",
      "complete": true,
      "output": ["ip_src_addr", "ip_dst_addr", "message"],
      "config": {
        "ip_src_addr": "ipSrc",
        "ip_dest_addr": "ipDst"
      }
    }
  ]
}

which would give me the set ["ip_src_addr", "ip_dst_addr", "message”] 
effectively making the nulling in my previous example implicit. 

Thoughts? 

Also, in the second scenario, if ‘output' were to be empty would we assume that 
the output field set should be ["ip_src_addr", “ip_dst_addr”]? 

Simon

Reply via email to