Comments (8)
I would expect something like event.action
for this use case!
from ecs.
We'll have to try some things and see how they go. I'll try to keep you posted.
from ecs.
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"
},
...
}
}
from ecs.
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?
from ecs.
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.
from ecs.
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.
from ecs.
@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.
from ecs.
Housekeeping: closing this, as event.action
should do the trick. Please reopen or open another issue if that's not the case :-)
from ecs.
Related Issues (20)
- [Discuss] `ignore_above` on `flattened` fields
- [ci] Pipeline should fail if schema contains invalid field types
- field collisions with organization.id & elastic maintained integrations
- [RFC] Support id in threat.indicator for STIX 2.1 HOT 6
- Create equivalent of ecs-dotnet and ecs-typescript for java
- new field set: for log documents themselves
- Clarify the type of container disk and network metrics HOT 1
- ECS Vulnerability Published field
- Add threat.indicator.tags field
- [Proposal] Make event.kind a list HOT 3
- Incorrect generated/beats/fields.ecs.yml, not accounting on top_level: false HOT 1
- [ECS] Addition - http.request.header.bytes & http.response.header.bytes HOT 2
- Add lowercase normaliser to ECS fields which support security incident response process
- Mark experimental fields as `beta` in generated files
- Elastic-Agent Integrations Use of Legacy Mapping Types Impacts .fleet_globals & prevents agents from being upgraded
- Add `related.url` field
- Add event.zone and event.environment fields
- Addition of additional allowed values for event.type
- Support cloud events in schema HOT 1
- Better abstraction of the type event.kind: alert
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ecs.