7.6.0 vs new signals and futher enrich ingestion

Just updated our cluster to 7.6.0 and are wondering where to read up on utilizing the new SIEM signals and if needed how to do further ingestion enriching to enhance signals eta.

Currently got winlog(+sysmon) and audit beat data ingesting from Windows Assets enriching with geo data in ingest pipelines.


Signals view from SIEM overview page seems to not known about which indices to look in:

Hi stefws,

Thanks for the screenshot. That is looking like an interaction bug somewhere we have. We create the siem signals index when you first click the detections tab and then navigate to the "manage signal detection" page by clicking the button.

That should hopefully make things right and only a one time thing. I think we just forgot one or two first time visiting places to initialize it (such as that page) as a lot of people were working on things concurrently during the development cycle and what you're seeing is a bug.

For docs, we have a lot here at the moment that hopefully helps you out:


I have been able to reproduce it and this should be just a one time issue you're seeing on first page loads until you make your way to the "manage signal detection rules" page where it will initialize the siem signals index.

Issue if you want to track it:

Right thanks, assume it requires a License, currently still only on Basic License :confused:

Will dig into doc link...

Ah I need further permission properly to enter Detections... only in order to be able to launch 7.6.0 kibana I needed to removed this config key:

#7.6.0 dont like this key#xpack.encrypted_saved_objects.encryptionKey: <redacted>

otherwise kibana would start :confused: Get this error on launch with encryptionKey defined:

tail -f /var/log/kibana/kibana.log:
{"type":"log","@timestamp":"2020-02-14T09:40:01Z","tags":["info","plugins-service"],"pid":16961,"message":"Plugin \"case\" is disabled."}
{"type":"log","@timestamp":"2020-02-14T09:40:05Z","tags":["warning","legacy-plugins"],"pid":16961,"path":"/usr/share/kibana/src/legacy/core_plugins/expressions","message":"Skipping non-plugin directory at /usr/share/kibana/src/legacy/core_plugins/expressions"}
{"type":"log","@timestamp":"2020-02-14T09:40:05Z","tags":["warning","legacy-plugins"],"pid":16961,"path":"/usr/share/kibana/src/legacy/core_plugins/kbn_doc_views","message":"Skipping non-plugin directory at /usr/share/kibana/src/legacy/core_plugins/kbn_doc_views"}
{"type":"log","@timestamp":"2020-02-14T09:40:05Z","tags":["warning","legacy-plugins"],"pid":16961,"path":"/usr/share/kibana/src/legacy/core_plugins/metrics","message":"Skipping non-plugin directory at /usr/share/kibana/src/legacy/core_plugins/metrics"}
[root@kibana6 ~]# tail /var/log/messages
Feb 14 10:40:06 kibana6 kibana: FATAL  Error: Unknown configuration key(s): "xpack.encrypted_saved_objects.encryptionKey". Check for spelling errors and ensure that expected plugins are installed.
Feb 14 10:40:07 kibana6 systemd: kibana.service: main process exited, code=exited, status=64/n/a
Feb 14 10:40:07 kibana6 systemd: Unit kibana.service entered failed state.
Feb 14 10:40:07 kibana6 systemd: kibana.service failed.

Ah spelled differently xpack.encryptedSavedObjects.encryptionKey, this works to launch kibana at least, will investigate permissions further...

1 Like

Okay, then it created the .siem-signals-<space> index but to be able to load rules it seems I need to enable API keys:

{"type":"log","@timestamp":"2020-02-14T09:52:32Z","tags":["error","plugins","security","api-key"],"pid":17120,"message":"Failed to create API key: [illegal_state_exception] api keys are not enabled"}
{"type":"error","@timestamp":"2020-02-14T09:52:32Z","tags":[],"pid":17120,"level":"error","error":{"message":"[illegal_state_exception] api keys are not enabled","name":"Error","stack":"Error: [illegal_state_exception] api keys are not enabled\n    at transformError (/usr/share/kibana/x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/utils.js:24:14)\n    at handler (/usr/share/kibana/x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/add_prepackaged_rules_route.js:84:16)\n    at process._tickCallback (internal/process/next_tick.js:68:7)"},"url":{"protocol":null,"slashes":null,"auth":null,"host":null,"port":null,"hostname":null,"hash":null,"search":null,"query":{},"pathname":"/api/detection_engine/rules/prepackaged","path":"/api/detection_engine/rules/prepackaged","href":"/api/detection_engine/rules/prepackaged"},"message":"[illegal_state_exception] api keys are not enabled"}

Okay, this took me most of today to convert http to https for all Elastic Clients (kibana/grafana/log stash/beat instances) in our production cluster. Will dig further next week on how to activate the API-key API...


Glad you got through most of that. The cloud deployments are all configured with security in mind and so that is honestly the easiest way to get and stay setup for the Elastic Stack. Nothing wrong with on prem deployments, just mentioning the cloud deployment self managed model does the configuration steps automatically since it is already behind things like https.

The https/TLS, API Key setup, and encryption key setup should hopefully make sense as when you are creating SIEM rules and they run even when you are no longer logged in they use API Keys under the covers. Because it uses that mechanism it is going to need the other security mechanism turned on.

This part of the docs might help out more where it explains more in depth parts of permissioning:

Okay, after converting to https between all cluster-internally elastic clients (externals clients was/are terminating TLS on a HAproxy cluster, load balancing across ingest/logstash nodes) and our elastic cluster. I now could load the 92 elastic signal detection rules, which each created their own never-expiring API key :slight_smile:

Thanks, will read up on the detection engine to understand it's inner workings better...

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.