Field and Document level security Integration

[JesseNordin]

Hello

I'd like to ask if there are any future plans on the roadmap to integrate Field and Document level security for the data ingested by Fortinet-2-elasticsearch. We have a UTM with many different customer integrations, the only differentiator being the Security Profile names.

I have seen with some of the dashboards it's possible to filter by these security profiles or even the subnets allocated to a customer but I would like to expand on that and create a "Space" for that customer granting read only access to the needed Indices. I have asked the elasticsearch team on how one can prevent a user from seeing data that's not relevant to them and I was shown the below:

I have however noticed that this option (Grant Access to specific fields) does not exist in our ELK Stack, I'd like to clarify if this is due to the way the data is ingested or is this due to our subscription level (Currently Free and open Basic) ?

General Info: Fortigate Version: v7.0.11 ELK Stack Version: 8.12.1

[enotspe]

you can copy the utmprofile value to namespace.

That is what is cool about all the code being open, you can tweak to your case, which is very very specific. Normally I have seen the use of VODMs for partioning clients.

mutate { replace => { "[data_stream][namespace]" => "%{[fgt][profile]}" } }

[JesseNordin]

Sorry, I'm not entirely sure that I follow,

Are you saying that we could apply this mutation on a per "Space" level while specifying the space and associated fgt profile ?

Or would this be globally applied so that elk can pick up the fgt profiles within the data streams to allow for the options of grant access to specific fields etc

[enotspe]

I was digging a little bit more into alternatives to your request @JesseNordin .

Let me first clarify your setup: you have one firewall with on vdom that receives traffic from many clients. I guess you have them split in several policies, and each policy applies a different UTM profiles customized for each client.

So

Policy1 --> Client1 Policy2 --> Client1 Policy3 --> Client2 . . .

Am I right???

Well, if that is the case, I think the best solution will be to apply a custom field for every policy.

  config log custom-field
      edit "1"
          set name "client"
          set value "client1"
      next
  end

  config log custom-field
      edit "2"
          set name "client"
          set value "client2"
      next
  end

and then apply this custom fields to the corresponding policies

config firewall policy
    edit <policyid-client1>
       set custom-log-fields "1"
    next
end

config firewall policy
    edit <policyid-client2>
       set custom-log-fields "2"
    next
end

that way traffic logs, and hopefully utm logs as well, will have a way to identify your final client.

Then just simply copy that field to data_stream.namespace so you can segment your indexes accordingly

mutate { replace => { "[data_stream][namespace]" => "%{[fgt][client]}" } }

I have not tested any of this code, but I see no reason why it would not work.

Hope this is usefull and please share your results.

[JesseNordin]

Hello @enotspe , yes that's basically it.

We have for example a Large subnet that's been splitted into smaller ones for clients to use.

With each of these smaller subnets there are a set of policies that contain a web filter,dns filter etc and in some cases even destination address groups for filtering.

client1 - policy name, client1-source-subnet -> client1 - webfilter ,client1 - dnsfilter , client1 - appfilter (Here client1 being a unique customer account number)

I think I follow, basically setting a custom value in the fgt and then seeing it in ELK.