Discussion Topic: Verbs

[ave19]

We're attempting to adapt our feeds to ECS to try it out. So far, so good when it comes to identifying the Nouns in the events, but we're struggling with the Verbs.

If a firewall (covered) blocks traffic, some source IP (covered) some dest IP (covered) on such and such ports (all covered) at some time (covered), I get to what happened: REJECT

Where does that go...

I see the http now and I'm thinking, maybe we could abstract that and use it for other services? Maybe service is that abstraction?

{ 
  "service: {
    "name": "httpd",
    "verb":  404,
   ...
}

{ 
  "service": {
    "name": "firewall",
    "verb": "reject",
   ...
}

That doesn't feel exactly right... but I feel like we need something like that. Anyone else thinking about that?

Whether it was an authentication failure (or success) for ssh, or a firewall blocking something, or whatever... something is happening in those logged messages. I want to capture that part.

I feel like making tags for every service is the wrong path, I'm not sure what to do. :-\

Thanks for listening anyway :D

[ave19]

Because service is a noun in some contexts, what if we just had application as a container for things like httpd, su, ssh, firewalld, etc etc.

{ 
  "application": {
    "name": "httpd",
    "response": {
       "status_code": 404,
       "body": "Hello world"
    },
   ... 
  }
}

[praseodym]

I would expect something like event.action for this use case!

[ruflin]

I've been thinking about this quite a bit and this is one of the main challenges of ECS. What should be abstracted out and what not.

Let me explain it on an example. The http and the cassandra protocol both have a response object. Should there now be global response object with the common values or should each be under it's own prefix. My conclusion so far is they should be under their own prefix because it is highly unlikely that someone wants to correlate the response data from cassandra and http protocol as it has a very different meaning.

The next question is should http and cassandra both have a definition in ECS. For http I think the answer is yes as the usage is so wide spread. For cassandra I'm not so sure. It could be covered in an extended version of ECS.

Also I think there are cases where the original field should be kept but still allow ECS queries. Here I hope in the future Alias Types in Elasticsearch will come into play: elastic/elasticsearch#30230

Getting back to the original problem. @ave19 is all your traffic http. Then so far I would put it under the http prefix? If we need to go beyond http I like the idea of event.action or similar.

For the service / application proposal: What is the difference from your perspective between service and application in this context?

[ave19]

Ha! @ruflin posted while I was typing!

@praseodym That really got me thinking, too. FOR DAYS!

@ruflin Difference between application and service: I didn't want my example to collide and bring preconceived notions to the party, so I picked a different word to keep it open, but service would be totally fine.

@everyone I like the idea of event.action to consolidate concepts like this network exchange did not happen determined by an http status of 403, or a firewall REJECTing something. That rejection is kind of a meta-concept. But that doesn't feel like a good place to record the actual REJECT part of the original event. I'm going to pull that REJECT out so we can filter on it.

I think having an http tag is probably going to be OK if we think of it as a protocol and would be where you put apache and nginx logs. Status 403 has the same meaning for those services because HTTP is a protocol. That would keep us from needing a tag for every application in the universe. (Probably the original intent, right?) Even a python script that's doing HTTP would have a home. Like @ruflin says, http is pretty ubiquitous and probably deserves it's own tag. Maybe other protocols do to? Like SSH? I have those in my syslog and parse them out so I can see who's trying to log in from where, etc.

I'd be happy making firewall fields fit under service. I don't see anything in service like service.port that would make me think it's a running service listening for connections kind of service. I could put { "service": { "name": "firewall" }} or maybe type, and fill in custom things. Setting the name or type would let me add that to Query DSL to make sure my "action" values don't collide with other services.

[ave19]

I just thought of an example: If you're doing cyber defense, you may want a consolidated way to track if one of your systems is experiencing a large number of rejections as a meta-concept, as you might record in (and filter on) event.action. Attackers might try all your doors and windows, so you might see rejects from HTTP, or TCP wrappers, or failed login from SSH, etc., etc. All of those could be event.action failures. Failures specific to the protocols I think need to be recorded somewhere else specific to the protocol. Because then, I can have a script that looks for certain things in say an SSH message and does an _update API call to set event.action to whatever that message means. If that makes sense.

[ruflin]

@ave19 I like the approach on taking specific use cases and base new fields on it. I agree that ssh and tcp will probably have their own prefix and also TLS as you can see here: #6

It seems event.action would do the job. Anyone wants to open a PR with it?

@ave19 One more note for the firewall: In case it's a hardware firewall, there is also device.* that you could use. But also on this device in the end a service is running.

[ave19]

We'll have to try some things and see how they go. I'll try to keep you posted.

[webmat]

Housekeeping: closing this, as event.action should do the trick. Please reopen or open another issue if that's not the case :-)